The book Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions by Andrew Harmel-Law presents a modern, decentralised, and human-centric approach to software architecture. It challenges the traditional model of a single, centralised architect (often referred to as the “Ivory Tower” architect or even the sole “Hands-on” architect) as fundamentally incompatible with the speed, complexity, and distributed nature of modern software delivery (driven by Agile, DevOps, and Cloud/Microservices revolutions).
The central thesis is that the architect’s role must evolve from a technical decision-maker into a facilitator and connector. This facilitator empowers development teams to own and make the majority of the architectural decisions, thereby eliminating the architect as a bottleneck and fostering a culture of collective ownership, accelerated learning, and systemic resilience. The book is structured around defining the problem with traditional architecture, establishing a new core practice around architectural decisions, and creating the necessary culture of trust and alignment to support this decentralised model.
Part I: First Principles: The Need for Decentralisation
1. Centralised Architecture Practices in a Decentralised World
The book begins by detailing the Five Revolutions (Agile, Cloud, DevOps, Microservices, and Continuous Delivery) that have fundamentally changed software development. These revolutions prioritise speed, autonomy, and small, iterative changes. The traditional, centralised architecture model, where a single person or small group makes all major decisions, has become a bottleneck to this speed.
Harmel-Law describes two archetypes of traditional architects:
- The “Ivory Tower” Architect: Removed from the code, they deliver grand designs that are often impractical or quickly outdated, leading to slow, non-emergent architecture.
- The “Hands-on” Architect: Deeply embedded in the code, they make excellent technical decisions but still become a bottleneck due to their limited capacity and inability to be everywhere at once.
The book argues that a new practice must:
- Embrace Uncertainty: Modern systems are complex and emergent; decisions should be seen as points in a flow, not endpoints.
- Allow for Emergence: Architecture should be a continuous stream of small, fast decisions made close to the code, not a one-time upfront design.
- Prioritise Sociotechnical Systems: Recognise that architecture is a product of human interactions and organisational structures (Conway’s Law), not just technology.
2. To Practice Architecture is to Decide
Harmel-Law redefines the essence of software architecture as the set of significant architectural decisions that shape a system. He emphasises that the “architecture” of a system is defined not by the diagrams, but by the accumulation of these impactful choices.
An Architecturally Significant Decision (ASD) is one that has a material impact on four main areas:
- Structure: Placement of function, component breakdown, and overall topology.
- Cross-Functional Characteristics (Quality Attributes): Security, performance, operability, scalability, etc.
- Dependencies and Interfaces: How components interact and what external systems are used.
- Construction Techniques: Major technology choices, frameworks, and tools.
The core shift is ensuring that the process of making these decisions is exposed, understood, and distributed throughout the development teams.
3. Decisions at Scale
To scale architecture, the decision-making process itself must be streamlined and decentralised. A complete decision process involves three stages:
- Decision Required: Identifying a need for a decision.
- The Act of Deciding: Investigating options, gathering advice, and selecting an option.
- Decision Implemented: Writing the code and observing the consequences.
The failure of centralised approaches lies in their inability to scale “The Act of Deciding,” causing delays and frustration. The solution is to introduce a lightweight, decentralised mechanism for decision-making.
4. The Architecture Advice Process
This chapter introduces the book’s signature practice: the Architecture Advice Process (AAP). Inspired by processes used in self-managing organisations (like Holacracy or Sociocracy), the AAP is designed to be fast, decentralised, and to create a social contract of accountability.
The AAP is governed by a single, crucial rule:
The person or team who is accountable for a decision must seek advice from two groups of people before implementing their decision:
- People who will be consequenced by the decision (i.e., will have to live with or maintain the outcome).
- People who have expertise in the domain of the decision.
Key attributes of the AAP:
- Speed: The accountable party can proceed once advice is sought; they do not need consensus or approval, only input.
- Decentralisation: Decision-making authority is pushed down to the team level.
- Social Contract: It formalises the expectation that teams will seek and give high-quality advice, building trust and shared understanding. The team remains accountable for the decision’s outcome, but they are obligated to learn from their peers.
5. Rolling Out the Architecture Advice Process
The implementation of the AAP requires an intentional, small-step approach, avoiding a “big bang” organisational change. The focus is on overcoming confidence concerns—both the architect’s fear of losing control and the team’s fear of taking on responsibility.
Practical steps include:
- Start Small: Apply the AAP to a single, low-risk project or a non-critical team first.
- Explain the “Why”: Continuously communicate the benefits of speed, learning, and autonomy.
- Explicit Accountability: Ensure it’s crystal clear who owns and is accountable for the decision, as this is the check against reckless behavior.
6. Architectural Decision Records (ADRs)
The AAP relies on the transparent, documented capture of the decision-making process, a practice best served by Architectural Decision Records (ADRs). ADRs are lean, lightweight documents that record a significant architectural decision, its context, the options considered, and the reasoning for the selected option.
The structure of a good ADR includes:
- Title: Concise and clear.
- Meta-Elements: Status, Decider, Date.
- Context: The problem or dilemma leading to the decision.
- Options: A list of alternatives considered.
- Consequences: The pros and cons for each option, highlighting trade-offs.
- Decision: The chosen option and the rationale for its selection.
- Advice: The input received from the two groups (consequenced and experts).
ADRs serve several critical functions:
- Shared Mental Model: They create a transparent, auditable history, replacing guesswork (“ghost decisions”) with clarity.
- Onboarding: They quickly inform new team members about the system’s history and trade-offs.
- Revisiting Decisions: They provide the necessary context to safely reconsider a decision when constraints or external factors change.
Part II: Nurturing and Evolving Your Culture of Decentralised Trust
7. Replacing Hierarchy with Decentralised Trust
Decentralising decision-making requires a deep-seated organisational culture of trust and psychological safety. The architect’s shift to facilitation is key to replacing traditional hierarchical governance with decentralised accountability.
Key components of this cultural shift:
- Shift in Accountability: Accountability moves to the team implementing the decision, but the architect (facilitator) retains responsibility for the effectiveness of the decision-making process itself.
- Keeping Space: The facilitator must actively guard the team’s decision-making space, protecting them from unnecessary, top-down interference while ensuring the AAP is followed.
- ADR Accountability as a Check: The public and explicit nature of the ADR acts as a check, preventing teams from making purely reckless choices, as they must document and justify their decision against the advice received.
8. Architectural Alignment Mechanisms
As architecture is decentralised, mechanisms are needed to prevent chaos and ensure coherence across multiple autonomous teams. Harmel-Law identifies four essential Alignment Mechanisms:
- Shared Experience and Trust: The fundamental human factor, built through practices like the AAP.
- Communities of Practice (CoP): Groups of individuals (e.g., all backend developers, all security-focused engineers) who share knowledge, mentor, and define standards across team boundaries.
- The Architecture Advice Process (AAP): The formal, lightweight process for seeking input on significant decisions.
- Technology Radar: A visualised, collectively curated list of technologies with clear guidelines (Adopt, Trial, Assess, Hold) that informs and constrains decision options. This provides guardrails without imposing mandates.
9. Learning and Evolving the Architecture
The final part of the book emphasises that architecture is not a static state but a continuous flow of decisions and learning. This continuous evolution is enabled by integrating feedback loops directly into the architecture practice:
- Feedback Loops: Collecting data from running systems (observability, metrics) and organisational processes (Team Topologies metrics) to validate or invalidate past architectural decisions.
- Revisiting ADRs: Using new information to challenge old decisions. If a consequence predicted in an old ADR did not materialise, or if a new constraint makes an old rejected option now viable, the ADR provides the basis for a new, informed decision.
- Embracing Imperfection: Recognising that the “perfect” decision is often the enemy of the “good and fast” decision. The focus should be on decisions that are good enough to start and cheap enough to change.
The book concludes that the new architect, the facilitator, is a coach, mentor, connector, and gardener. Their primary goal is not to design the system, but to design the system for making decisions and to cultivate a culture where the architecture can evolve sustainably at the pace required by the business.