Facilitating Software Architecture

Book description

The software architect role is evolving. As systems and distributed teams become more complex, it's often impossible for architects to be everywhere they need to be. To be effective, consultants and in-house architects alike have to move constantly from client to client or team to team to collaborate and work with code. And the situation is reaching a breaking point.

There's a better way. Andrew Harmel-Law, tech principal at Thoughtworks, shows you how architects and development teams can collaborate effectively and efficiently on the architectures of their systems. Techniques in this book help you ensure that everyone and everything is working toward the same goal. You'll learn how to create a collaborative, decentralized mindset that allows everyone to do architecture and build the best systems they've ever experienced.

With this book, you will:

  • Understand the new dynamics that affect modern software delivery and how to take advantage of them to optimize for fast flow and continuous feedback
  • Learn a methodology that brings software architecture and development together in partnership
  • Nurture the fundamental interplay of decisions, advice, autonomy, and architecture
  • Initiate practices and constraints that maximize benefits and mitigate risks
  • Create an approach tuned to your skill sets, architecture, and your organization's engineering culture
  • Identify and work to prevent failure modes when they threaten to arise

Publisher resources

View/Submit Errata

Table of contents

  1. Brief Table of Contents (Not Yet Final)
  2. 1. Centralized Architecture Practices in a Decentralised World
    1. Both the Practice and End-Result of Software Architecture are Essential
    2. What are the Traditional Architecture Practices?
    3. The Five Software Revolutions
    4. The Effect of the Software Revolutions on Architecture Practice
      1. The rise of decentralization
      2. Teams work best when decentralized
      3. Modern software works best when intentionally decentralized
      4. The decentralization of teams and their software must be aligned
      5. Centralized architectures and practices cause blocking and are inefficient
      6. Traditional architecture practices block delivery flow
      7. Traditional architecture practices fail to factor in sufficient feedback
    5. The Need for a New Approach to Architecture
      1. Architecture cannot protect against the forces of chaos
      2. Architectures should acknowledge complexity
      3. Architects should respond to emergence
    6. Conclusion
  3. 2. To Practice Architecture Is to Decide
    1. Decisions are the core of software architecture
    2. What Constitutes an “Architectural” Decision?
      1. Structure
      2. Cross-functional characteristics
      3. Dependencies
      4. Interfaces
      5. Construction techniques
      6. Some examples of architectural and non-architectural decisions
      7. Who makes these architectural decisions?
    3. Architecturally significant decisions
      1. What makes an architectural decision “significant”?
      2. Who decides, and how long they take to decide is irrelevant to architectural significance
      3. “Architectural significance” is in relation to deployed software
      4. Some examples of significant architectural decisions
    4. Conclusion
  4. 3. Decisions at Scale
    1. Decision Processes
      1. Stage 1: Decision required
      2. Stage 2: The act of deciding
      3. Stage 3: Decision implemented
      4. Where does the power balance lie in decision processes?
    2. Traditional architectural approaches insufficiently expose teams to the “making” stage of the decision process
    3. Decision Processes at Scale
      1. Standard approaches to decisions at scale
      2. Decision processes in a post-revolutionary world
    4. Conclusion
  5. 4. The Architecture Advice Process
    1. The Need for a Faster, Decentralized Decision Process
    2. The Architecture Advice Process: One Rule, Two Advice-Offering Groups, and One Contract
      1. The Architecture Advice Process is fast
      2. The Architecture Advice Process is decentralized
      3. The Architecture Advice Process gives rise to a social contract
    3. Decision-Triggers in the Architecture Advice Process
      1. Scenario 1: A development team needs a decision
      2. Scenario 2: A decision arises from the overall architecture
    4. The Centrality of Advice
      1. Advice is suggested direction plus reasoning
      2. Advice powers up and empowers decision-takers
      3. Offering advice does not make you accountable. Taking decisions does
    5. The Importance of Conversations
    6. The Significance of Trust
    7. Conclusion
  6. 5. Rolling out the Architecture Advice Process
    1. First Steps
      1. If you already have decision-taking authority
      2. If you currently lack decision-taking authority
      3. Regardless of where you begin, start small
    2. Overcoming Early-Stage Challenges
      1. Explain the Architecture Advice Process to everyone involved
      2. Source advice from the right people
      3. Ask the right people and find out “why?”
      4. Make accountability explicit
    3. Retrospectives are a Superb Learning Tool
    4. Confidence concerns arising from the advice process
      1. Lack of confidence in your and others’ decision-making skills
      2. Lack of confidence in the advice seeking and offering
      3. Lack of confidence in knowing everything that is happening
    5. Conclusion
  7. 6. Architectural Decision Records
    1. Introducing Architecture Decision Records
    2. The Structure of an ADR
      1. Title
      2. Meta elements
      3. Decision
      4. Context
      5. Options
      6. Consequences
      7. Advice
    3. Experiment with Your ADR Template
    4. Drafting an ADR to Support Deciding
      1. Step 1: Create your empty ADR and set its metadata
      2. Step 2: Write the Context
      3. Step 3: Make Options and gather their Consequences
      4. Step 4: Propose a selected Option
    5. Using ADRs to Facilitate the Advice Process
      1. When and how to seek advice
      2. Setting up the Advice section
      3. Gathering Advice
      4. Updating the ADR to reflect the contributions of others
    6. Taking Your Decision and Completing the ADR
      1. Select the decision option
      2. Write your Decision section
      3. Change the ADR status to “Accepted”
      4. Sharing the decision
    7. The ADR Lifecycle
      1. Standard statuses: Draft, Proposed, Accepted, and Superseded
      2. Non-standard ADR statuses
    8. Managing ADRs
      1. Fundamental aspects of managing ADRs
      2. ADRs on wikis and rich text files in source control
      3. ADRs in work-ticketing systems
    9. Curating ADRs
    10. Conclusion
  8. 7. Nurturing and Evolving Your Decentralized Culture
    1. The Grand Resetting
      1. What the reset removes
      2. The resetting is compatible with existing architecture frameworks
      3. Explicit ADR accountability is a check to the reckless
      4. Teams have permission to decide, but are not obligated to
    2. Protecting the Architectural Practice Space
      1. Deliberately including “just enough” supporting elements
      2. Understanding the impact of culture on trust
    3. Decentralized Trust at Scale
      1. Understand the dynamics of trust as you scale
      2. Adopt supporting elements to protect the space for trust
    4. Embarking on Organizational Learning
      1. Check your motivation before you add anything
      2. Netflix: An example of the flow-finding mindset
      3. Beware the siren songs of “certainty” and “predictability”
      4. Experiment to find your organization’s flow
    5. The BOSSAnova experimentation method
      1. Where do the probes come from?
      2. Running experiments
      3. Act on the results
    6. Conclusion
  9. 8. An Architecture Advice Forum
    1. Optimizing the Architecture Advice Process
    2. Introducing the Architecture Advice Forum
      1. A simple standing agenda
      2. How an advice forum differs from traditional architecture meetings
    3. Running an Architecture Advice Forum
      1. Before an Architecture Advice Forum
      2. A simple standing agenda
      3. Opening an Architecture Advice Forum session
      4. Introducing an ADR
      5. Offering and receiving of advice
      6. Recording the advice
    4. Social Dynamics at the Advice Forum
      1. Architectural interactions are adversarial and hierarchical by default
      2. “Coalescent argumentation” - an alternative to “adversarial argument”
      3. The Architectural Advice Process and ADRs as a coalescent approach to deciding
    5. Advice Forums Catalyze Powerful Group Dynamics
      1. The experience for advice offerers
      2. The experience for advice seekers
      3. The experience for learning observers
      4. The shared participation in concrete creativity
    6. Architectural Advice Forums Foster Conceptual Integrity and Social Cohesion
      1. Decentralizing execution while centralizing coordination
      2. Deep domain expertise - when centralization works best
      3. Transparency for social cohesion and trust
      4. The strengthening ritual of cadence
    7. Kicking off the Advice Process with an Advice Forum
      1. Terms of reference
      2. If you’re using the Advice Forum to kick off the Advice Process
      3. Who convenes the first Advice Forum?
      4. How the first advice forum will differ from subsequent ones
    8. Alternative Advice Forum Flavors
      1. Ideas to remove
      2. Ideas to add
      3. When to experiment?
    9. Conclusion
  10. About the Author

Product information

  • Title: Facilitating Software Architecture
  • Author(s): Andrew Harmel-Law
  • Release date: March 2025
  • Publisher(s): O'Reilly Media, Inc.
  • ISBN: 9781098151867