Author: Mark Richards, Neal Ford
A guide to the role of software architect and the foundational concepts of the discipline: defining architecture, the characteristics (“-ilities”) systems must support, and how to reason about trade-offs. A recurring theme is that architecture is always a product of its context — the practices and economics of the era shape what is even buildable.
Chapter 1. Introduction
The authors stress that architects should regularly question inherited assumptions. Much of the established literature was written for a world that no longer exists. Their go-to illustration: pitching microservices (each service on its own machinery with its own database) to a 2002 data centre would have been absurdly expensive given per-machine licensing. Only open source plus the DevOps revolution made it feasible. All architectures are a product of their context.
Defining software architecture
The book frames architecture as four interacting things:
- Structure — the architecture style(s) the system uses (microservices, layered, microkernel, etc.).
- Architecture characteristics — the “-ilities” the system must support (the success criteria, generally orthogonal to functionality).
- Architecture decisions — the rules for how the system is built (e.g. “only the business and services layers may touch the database”). When a rule can’t be honoured somewhere, it’s broken via an explicit variance, typically approved by an architecture review board (ARB) or chief architect.
- Design principles — guidelines rather than hard rules (e.g. “prefer asynchronous messaging between services”). A principle leaves room for the developer to pick the right tool for a specific case; a rule can’t cover every situation.
Expectations of an architect
Eight core expectations, regardless of title:
- Make architecture decisions
- Continually analyse the architecture
- Keep current with the latest trends
- Ensure compliance with decisions
- Have diverse exposure and experience
- Have business domain knowledge
- Possess interpersonal skills
- Understand and navigate politics
A few worth expanding:
- Make decisions — the operative word is guide, not specify. A good decision steers teams toward the right technical choice rather than making it for them. The exception: an architect may dictate a specific technology when it’s needed to preserve a characteristic like scalability or availability.
- Continually analyse — this is architecture vitality: is a design from three-plus years ago still viable given how business and tech have moved? Neglecting this leads to structural decay, where incremental changes erode required characteristics. Testing and release environments are frequently forgotten here — fast code changes are pointless if testing takes weeks and releases take months.
- Diverse exposure — favour technical breadth over depth. You don’t need to be an expert in everything, but knowing 10 caching products and their trade-offs is more valuable to an architect than mastery of one.
- Interpersonal skills — “no matter what they tell you, it’s always a people problem” (Gerald Weinberg). Leadership is at least half the job.
- Politics — almost every decision gets challenged (on cost, effort, or by developers who prefer their own approach). Navigating this with negotiation is part of the role.
Intersection of architecture and…
- Engineering practices — unknown unknowns are the nemesis of software; you can’t design for them, which is why Big Design Up Front fails. Mark’s line: “All architectures become iterative because of unknown unknowns. Agile just recognises this and does it sooner.” Architecture style and engineering practices must form a symbiotic mesh — microservices assume automated provisioning, testing, and deployment, and fall apart without them.
- Operations / DevOps — older architectures were often built defensively because operations was outsourced and out of the architect’s control (see space-based architecture, Chapter 15). Microservices instead create a liaison with ops and hand operational concerns to the people who do them best, removing accidental complexity.
- Process — Agile gives architects a faster feedback loop, enabling more aggressive experimentation. It also shines at restructuring (migrating from one pattern to another) thanks to tight feedback and techniques like the Strangler Pattern and feature toggles.
- Data — DBAs work alongside architects on data architecture, analysing how relationships and reuse affect a portfolio of applications.
Laws of Software Architecture
Everything in software architecture is a trade-off. — First Law
If an architect thinks they’ve found something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet. — Corollary 1
Why is more important than how. — Second Law
You can usually reverse-engineer how an unfamiliar system works by inspecting its structure, but you’ll struggle to explain why particular choices were made over the alternatives — and the why is what matters.
Contents
Source
Mark Richards & Neal Ford, Fundamentals of Software Architecture, Preface and Chapter 1.