book

Facilitating Software Architecture

by Andrew Harmel-Law

November 2024

Intermediate to advanced

512 pages

16h 49m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Includes

Includes Quizzes

Who Should Read This BookWhy I Wrote This BookNavigating This BookConventions Used in This BookSupplemental MaterialO’Reilly Online LearningHow to Contact UsAcknowledgments
Both the Practice and the End Result of Software Architecture Are Essential for SuccessWhat Are the Practices of Traditional Architecture?Ivory Tower ArchitectsHands-on ArchitectsWhat’s Wrong with Both Traditional Approaches?Five Revolutions Unlocked the Power of SoftwareThe Effects of the Five Revolutions on Architecture PracticeThe Rise of DecentralizationThe Fall of Centralized Architecture PracticesWhat Must Any New Practice of Architecture Provide?No Approach Can Protect Against the Forces of ChaosArchitectures Should Embrace UncertaintyArchitectures Should Allow for EmergenceConclusion
Decisions Are the Core of Software ArchitectureWhat Constitutes an Architectural Decision?StructureCross-Functional CharacteristicsDependenciesInterfacesConstruction TechniquesSome Examples of Architectural and Nonarchitectural DecisionsWho Makes These Architectural Decisions?Architecturally Significant DecisionsWhat Makes an Architectural Decision “Significant”?What Shouldn’t Be Considered Regarding Architectural Significance?Architectural Significance in Relation to Deployed SoftwareSome Examples of Significant Architectural DecisionsConclusion
Decision ProcessesStage 1: Decision RequiredStage 2: The Act of DecidingStage 3: Decision ImplementedWhere Does the Power Balance Lie in Decision Processes?Traditional Architectural Approaches Insufficiently Expose Teams to the Option-Making Stage of the Decision ProcessDecision Processes at ScaleStandard Approaches to Decisions at ScaleDecision Processes in a Revolutionized WorldConclusion
The Need for a Faster, Decentralized Decision ProcessThe Architecture Advice Process: One Rule, Two Advice-Offering Groups, and One ContractThe Architecture Advice Process Is FastThe Architecture Advice Process Is DecentralizedThe Architecture Advice Process Gives Rise to a Social ContractTwo Examples of the Architecture Advice Process in ActionStory 1: A Development Team Decides to Use Release TogglesStory 2: An Architect Decides to Unpick a Workflow ProblemThe Centrality of AdviceAdvice Is Suggested Direction Plus ReasoningAdvice Powers Up Option Makers and Decision TakersOffering Advice Does Not Make You Accountable—Taking Decisions DoesThe Importance of ConversationsThe Significance of TrustConclusion
First StepsIf You Already Have Decision-Taking PowerIf You Currently Lack Decision-Taking PowerRegardless of Where You Begin, Start SmallOvercoming Early-Stage ChallengesExplain the Architecture Advice Process to Everyone InvolvedSource Advice from the Right PeopleAsk the Right People and Find Out “Why?”Make Who Is Accountable for Each Decision ExplicitConfidence Concerns Arising from the Architecture Advice ProcessLack of Confidence in Your and Others’ Deciding SkillsLack of Confidence in Advice Seeking and OfferingLack of Confidence in Knowing Everything That Is HappeningConclusion
Introducing Architectural Decision RecordsThe Structure of an ADRTitleMeta-ElementsDecisionContextOptionsConsequencesAdviceDrafting an ADR to Support DecidingStep 1: Create Your Empty ADR and Set Its MetadataStep 2: Write the ContextStep 3: Make Options and Gather Their ConsequencesStep 4: Propose a Selected OptionUsing ADRs to Facilitate the Advice ProcessWhen and How to Seek AdviceSetting Up the Advice SectionGathering AdviceUpdating the ADR to Reflect the Contributions of OthersTaking Your Decision and Completing the ADRSelect the Decision OptionWrite Your Decision Section and Update Your TitleChange the ADR Status to AcceptedShare the DecisionThe ADR LifecycleStandard Statuses: Draft, Proposed, Accepted, and SupersededNonstandard ADR StatusesManaging ADRsFundamental Aspects of Managing ADRsADRs on Wikis and Rich Text Files in Source ControlADRs in Work-Ticketing SystemsCurating ADRsConclusion

Responsibility and Accountability Have MovedMost Traditional Governance Practices Become ObsoleteThe Advice Process Is Compatible with Existing Enterprise Architecture FrameworksExplicit ADR Accountability Is a Check to the RecklessTeams Are Not Obligated to DecideThe Architectural Practice Space Opens UpKeeping Space for a Culture of Learning and TrustTwo Examples of Trust (or Lack of It) in ActionYou Can’t Assume a Culture of Trust and Learning Will AppearA Culture of Trust and Learning Must Be Carefully NurturedUnderstand the Changing Dynamics at Different Org SizesAdopt Supporting Elements to Protect the Space for TrustProtecting the Architectural Practice SpaceThere Is No Standard Prescription for the Supporting ElementsMake Any Supporting Element YoursCheck Your Motivation Before You Add AnythingNetflix: An Example of the Flow-Finding MindsetBeware the Siren Songs of Certainty and PredictabilityExperiment to Find Your Organization’s FlowConclusion
Introducing the Architecture Advice ForumA Simple Standing AgendaHow an Advice Forum Differs from Traditional Architecture MeetingsRunning an Architecture Advice ForumBefore an Architecture Advice ForumSharing the AgendaOpening an Architecture Advice Forum SessionIntroducing an ADROffering and Receiving of AdviceRecording the AdviceSocial Dynamics at the Advice ForumArchitectural Interactions Are Adversarial and Hierarchical by DefaultCoalescent Argumentation: An Alternative to Adversarial ArgumentThe Architecture Advice Process and ADRs as a Coalescent Approach to DecidingAdvice Forums Catalyze Powerful Group DynamicsThe Experience for Advice OfferersThe Experience for Advice SeekersThe Experience for Learning ObserversShared Participation in Concrete CreativityArchitecture Advice Forums Foster Conceptual Integrity and Social CohesionDecentralizing Execution While Centralizing CoordinationDeep Domain Expertise: When Centralization Works BestTransparency for Social Cohesion and TrustThe Strengthening Ritual of CadenceKicking Off the Advice Process with an Advice ForumTerms of ReferenceIf You’re Using the Advice Forum to Kick Off the Advice ProcessWho Convenes the First Advice Forum?How the First Advice Forum Will Differ from Subsequent OnesConclusion
The Importance of Organizational AlignmentAlignment Doesn’t Guarantee EffectivenessDetecting Insufficient Organizational AlignmentFour Means of AlignmentYou’re Aligned When You’re Not SurprisedMinimum Viable AgreementCross-Functional RequirementsTechnology StrategyWorking Toward Your Organization’s Minimal Viable AgreementConclusion
Source Architectural Principles from Everyone InvolvedExamples of Architectural PrinciplesCharacteristics of Good Architectural PrinciplesCharacteristics of Poor Architectural PrinciplesPrinciples Can Be Cross-Functional Requirements in DisguiseArchitectural Principles Complement an Advice Process and ADRsCapturing Your Architectural Principles with a Principles WorkshopPreparing the Inputs for Your Principles WorkshopSetting Up Your Principles WorkshopRunning Your Principles WorkshopPresenting Your Principles Ready for UseKeeping Principles UsefulFeedback from Decisions Should Affect Architectural PrinciplesUpdating and Maintaining PrinciplesFeedback from Decisions Might Affect Technical StrategyConclusion
Sense Tech Trends and Capture GuidelinesTechnology Radars Continually Collect and Share GuidanceHow the Thoughtworks Technology Radar WorksYour Internal Technology Radar Will Be Structured DifferentlyYour Radar’s Place in an Advice ProcessCreating Your Technology RadarBlip GatheringBlip Sorting and ValidationBlip FocusingBlip PositioningBlip DocumentingRadar PublishingUpdating Your BlipsPeriodic ResweepsAd Hoc Updates Based on Shared ExperienceCapturing Previous Blips and Their HistoryConclusion
The Importance of the Softer SideFraming the ContextExcluding Is as Important as IncludingQuestions That Improve Judgment Around FramingInvolve the Right StakeholdersDiscerning Options and Their ConsequencesDon’t Let the Frame Limit Your CreativitySeek InspirationSharpen Context and Options with AdviceDevelop Your MetacognitionExercise 1: Share Your ReasonsExercise 2: Are You Reacting or Responding?Exercise 3: Intentionally Seek Advice That Challenges YouCoping with Uncooperative IndividualsSelecting a Decision OptionOvercoming FearOvercoming BiasTaking the DecisionWhen You Are Taking the DecisionWhen Others Are Taking the DecisionConclusion
The Effect of Variability on the Practice of ArchitectureVariability Makes Developing Systems DifficultVariability Is the Lifeblood of Software DevelopmentWorking Effectively with Architectural VariabilityTackle Variability by Taking and Testing Decisions RapidlyTest Decisions Deeply Using Their Functional ContextUse Walking Skeletons to Test Your Earliest Decisions in Their Functional ContextTackle Variability with Smaller DecisionsThe Impact of Architectural Decisions on Future FlowGood Technical Infrastructure Enables Small DecisionsGood Sociotechnical Infrastructure Enables Small Decisions TooUse the Advice Process to Decouple Decisions for FlowEnlisting Variability to Combat Risk and Uncover ValueFast and Wrong Is Better Than Slow and CorrectWatch the OutliersSequence the Most Valuable Decisions FirstConclusion
Finding a Path Through VariabilityIntroducing SpikesSpikes Can Tackle Architectural Variability More CheaplyWhere Do Spikes Sit in a Decision Process?Spiking ADRsSpiked ADRs Still Follow the Advice ProcessExamining the Interconnectedness of DecisionsDecisions Are a SeriesDecisions Are an Inverted HierarchyDecisions Are AtomicDecisions Are Two-Way ConversationsInterrelated Decisions Are Socially ComplicatedConclusion
Power Transitions Are Never StraightforwardThe Transition for Those Who Gain PowerDoes Everyone Believe They Have the Power to Decide?Does Everyone Understand Their Accountabilities?Why Aren’t People Taking the Power Available to Them?The Importance of SafetyThe Transition for Those Who Must Share Their PowerFear Within Those Who Gave Power AwayThe Behavior of Those Who Don’t Like the Fact That Power Got SharedTransitions Are UncomfortableConclusion
Misconceptions About LeadershipMisconception 1: Leadership Is InnateMisconception 2: Leadership Is Tied to HierarchyMisconception 3: Leadership Is UnidirectionalMisconception 4: Leadership Is ManagementWhat Leadership IsDeming’s 14 PointsServant LeadershipAdaptive LeadershipLeader-Leader LeadershipChallenges with Transitioning to Leader-Leader LeadershipThe Need for Ongoing Moral LeadershipResponding to Moral ChallengesBe Sensitive of—But Not Beholden to–All Your Current CulturesThere Are No “Permanent Leaders”Conclusion
The Software Engineering SubcultureReason 1: Software Development Doesn’t Follow Standard Mental Models for CreationReason 2: Rates of Change in IT Departments Are Far Greater Than Anywhere ElseReason 3: The Touch Points Between Software Engineering and the Rest of the Org Are Few and DistinctReason 4: The Cultural Divide Between Software Engineering and the Rest of the Org Is Already AcceptedAdvice Process BubblesBubbles Are Evident Only to Those Looking for ThemBubbles Self-OrganizeBubbles Are PermeableExternal Expectations on Those Within the BubbleSelf-Evident ExpectationsLess-Evident ExpectationsBubbles Present an Interface Independent of ImplementationThe Bubble’s Interface ContractMake the Valuable Translation Work ExplicitGrowing BubblesIncremental Growth, Team by TeamEnsure You Protect the Core Goals of Your Architectural PracticeDividing Bubbles When They Get Too BigNothing Can Grow ForeverDivide a Bubble When the Core Goals of Your Architectural Practice Are ThreatenedHow to Divide Your BubbleStaying Aligned Across BubblesProtect and Encourage Differences Between BubblesConclusion

Content preview from Facilitating Software Architecture

Part II. Nurturing and Evolving Your Culture of Decentralized Trust

In Part I, you learned about combining the architecture advice process with ADRs to form the basis of a collective practice of architecture. In Part II, we’ll take this a step further by looking at the elements that can support your decentralized architectural deciding by nurturing and evolving your culture of trust.

Chapter 7 begins by taking a step back, exploring how power centers and governance are reset when the advice process is introduced. It considers where accountability for decisions moves (to the decision initiator and taker) and how the space it opens up for a culture of trust to develop needs to be consciously protected.

But how? With one or more optional supporting elements. In the remaining chapters of Part II, I describe a number of these supporting elements. Each of them acknowledges a particular systemic need you might be experiencing. As with the architecture advice process and ADRs, these supporting elements are deceptively simple, and the chapters that present them incorporate discussion about what they might contain and how they might land, fit, evolve, and potentially become redundant.

Chapter 8 introduces the first supporting element, which flips standard architectural sign-off meetings into an architecture advice forum: a focused space for conversations, advice, transparency, trust building, and group and organizational learning.

Chapter 9 then shines a light on a pair of areas frequently ...