This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
Most architecture books tell you how to build systems. Mark Richards and Neal Ford’s Fundamentals of Software Architecture: A Modern Engineering Approach tells you how to think about building them. Now in its second edition, updated for cloud-native patterns and generative AI, it’s less a technical manual and more a field guide for making decisions under uncertainty.
What struck me most wasn’t the coverage of architecture styles or component patterns (though both are thorough). It was how much of the book is about the human side of the role: communication, collaboration, ego, and the courage to admit you don’t have all the answers. Here are the quotes and ideas that resonated most strongly with me as a consultant and fractional CTO.
Everything Is a Trade-Off
Nothing exists on a nice, clean spectrum. Every decision a software architect makes must account for a large number of variables that take on different values depending on the circumstances. Trade-offs are the essence of software architecture decisions.
This is the thesis of the entire book, and it sets the tone for everything that follows. There is no objectively “right” architecture. There is only the least worst set of trade-offs for your specific situation, given your team’s capability, your budget, your timeline, your existing technical debt, and your business goals.
I’ve lost count of the number of times I’ve been asked “should we use microservices?” without any discussion of what problem the team is actually trying to solve. The answer is always “it depends,” and the quality of your architecture depends entirely on how well you understand what it depends on. Richards and Ford come back to this point repeatedly throughout the book, and rightly so. If you take one thing from this review, let it be this: every architecture decision is a trade-off, and the job of the architect is to make those trade-offs visible rather than hiding behind a single “correct” answer.
Breadth Over Depth
Unlike developers, who must have a significant amount of technical depth to perform their jobs, software architects must have a significant amount of technical breadth to see things from an architectural point of view. Technical depth is all about having deep knowledge of a particular programming language, platform, framework, product, and so on, whereas technical breadth is all about knowing a little bit about a lot of things.
The transition from developer to architect (or to any leadership role that involves technology decisions) requires a fundamental shift in how you acquire knowledge. Depth makes you effective at implementation. Breadth makes you effective at decision-making. This doesn’t mean abandoning depth entirely, but it means consciously investing time in understanding technologies you’ll never use directly.
This resonates with how I approach consulting. When a client asks me to evaluate their architecture, I need to understand not just the stack they’ve chosen but the alternatives they didn’t choose and why those alternatives might or might not have been better. That requires breadth. Recommending the right tool for the problem means knowing more than one tool; and being honest about the trade-offs of each.
Beware the Memetic Bubble
When developers, architects, and other technologists become heavily invested in a specific technology, pouring our work and thought into it, we tend to live in a memetic bubble. Inside the bubble, which also serves as an echo chamber, everyone knows and cares about that technology as much as we do. We might not even see honest appraisals from outside the bubble, especially if the bubble was created by a technology vendor in the first place. And when the bubble begins to collapse, there’s no warning until it’s too late.
If your entire team uses React, every problem looks like a React problem. If your architect came from a Java background, every solution will lean toward Java Virtual Machine (JVM) patterns. The bubble is comfortable, and vendor marketing actively reinforces it. Conferences, community forums, and social media algorithms all push you deeper into the bubble rather than encouraging you to look over the wall.
I’ve seen this play out in consulting engagements: teams who’ve been “all in” on a single technology for years and can’t see that the landscape has shifted around them. The authors’ advice to treat your technology portfolio like a financial portfolio (diversify) is sound. Breaking out of the bubble is uncomfortable. It means admitting that the technology you’ve invested years in might not be the right choice for your next project. But that discomfort is where the best architectural decisions come from.
Iteration Over Perfection
Strive to design architecture that is as iterative as possible. The easier it is to change the architecture, the less everyone needs to stress about discovering the exact correct thing in the first attempt. One of the most important lessons of Agile software development is the value of iteration; this holds true at all levels of software development, including architecture.
The waterfall-era idea that you could design a complete architecture upfront and hand it to developers to implement is how we ended up with systems that were outdated before they launched. Architecture needs to be as iterative as the code it supports. If changing a fundamental architectural decision requires rewriting half the system, that’s a sign the architecture wasn’t designed for change.
Elsewhere in the book, Richards and Ford make a related observation that opened my eyes: “There is no measure for agility, so architects must ask: what is agility composed of? It includes things like deployability, modularity, and testability, all of which are measurable.” We don’t measure agility; we measure velocity, which is speed AND a direction, not just speed OR a direction. If you want to know how agile your architecture actually is, measure the things that make it agile. How quickly can you deploy a change? How easily can you replace a component? How thoroughly can you test in isolation? Those are the numbers that matter.
Checklists Belong in Architecture Too
Atul Gawande’s influential book The Checklist Manifesto describes how professionals such as airline pilots and surgeons use checklists. (Sometimes they’re even legally mandated to do so.) It’s not because those professionals don’t know their jobs or are forgetful. Rather, when professionals do a highly detailed job over and over, it becomes easy for details to slip by them; a succinct checklist forms an effective reminder. This is the correct perspective on fitness functions; they are not a heavyweight governance mechanism, but a mechanism for architects to express and automatically verify important architectural principles.
If you’ve read my recent CPD post on The Checklist Manifesto, you’ll recognise the thread here. Richards and Ford extend Gawande’s argument into the world of architecture fitness functions: automated checks that verify architectural principles are being maintained. The connection between checklists and fitness functions is one of those “obvious in retrospect” moments. Both are about making implicit expectations explicit and verifiable.
Developers know they shouldn’t release insecure code. They know they should maintain module boundaries. They know they should keep dependencies up to date. But those priorities compete with dozens of others, and in the pressure of a sprint, something slips. Fitness functions are the architectural equivalent of the pilot’s pre-flight checklist: not an insult to professional competence, but a recognition that competence and consistency are two different things.
The Silence in the Room
Pluralistic ignorance is when everyone privately rejects a norm, but agrees to it because they think they are missing something obvious. For example, suppose the majority of people on a large team agree that using messaging between two remote services is the best solution. One person thinks this is a silly idea, because of a secure firewall between the two services. However, that person publicly agrees along with everyone else to use messaging. Although they privately reject the idea, they are afraid that they might be missing something obvious if they speak up. The larger the group, the less willing people are to confront others.
This is psychological safety applied to architecture decisions. Everyone privately disagrees but nobody speaks up, because each person assumes they must be missing something. The result is bad decisions that everyone saw coming but nobody prevented.
I’ve been in architecture review meetings where this happened. The most senior person proposes a solution, everyone nods, and the problems only surface weeks later during implementation. The fix isn’t just about creating a safe environment for dissent (though that’s essential). It’s also structural: keeping decision groups small enough that people feel comfortable challenging ideas, and explicitly asking “what could go wrong with this approach?” before committing. Richards and Ford note that the larger the group, the less willing people are to confront each other. That’s worth remembering the next time you invite fifteen people to an architecture review.
Let Go of the Beautiful Diagram
The Irrational Artifact Attachment antipattern describes the proportional relationship between a person’s irrational attachment to some artifact and how long it took the person to produce the artifact. If someone spends four hours creating a beautiful diagram in some tool like Visio, they’ll be even more irrationally attached to that artifact than if they’d invested only two hours.
Sunk cost fallacy, applied to architecture documents. The more time you invest in an artifact, the harder it is to throw it away, even when the evidence says you should. Anyone who has spent three hours perfecting a Mermaid diagram only to realise the architecture it describes doesn’t actually solve the problem will recognise this feeling.
The authors’ recommendation is deliberately low-tech: index cards, sticky notes, whiteboard sketches. Tools that are cheap to create and painless to discard. When the artifact is disposable, the idea behind it becomes the focus. When the artifact is polished, the polish becomes the focus, and bad ideas survive longer than they should because nobody wants to waste the work that went into presenting them.
Come Down from the Tower
When development teams feel disconnected from the architecture (or the architect), they often feel left out of decisions. This is a classic example of the Ivory Tower Architecture antipattern. Ivory tower architects dictate from on high, giving development teams orders without regard for their opinions or concerns. This usually leads to the team losing respect for the architect and can eventually cause the team’s dynamics to break down altogether.
Architecture decisions made in isolation from the people who have to implement them are architecture decisions that will be resisted, worked around, or quietly ignored. Richards and Ford are blunt about this: the ivory tower antipattern leads to a complete breakdown in team dynamics.
The antidote is collaboration, and specifically how you collaborate. The authors note that “providing the justification first is always a good approach. Most people tend to stop listening as soon as they hear something they disagree with.” Stating the reason before the demand ensures the team hears your reasoning. It’s a small communication shift with an outsized impact. A similar point was raised by Jerry Nixon in an episode of The Modern .NET Show; the best technical decisions mean nothing if the team doesn’t understand or buy into the reasoning behind them.
Welcome to Software Architecture
As architects, we make our decisions in a swamp of uncertainty. Accommodating this is annoying, but necessary. Not only do we sometimes have to base important decisions on incomplete information, but often the decision wouldn’t be clear-cut, even if we had the full scoop, because it resides somewhere on a spectrum between two extremes. Welcome to software architecture!
After almost 20 years in this industry, I find this oddly comforting. The uncertainty doesn’t go away with experience. You don’t reach a point where architecture decisions become obvious. What changes is your relationship with the uncertainty: you get better at navigating it, at identifying the trade-offs that matter most, and at making decisions that are good enough to move forward while remaining flexible enough to change course.
That, in the end, is the recurring theme across this entire book. It’s not really about architecture styles or component patterns or deployment topologies. It’s about the human qualities that good architecture demands: judgement in the face of trade-offs, self-awareness to escape the memetic bubble, humility to iterate rather than insist on perfection, courage to speak up when everyone else is nodding, and the communication skills to bring a team along with you.
If your architecture decisions feel like they’re being made in isolation, or if your team is stuck in a memetic bubble that nobody wants to acknowledge, that’s a conversation worth having. Let’s talk.