Transcript
Thomas Betts: Welcome to leveling up your software architecture game. If you ask most people, outside of software folks, for examples of architecture, they point to famous buildings. There's plenty of them around London, for example.
Architecture in that traditional sense, has a shared collective understanding. If you asked for examples of software architecture, you'll probably get a shrug from people outside the software community, and even within the software community doesn't have a clear answer. Sure, we have diagrams, but that's like pointing to the blueprints of the building, rather than the building itself. Because we can't see it, we can't see the software, software architecture is harder to define.
If software architecture is harder to define, that means the role of a software architect is also not clearly defined. Imagine you're at a party and someone says, what do you do? Somebody introduces themself as an architect. You're like, I know what they do. They design buildings and places for people to live. They say, what do you do? You say, I'm a software architect. You get a, ok, smile and a nod. Maybe they sip their drink as they try and figure out how to talk to you. Nobody quite understands it. That's why I sometimes go with the same definition my mother uses, which is, he does something with computers. That's accurate.
Now that I've established that there's no clear definition for either software architecture, or software architects, how can we come up with a game plan to level up our software architecture game? The challenge is, we need to get to the fundamental skills of what is needed to be a software architect. Then once we understand those low-level requirements, we can find ways to improve upon them, and use them as building blocks to establish a framework for next level software architecture. Architects love to create frameworks.
Background
I'm Thomas Betts. I'm the lead editor for architecture and design at InfoQ, and a cohost of the InfoQ podcast. Much of what I'll be talking about comes from the experts that I've interviewed and the articles I've edited over the years for InfoQ. One of the core values of InfoQ and QCon is information Robin Hoods. This is a chance to take that knowledge and share it much more broadly.
My day job, I'm an application architect at Blackbaud, which is the leading software provider for the social good community. If you haven't heard of Blackbaud, and you live in the UK, you might be more familiar with JustGiving. That's one of our brands. My official job title is laureate software engineer. I'm once again showing, even our HR system can't figure out, what does an architect mean?
Outline and Goals
I'll start by covering the responsibilities that architects need to do. Then I'll identify some of the fundamental skills, so think those small building blocks we're going to use to create our framework and achieve our goals.
Finally, we'll look at ways that great architects are combining all those skills, taking the practice of architecture to the next level. From this point forward, I'm going to be talking about software. In the interest of brevity, I might not always say, software architecture or software architect, but I think we'll all be on the same page.
Responsibilities of Architects
One thing that architects are typically known for, and in some organizations, all that they're known for, is creating those diagrams I showed earlier. That is part of the job. Those diagrams are useful. However, creation of diagrams is not the primary responsibility of an architect. That's just what you make. Thinking about a system, designing those components and the interactions, that's the job.
The diagram is just one tangible output. I want to make this distinction because if we work on the fundamental skills and behaviors that it takes to do the job of architecting, those can apply to any situation. That breadth of applicability is crucial to being a next level architect. If we're able to improve the practice of doing architecture, that will lead us to having better software. That seems like an admirable goal.
The work that's undertaken by architects varies a lot from one company to the other and even within a company, but there are some broad themes that I think always apply. First, architects need to understand both business and technical requirements for whatever project or product they're working on. Architects have to make decisions and design software systems.
Then architects are also responsible for explaining that design to stakeholders, developers, product owners, whoever else. None of those responsibilities says you have to have architect in your job title. That's because anyone can practice architecture. Some of those people will be enterprise architects, systems architects, application architects. Even the lead engineer has some architecture responsibility. It's like those staff-plus roles we keep talking about.
I want to dispel the myth that you have to get to a certain level, before you can start doing architecture. The main differentiator isn't the type of work being done, it's the scope of the influence and the impact of the decisions that a person makes. I also want to point out that leveling up your architecture game does not mean moving up job titles, like on this list. The skills that make you successful, apply to any level of the org chart, regardless of the title you have.
Four Characteristics of Great Software Architects
That brings us to the fundamental skills that we need to practice. There are four that I've identified that come into play every day for architects, and they build upon each other. At the base is communication.
The second one is decision making. That might seem surprising, because making decisions sounds like the first line of a job description. Trust me, it is second in importance to communication.
Third, is being able to adapt to change. Fourth, we have leadership. These are all important. On any given day, you might need to focus on one more than the other, but this is the baseline rank.
Communication
Number one, the most important skill for an architect, communication. Why do I believe that? Because every software problem is fundamentally a communication problem. That's important. That's true when we have two machines that are trying to communicate, or a person that's trying to develop or use a piece of software, or two people that are trying to communicate about software. Maybe it'll help if we look at some examples.
First, we have well known errors that specifically say, I don't understand you. A 400 bad request is when a client asks a server something, and the server doesn't know how to handle that request. That communication problem is so common that it's the first of the 400 series client errors in the HTTP spec. That specification is full of all the rules of how two systems can communicate. It is again, software to software. When we show a 400 or a 404 error to a user, that's a leaky abstraction. We've now communicated our problem that shouldn't be their problem. Some people say that every software problem is really a DNS problem. That's fun, but if you look at it, DNS is really just another tool that helps with communication. When we have those DNS problems, those are still communication problems.
What about when we start using the software and it doesn't quite do what we want it to do, doesn't meet the requirements. Or, you built the system, and you look at the design, it's like, that doesn't match. Why wasn't it built the way we wanted it to be built? Why did that happen? Maybe the developer didn't read all the requirements. Maybe they read the requirements, but they were vague, or they were subject to interpretation, and what they did wasn't what the person who wrote them expected it to be. Maybe the developer wrote a bug. I know that happens from time to time. That means you told the computer to do something different from what you intended. It's a communication problem.
No matter the specifics, all these examples come down to a breakdown somewhere in communication, either between the people, or when translating the requirements into code, or when those two systems are trying to communicate.
Communication problems are the root of all software problems. That means the biggest impact that a software architect can have is by improving communication. We can improve how our systems talk to each other. We can improve how developers build those systems. We can improve how people talk about those systems. Architects are able to make positive changes in all three of those communication paths.
How do we get started improving communication? We again, go back to the fundamentals. Think back to a time when you were sitting in a classroom, learning how to communicate with others. I know there's a famous book that says this all came from kindergarten. Don't get me wrong, lots of great stuff comes out of kindergarten. For today, we're talking about going back to college.
English Composition is a required course for first year students at most colleges in the U.S. Why? Because writing is required in nearly every course. If you're going to be effective in communicating your ideas, in any subject, you need to be able to write effectively. For the same reason, a lot of colleges require a speech or oral communication class. I want to emphasize a three-word phrase that's taught in Comp 101, that's applicable to all forms of communication: know your audience. That's it. Always consider who you are communicating with, what information you're trying to convey, and how best to get that point across.
Architecture diagrams are useful, but they might not be the best tool for every audience. You might need to write a document or give a presentation. What developers need to implement something is different than what the product owners and business stakeholders need. Knowing your audience is crucial for when you're communicating out.
Communication is always two-sided. How do you improve your ability to receive communication? This is one of the statements that sounds so obvious, it almost doesn't merit mentioning. To improve your ability to receive information, you need to ask questions. Just think, have you ever heard someone after something goes wrong, and they're sitting over there saying, if they'd only asked me? Too often, we don't take enough time seeking out the information that other people around us have. That's also covering the idea of, question every assumption. Ask those questions. Is that really true?
As a personal note, this is something that I have to work at. I've taken all those personality profiles, and everything confirms that I'm really good at doing low-level analyticals, deep dive, figuring out things. I am not good at naturally asking people questions. I can't just say, that's not something I do. I actively work at it. I'm guessing that most of the people listening to this are in that same personality profile, or are on that same spectrum of not naturally asking other people questions. You need to work at it.
Because we're talking about the receiving side of communication, asking questions is only effective if you listen to the answers. Listen to people, trust what they're saying. Don't just dismiss it. Then use that to help you inform your decisions.
Now that we're listening, the last little bit of communication advice doesn't come from college, it comes from the world of improv. The idea of, yes, and, is the foundation of improv, because it's what allows a scene to continually build. The opposite of that would be saying no, or yes, but, and then changing direction, which creates friction and destroys the flow of that scene that's progressing.
This is true also for architecture discussions. As an architect, you have to avoid the temptation to simply say, that's not right, when you hear someone that has an idea that you disagree with. That can take a level of humility, and admitting that you don't have all the right answers. If you think you have a suggestion that's better, acknowledge what someone else said.
Then add to it and gradually guide them towards your idea. Understand where they're coming from. Taking that time to understand other opinions, or other options, then providing reasoned arguments for and against them, rather than simply a yes or no decision, or yes or no response, that's a core skill for architects.
Decision Making
Which gets us to our second important skill, decision making. This is the primary day-to-day job responsibility for architects, making decisions. When making architecture decisions, there's some steps you always go through. It's like the scientific method. It starts with understanding what decision needs to be made. Then you come up with some options. You evaluate those options, and you choose one. You make a decision.
Finally, you communicate your decision. You can't skip any of these steps. For small decisions, this might be a quick call and talk through things with people, and you don't need them rigor but you always go through this process.
The first and the last steps point to the importance of communication. If you don't understand the decision that's going to be made, then everything after that can be wasted effort. If you cannot effectively communicate your decision, you risk not how having it carried out as you intended. As for improving your decision-making skills, we're going to focus in the center of the box, those core steps of the process where we create the options, evaluate them, and then choose one. We will come back to the communication steps.
When you ask an architect any question, the default answer is, it depends. Why do they say that? There's a lot of reasons. The follow-up question should always be, what does it depend on? That's what's going through their head. That means understanding the various criteria that are important to that decision. Sometimes, you're provided specific functional requirements, something like, the system must store file attachments up to 10 megabytes. That's great. Very useful. More often, we deal with the non-functional requirements, things that are referred to as the -ilities, because they include scalability, maintainability, extensibility. Also, sometimes referred to as quality attribute requirements, because these are the qualities of the system.
There's always a cost factor. Sometimes it's more obvious than others and more explicit. A build versus buy decision is probably easy to see the cost differential, looking at a PaaS versus an IaaS option, you might be able to see the cost. These are some of the examples of the things you have to think about as the criterias for your decision.
We're going to focus on those -ilities, the quality attributes, because that's really where architecture gets wrapped around sometimes. You have to evaluate those non-functional requirements that are usually not well defined, if they're defined at all. If you can get something measurable, maybe you have an SLA that you have to meet, that's helpful. When you don't have that, at a minimum, just try and rank them in order of importance and do those high-level quality tradeoffs. Which one do you want more than the other?
For example, asynchronous messaging versus synchronous API calls. Asynchronous messaging has more scalability than a synchronous call, but it introduces eventual consistency, and maybe it makes your system more complex. What's more important? Do you want to have that data that's immediately accessible or do you need the scalability? It's going to depend on your situation. Tradeoffs are always context specific. What quality attributes are most important? It depends.
Once you've evaluated your options, and decided on the one that you think is best for your situation, you need to communicate that decision. This was the fifth step in our scientific method. What's the most effective way to communicate your decisions? Again, it depends. Maybe it's drawing diagrams, because diagrams will always be important. You might use a very structured format like UML, or SysML. Maybe you just wing it each time, boxes and arrows, and that's fine.
One technique that's been consistently useful is Simon Brown's C4 model. C4 is a hierarchical set of diagrams that are for context, containers, components, and code. Whatever technique you use, remember that the point of a diagram is to help communicate your design decisions. If your goal is to communicate your design decisions to various stakeholders, you need to know your audience. The C4 model acknowledges this with each layer of the hierarchy from context to code, having a slightly different intended audience.
Even the best diagrams, they have some limitations, because a diagram is just a model. As someone once said, all models are wrong, but some are useful. Diagrams are often useful because they show what to build. What they don't show is why it should be built that way.
We went through the decision-making process. We evaluated multiple options. We looked at the tradeoffs, we chose one. That diagram only captures the winner. Imagine watching the Olympics, and all you see are the gold medalists. There's no other athletes. There's no coverage of the events. You know right away, something's missing. I want more information. The other challenge with diagrams is you have to keep them up to date. When do you have to go and update a diagram? You update them when your decisions change.
The problem is that those changes aren't always explicit. It's not always, I change our design from A to B. Sometimes it just drifts a little bit. That means diagrams can get stale, because those implicit changes that no one wrote down have affected the design and now what is actually implemented doesn't match the diagram. When it comes to communicating our design decisions, we can do better than just drawing pictures.
Architecture Decision Records, or ADRs, are a great tool for the entire decision-making process. The term was first coined by Michael Nygard, back in 2011. In his blog post, he points out that agile methods are not opposed to documentation, only to valueless documentation. The value of the ADR is it fills in the gaps. It explains the why behind the decision. ADR is just a lightweight template with sections that align to the steps I outlined earlier as the scientific method.
At a minimum, you can start by describing the context of the decision and then jump down to, here's the chosen option. If that's all you read, that's basically the same information that was provided in the diagram, here's the decision.
There's more because the ADR captures everything in between. It lists all the options that were considered. It lists the decision criteria that were important, and how those tradeoffs were made, describing the pros and cons of each option. That's powerful stuff. It's not really that complicated. It's just a useful template. If you're like me, you've probably stared at a lot of blank whiteboards thinking, what should that system look like? A blank ADR starts with a template with the sections you need to fill in. It's already a little more helpful than the blank whiteboard.
ADRs are helpful because they help you start thinking about communication. It makes you take the time to write down the decision that's being made: write down your options, describe the tradeoffs. That naturally gets you thinking, how would I explain this to someone else? It's like trying to teach a class to a group of people, and you have to learn the material more than if you just learned it for yourself. ADRs have that same effect for you as an individual because they just force you to go through the deliberate thinking process.
I know some people are more comfortable drawing boxes and arrows than writing prose. This doesn't need to be a lot of writing. There's an emphasis on it being really lightweight. I personally prefer to write ADRs using Markdown. There's a few different templates out there. The one I use is from MADR. It comes with a CLI. I can type MADR new, the name of my decision, and I get a new file. It's added to a little index catalog. Then I just start writing, and it tells me what to fill in. Because it's Markdown, in Markdown, you can do mermaid diagrams. If you have simple diagrams that you need to include that might help you describe and visualize those two options you're considering, you can put those in there as well.
ADR starts with a header that has header information. The ID and the name get added when you create a new file. The date and the deciders I think are really important. The date tells you, is this a new decision? Was this in the last few months, or is it a couple years old? If it's a couple years old, how much do I trust it? The deciders, I don't like saying it's a who to blame, but it's who to blame. Because you should not put down a department name or a job title, put down your name and stand by your decisions. That way, if someone has a question, they can come back and ask you and you can review it together.
The status is there because you should never delete an ADR. That if you made a decision six months ago, and you're making a new decision that changes that, you should change the status to supersede it and explain, go look at this new one. Then the new one can refer back to, this supersedes the previous one. Then what's nice about it being in Markdown, it's just a text file. Text files are great for checking into the source control.
Then you get all the benefits that Git or whatever your source control provider has. You can see the history. You can use pull requests for gathering feedback. It lives where everyone is going every day, right in your source control repository. It's not a separate Wiki that only the architects know about or a SharePoint site or a share drive. It's right there. Treat it like your code. Version it like your code. Use it like your code.
ADRs and diagrams are not the only ways to communicate design decisions. Design decisions are not the only things that architects need to discuss. Always be thinking about your audience. What do they need to know and what should you leave out? I'm not saying you should deliberately hide information. There are times when you need to be able to give a high-level summary with the elevator pitch without all the details, and then other times you need to go into those details. That's where knowing your audience comes in handy because if you only have five minutes to present versus an hour, you've got to figure out what's important for that audience. During that first phase of our scientific method, you need to do some research.
Two of the techniques that I've found useful are event storming, and domain storytelling. Event storming is useful for understanding the business process, and seeing all the actors and interaction paths. You get a bunch of people together in a room, put some butcher paper up on the wall, and go wild with Sticky Notes. You rearrange them until you have your process mapped out. This is moved online using tools like Miro.
Then, domain storytelling is similar, but it adds a specific graphical language, little glyphs that you use just to describe your process. That creates visual documentation. It helps you visualize what that workflow is. You can show it to your audience and say, does this map your perception of how this process flows? Both those techniques are useful for either understanding existing processes, or for designing new ones. If you're going to come up with a new system, map it out.
Those are just two techniques. My point being that next level architects need to be aware of these techniques and others when we're designing complex systems, because they really help with gathering that information in that early communication phase.
Adaptability
We've got our first two superpowers, improve communication, because we know our audience, and better decision making, and communicating those decisions, because we're using Architecture Decision Records, ADRs. Our third skill for leveling up as architects is adaptability. Planning is important, but nothing ever goes exactly as planned. The Agile Manifesto backs us up saying we should value responding to change over following a plan. How do we improve how we respond to change? Making a change from our plan instead means that we've changed one or more of our decisions. That's either the circumstances have changed, or maybe there was an assumption that we made that we found out was invalid.
Hopefully, our overall goal has remained about the same, and we only need a minor course correction. In any case, if we've documented how the decision was made, we can revisit it. We can read that ADR and then supersede it with a new decision based on our new information. Without the ADR, all we'd have is the original diagram, and we'd spend too much time and effort maybe designing something drastically different, when all we needed to do was look at, we chose option B last time, option C was right there, we didn't think it made sense.
Now we think C makes more sense. Having those available to allow you to reevaluate, makes it a lot faster to make small decision changes and do those minor course corrections based on new information as it arises.
We spent decades trying to be agile for developing software, and architecture has been playing catch-up. If we want our architecture to be agile, it has to respond to change. Some ideas of how to design your architecture to allow for continuous evolution are captured in a seven-part article series by Pierre Pureur and Kurt Bittner on InfoQ. Pierre is also coauthor of a book on Continuous Architecture. One idea that's discussed in those articles is the minimum-viable architecture.
The MVA is the architecture that supports your MVP, minimum-viable product. You make your design decisions, but with the idea that those decisions are just what you need right now. You know they're going to change later when your software has been adopted, and you have new scalability concerns or different user requirements. You can now revisit those decisions and make new ones. The MVA allows you to validate your decisions and see how they perform in the real world. That means the architecture can continually evolve, because it's based on decisions that we expect to continually evolve. That's agile architecture.
We want our system to be agile. We also need to be agile as architects. This goes back to that idea of architects design the architecture, but they also practice architecture. Clearly, the biggest factor in the last few years has been the move to hybrid and remote teams, no hiding that. That has led to some communication challenges. Innovative architects are finding ways to adapt and thrive.
There's an entire track at QCon about remote and hybrid working because there's so much good information there. Those ideas discussed are actionable right away. It might take you a year to implement the new technology you heard about, but you might be able to try some of those new processes for improving communication on remote teams tomorrow. One common observation in those discussions is that asynchronous forms of communication are more standard and are being used more effectively. ADRs lend themselves to asynchronous communication.
We don't have the conference room whiteboard to stand around for hours, that means the architects can't hide and do it alone. It also means that people can't walk by and see what's going on in there. Having it not hidden in the architecture wing of the building, maybe that's a good thing. Maybe it's now more accessible because the ADRs are out there in source control. We're also seeing changes in the work habits that are influencing the software that gets built. I call this the COVID Corollary to Conway's Law, that highly effective distributed teams are able to build highly effective distributed systems. Conversely, when teams struggle with interpersonal distributed communication, those communication problems will manifest within the software that they build.
Adaptability is important because technology is always changing. That means we'll see new quality attributes that are driving our design decisions, and the ones we have will evolve over time. Have you seen the Principles for Green Software Engineering? One of the philosophies in there is that everyone has a role to play in the climate solution. Architects actually have a major role, because architecture decisions can have a significant impact on the carbon footprint of a system. If you think about how you're building many microservices versus one mega server, but do those services need to be on all the time? Can you go to functions? Can you go to smaller processes that only run when you need them to? How do you make those tradeoffs to affect your sustainable and carbon impact?
We're also seeing other quality attributes evolve, like extensibility. That used to be, make some good APIs, so that people can extend your software. The intended audience of those APIs was always professional developers, people who could write a lot of code. We now have the rise of low-code and no-code platforms. That means our extensibility plans have to accommodate citizen developers. That's going to change how architects design systems. Then, being adaptable means you're just more prepared for whatever comes next. You're not fixed and set in your ways, because we don't know what the future holds. If you are stubbornly set in your ways, like this is how I'm always going to design systems, we're going to leave you behind. You won't get to the next level.
Leadership
The last of our four skills for great architects is leadership. For several years, architect as technical leader has been on the InfoQ Architecture and Design Trends report. That's because software architecting is a skill that all developers need. Experienced architects have an obligation to share that experience, and help others. Several years ago, I worked at Nordstrom.
A high-end department store chain that is known for excellent customer service. That's where I was introduced to the idea of the inverted pyramid. You can look this up. It's taught in business schools. Other companies have adopted it, but it's what Nordstrom is really known for. Their org chart is upside down. It is an inverted pyramid. Employees do not report up to managers, managers support their employees. The person that's selling shoes, the one interacting with the customer, they're at the top of the org chart, not the CEO.
When I was a technical lead, I supported the engineers on my team. I'm no longer at Nordstrom, and every company I've worked for before and since has had a traditional top-down org chart. That's still a driving force of how I see my role and responsibilities. It's the idea of servant leadership. That can apply regardless of your org chart structure. It means not being hands-off in how I approach my job. I can't just draw a diagram, throw it out the ivory tower, and hope the team implements it correctly. That's also why I enjoyed talking to Andrew Harmel-Law about the architecture advice process.
One of the key takeaways from that conversation was that anyone can make architecture decisions. I've hit on this already. What he says is that those people have to do two things, consult with two groups: people that are affected by the decision, and people with relevant experience. He uses ADRs as a framework, to have developers encouraged to make architectural decisions.
The architects are there to provide advice and help identify those people who will be affected by the decision or the people who have the relevant knowledge, because the architects may know more of the organization. It all brings us back to the importance of communication. We're communicating how to make architecture decisions.
That advice process really shows that the architecture is not only for architects. If your role is primarily as an architect, then you need to be that technical leader. That means empowering those engineers to make good decisions. If your ADRs are stored in source control, they can serve as a good example of how to go through the decision-making process. How do we evaluate the tradeoffs? Building software is a process of dealing with uncertainty. I think architects have to be comfortable working in that zone of uncertainty.
Engineers sometimes are shielded from it because people have made the decisions for them. When faced with the unknown, we need to have our engineers not just sit idle waiting for an architect to tell them what to do. Instead, we want to provide the support and grow their ability to make good decisions. Provide the safety net, but show them how to get out of that rut and continue on when they don't know where to go.
Putting it All Together
That gets us through all four of the important skills. Let's put them together and talk about some practical examples. To recap, our four characteristics of great software architects. They start with communication, decision making, adaptability, and leadership. Maybe you're wondering if there's something else that should be on the list. He hasn't talked about microservices, stream processing, Kubernetes, Kafka, Quarkus.
Architecture is not a game of buzzword bingo. New architecture patterns and tools and technologies, they'll come and go. You need to use critical thinking skills and good decision making to understand if they are right for you. It depends. That means, in addition to being able to communicate your good decisions, you sometimes need to explain why if we use that, that would be a bad decision. Here, I understand why.
Talking back to the idea of architecture not just being limited to architects. Those job titles sometimes include architect in them. Even when you don't, you still have architecture work. That means that the roles, that everything we've talked about that architects need to do, can apply at any of these technical levels. You can make these decisions, whether or not you have architect in your title.
The role of architect and engineer, they're getting more entwined. Again, we're getting out of the ivory tower where the architect does one thing and engineers do something different. They are very much interrelated now. In fact, just as every engineer has some level of architectural responsibility, I think every architect has some level of engineering and programming responsibility. That's why I say that all architects should write code. Maybe that's a controversial statement. It shouldn't be.
Software architects need to write code. I've made my decision. I can just walk away now and tell you, and hope you all go off and implement that. I wrote it in a large font, I clearly was clear. You've probably been paying attention and thinking, that decision would be more useful if he explains why.
First, writing code is a way to validate your designs, especially when you're defining a new pattern. ADRs are very helpful for walking through the tradeoffs. Sometimes you don't really understand what that design is going to look like until you try to implement it. I think you can relate to that. That also means that you get to share in the pain and frustration when things don't go right, because they don't always go right. When they do, you've got a little skin in the game, both for the positive and negative. You can celebrate with the team when it works well.
As an industry, we are definitely seeing fewer ivory tower architects than we used to, maybe a decade ago. Remote work has isolation built into it, and you can feel very isolated in making your design decisions. You need to be proactive, and ensure that you're having all those interactions that are necessary to be successful. Writing code is a great way to interact with engineers. You get to feel that osmosis that you lost when you were walking around and just listening to them talk about things. If you want more details, I wrote an ADR for this decision.
The Design Team
When I say architects should write code, I really do not mean full time, they would be engineers. One of the interaction patterns I've encountered at a few companies, but it isn't everywhere, is the design team. Architects usually participate in these. That's because system design has to consider multiple viewpoints. The design team brings together stakeholders who represent three distinct viewpoints. That's why sometimes it's called a triad.
The product owner represents business needs. We need someone for the user experience, some designer. Then, we need someone at the table to talk about the technical needs. We'll call them an architect, but it doesn't have to be an architect. It could be a dev lead, any staff-plus engineer. These are roles, these aren't job titles. It's just different ways of thinking, and someone has a responsibility to have that separate viewpoint.
Software is created to solve business needs. That's the what that needs to get built. The technical seat at the table is responsible for how the software will get built. The design team is where you start capturing those technical decisions that you need to make, the things that aren't obvious and you have to go and figure out. At the table of the design team, you can discuss the functional and non-functional requirements, and what tradeoffs you need to think about. That's the first step in our scientific method, gathering the information for the decision to be made.
Ideally, you're looking a little bit into the future, that this team is looking a few months ahead on the work that you plan to do. That gives you time for the big decisions to actually sit down and do the analysis you need to. There are sometimes when that's just an afternoon, but there's sometimes it might take weeks. Put the design team a few steps ahead of the actual team that's implementing decisions.
Asking for Help
I said ADR can be a template, it can be a better starting point than a blank whiteboard. Sometimes it can be a struggle to just write the first few words. Luckily, we now live in a world of OpenAI chatbots, such as ChatGPT, and Bing. You can ask about the tradeoffs between the options you're considering and have the conversation about the pros and cons. They may not know the specifics of your situation, but they can help you regarding typical circumstances. If you really want to jumpstart, just ask them to write an ADR.
Here's Bing's recommendation when I asked if architects should write code. Bing thinks they should. I did ask Bing after I'd written my own ADR and most of this presentation was done. I was pleased that some of its points lined up with the points that I gave. With any use of AI, please don't take what it says at face value. I did say you should question every assumption and question your AI's decisions as well. Again, is useful for maybe filling in the blanks and thinking about something you hadn't considered.
Architecture decisions are made at many levels, within a single dev team, or across a few teams. They're at the product level. They're at the department and corporate level. Individually, you as an architect are likely responsible for decisions at one of those levels. It also means that you can have influence on people's behavior, at least one level above and below. That's where you go and help the engineers make architecture decisions that are just affecting their team. I think working with the stakeholders and the design team, you have an ability to influence their behavior.
If they see how ADRs are effective for technical decisions, why not see if they work for non-technical decisions. This is very much an innovator trend. If you look at the MADR project, the latest version has renamed it to Any Decision Record. There's nothing in the template that only applies to architecture. That's really an artifact from the first people who used it being software architects like Michael Nygard.
They needed to improve the decision-making process and communicate those decisions, and so ADRs were born. Now that we have them, it doesn't mean the ADRs have to stay within the realm of software. I would love to see ADRs be used to describe how we got to our corporate goals or new product approvals. Some companies are pretty good at communicating the rationale down to employees, but that's not always the case. Maybe ADRs is a way that we can help improve those.
Communication Based on Participants
The design team is just one group that an architect will interact with. Architects need to work with the engineering teams that build the software, as well as a lot of business stakeholders, especially that time gathering information and communicating decisions. That means working with people across the company. Gregor Hohpe describes this as riding the architect elevator from the IT engine room, up to the CEO penthouse.
My advice before you step off onto a different floor, always keep in mind, know your audience. How are you going to communicate to those people on that floor? I've also described that every software problem is a communication problem. It may sound like most of what I've talked about only applies between two people. If you think about it, most of the communication things I've described can also apply to human-computer interaction, and between two computers. Think about when you're writing code. That's a human telling a computer what to do. Know your audience is the computer.
There's always more than one way to write code that has the same desired output. That can be something as simple as formatting your curly braces, or choosing a different algorithm, or even a different language. When you're making the decision about how to write code, the audience that you actually need to consider is other developers who have to read that software, read that code later. That's your audience that's more important. If I have a choice between two ways of writing things, I always favor the more human readable choice.
We can come back and reevaluate it for performance later. Even in the computer to computer scenario, the specification and requirements for that interface need to be clearly defined so that developers know how to write their code appropriately. That's something like the 400 bad requests that are part of the HTTP specification. It's also about using OpenAPI and AsyncAPI, or other ways to have a specification that clearly expresses, how do you communicate with my service.
One of the best references for dealing with all three of these pathways of communication is Domain-Driven Design by Eric Evans. The subtitle of his book is tackling complexity in the heart of software. Having a ubiquitous language within a bounded context, gets right at two major problems about tackling when talking about software. What's the scope of the system or subsystem we're talking about? What are the words we will use to talk about it? Take that language from your business domain, use that language in your design and implement in your software using the same language. That goes a long way to tackling complexity and alleviating a lot of communication problems.
Architects, in this day and age can no longer just focus on technology, you have to understand the sociotechnical concerns. That's another way that we have to be adaptable. Team Topologies embraces the idea of Conway's Law, and describes four ways that teams should be organized. Those are four topologies. Architects need to either accept the organizational structure, and engineer their systems, architect their systems to align with that org structure, or they have to perform a reverse Conway maneuver, restructure the organization to align with the desired architecture. That can be challenging.
In either case, the goal of architects is to find ways to reduce the cognitive load of development teams. It also means you have to recognize that desire for things like low coupling and high cohesion, that's not just among your system components. That's also desirable among the teams that are building those components. That's the book review part of the talk.
Key Takeaways
I want to revisit what we've covered, aligning with those four characteristics of great architects:
- Because every software problem is really a communication problem, the biggest impact a software architect can make is by improving communication.
- Know your audience, and find new and effective ways to communicate with them.
- When making decisions, use Architecture Decision Records to explain why a decision was made.
- Be adaptable, both in how you practice architecture, and in the architecture that you design.
- Finally, be a leader by providing advice to help make other people make better decisions.
I want to finish with a modified quote from Kelsey Hightower. He originally said engineer, but since every architecture can be done by everyone, I'm going to substitute architect in there. I totally believe this, that you become a 10x, not when you do the work of 10 people, but when you make 10 other people better than they were before. I can't think of a better description of leveling up your architecture game.
See more presentations with transcripts
