Architecture for Flow • Susanne Kaiser & James Lewis
In an interview with James Lewis, Susanne Kaiser discusses her book "Architecture for Flow," which synthesizes Domain-Driven Design, Wardley Mapping, and Team Topologies. She explains how this holistic approach helps design adaptive socio-technical systems by starting with the problem space, visualizing the value chain, and aligning team structures to the software architecture, all guided by her practical "Architecture for Flow Canvas."
In her book, “Architecture for Flow,” Susanne Kaiser presents a holistic approach that evolved over several years, integrating three powerful frameworks—Domain-Driven Design (DDD), Wardley Mapping, and Team Topologies—to design and evolve adaptive socio-technical systems. The goal is to optimize for a fast and sustainable flow of value by bridging business strategy, software design, and team organization.
The Three Pillars of Flow
The methodology is built on the synthesis of three distinct but complementary frameworks:
-
Domain-Driven Design (DDD): The journey began with DDD as a tool to decompose a monolithic “big ball of mud” into modular components, known as Bounded Contexts. This strategic design practice is essential for managing complexity in the solution space.
-
Wardley Mapping: Encountered at serverless conferences, Wardley Mapping provided the strategic business context that was missing. It visualizes a landscape with the user and their needs at the top, a value chain of components fulfilling those needs on the y-axis, and the evolution of those components (from genesis to commodity) on the x-axis. This perfectly complements DDD by allowing subdomains (core, supporting, generic) to be mapped visually, which in turn helps drive strategic decisions about whether to build, buy, or outsource components.
-
Team Topologies: This was the “missing puzzle piece” that addresses Conway’s Law, which states that an organization’s communication structures are mirrored in its system design. Team Topologies provides well-defined team types (e.g., stream-aligned, platform) and interaction modes, offering a clear language to discuss and design the organizational side of a socio-technical system.
From Individual Frameworks to a Holistic System
Combining these frameworks creates a result that is greater than the sum of its parts. It brings exceptional clarity to abstract concepts like “value streams.” For instance, a Wardley Map provides the high-level entry point to see a value chain, and from there, one can identify the specific value streams—the end-to-end flows of change—that support it. This applies to both external, customer-facing value streams and internal ones, where teams are the customers of internal platforms.
This holistic view, informed by the Theory of Constraints, helps identify and mitigate system-wide bottlenecks. It prevents the trap of local optimization, where a single high-performing team might be working rapidly but is not addressing the actual constraint that is slowing down the entire system’s performance.
Furthermore, the approach makes underlying team dynamics and change couplings explicit. Using DDD’s Context Mapping patterns, teams can visualize not just technical API integrations but also the powerful, often invisible, team interdependencies. This includes patterns like “separate ways,” where teams duplicate functionality to avoid costly integration, or “customer-supplier” power dynamics, where a consuming team can exert significant influence over a supplying team’s priorities.
The Architecture for Flow Canvas: A Practical Guide
To make this approach actionable, Kaiser developed the “Architecture for Flow Canvas,” an opinionated, structured guide for teams to apply these principles. It is not a rigid framework but a starting point for a continuous, iterative process. The canvas guides teams through two main phases:
-
Assess the Current Situation: This involves mapping the “teams of today”—their structure, responsibilities, dependencies, and current ways of working. Teams identify existing blockers that slow them down and elements that support flow, which should be preserved. This phase also includes creating a Wardley Map of the current business landscape to understand the organization’s operational context.
-
Design the Ideal Future: The process then moves from the problem space to the solution space.
- First, user needs are categorized into core, supporting, and generic subdomains to define the problem space.
- Next, using techniques like Event Storming, the solution space is modularized into Bounded Contexts.
- These Bounded Contexts are then mapped back to the subdomains and visualized on a future-state Wardley Map to guide build-vs-buy decisions.
- Finally, Team Topologies are used to align teams to this new architecture. Bounded Contexts often become the responsibility of stream-aligned teams, while underlying components on the map may be provided by platform teams.
A key success factor is that the teams themselves drive these decisions, which fosters a deep sense of ownership. The decision of team membership assignments is deliberately deferred to the very end to ensure that the solution is designed based on problems and needs, free from emotional attachments.
The Core Takeaway
The most critical principle is to first understand the problem space before diving into the solution space. By starting with user needs—whether for external customers or internal teams—and applying a holistic view, organizations can build the right thing and build the thing right, creating adaptive systems designed for a continuous flow of value.