کتاب تسهیل معماری نرم‌افزار

ممارست‌های معماری متمرکز در دنیای غیرمتمرکز

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 • What’s 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 • The Fall of Centralized Architecture Practices • 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

ممارست در معماری یعنی تصمیم‌گیری

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 • Who Makes These Architectural Decisions? • Architecturally Significant Decisions • What Makes an Architectural Decision “Significant”? • What Shouldn’t Be Considered Regarding Architectural Significance? • Architectural Significance in Relation to Deployed Software • Some Examples of Significant Architectural Decisions • Conclusion

تصمیم‌گیری در مقیاس وسیع

Decision Processes • Stage 1: Decision Required • Stage 2: The Act of Deciding • 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 • Decision Processes in a Revolutionized World • Conclusion

فرآیند مشورت معماری

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 Accountable—Taking Decisions Does • The Importance of Conversations • The Significance of Trust • Conclusion

پیاده‌سازی فرآیند مشورت معماری

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?” • Make Who Is Accountable for Each Decision Explicit • 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

سوابق تصمیمات معماری

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 • 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 • 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

جایگزینی سلسله‌مراتب با اعتماد غیرمتمرکز

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 Can’t 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 • 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 Organization’s Flow • Conclusion

مجمع مشورت معماری

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 • The Strengthening Ritual of Cadence • Kicking Off the Advice Process with an Advice Forum • Terms of Reference • If You’re 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

نیازمندی‌های غیرکارکردی قابل آزمون و استراتژی فناوری

The Importance of Organizational Alignment • Alignment Doesn’t Guarantee Effectiveness • Detecting Insufficient Organizational Alignment • Four Means of Alignment • You’re Aligned When You’re Not Surprised • Minimum Viable Agreement • Cross-Functional Requirements • Technology Strategy • Working Toward Your Organization’s Minimal Viable Agreement • Conclusion

اصول معماری گردآوری‌شده به صورت جمعی

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 • Setting Up Your Principles Workshop • Running Your Principles Workshop • Presenting Your Principles Ready for Use • Keeping Principles Useful • Feedback from Decisions Should Affect Architectural Principles • Updating and Maintaining Principles • Feedback from Decisions Might Affect Technical Strategy • Conclusion

استفاده از رادار فناوری

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 Radar’s Place in an Advice Process • Creating Your Technology Radar • Blip Gathering • Blip Sorting and Validation • 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

هنر تصمیم‌گیری

The Importance of the Softer Side • Framing the Context • Excluding Is as Important as Including • Questions That Improve Judgment Around Framing • Involve the Right Stakeholders • Discerning Options and Their Consequences • Don’t 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

مواجهه با تغییرپذیری معماری

The Effect of Variability on the Practice of Architecture • Variability Makes Developing Systems Difficult • 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 • 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

تغییرپذیری و ارتباط متقابل تصمیمات

Finding a Path Through Variability • Introducing Spikes • Spikes Can Tackle Architectural Variability More Cheaply • Where Do Spikes Sit in a Decision Process? • Spiking ADRs • Spiked ADRs Still Follow the Advice Process • Examining the Interconnectedness of Decisions • Decisions Are a Series • Decisions Are an Inverted Hierarchy • Decisions Are Atomic • Decisions Are Two-Way Conversations • Interrelated Decisions Are Socially Complicated • Conclusion

گذار قدرت و مسئولیت‌پذیری

Power Transitions Are Never Straightforward • The Transition for Those Who Gain Power • Does 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 Safety • The Transition for Those Who Must Share Their Power • Fear Within Those Who Gave Power Away • The Behavior of Those Who Don’t Like the Fact That Power Got Shared • Transitions Are Uncomfortable • Conclusion

درباره رهبری

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 • Deming’s 14 Points • Servant Leadership • Adaptive Leadership • Leader-Leader Leadership • Challenges with Transitioning to Leader-Leader Leadership • The Need for Ongoing Moral Leadership • Responding to Moral Challenges • Be Sensitive of—But Not Beholden to–All Your Current Cultures • There Are No “Permanent Leaders” • Conclusion

تطبیق فرآیند مشورت با سازمان شما

The Software Engineering Subculture • Reason 1: Software Development Doesn’t 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 • Bubbles Are Permeable • External Expectations on Those Within the Bubble • Self-Evident Expectations • Less-Evident Expectations • Bubbles Present an Interface Independent of Implementation • The Bubble’s Interface Contract • Make the Valuable Translation Work Explicit • Growing Bubbles • Incremental Growth, Team by Team • 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 • Staying Aligned Across Bubbles • Protect and Encourage Differences Between Bubbles • Conclusion