Architecture for Flow • Susanne Kaiser & James Lewis • GOTO 2026

Susanne Kaiser discusses her book "Architecture for Flow," which integrates Domain-Driven Design, Wardley Mapping, and Team Topologies into a holistic framework. She introduces the "Architecture for Flow Canvas," a practical tool for designing and evolving adaptive socio-technical systems by starting with the problem space and aligning software design with team organization and business strategy.

February 5, 2026 4 min read

Architecture for Flow • Susanne Kaiser & James Lewis • GOTO 2026 — source: https://www.youtube.com/watch?v=NwtE82Wzs_U

In her book, “Architecture for Flow,” Susanne Kaiser presents a holistic framework for designing and evolving adaptive socio-technical systems. This approach synthesizes three powerful methodologies—Domain-Driven Design (DDD), Wardley Mapping, and Team Topologies—to optimize for a fast and sustainable flow of value. The framework evolved over several years of practical application, aiming to bridge business strategy, software design, and team organization.

The Three Pillars of Flow

The core of the approach rests on integrating three distinct but complementary perspectives:

Domain-Driven Design (DDD): Initially adopted to tackle monolithic systems, DDD provides the tools to decompose a system into modular components, known as Bounded Contexts. This strategic design helps in managing complexity and establishing clear boundaries based on business domains.
Wardley Mapping: This provides a visual method for understanding the business landscape. A Wardley Map plots a value chain against stages of evolution (Genesis, Custom, Product, Commodity). This visualization complements DDD by helping to categorize subdomains (Core, Supporting, Generic) and informs strategic decisions like whether to build, buy, or outsource a component.
Team Topologies: Described as the “missing puzzle piece,” Team Topologies addresses Conway’s Law, which states that a system’s design mirrors the organization’s communication structure. By providing well-defined team types (e.g., Stream-aligned, Platform) and interaction modes, it allows for the conscious design of team organization to support the desired architecture.

From Value Chains to Team Dynamics

The framework emphasizes understanding the flow of change through the system. A value chain, as depicted on a Wardley Map, is supported by a network of value streams. By analyzing these streams, teams can identify bottlenecks and constraints that slow down performance. The goal is to avoid local optimizations (e.g., one team performing at high speed while creating a backlog for another) and instead focus on improving the overall system’s flow.

To make the intricate dependencies and power structures between teams explicit, the framework leverages Context Mapping from DDD. This technique goes beyond technical API integrations to visualize the underlying team dynamics:

Change Coupling: It reveals which parts of a system need to change together, even if they aren’t directly integrated.
Power Dynamics: It can illustrate relationships like a customer-supplier dynamic, where a consuming team can influence the supplier’s backlog, or a separate ways pattern, where teams choose to duplicate functionality to avoid costly integration.

The Architecture for Flow Canvas: A Practical Framework

To make these concepts actionable, Kaiser developed the “Architecture for Flow Canvas,” an opinionated, structured approach for teams to assess their current state and design their future. It is an iterative process, not a rigid one.

The process generally follows these steps:

Assess the Present: The journey begins by analyzing the “teams of today.” This involves mapping their current structure, responsibilities, dependencies, and identifying existing blockers to flow. Teams often know best what slows them down.
Visualize the Business Landscape: A Wardley Map is created to understand the current business landscape, starting from user needs and the value chain that serves them.
Transition to the Ideal Future: The focus shifts from the problem space to the solution space. User needs are categorized into core, supporting, and generic subdomains.
Model the Solution: Using collaborative techniques like EventStorming, the solution space is modularized into Bounded Contexts.
Bridge and Align: The identified Bounded Contexts are mapped back onto a future-state Wardley Map. This helps align the technical solution with business strategy and facilitates decisions on what to build in-house versus what to source externally.
Design the Teams: Finally, Team Topologies principles are used to align teams around the architecture. Bounded Contexts, for example, become natural candidates for ownership by Stream-aligned teams, while underlying components on the map may point to the need for Platform teams.

Key Takeaway

The most critical principle is to first gain a deep understanding of the problem space before jumping into the solution space. Building the right thing requires a holistic view that considers user needs, business strategy, software architecture, and team organization as interconnected parts of a single socio-technical system. As Clayton Christensen stated, “people buy products in order to get a job done,” and the ultimate goal is to help users—whether external customers or internal teams—accomplish that job effectively.