Facilitating Software Architecture

Spis treści książki

• Foreword
• Preface
  • Who Should Read This Book
  • Why I Wrote This Book
  • Navigating This Book
  • Conventions Used in This Book
  • Supplemental Material
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• 1. Centralized Architecture Practices in a Decentralized World
  • Both the Practice and the End Result of Software Architecture Are Essential for Success
  • What Are the Practices of Traditional Architecture?
    • Ivory Tower Architects
    • Hands-on Architects
    • Whats Wrong with Both Traditional Approaches?
  • Five Revolutions Unlocked the Power of Software
  • The Effects of the Five Revolutions on Architecture Practice
    • The Rise of Decentralization
      • Teams work best when decentralized
      • Modern software works best when intentionally decentralized
      • Decentralized teams and their software must be aligned
    • The Fall of Centralized Architecture Practices
      • Traditional architecture practices block delivery flow
      • Traditional architecture practices fail to factor in sufficient feedback
      • Traditional architecture practices are incompatible with a decentralized world
  • What Must Any New Practice of Architecture Provide?
    • No Approach Can Protect Against the Forces of Chaos
    • Architectures Should Embrace Uncertainty
    • Architectures Should Allow for Emergence
  • Conclusion
• I. First Principles
• 2. To Practice Architecture Is to Decide
  • Decisions Are the Core of Software Architecture
  • What Constitutes an Architectural Decision?
    • Structure
    • Cross-Functional Characteristics
    • Dependencies
    • Interfaces
    • Construction Techniques
    • Some Examples of Architectural and Nonarchitectural Decisions
      • Architectural decisions
      • Nonarchitectural decisions
    • Who Makes These Architectural Decisions?
  • Architecturally Significant Decisions
    • What Makes an Architectural Decision Significant?
    • What Shouldnt Be Considered Regarding Architectural Significance?
    • Architectural Significance in Relation to Deployed Software
    • Some Examples of Significant Architectural Decisions
      • Architecturally significant decisions
      • Not architecturally significant decisions
  • Conclusion
• 3. Decisions at Scale
  • Decision Processes
    • Stage 1: Decision Required
    • Stage 2: The Act of Deciding
      • Step 2a: Making your set of decision options
      • Step 2b: Taking your decision
      • Step 2c (optional): Sharing your decision
    • Stage 3: Decision Implemented
    • Where Does the Power Balance Lie in Decision Processes?
  • Traditional Architectural Approaches Insufficiently Expose Teams to the Option-Making Stage of the Decision Process
  • Decision Processes at Scale
    • Standard Approaches to Decisions at Scale
      • Centralized decision processes
        • Autocratic decision process
        • Delegation decision process
        • Consultative decision process
      • Decentralized decision processes
        • Consent decision process
        • Democratic decision process
        • Consensus decision process
      • Avoidant decision process
    • Decision Processes in a Revolutionized World
      • What makes a decision method fast to respond?
      • What makes a decision method decentralized in decision rights?
      • What are the requirements for a decision process fit for the revolutionized world?
  • Conclusion
• 4. The Architecture Advice Process
  • The Need for a Faster, Decentralized Decision Process
  • The Architecture Advice Process: One Rule, Two Advice-Offering Groups, and One Contract
    • The Architecture Advice Process Is Fast
    • The Architecture Advice Process Is Decentralized
    • The Architecture Advice Process Gives Rise to a Social Contract
  • Two Examples of the Architecture Advice Process in Action
    • Story 1: A Development Team Decides to Use Release Toggles
    • Story 2: An Architect Decides to Unpick a Workflow Problem
  • The Centrality of Advice
    • Advice Is Suggested Direction Plus Reasoning
    • Advice Powers Up Option Makers and Decision Takers
    • Offering Advice Does Not Make You AccountableTaking Decisions Does
  • The Importance of Conversations
  • The Significance of Trust
  • Conclusion
• 5. Rolling Out the Architecture Advice Process
  • First Steps
    • If You Already Have Decision-Taking Power
    • If You Currently Lack Decision-Taking Power
    • Regardless of Where You Begin, Start Small
  • Overcoming Early-Stage Challenges
    • Explain the Architecture Advice Process to Everyone Involved
    • Source Advice from the Right People
    • Ask the Right People and Find Out Why?
      • Dangers of seeking advice only via established, hierarchical relationships
      • Seek advice from those with conflicting views
    • Make Who Is Accountable for Each Decision Explicit
      • If you take on the responsibility to decide, you are solely accountable
      • Not everyone is ready for accountability
  • Confidence Concerns Arising from the Architecture Advice Process
    • Lack of Confidence in Your and Others Deciding Skills
    • Lack of Confidence in Advice Seeking and Offering
    • Lack of Confidence in Knowing Everything That Is Happening
  • Conclusion
• 6. Architectural Decision Records
  • Introducing Architectural Decision Records
  • The Structure of an ADR
    • Title
    • Meta-Elements
    • Decision
    • Context
    • Options
    • Consequences
    • Advice
  • Drafting an ADR to Support Deciding
    • Step 1: Create Your Empty ADR and Set Its Metadata
    • Step 2: Write the Context
    • Step 3: Make Options and Gather Their Consequences
    • Step 4: Propose a Selected Option
  • Using ADRs to Facilitate the Advice Process
    • When and How to Seek Advice
      • Early in the decision process
      • Later in the decision process
      • Advice can relate to any part of the decision
      • More than once and when necessary
    • Setting Up the Advice Section
    • Gathering Advice
    • Updating the ADR to Reflect the Contributions of Others
  • Taking Your Decision and Completing the ADR
    • Select the Decision Option
    • Write Your Decision Section and Update Your Title
    • Change the ADR Status to Accepted
    • Share the Decision
  • The ADR Lifecycle
    • Standard Statuses: Draft, Proposed, Accepted, and Superseded
    • Nonstandard ADR Statuses
      • Expired status
      • Retired status
      • Rejected status
  • Managing ADRs
    • Fundamental Aspects of Managing ADRs
    • ADRs on Wikis and Rich Text Files in Source Control
    • ADRs in Work-Ticketing Systems
  • Curating ADRs
  • Conclusion
• II. Nurturing and Evolving Your Culture of Decentralized Trust
• 7. Replacing Hierarchy with Decentralized Trust
  • Responsibility and Accountability Have Moved
    • Most Traditional Governance Practices Become Obsolete
    • The Advice Process Is Compatible with Existing Enterprise Architecture Frameworks
    • Explicit ADR Accountability Is a Check to the Reckless
    • Teams Are Not Obligated to Decide
  • The Architectural Practice Space Opens Up
  • Keeping Space for a Culture of Learning and Trust
    • Two Examples of Trust (or Lack of It) in Action
    • You Cant Assume a Culture of Trust and Learning Will Appear
    • A Culture of Trust and Learning Must Be Carefully Nurtured
    • Understand the Changing Dynamics at Different Org Sizes
      • High trust in small groups
      • Upsetting the trust balance
      • Growth-triggered distrust
    • Adopt Supporting Elements to Protect the Space for Trust
  • Protecting the Architectural Practice Space
    • There Is No Standard Prescription for the Supporting Elements
    • Make Any Supporting Element Yours
    • Check Your Motivation Before You Add Anything
    • Netflix: An Example of the Flow-Finding Mindset
    • Beware the Siren Songs of Certainty and Predictability
    • Experiment to Find Your Organizations Flow
  • Conclusion
• 8. An Architecture Advice Forum
  • Introducing the Architecture Advice Forum
    • A Simple Standing Agenda
    • How an Advice Forum Differs from Traditional Architecture Meetings
  • Running an Architecture Advice Forum
    • Before an Architecture Advice Forum
    • Sharing the Agenda
    • Opening an Architecture Advice Forum Session
    • Introducing an ADR
    • Offering and Receiving of Advice
    • Recording the Advice
  • Social Dynamics at the Advice Forum
    • Architectural Interactions Are Adversarial and Hierarchical by Default
    • Coalescent Argumentation: An Alternative to Adversarial Argument
    • The Architecture Advice Process and ADRs as a Coalescent Approach to Deciding
  • Advice Forums Catalyze Powerful Group Dynamics
    • The Experience for Advice Offerers
    • The Experience for Advice Seekers
    • The Experience for Learning Observers
    • Shared Participation in Concrete Creativity
  • Architecture Advice Forums Foster Conceptual Integrity and Social Cohesion
    • Decentralizing Execution While Centralizing Coordination
    • Deep Domain Expertise: When Centralization Works Best
    • Transparency for Social Cohesion and Trust
      • Transparency means anyone can influence the many small decisions
      • Everyone gets exposure to in-flight decisions, their sequencing, and their coordination
      • Architecture advice forums actively foster trust
    • The Strengthening Ritual of Cadence
  • Kicking Off the Advice Process with an Advice Forum
    • Terms of Reference
    • If Youre Using the Advice Forum to Kick Off the Advice Process
    • Who Convenes the First Advice Forum?
    • How the First Advice Forum Will Differ from Subsequent Ones
  • Conclusion
• 9. Testable CFRs and Technology Strategy
  • The Importance of Organizational Alignment
    • Alignment Doesnt Guarantee Effectiveness
    • Detecting Insufficient Organizational Alignment
    • Four Means of Alignment
    • Youre Aligned When Youre Not Surprised
  • Minimum Viable Agreement
    • Cross-Functional Requirements
      • CFR example 1: A testable access logging requirement
      • CFR example 2: Multiple testable performance requirements
    • Technology Strategy
      • What technology strategy does
      • How technology strategy works
      • Technology strategy is a form of agreement
        • Strategy can answer a little or a lot
        • Strategy can offer a single answer or multiple answers to a given question
        • Strategic investments codify strategic direction
    • Working Toward Your Organizations Minimal Viable Agreement
  • Conclusion
• 10. Collectively Sourced Architectural Principles
  • Source Architectural Principles from Everyone Involved
    • Examples of Architectural Principles
    • Characteristics of Good Architectural Principles
    • Characteristics of Poor Architectural Principles
    • Principles Can Be Cross-Functional Requirements in Disguise
    • Architectural Principles Complement an Advice Process and ADRs
  • Capturing Your Architectural Principles with a Principles Workshop
    • Preparing the Inputs for Your Principles Workshop
      • Sourcing your organizations goals
      • Extracting three themes
    • Setting Up Your Principles Workshop
      • Identify invitees
      • Find a time for the workshop and book it
      • Prepare the workshop space
    • Running Your Principles Workshop
      • Kickoff: Goal of the workshop, goal of the organization, and key definitions (10 minutes)
      • Split: Groups break out to propose architectural principles (30 minutes)
      • Reconvene: Each group shares their initial principles (20 minutes)
      • Split: Modify principles as individual groups (30 minutes)
      • Reconvene: Groups present again, and duplicate principles are identified (20 minutes)
      • Dot-voting (first round): Everyone votes and selects 815 of the top collated principles (5 minutes)
      • Consider implications (20 minutes)
      • Dot-voting (second round): Another round of voting, and the principles are reranked (5 minutes)
      • Commit to adoption and close (10 minutes)
    • Presenting Your Principles Ready for Use
      • The Architectural Principles Hub page
      • Individual principle pages
      • Sharing the new principles hub with everyone
      • Recording the adoption of the principles as an ADR
  • Keeping Principles Useful
    • Feedback from Decisions Should Affect Architectural Principles
      • A single decision conflicts with a single principle
      • Repeated conflicts between multiple decisions and a principle are a signal to change
      • Spot missing principles and those that should be retired
    • Updating and Maintaining Principles
      • Use ADRs with a more rigorous adoption process to update your principles set
      • Maintain your set of principles
    • Feedback from Decisions Might Affect Technical Strategy
  • Conclusion
• 11. Using a Technology Radar
  • Sense Tech Trends and Capture Guidelines
  • Technology Radars Continually Collect and Share Guidance
    • How the Thoughtworks Technology Radar Works
    • Your Internal Technology Radar Will Be Structured Differently
  • Your Radars Place in an Advice Process
  • Creating Your Technology Radar
    • Blip Gathering
    • Blip Sorting and Validation
    • Blip Focusing
    • Blip Positioning
    • Blip Documenting
    • Radar Publishing
  • Updating Your Blips
    • Periodic Resweeps
    • Ad Hoc Updates Based on Shared Experience
    • Capturing Previous Blips and Their History
  • Conclusion
• III. Finding Your Way Through the Decision Landscape
• 12. The Art of Deciding
  • The Importance of the Softer Side
  • Framing the Context
    • Excluding Is as Important as Including
      • Framing the circumstances
      • Framing time
    • Questions That Improve Judgment Around Framing
    • Involve the Right Stakeholders
  • Discerning Options and Their Consequences
    • Dont Let the Frame Limit Your Creativity
    • Seek Inspiration
  • Sharpen Context and Options with Advice
  • Develop Your Metacognition
    • Exercise 1: Share Your Reasons
    • Exercise 2: Are You Reacting or Responding?
    • Exercise 3: Intentionally Seek Advice That Challenges You
    • Coping with Uncooperative Individuals
  • Selecting a Decision Option
    • Overcoming Fear
    • Overcoming Bias
  • Taking the Decision
    • When You Are Taking the Decision
    • When Others Are Taking the Decision
  • Conclusion
• 13. Tackling Architectural Variability
  • The Effect of Variability on the Practice of Architecture
    • Variability Makes Developing Systems Difficult
      • Variability is hard to work with
      • Variability comes from unpredictable places at unpredictable times
      • Variability produces cognitive load
      • Variability produces communication and synchronization load
    • Variability Is the Lifeblood of Software Development
  • Working Effectively with Architectural Variability
    • Tackle Variability by Taking and Testing Decisions Rapidly
    • Test Decisions Deeply Using Their Functional Context
    • Use Walking Skeletons to Test Your Earliest Decisions in Their Functional Context
    • Tackle Variability with Smaller Decisions
      • Benefits of reducing decision size
        • Variability is tackled earlier
        • Overhead is reduced
        • Its easier on the people involved
        • Feedback is accelerated and risk reduced
      • Splitting large decisions into multiple smaller ones
        • Understand the problem context and solution options with an ADR
        • Watch out for the similar trap and focus on what makes things different
        • Identify fracture planes
  • The Impact of Architectural Decisions on Future Flow
    • Good Technical Infrastructure Enables Small Decisions
    • Good Sociotechnical Infrastructure Enables Small Decisions Too
    • Use the Advice Process to Decouple Decisions for Flow
  • Enlisting Variability to Combat Risk and Uncover Value
    • Fast and Wrong Is Better Than Slow and Correct
    • Watch the Outliers
    • Sequence the Most Valuable Decisions First
  • Conclusion
• 14. Variability and the Interconnectedness of Decisions
  • Finding a Path Through Variability
  • Introducing Spikes
    • Spikes Can Tackle Architectural Variability More Cheaply
    • Where Do Spikes Sit in a Decision Process?
    • Spiking ADRs
      • Writing a spike
      • Playing a spike
      • Feeding a spikes outcomes into an ADR
    • Spiked ADRs Still Follow the Advice Process
  • Examining the Interconnectedness of Decisions
    • Decisions Are a Series
      • Comparing spiked and nonspiked decisions
      • Spikes are an underused way to fail safely at decision points
    • Decisions Are an Inverted Hierarchy
      • The lowest three layers of the inverted decision hierarchy
        • Decision layer 1: Independent products or programs of work
        • Decision layer 2: Protect and mark limits
        • Decision layer 3: Self-governing, connected communities
        • Some general points about decisions in layers 13
      • Identify your starting context
      • Spikes uncover key underlying decision consequences
    • Decisions Are Atomic
      • CFR interactions reveal atomic decisions
      • Spiking atomic decisions is essential early on
    • Decisions Are Two-Way Conversations
      • A decisions consequences continue to emerge after they are taken
      • The constant evolutionary pressure of supply and demand competition
      • Spikes investigate options to supersede previous underlying decisions
  • Interrelated Decisions Are Socially Complicated
  • Conclusion
• IV. Centering the Social in Your Practice of Architecture
• 15. The Transition of Power and Accountability
  • Power Transitions Are Never Straightforward
  • The Transition for Those Who Gain Power
    • Does Everyone Believe They Have the Power to Decide?
      • Does everyone believe they were given the decision power?
      • Was the transfer of decision power properly communicated?
      • Transfer power openly and learn together
    • Does Everyone Understand Their Accountabilities?
      • Accountability is all the way to done
      • Everyone wont understand everything in the same way, at the same time
      • Make the implicit (roles and responsibilities/accountabilities) explicit
    • Why Arent People Taking the Power Available to Them?
      • The long shadow of hierarchical mental models
      • Entertaining alternative mental models of organizing
    • The Importance of Safety
      • Destigmatizing failure
      • Fostering the levels of safety
        • Feeling included
        • Feeling safe enough to contribute
        • Feeling safe enough to challenge
          • Feeling safe enough to learn, including from failure
  • The Transition for Those Who Must Share Their Power
    • Fear Within Those Who Gave Power Away
      • Acknowledge fear of bad decisions
      • Celebrate all decisions
      • Pay attention to who is deciding
      • The fear of obsolescence
    • The Behavior of Those Who Dont Like the Fact That Power Got Shared
      • Power plays
      • Types of sabotage
      • The advice process plus ADRs can neutralize sabotage
  • Transitions Are Uncomfortable
  • Conclusion
• 16. On Leadership
  • Misconceptions About Leadership
    • Misconception 1: Leadership Is Innate
    • Misconception 2: Leadership Is Tied to Hierarchy
    • Misconception 3: Leadership Is Unidirectional
    • Misconception 4: Leadership Is Management
  • What Leadership Is
    • Demings 14 Points
    • Servant Leadership
    • Adaptive Leadership
      • Give the work back to the people
      • Leadership can come from anywhere
  • Leader-Leader Leadership
    • Challenges with Transitioning to Leader-Leader Leadership
      • Leadership challenge 1: Let go of the controls
      • Leadership challenge 2: Prioritize safety over specific decisions
      • Leadership challenge 3: Implement I intend to
      • Leadership challenge 4: Trust, then verify (but only if you need to)
  • The Need for Ongoing Moral Leadership
    • Responding to Moral Challenges
      • Challenges during transition to the advice process
      • Challenges when sustaining the advice process
    • Be Sensitive ofBut Not Beholden toAll Your Current Cultures
    • There Are No Permanent Leaders
  • Conclusion
• 17. Fitting the Advice Process Within Your Organization
  • The Software Engineering Subculture
    • Reason 1: Software Development Doesnt Follow Standard Mental Models for Creation
    • Reason 2: Rates of Change in IT Departments Are Far Greater Than Anywhere Else
    • Reason 3: The Touch Points Between Software Engineering and the Rest of the Org Are Few and Distinct
    • Reason 4: The Cultural Divide Between Software Engineering and the Rest of the Org Is Already Accepted
  • Advice Process Bubbles
    • Bubbles Are Evident Only to Those Looking for Them
    • Bubbles Self-Organize
      • Collective org design within bubbles
      • Org design is an ongoing process
    • Bubbles Are Permeable
  • External Expectations on Those Within the Bubble
    • Self-Evident Expectations
      • Expectation: Systems meet requirements and align to the vision and goals
      • Expectation: Systems are predictably delivered and securely operated
      • Expectation: Accountability and responsibility are explicit and transparent
    • Less-Evident Expectations
      • Expectation: Those in bubbles can answer basic hierarchical questions
      • Expectation: Appropriate skills are available in sufficient number and depth
        • Explicitly define the behaviors and contributions valued inside the bubble
        • Explicitly recognize progress and reward achievements
        • Explicitly assist in hiring and onboarding new joiners
      • Expectation: Bubble inhabitants participate in org-wide ceremonies
  • Bubbles Present an Interface Independent of Implementation
    • The Bubbles Interface Contract
    • Make the Valuable Translation Work Explicit
  • Growing Bubbles
    • Incremental Growth, Team by Team
      • Positive changes to bubble interfaces
      • Coping with external-expectation sabotage
    • Ensure You Protect the Core Goals of Your Architectural Practice
  • Dividing Bubbles When They Get Too Big
    • Nothing Can Grow Forever
    • Divide a Bubble When the Core Goals of Your Architectural Practice Are Threatened
    • How to Divide Your Bubble
      • Dividing teams
      • Dividing the advice forum
      • Dividing ADRs
      • Architectural principles dont divide initiallythey get copied
      • The technology radar doesnt divide
    • Staying Aligned Across Bubbles
    • Protect and Encourage Differences Between Bubbles
  • Conclusion
• Index

pokaż cały spis treści

ukryj recenzje