Architecture for Flow Workflow¶

This method yields a coherent architecture and team structure plan with explicit team boundaries, interaction modes, and a migration roadmap, derived from desired business outcomes.

When to use¶

Use this method when starting a new product or system design, or when an existing architecture and team structure are creating delivery bottlenecks, high cognitive load, or frequent cross-team dependencies. It is suited for product leadership and architects who want to align organizational design with technical architecture from the ground up.

Steps¶

1. Identify personas and build a value chain: Start from the personas the system serves and trace each of their needs into a chain of components. Place each component on the visibility axis: elements visible to users sit high and enabling infrastructure sits low.

2. Build a Wardley Map: Add the evolution axis to the value chain, placing each component from genesis through custom built and product to commodity. This reveals which components are differentiating and which should be bought or outsourced, giving strategic context for architectural decisions.

3. Map the domain: Apply Domain-Driven Design to decompose the value chain into bounded contexts. Use the Wardley Map to classify each context as core domain (high value, genesis or custom built), supporting subdomain, or generic subdomain.

4. Assess climate: Project how each component will evolve on the evolution axis. Where commoditization is approaching, avoid custom investment and consider extracting a new supporting subdomain to reduce cognitive load. Core domains must stay in genesis or custom built territory because that is where competitive differentiation happens.

5. Assess doctrine: Score the organization against Wardley's doctrine principles across four phases to establish its current maturity and identify gaps. Use the gap analysis to calibrate how ambitious the target state can realistically be and which organizational habits need to change first.

6. Design for flow: Use Team Topologies patterns to assign each bounded context to a team type (stream-aligned, platform, enabling, or complicated-subsystem). Organize teams around contexts rather than technical layers to build cross-functional teams. Cognitive load increases the further left a context sits on the evolution axis, so genesis-stage contexts limit a team's capacity for additional responsibilities.

7. Apply the Inverse Conway Maneuver: Reshape the proposed team structure so that communication paths between teams match the desired software architecture rather than the current organizational chart.

8. Define interaction modes: For each team boundary, specify the collaboration mode (collaboration, X-as-a-Service, or facilitating) and set explicit expectations for interface contracts and handoff points. Team Topologies interaction modes map directly onto DDD context map relationships: upstream/downstream patterns align with X-as-a-Service, partnership with collaboration, and open-host service with facilitating.

9. Define the leadership strategy: Use Wardley's strategies to identify the conditions that would make the desired outcome inevitable rather than prescribing a sequence of steps. Ask not what must be done, but what environment must exist for the target architecture to emerge naturally.

10. Identify constraints and risks: Review existing technical debt, platform limitations, and organizational constraints that may prevent the target architecture, and note mitigations for each.

11. Build the migration roadmap: Sequence the architectural and team changes into incremental steps, prioritizing moves that unblock the highest-value delivery streams first. Once strategic alignment is complete, develop a C4 model for each bounded context to prepare the tactical implementation decisions.

Example¶

The following walkthrough applies the method to a conference event planning system.

Steps 1 and 2: Personas, value chain, and Wardley Map — Two personas drive the system: a Speaker who submits and manages session proposals, and an Organizer who reviews submissions and publishes the schedule. Tracing their needs produces a value chain with six visible activities: Submit Session, Manage CfP, Evaluate Submission, Build and Publish Schedule, Communicate with Speakers, and Signup/Login. Invisible infrastructure sits below: a central event planner service, search engine, message broker, data storage, compute platform, and VMs.

Adding the evolution axis places the submission and schedule management activities in genesis or custom built territory, since they are the system's unique capabilities. Search, identity, messaging, storage, and compute sit in product or commodity territory because ready-made solutions cover all of them.

Steps 3 and 4: Domain mapping and climate — DDD decomposes the value chain into five core domain bounded contexts (Submission Handling, CfP Management, Session Evaluation, Schedule Management, Messaging) and one supporting subdomain (Identity and Access). The infrastructure components become generic subdomains. Climate confirms that identity management is already a mature product market: investing custom development in it provides no competitive advantage, so it should be bought or outsourced.

Steps 5 and 6: Doctrine and design for flow — Doctrine assessment reveals the team currently organizes around technical layers (frontend, backend, database) rather than business contexts. The target shifts to cross-functional stream-aligned teams, one per cluster of related bounded contexts. Three stream-aligned teams emerge: one owns Submission Handling and CfP Management, a second owns Session Evaluation and Schedule Management, and a third owns Messaging. A platform team owns the commodity infrastructure: search, identity provider, message broker, data storage, and compute. The genesis-stage contexts in the first two teams carry high cognitive load, so neither team takes on any additional responsibilities.

Steps 7 and 8: Inverse Conway Maneuver and interaction modes — The three stream-aligned teams communicate only through platform team services (X-as-a-Service). No stream-aligned team depends directly on another for delivery. The platform team exposes stable interfaces and the stream-aligned teams consume them without coordination overhead. This communication structure is then encoded in team boundaries and API contracts before any code moves. The diagram below shows how DDD context map relationships map onto Team Topologies interaction modes.

Step 9: Leadership strategy — Rather than prescribing a migration sequence, the strategy identifies the condition that makes fast flow inevitable: each bounded context must be independently deployable. The team restructuring and interface contracts are the environmental levers; the migration roadmap sequences them to establish that condition as early as possible, starting with the platform team's services so the stream-aligned teams can decouple immediately.

Sources¶

• Finding software boundaries for fast flow — Team Topologies and Domain-Driven Design
• Simon Wardley: Wardley Mapping
• Matthew Skelton, Manuel Pais: Team Topologies
• Development Teams Are Software: Team Topologies and Domain-Driven Design Map How

Applies to: Architecture for Flow · Team Topologies · Domain-Driven Design · Inverse Conway Maneuver · Bounded Context · Cognitive Load · Stream-Aligned Team