Thinking Like an Architect

In modern software development, we changed the way how we were used to design software. But the real challenge is now developers have way more things to think about. Think about the DevOps part, the architecture, security, and so on and so forth. This shift left movement started to kick in very aggressively towards developers, and now they need to cover a variety of tasks.

The challenge with architecture is that very often people think that architecture is nothing more than selecting the right tech stack or the most bleeding-edge tech stack. Unfortunately, this is wrong. Because the reality is that architecture is composed by three simple things. You take some decisions based on the context and the information that you have, then you need to balance the trade-offs regarding the decision you need to make, and finally, dealing with consequences. Because the reality is, architecture is not something you decide and then you forget about that. You need to live with that for a long period of time very often.

Therefore, architecture is not defined as a title, in my opinion, but like a mindset. If you have the architect role inside your job title, you might or might not represent a good architect. During this talk, I want to share with you 11 tips that I learned in the trenches in the past 22 years. My name is Luca and I'm working currently for AWS. But in the past, as you can see, I have done quite a few roles that started from a simple developer up to a CTO and everything in between. I had the pleasure to work with a large organization, Unicorn, companies that move from zero to millions of customers and stuff like that.

I believe that these 11 insights will help you to rethink how architecture should be thought inside your system. Let's start first with the problem space. We need to understand that. In modern architecture, one thing that changes is the decentralization part because we are not decentralizing anymore, just the practices, the engineering practices to multiple teams that are working on a specific area of the system, but also the organization. But for the vast majority of the time, the organization is an afterthought. We think that with a simple architecture like microservices or a self-based architecture, whatever, we solve all our problems. That's not the case. The second problem is that we focus a lot on the technology. We ignore the business needs and we focus on what we are passionate about, writing code or building with the latest cloud service. And lastly, we ignore our context, what the business needs. So what are the technical skills inside our organization and how our organization is structured and so on and so forth. Our context is the king here because if we design something that helps our context to thrive, then therefore we are in a good situation.

So let me start with a few tips that I learned in the trenches in the past 22 years. So first of all, you need to remember that architecture is linked, directly linked to engineering culture and organization.

Something as simple as selecting a monorepo versus a polyrepo approach will basically shape the way how your teams are communicating together. And that's not something that you can underestimate. Very often people think that it's just a technical decision. The reality is you are basically defining how your teams should work, maybe using trunk-based development. Do they have the skill for doing that or how much friction you will create inside the trenches and also how they are going to communicate. Because sharing with the monorepo is different from sharing with the polyrepo approach and so on and so forth.

So never underestimate a technical decision to think that is just living in that realm. The other thing that you need to think about is understanding what your product or business needs. This is the first point for me. And very often, either that you're working in a Greenfield project or a Brownfield project is underestimated. It's extremely important we understand what kind of KPIs do we need to track? What is the benefit of this feature for our users? Why we are doing that? What is the minimum valuable product that they can deliver as soon as possible in order to gather information from the users?

There are two techniques that I usually use with customers now with AWS but before also in my company. One is a collaborative workshop called event storming that drags a bunch of people inside the same room and starts to take a step back from technology and looking on the business and how your users will behave inside the system. The other one is domain storytelling, very similar but with different approach where we tell a story and we explain how our users are going to interact with our system. But both of them have something in common. They don't need to talk about technology that at the beginning is not needed. You need to understand what you need to express inside your system.

And that leads us to the second tip. So start with boundaries. When you understand how the system works then you start to think about how your boundaries look like. Domain driven design is phenomenal on that because usually it helps to create a common vocabulary between product and engineering. But more importantly, when you identify through event storming on domain storytelling the different boundaries that your system is composed to or your feature is composed to, you can start to categorize them. You can define what is core, so the most important things inside your system. What is supporting that helps core to thrive and what is generic. Let me give you an example. So if we take Netflix for instance, a core domain for Netflix, so the reason why Netflix exists is allowing you to watch your favorite series in any device and at any given point of the day. The supporting domain, for instance, could be personalization. And personalization means that if I have a catalog that is the core domain and I have a personalization, yeah, I can have a better experience. But the reality is if the personalization service is down, I can still watch the catalog, I can still search. So it's not too bad. So I can immediately start to apply characteristics to supporting domains.

That is the same for generic. In order to consume video on Netflix, you need to subscribe. And in order to subscribe, you need to pay a fee with, I don't know, PayPal, my credit card or whatever other payment method that you want. Netflix is not a payment gateway, but they leverage an integration in order to do that. That is a generic domain that does not add any value to Netflix itself, but the reality is it's needed in order to have the Netflix service available to you.

Moreover, remember, if you're working on a brownfield project, you need to also revisit regularly your boundaries, because your business is evolving as well as your architecture. Because the reality is that if you ignore that the business is taking a direction and then you start to arise friction in the trenches, you cannot blame the architecture. So you just need to revalidate that the boundaries are still valid in the way and the form that the company wants to go. The other thing is that you need to, as a third part, you need to identify your architecture characteristics.

Because very often, I speak with companies and teams that are starting to ask, oh, look, what do you think about this? It's like, perfect, so let's try to understand what you need to express here. What are your security requirements? What is your SLA? Are you affected by latency? And so on and so forth. Let me give you an example. So if you think about latency, for instance, if you're working on, I don't know, a financial system that deals with the stock market, definitely latency matters. You cannot design something that has a lot of hops between the network in order to increase the latency. Probably you need to think about co-locating certain things. And there are some interesting case studies that shows that for specific things where latency is mandatory, we need to design things differently.

While I think about another requirement, like for instance, the availability, you need to think about how many nights you want. Because the reality is designing a thing with, I don't know, three nights of availability, it means that you are going to have a certain more or less an hour of potential downtime inside your system. Is it acceptable or is not? And if it's not, you need to think about using a multi-regional strategy. So those kind of decision or architectural characteristics that you need to implement inside the system are mandatory to understand because otherwise you cannot design properly your system. There are certain things that will be immediately filtered out when you have clarity on your architectural characteristics.

Now, the other thing when you have done that is understanding how you could modularize your system. So there are different techniques in architecture, right? So we can start with monolith, modular monolith, or microservices, or even a self-based architecture. And all of them are not right or wrong. We need to stop this fight thinking, oh yeah, microservices are not great for this reason, that reason, that reason, or monolith are for the past. There are situations where you need to optimize, for instance, for retrieving, gathering feedback fast from your users. And maybe a monolith could be the answer. There are other situations where your context tells us that you need to have multiple teams working together, but they cannot always depend on each other. So you want to reduce external dependencies. And therefore, in order to express that, you might use a microservice architecture.

So when you think about how granular you want to go, and that is not only for the design of the architecture, it could be also the code wise, start to think about what is the rate of change of a specific feature. If you have a feature, for instance, that you know that there is a high rate of change at the beginning because you need to build from scratch, but then they are going to change once or twice per year. So the for is keeps the lights on on this feature. Then probably you can even allow you to co-locate more, while on the other side, if you have something to change very often, you might need to think very well on the way how to encapsulate your service. So you can change independently, reducing, not eliminating the external dependencies and start to, let's say, work more on fast iteration. And as you can see now, the idea of I have a modular monolith or microservices doesn't add up too much because you don't have to be, let's say, to follow a specific path. And when you decide one thing, you only use that path. It has to be, let's say, slightly more fluid.

Be pragmatic and not dogmatic. Because I give you this example. So imagine that you are working in a system that is, by design, event-driven architecture. So there is a service that you see at the top that is communicating through an event to a system that is sending email and SMS and push notification to all your customers. Now, when you think about the implementation of this service, you can have like a bit of compute, container, serverless, wherever you want. And then you store in a database when you need to notify this user. And maybe you can decide now that through a technique that certain databases have that are called CDC, you can trigger when, let's say, a record expires or changes and start to trigger a specific event for saying, OK, send to the push notification or better send an email. Now, if you think about that, the trade-off here would be that I'm leveraging more the infrastructure and me, as a developer, I have a lot of free time to do something else. That could be a decision that you want to take in this case, right? But at the same time, what happens about scale? So if I have like 100 messages, that's fine. So I send like 100 messages and then I will store 100 record in a database. And then for CDC, I will send 100 times this information to a third party or another service for sending the push notification or email. But what if I have 10 millions? And now it's starting to get slightly more complicated. So I need to rethink my system. If I have 10 millions, it means that probably I can look into how I can optimize cost, but at the same time having the same benefits.

Because if you send a push notification at the end of the day, if you send at the top of the hour or 10 minutes late, no one will complain in certain cases, obviously, if there are certain scenarios that it needs. But let's assume that it's not in this case. And then you can start to think about, for instance, using a cron job. And then every 10 minutes you take the last, I don't know, a certain amount of messages that you need to send and then start to send out. Now, what is the challenge, though? That? Yes, probably the infrastructure will be cheaper. But at the same time, your costs start to raise because you need to write the code, maintain the code, update the code and so on and so forth. You are not a free resource.

You are not a free resource. And when you think like an architect, you need to think holistically about the plan. Both approaches can work. But the context will drive your decision.

Now, the other thing that you need to think about, even in the previous example, our change in a situation like that would be minimal because we want to have an evolutionary mindset when we are designing our system. The only two constants in architecture are changes and tradeoff. And the funny part for me is that very often I heard, oh, yeah, because we have always done it this way from certain teams.

But unfortunately, you cannot fight that. You need to embrace this because this is what the company wants to have. And we need to think about our users, our customers, because that is the only priority. Our users are the people that are basically buying. They don't care if you have a self-based architecture behind the scene or a monolith. What they care about is they can accomplish a specific task. And therefore, your job is not building the perfect system. We're not here to use only the most amazing technology ever, is to instead help our customer to reach a specific goal. And here the balancing act that we need to do when we think like an architect.

So what is the long term vision? What is the immediate needs? There are certain situations that happened to me several times where, for instance, I had to integrate and import a bunch of more or less like half a million users from one platform to another platform. Now we could do the right things or we can do let's say the immediate and scrappy way. And we went with the scrappy way for one reason, there was a key constraint, there was a deadline for the beginning of the football season and then surprise and you cannot move it. And therefore, yes, I bargain with the business that we will do the quick win. But at the same time, right after we start to work on the long term implementation, because those are the things that you need to deal with tradeoffs, as we said before.

And very often when you do this kind of decision, you need to take a lean mindset. So take the best decision that can at the last responsible moment. And I can guarantee you that if you stay in the procrastination mode, the starting to think or need to gather more information than they need more information, you are going to in a rabbit hole that they are not going to move the final decision too much. When you have enough, you can start to change. And if you use an evolutionary mindset, you can evolve over time.

So therefore, as a developer or tech lead, what you need to do for me, for thinking like an architect, are three things. So the first one is you need to have a great understanding of your domain. At the end of the day, you're working inside your domain. But you need also to understand your consumers, that is something that they didn't see very often. What do they want? What kind of new features are building? Do they want me to design an API? Better stuff like that. And finally, you need to have a bigger understanding of the system. If you start today in a new company and you want to start understanding your system going this direction, because when you have an holistic idea of the system, you can take better decision inside your domain. But you don't have to rush into that. You need to master first what is closer to you and then you take, let's say, a more holistic view step by step.

Then the other important things that every architect should have is communication. But not only that. Inclusion and documentation. Those three things for me are at the core of architecture skills.

Back in the days when I didn't have the air, but my beard wasn't too white, communication was called a soft skill. But big spoiler, it's not anymore because the reality is that if you're not able to communicate how you can influence how to design a specific system, the for for me, communication is a core skill.

When I was VP of architecture, one of the key things I was saying to my team is that 70 percent of their time, they should create bridges with the teams and empathy with the teams in order to understand how the things are working. And instead, 30 percent of the time, they should be technical because of their role of an architect is not only writing code or, let's say, thinking about themselves or how to apply the next pattern is understanding the social technical aspect that is basically behind every single system out there.

Therefore, you need to understand how to change your language accordingly. If you are a tech lead or you are a lead on a side of the team, the way how you are talking with your peers and the way you are talking with the C-suite in order to communicate exactly the same message has to be different. The C-suite don't expect to have too much technical jargon. But what they expect is that they understand the business value. So your role as a lead is shifting the gear and transform what is, let's say, a technical implementation into something that the business can understand. And that will enable you to be a more effective communicator.

But more importantly, you will be, let's say, an asset for your company. Now, the other thing that you need to remember when you're when you're talking with your peers is that you don't have to provide always solution. You need to share your reasoning because you in order to arrive to a certain decision, you pass through a certain steps and you have a certain background that other people might not have and probably won't have. But if you are capable to say, OK, so instead of saying this is the solution, period, you start to say, OK, so if we're doing this way and then we're doing that way and then we're doing that way, we arrive to the same solution. Yes, it's taking slightly longer, but everyone will be on board and everyone will support you. More importantly, they can plug into the journey or your train of thoughts properly in order to augment your final decision.

The four four activities that you need to think about when you are thinking about documentation and train of thought and stuff like that is. So first of all, architectural decision record, write it down, because when you write, your brain starts to connect and starts to understand better the problem space and the solution space. Therefore, writing down why certain decisions were made. Requests for comments are perfect for communicating with your peers and also with other teams, the consumers that we mentioned before, in order to evolve your system. Sequence diagrams, I found them super helpful when you are talking with teams, especially if you are a tech lead or whatever, because they are clear to the spot and they describe a portion of the system very in detail. Then you can use other type of diagrams like C4 model. For instance, I'm a big fan of to describe the system end to end from the highest level to the more deep level. And last but not least, there is no excuse anymore to not understand architecture as code. So stuff like Merrimel JS, for instance, is a great asset for designing diagrams through code. So I highly encourage you to master this stuff because that will enable you to include not only the people that have a voice, but also the people that might have a voice, but they are introverts or they are people that are not used to perform very well in front of other people.

Maybe because of lack of seniority or personal things. And instead, if you allow everyone and democratize basically the possibility to provide wisdom and the voice that you will be able to, thanks to these asynchronous communication approaches.

Finally, my 11th tip is to focus on what really matters. One day my CTO told me, remember, Luca, everything is on fire all the time. And since then, I stick it in my head and never forget it because that's the reality. You cannot distinguish every fire, but you need to understand where the real value lies. Therefore, if you are capable to understand, OK, what is how I can move the business needs better if I do this or if I do that. It's basically your role when you are thinking like an architect, because the reality is everyone has something that doesn't work, but not everything is important for the company.

Remember, at the beginning, when I was talking about domain driven design categorization of the subdomains. So core supporting that is your guide that will help you to focus on what really matters. Therefore, don't be afraid to create technical depth that is strategic. So saying and I've done that plenty of times, this part, yes, I'm fine that we are scrappy there. But this part has to be extremely polished, has to perform because the business value is different.

Finally, the best architecture are not the ones that. Stop here is the last slide, sorry about that. I start again. Finally, remember that the best architectures are the ones that are adaptive, not the ones that last forever. That's all I got. I hope that you enjoy that you take some of these tips with you in your next project and enjoy the rest of the conference. I hope that it was helpful and feel free to reach me out anytime.