Facilitating Software Architecture

Facilitating Software Architecture

by Andrew Harmel-Law
Released November 2024
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781098151867

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Buy on Amazon Buy on ebooks.com
Start your free trial

Book description

The software architect role is evolving. As systems and their interactions with the teams that build, run, and evolve them become more complex, it's often impossible for those playing the traditional architect roles to be everywhere they need to be. There's simply too much architecture to be done, and the situation has reached a breaking point.

There's a better way. Author Andrew Harmel-Law shows you how architects and development teams can collaborate to create and evolve more efficient architectures for their systems. Techniques in this book will help you learn how to create a mindset that allows everyone to practice architecture and build the best systems they've ever experienced.

With this book, you will:

  • Understand the new dynamics that affect modern software delivery
  • Learn a methodology that brings software architecture and development together
  • Nurture the fundamental interplay of decisions, advice, architecture, and feedback from running systems
  • Initiate practices that maximize benefits and mitigate risks
  • Create an approach tuned to architecture, everyone's skills, and your organization's culture

Publisher resources

View/Submit Errata

Table of contents

  1. Foreword
  2. Preface
    1. Who Should Read This Book
    2. Why I Wrote This Book
    3. Navigating This Book
    4. Conventions Used in This Book
    5. Supplemental Material
    6. O’Reilly Online Learning
    7. How to Contact Us
    8. Acknowledgments
  3. 1. Centralized Architecture Practices in a Decentralized World
    1. Both the Practice and the End Result of Software Architecture Are Essential for Success
    2. What Are the Practices of Traditional Architecture?
      1. Ivory Tower Architects
      2. Hands-on Architects
      3. What’s Wrong with Both Traditional Approaches?
    3. Five Revolutions Unlocked the Power of Software
    4. The Effects of the Five Revolutions on Architecture Practice
      1. The Rise of Decentralization
      2. The Fall of Centralized Architecture Practices
    5. What Must Any New Practice of Architecture Provide?
      1. No Approach Can Protect Against the Forces of Chaos
      2. Architectures Should Embrace Uncertainty
      3. Architectures Should Allow for Emergence
    6. Conclusion
  4. I. First Principles
  5. 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 Nonarchitectural Decisions
      7. Who Makes These Architectural Decisions?
    3. Architecturally Significant Decisions
      1. What Makes an Architectural Decision “Significant”?
      2. What Shouldn’t Be Considered Regarding Architectural Significance?
      3. Architectural Significance in Relation to Deployed Software
      4. Some Examples of Significant Architectural Decisions
    4. Conclusion
  6. 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 Option-Making Stage of the Decision Process
    3. Decision Processes at Scale
      1. Standard Approaches to Decisions at Scale
      2. Decision Processes in a Revolutionized World
    4. Conclusion
  7. 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. Two Examples of the Architecture Advice Process in Action
      1. Story 1: A Development Team Decides to Use Release Toggles
      2. Story 2: An Architect Decides to Unpick a Workflow Problem
    4. The Centrality of Advice
      1. Advice Is Suggested Direction Plus Reasoning
      2. Advice Powers Up Option Makers and 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
  8. 5. Rolling Out the Architecture Advice Process
    1. First Steps
      1. If You Already Have Decision-Taking Power
      2. If You Currently Lack Decision-Taking Power
      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 Who Is Accountable for Each Decision Explicit
    3. Confidence Concerns Arising from the Architecture Advice Process
      1. Lack of Confidence in Your and Others’ Deciding Skills
      2. Lack of Confidence in Advice Seeking and Offering
      3. Lack of Confidence in Knowing Everything That Is Happening
    4. Conclusion
  9. 6. Architectural Decision Records
    1. Introducing Architectural Decision Records
    2. The Structure of an ADR
      1. Title
      2. Meta-Elements
      3. Decision
      4. Context
      5. Options
      6. Consequences
      7. Advice
    3. 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
    4. 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
    5. Taking Your Decision and Completing the ADR
      1. Select the Decision Option
      2. Write Your Decision Section and Update Your Title
      3. Change the ADR Status to Accepted
      4. Share the Decision
    6. The ADR Lifecycle
      1. Standard Statuses: Draft, Proposed, Accepted, and Superseded
      2. Nonstandard ADR Statuses
    7. 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
    8. Curating ADRs
    9. Conclusion
  10. II. Nurturing and Evolving Your Culture of Decentralized Trust
  11. 7. Replacing Hierarchy with Decentralized Trust
    1. Responsibility and Accountability Have Moved
      1. Most Traditional Governance Practices Become Obsolete
      2. The Advice Process Is Compatible with Existing Enterprise Architecture Frameworks
      3. Explicit ADR Accountability Is a Check to the Reckless
      4. Teams Are Not Obligated to Decide
    2. The Architectural Practice Space Opens Up
    3. Keeping Space for a Culture of Learning and Trust
      1. Two Examples of Trust (or Lack of It) in Action
      2. You Can’t Assume a Culture of Trust and Learning Will Appear
      3. A Culture of Trust and Learning Must Be Carefully Nurtured
      4. Understand the Changing Dynamics at Different Org Sizes
      5. Adopt Supporting Elements to Protect the Space for Trust
    4. Protecting the Architectural Practice Space
      1. There Is No Standard Prescription for the Supporting Elements
      2. Make Any Supporting Element Yours
      3. Check Your Motivation Before You Add Anything
      4. Netflix: An Example of the Flow-Finding Mindset
      5. Beware the Siren Songs of Certainty and Predictability
      6. Experiment to Find Your Organization’s Flow
    5. Conclusion
  12. 8. An Architecture Advice Forum
    1. Introducing the Architecture Advice Forum
      1. A Simple Standing Agenda
      2. How an Advice Forum Differs from Traditional Architecture Meetings
    2. Running an Architecture Advice Forum
      1. Before an Architecture Advice Forum
      2. Sharing the Agenda
      3. Opening an Architecture Advice Forum Session
      4. Introducing an ADR
      5. Offering and Receiving of Advice
      6. Recording the Advice
    3. 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 Architecture Advice Process and ADRs as a Coalescent Approach to Deciding
    4. 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. Shared Participation in Concrete Creativity
    5. Architecture 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
    6. 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
    7. Conclusion
  13. 9. Testable CFRs and Technology Strategy
    1. The Importance of Organizational Alignment
      1. Alignment Doesn’t Guarantee Effectiveness
      2. Detecting Insufficient Organizational Alignment
      3. Four Means of Alignment
      4. You’re Aligned When You’re Not Surprised
    2. Minimum Viable Agreement
      1. Cross-Functional Requirements
      2. Technology Strategy
      3. Working Toward Your Organization’s Minimal Viable Agreement
    3. Conclusion
  14. 10. Collectively Sourced Architectural Principles
    1. Source Architectural Principles from Everyone Involved
      1. Examples of Architectural Principles
      2. Characteristics of Good Architectural Principles
      3. Characteristics of Poor Architectural Principles
      4. Principles Can Be Cross-Functional Requirements in Disguise
      5. Architectural Principles Complement an Advice Process and ADRs
    2. Capturing Your Architectural Principles with a Principles Workshop
      1. Preparing the Inputs for Your Principles Workshop
      2. Setting Up Your Principles Workshop
      3. Running Your Principles Workshop
      4. Presenting Your Principles Ready for Use
    3. Keeping Principles Useful
      1. Feedback from Decisions Should Affect Architectural Principles
      2. Updating and Maintaining Principles
      3. Feedback from Decisions Might Affect Technical Strategy
    4. Conclusion
  15. 11. Using a Technology Radar
    1. Sense Tech Trends and Capture Guidelines
    2. Technology Radars Continually Collect and Share Guidance
      1. How the Thoughtworks Technology Radar Works
      2. Your Internal Technology Radar Will Be Structured Differently
    3. Your Radar’s Place in an Advice Process
    4. Creating Your Technology Radar
      1. Blip Gathering
      2. Blip Sorting and Validation
      3. Blip Focusing
      4. Blip Positioning
      5. Blip Documenting
      6. Radar Publishing
    5. Updating Your Blips
      1. Periodic Resweeps
      2. Ad Hoc Updates Based on Shared Experience
      3. Capturing Previous Blips and Their History
    6. Conclusion
  16. III. Finding Your Way Through the Decision Landscape
  17. 12. The Art of Deciding
    1. The Importance of the Softer Side
    2. Framing the Context
      1. Excluding Is as Important as Including
      2. Questions That Improve Judgment Around Framing
      3. Involve the Right Stakeholders
    3. Discerning Options and Their Consequences
      1. Don’t Let the Frame Limit Your Creativity
      2. Seek Inspiration
    4. Sharpen Context and Options with Advice
    5. Develop Your Metacognition
      1. Exercise 1: Share Your Reasons
      2. Exercise 2: Are You Reacting or Responding?
      3. Exercise 3: Intentionally Seek Advice That Challenges You
      4. Coping with Uncooperative Individuals
    6. Selecting a Decision Option
      1. Overcoming Fear
      2. Overcoming Bias
    7. Taking the Decision
      1. When You Are Taking the Decision
      2. When Others Are Taking the Decision
    8. Conclusion
  18. 13. Tackling Architectural Variability
    1. The Effect of Variability on the Practice of Architecture
      1. Variability Makes Developing Systems Difficult
      2. Variability Is the Lifeblood of Software Development
    2. Working Effectively with Architectural Variability
      1. Tackle Variability by Taking and Testing Decisions Rapidly
      2. Test Decisions Deeply Using Their Functional Context
      3. Use Walking Skeletons to Test Your Earliest Decisions in Their Functional Context
      4. Tackle Variability with Smaller Decisions
    3. The Impact of Architectural Decisions on Future Flow
      1. Good Technical Infrastructure Enables Small Decisions
      2. Good Sociotechnical Infrastructure Enables Small Decisions Too
      3. Use the Advice Process to Decouple Decisions for Flow
    4. Enlisting Variability to Combat Risk and Uncover Value
      1. Fast and Wrong Is Better Than Slow and Correct
      2. Watch the Outliers
      3. Sequence the Most Valuable Decisions First
    5. Conclusion
  19. 14. Variability and the Interconnectedness of Decisions
    1. Finding a Path Through Variability
    2. Introducing Spikes
      1. Spikes Can Tackle Architectural Variability More Cheaply
      2. Where Do Spikes Sit in a Decision Process?
      3. Spiking ADRs
      4. Spiked ADRs Still Follow the Advice Process
    3. Examining the Interconnectedness of Decisions
      1. Decisions Are a Series
      2. Decisions Are an Inverted Hierarchy
      3. Decisions Are Atomic
      4. Decisions Are Two-Way Conversations
    4. Interrelated Decisions Are Socially Complicated
    5. Conclusion
  20. IV. Centering the “Social” in Your Practice of Architecture
  21. 15. The Transition of Power and Accountability
    1. Power Transitions Are Never Straightforward
    2. The Transition for Those Who Gain Power
      1. Does Everyone Believe They Have the Power to Decide?
      2. Does Everyone Understand Their Accountabilities?
      3. Why Aren’t People Taking the Power Available to Them?
      4. The Importance of Safety
    3. The Transition for Those Who Must Share Their Power
      1. Fear Within Those Who Gave Power Away
      2. The Behavior of Those Who Don’t Like the Fact That Power Got Shared
    4. Transitions Are Uncomfortable
    5. Conclusion
  22. 16. On Leadership
    1. Misconceptions About Leadership
      1. Misconception 1: Leadership Is Innate
      2. Misconception 2: Leadership Is Tied to Hierarchy
      3. Misconception 3: Leadership Is Unidirectional
      4. Misconception 4: Leadership Is Management
    2. What Leadership Is
      1. Deming’s 14 Points
      2. Servant Leadership
      3. Adaptive Leadership
    3. Leader-Leader Leadership
      1. Challenges with Transitioning to Leader-Leader Leadership
    4. The Need for Ongoing Moral Leadership
      1. Responding to Moral Challenges
      2. Be Sensitive of—But Not Beholden to–All Your Current Cultures
      3. There Are No “Permanent Leaders”
    5. Conclusion
  23. 17. Fitting the Advice Process Within Your Organization
    1. The Software Engineering Subculture
      1. Reason 1: Software Development Doesn’t Follow Standard Mental Models for Creation
      2. Reason 2: Rates of Change in IT Departments Are Far Greater Than Anywhere Else
      3. Reason 3: The Touch Points Between Software Engineering and the Rest of the Org Are Few and Distinct
      4. Reason 4: The Cultural Divide Between Software Engineering and the Rest of the Org Is Already Accepted
    2. Advice Process Bubbles
      1. Bubbles Are Evident Only to Those Looking for Them
      2. Bubbles Self-Organize
      3. Bubbles Are Permeable
    3. External Expectations on Those Within the Bubble
      1. Self-Evident Expectations
      2. Less-Evident Expectations
    4. Bubbles Present an Interface Independent of Implementation
      1. The Bubble’s Interface Contract
      2. Make the Valuable Translation Work Explicit
    5. Growing Bubbles
      1. Incremental Growth, Team by Team
      2. Ensure You Protect the Core Goals of Your Architectural Practice
    6. Dividing Bubbles When They Get Too Big
      1. Nothing Can Grow Forever
      2. Divide a Bubble When the Core Goals of Your Architectural Practice Are Threatened
      3. How to Divide Your Bubble
      4. Staying Aligned Across Bubbles
      5. Protect and Encourage Differences Between Bubbles
    7. Conclusion
  24. Index
  25. About the Author

Product information

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