Architecture for Flow

Susanne Kaiser has more than 20 years of experience in software engineering and software architecture. Her journey began in 2002 and includes working as a startup CTO, where she gained valuable insights into technical, organizational, and strategic challenges. She is an independent tech consultant, supporting organizations in designing, building, and evolving adaptive, socio-technical systems optimized for a fast flow of change. With a deep passion for tackling complex systems, Susanne specializes in connecting the dots between Wardley Mapping, Domain-Driven Design, and Team Topologies. She regularly presents at international tech conferences on this topic.

"Architecture for Flow connects strategic thinking with software design. The integration of Wardley Mapping and Domain-Driven Design is particularly valuable, showing how business strategy can directly inform architectural decisions. Essential reading for those ready to think beyond code."--Kent Beck, Rent-a-Kent.ai and creator of Extreme Programming"One of the most important lessons from the eras of Cloud and Generative AI is that effective, adaptive organizations are designed. The book Architecture for Flow superbly articulates these key design principles that enable organizations to scale whilst remaining nimble and responsive to technology changes: highly recommended."--Matthew Skelton, CEO/CTO, Conflux, and coauthor of Team Topologies"Susanne brilliantly synthesizes Domain-Driven Design, Team Topologies, and Wardley Maps into a unified approach that truly works in practice. Her exceptionally clear writing and approachable practical examples navigate strategy, architecture, and team organization in a way that technical leaders and practitioners can immediately apply to their context."--Aslam Khan, CEO, High Speed Training Limited"Susanne brilliantly combines Wardley Mapping, Domain-Driven Design, and Team Topologies to show how meaningful software can be delivered quickly. It empowers software architects to help design the solutions correctly. It empowers engineering leaders to help shape the team correctly to deliver value for the business. This book is a must-read for anyone serious about modern software architecture."--Indu Alagarsamy, principal engineer, domainanalysis.io"Susanne Kaiser's book offers a powerful, practical framework that combines Domain-Driven Design, Wardley Mapping, and Team Topologies to build adaptive, resilient systems. A must-read for architects, tech leads, and anyone looking to navigate complexity and design systems that thrive in an ever-changing world."--Dr. Carola Lilienthal, managing director, WPS"Susanne Kaiser writes with the precision of an architect and the care of a guide. This book is a powerful call to stop treating business, tech, and teams as separate problems. A must-read for anyone trying to evolve legacy software, a growing org, or their own thinking about complex systems."--Xin Yao, independent DDD consultant and sociotechnical architect"Susanne's book finally provides a blueprint for combining three approaches (DDD, Team Topologies, and Wardley Mapping) that forward-thinking organizations have been leveraging for real Business-IT alignment (and in the process achieving highly motivated workforces as well). She has made them accessible and connected for everyone. The secret to fast flow of value to customers, with adaptive organizations supporting the business strategy in ever evolving landscapes is now at everyone's fingertips!"--Manuel Pais, coauthor of Team Topologies

• Series Editor Foreword xvForeword xixPreface xxiAcknowledgments xxixAbout the Author xxxiPart I: The Concepts & Fundamentals 1Chapter 1: Business Strategy with Wardley Mapping 3The Strategy Cycle 4The Purpose: The "Why" of Business 6Visual Representation of the Landscape: The Wardley Map 7Assessing Efficiency Gaps 19Understanding Climatic Patterns 20Applying Doctrinal Principles 29Deciding on Strategic Actions (Leadership and Gameplay) 35Summary 37Chapter 2: Exploring the Problem Space with Strategic Domain-Driven Design and Wardley Mapping 39Obtaining Domain Knowledge Through Collaboration 39Domain-Driven Design Patterns and Practices 40Discovering Subdomains and Mapping Their Evolution Stages 42Build-or-Buy Decisions with Subdomain Types and Evolution Stages 48Summary 50Chapter 3: Designing the Solution Space with Strategic Domain-Driven Design 53What Are Domain Models and Bounded Contexts? 53Designing Domain Models and Bounded Contexts 56Overview of Modeling Techniques 59Bounded Contexts and Architecture Styles 66Bounded Contexts and Evolution Stages 69Strategic Design and Doctrine of Wardley Mapping 71High Cohesion and Loose Coupling 72Overview of Context Maps 74Making Implicit Dependencies Explicit with Context Maps 80Assessing Change Coupling When Integrating with the Core 81Context Maps for the Conference Event Planner Example 84Technical Communication Styles and Context Maps 85Summary 86Chapter 4: Implementing the Domain Model with Tactical Domain-Driven Design 89The Building Blocks of Domain-Driven Models 89The Ports and Adapters Architecture and Tactical Design 90Summary 98Chapter 5: Optimizing for Flow of Change with Team Topologies 101System Impacts Identified by Conway's Law 101Challenges with Functional Silo Teams 101Requirements for Flow Optimization from a Team Perspective 103Impact on Software Delivery Performance 104Team Cognitive Load and Mental Workload 105The Fundamental Team Topologies 106Team Interaction Modes 108Common Interactions Between Team Types 109Team Topologies Applying Doctrinal Principles of Wardley Mapping 110Summary 111Part II: Architecture for Flow 113Chapter 6 Connecting the Dots 115Identifying Suitable Streams of Change 115Assessing Flow of Changes 116Analyzing Dependencies 118Managing Constraints 120Finding Suitable Team Ownership Boundaries 122Targeting Small Teams 123Optimizing for Team Cognitive Load 124Considering a Mix of Mindsets for Adaptive Teams 129Identify Services Supporting Flow of Change 133A Possible Team Constellation 134Identifying Capability Gaps 136Summary 136Chapter 7: Visualizing Team Perspectives with Wardley Maps 139A Wardley Map from a Platform Team Perspective 139The Value Chain from an Enabling Team Perspective 148Summary 150Chapter 8: The Architecture for Flow Canvas 151Assessing the As-Is Situation 152Designing the Envisioned To-Be Situation 156Summary 162Part III: Evolving a Legacy System for Flow 163Chapter 9: Designing a Legacy System for Flow 165Assessing the Status Quo of a Legacy System Example 165Addressing the Why of Business: The Purpose 166Examining the Teams of Today 167Assessing the Current Flow of Change 168Visualizing the Current Landscape with a Wardley Map 171Identifying Suitable Streams of Change 174Categorizing the Problem Domain and Discovering the Core 174Modularizing the Solution Space: Designing Bounded Contexts 177Designing Context Maps 182Visualizing the Future Landscape 186Finding Suitable Team Ownership Boundaries 189Optimizing Team Cognitive Load 189Identifying Services Supporting Flow of Change 190The Future Team Constellation 192Identifying Capability Gaps 196Summary 197Chapter 10: Implementing Flow Optimization 199Sharing the Why of Movement 199Aligning Teams and Evolving Interactions to the System to Build 200Transitioning with Dynamic Reteaming 203Forming a Platform Team for Discovery 205Closing Efficiency Gaps with Cloud Migration Strategies 207Starting the Cloud Migration Journey with Replatforming 208Merging the Remaining Infrastructure Team Members into the Platform Team 211Forming the First Stream-Aligned Teams: Kicking Off the Refactoring Journey 213Decomposing the Big Ball of Mud Through Incremental Refactoring 214Evolution of Team Topologies’ Interaction Modes 219UI Handling 221Refactoring the Next Bounded Contexts 223Splitting the Merged Platform Team into Multiple Teams 224Implementing a Bounded Context with Tactical Design and Serverless Technologies 225Summary 238Chapter 11: Fostering Continuous Improvement and Driving Future Change 241What Is Being Left Behind, and What Is Being Adopted? 241Providing Opportunity to Switch Teams 243Organizational Culture and Safety Thinking 243The Learning Organization 245Where to Move Next? 248Summary 251Chapter 12: Conclusion 253References 257Index 265