Laws of Software Architecture
After defining the expectations of a Software Architect I wanted to take a small break and reason about some inevitable laws that drive the software industry in general. If you've been around long enough these will resonate with you greatly.
First Law of Software Architecture
Everything in Software Architecture is a trade-off.
If you paid attention to the Basics of Software Architecture you might have realized the reality of this law pretty quickly. Looking for example at the Characteristics of an architecture, you soon understand that you can't satisfy them all or better yet, you can satisfy some greatly at the cost of others. A simple example of this can be the conundrum between Usability vs Security. A system that provides a certain Security guarantee comes at the price of sacrificing some Usability. Think about authentication steps like complex passwords, 2FA setup, and so on. As an Architect you have to navigate these trade-offs in every decision. If you need another well-known example you can look at the CAP Theorem.
This is why it is important for an Architect to understand the technical landscape and have a very wide knowledge. Having that level of awareness can support you in understanding and explore other paths that offer different trade-offs. There might be something the project is willing to sacrifice more than others.
Corollary
If an architect thinks they have discovered something that isn't a trade-off, more likely they just haven't identified the trade-off yet.
Solely based on experience it resonates with me that there are always competing factors that make trade-offs inevitable. At a previous company we had one dedicated individual developing the iOS app and one focused on Android. Then we had several people focused on web with React experience. This made it so some of the challenges had to be resolved independently in 3 different ways by different groups of people. At the time we supported each other as much as we could but nonetheless we were split. In order to move more as unit, the team ended up switching everything to React Native. So we abstracted away the platform in the hope to increase velocity. We made several trade-offs and to this day I'm not convinced it was the right choice. We stumbled upon so many unnecessary obstacles due to a framework not even on v1 (welp, I just checked, it's still not a v1). We traded off a problem for another and while we could all sit down together to discuss it, it didn't make it any less painful.
Second Law of Software Architecture
Why is more important than how.
This is a powerful habit to develop, digging into Whys. I like to draw a parallel with how I feel about comments in code, the why is more important than the how. If you really want to, you can dissect a piece of code to its bare bones and understand how it's doing what it's doing. The biggest miss though would be not knowing why, this makes it impossible to apply any changes with confidence. Not to side track but arguably even complex pieces of code can benefit from leaving a comment or two, find a balance!
Thoughts
These principles are relevant beyond software architecture. Navigating trade-offs is an art but not something only architect benefit from. At a minimum, understanding and identifying the trade-offs is a good starting point. While you might not make the correct decisions even knowing the trade-offs, explicitly stating the why can help mitigate that and understand the reason behind certain choices. Thinking about the whys pushes the conversation to be focused on objectives and align rather than specific implementations or framework used.
If you are ready to discuss the outcome of an architectural decision but are not able to explain the whys not only does it become more challenging to persuade stakeholders, but it also undermines the credibility of the solution itself.