The role of the architect is an interesting one. Much has been written about the technical elements of an architect’s job – tools, technologies, frameworks, design patterns, architectural styles, etc. However, technology is not all there is to architecture. In fact, there’s a great deal more to it.
In this article, we don’t take a technology-focussed view. We also don’t cover a specific approach to architecture, like the TOGAF ADM. Rather, we cover the mindset of an architect and the way in which an effective architect operates. We’ll look at lessons learnt and practical considerations to apply. Consider this to be the rules of engagement for architects.
Before we get into that, however, let’s consider what an architect does – i.e. architecting, or designing, systems.
A key part of designing system revolves around making decisions on which things to prioritise over others. As an architect, your job is largely about balancing trade-offs. Every decision you make to optimise for one requirement likely comes at the expense of another.
You want fast? Get those big servers, but probably won’t be cheap. You want scale? Build microservices, but it might not be simple.
In designing systems, we make decisions that are bound by a set of constraints – our budgets, our performance requirements, market demand and timelines, etc. We determine which of these constraints are most important, and we prioritise them at the expense of those others. In other words, we manage trade-offs.
We also bridge the gap between a variety of stakeholders – business views the world in one way and developers in another. Our job is to get them onto the same page. Tech speaks one language and business speaks another, but we must be fluent in both.
Architects also play a leadership role, albeit with no (often limited formal authority) formal authority. Typically, as an architect, you are not anyone’s “boss”. However, you have to get people to rally behind your architecture vision and buy into your ideas and recommendations. Thus, without authority, you must find another way to lead – expert power, maybe?
With this context (more on that shortly), let’s move on to the rules of engagement.
Rule 1: Remember, Context is King
Your decisions should consider context. In choosing languages and frameworks for your architectures, what skills do you have available in your teams? When we design and build systems, we generally do it to support a business goal of some sort.
Understand what the business does that you work for. How do they make money? How heavily is their industry regulated? What is their budget for your solution? All of this should factor into your architecture definitions.
Rule 2: Always Consider Trade-Offs
Like I said earlier, managing trade-offs is a key part of your job as an architect. Once you understand the context, you can understand the impact of the trade-offs that you make. If you are building a transactional banking system, resiliency and accuracy is critical, so even if it comes at increased cost, the value of the trade-off is clear.
If you are building an MVP (minimum viable product) to prove a brand new idea, speed to market is critical – perhaps more so than a perfect codebase, so the trade-offs are different. Ultimately, when you optimise for one thing, be aware of what you are giving up in the process.
If you introduce coupling because, consider whether the rate of change for the components being coupled is similar. If not, are you making an ill-considered trade-off?
Rule 3: Bridge The Gap Between Tech and Business
As an architect, you design systems to meet a business goal. The systems you design will be implemented by technology teams. Often, these two groups of stakeholders speak very different languages and they care about different things. Business cares about the return on their investment and how it serves their customers. They don’t care about design patterns or programming languages. Developers, on the other hand, care about the technical details of implementing a solution, and things like technical debt. Again, context matters – sometimes you need to priotize new features because that will add immediate business value (which pays the bills), but at some point, you need to revisit the technical debt you incur before it becomes so severe that everything grinds to a halt. When bridging the gap, it’s important to make sure your stakeholders understand the why.
Speaking different languages also means that you need to be able to provide different views of your solution that can be understood by both sides. Eric Evans’ book, Domain Driven Design, speaks about a Ubiquitous Language – get your system to reflect your business. And when you communicate, leave the detailed diagrams with facades and VPCs and MVC and so forth to the devs.
Rule 4: Keep It Simple
Architecture is interesting, and it’s easy to come up with grand designs and ambitious over-engineering. Sometimes, it’s necessary, but when you see complexity arising, ask yourself whether or not it is necessary.
Fred Brooks said that an architect’s second system is the most dangerous – we bolt all the exciting things onto it that didn’t make it into the first system.
Don’t default to a complex architecture because of what you might need in the future. If you are unsure, keep it simple and defer the decision. For 100 users, do you really need all the complexity that goes with managing a distributed microservices architecture, or will a good old monolith actually do the trick?
Simpler architectures are easier to understand, easier to develop, and easier to maintain. So if you can keep it simple, it’s probably a good idea to do so. In thinking of complexity, consider both essential complexity (i.e. the complexity arising from the problem we’re solving) and accidental complexity (essentially, the problems we create for ourselves). By keeping things simple, you can reduce the amount of accidental complexity.
Rule 5: Be Humble and Consider Your Own Biases and Blind Spots
An architect is a fairly senior role, as far as software development careers go. Chances are that, if you are an architect, you’ve earned it through experience, hard work, and being a good developer. However, don’t see yourself as infallible because of your seniority. Seek input from others and respect their opinions. If you believe you know everything, it’s practically impossible to learn something new.
As an architect, your responsibility shifts away from what it was as a developer. As a developer, you care about the detail. As an architect, you care about the big picture.
In practice, this means that while you may have been the expert on a particular piece of technology at some point, you won’t be the expert forever. I think that our stacks are so broad (cloud, back-end languages, frameworks, a variety of databases, networks, etc.) that it’s impossible for an architect to be an expert on everything. However, I do believe that the architect should know enough to have a conversation with someone who is an expert on each part of the stack. I see an architect as a generalist, rather that a specialist.
Also, beware of your own biases and blinds spots. A particular approach may have served you well in the past, but will it work equally well in a different scenario? If you want to recommend a particular piece of technology, is it because of personal preference, or because you think it’ll look great on your resume, or because it really is the best tool for the job?
Rule 6: Define Principles
Architecture is difficult because there are often no clear right/wrong answers. The feedback loops are long, compared to development and the cost of change is high.
So, if there are no right answers, how do we make sure we’re making the right decisions? The answer lies in principles. As an architect, when you approach a new solution, decide on the principles (consider context, as always) and use those principles to guide your decisions.
A principle might state that ‘we prefer the use of open-source software’ — so when faced with a choice between two different technology stacks, the principle can serve to guide your decision.
Rule 7: Write Things Down
As an architect, you’ll find yourself dealing with vast amounts of information. You’ll have decisions and debate, you’ll have standard approaches and patterns that emerge over time.
In order to keep track of everything that’s going on, write things down. In order to communicate effectively, write things down.
To keep track of your decisions, keep architecture decision records. These should track the context of each decision, the options you considered, and the rationale behind the choices you make. If you look back a year from now, this is how you remember how a solution got to its current state.
When you create your architecture definitions, put them in written documents (diagrams and text) and break them down to various levels – from conceptual views to logical and physical views – in order to communicate your architecture to different stakeholders at the appropriate level of detail that makes sense in their context.
You’ll also encounter patterns and standard ways of solving recurring patterns. Build up a library for you and your team to refer back to so you don’t have to solve the same problems over and over again. Establish a set of reference architectures. Wikis are your friend.
In closing, I would like to share some book recommendations that I’ve found particularly valuable for anyone who is an architect or who aspires to move into an architect role.
The Mythical Man Month by Fred Brooks
The Software Architect Elevator by Gregor Hohpe
97 Things Every Software Architect Should Know by a variety of authors
The Fundamentals of Software Architecture by Neal Ford and Mark Richards
I hope that you’ve found value in this article. Let me know in the comments!
Disclaimer: As always, the views expressed in this post are my own.
