Architecture for Flow Workflow¶

Diese Methode liefert einen kohärenten Plan für Architektur und Teamstruktur mit expliziten Teamgrenzen, Interaktionsmodi und einer Migrations-Roadmap, abgeleitet aus gewünschten Geschäftszielen.

Wann anwenden¶

Diese Methode eignet sich für den Start eines neuen Produkts oder Systems sowie dann, wenn eine bestehende Architektur und Teamstruktur Lieferengpässe, hohe kognitive Last oder häufige teamübergreifende Abhängigkeiten verursachen. Sie richtet sich an Produktverantwortliche und Architekten, die Organisationsdesign und technische Architektur von Grund auf aufeinander abstimmen möchten.

Schritte¶

1. Personas identifizieren und Wertschöpfungskette aufbauen: Beginne mit den Personas, die das System bedient, und leite aus ihren Bedürfnissen eine Kette von Komponenten ab. Platziere jede Komponente auf der Sichtbarkeitsachse: nutzerseitige Elemente stehen oben, ermöglichende Infrastruktur unten.

2. Wardley Map erstellen: Ergänze die Wertschöpfungskette um die Evolutionsachse und ordne jede Komponente von Genesis über Custom Built und Produkt bis hin zu Commodity ein. So wird sichtbar, welche Komponenten differenzierend sind und welche eingekauft werden sollten, und schafft strategischen Kontext für Architekturentscheidungen.

3. Domäne modellieren: Wende Domain-Driven Design an, um die Wertschöpfungskette in Bounded Contexts zu zerlegen. Nutze die Wardley Map, um jeden Kontext als Kerndomäne (hoher Wert, Genesis oder Custom Built), unterstützende Subdomäne oder generische Subdomäne einzustufen.

4. Climate einschätzen: Projiziere, wie sich die einzelnen Komponenten auf der Evolutionsachse weiterentwickeln werden. Wo Kommoditisierung absehbar ist, sollten keine eigenen Investitionen getätigt werden; stattdessen empfiehlt es sich, eine neue unterstützende Subdomäne auszugliedern, um kognitive Last zu reduzieren. Kerndomänen müssen im Genesis- oder Custom-Built-Bereich bleiben, da dort die Wettbewerbsdifferenzierung stattfindet.

5. Doctrine bewerten: Bewerte die Organisation anhand der Wardley-Doctrine-Prinzipien in vier Phasen, um den aktuellen Reifegrad zu bestimmen und Lücken zu identifizieren. Nutze die Lückenanalyse, um einzuschätzen, wie ambitioniert der Zielzustand realistisch sein kann und welche organisatorischen Gewohnheiten sich zuerst ändern müssen.

6. Für Flow gestalten: Weise mit Team-Topologies-Mustern jeden Bounded Context einem Teamtyp zu (Stream-Aligned, Platform, Enabling oder Complicated-Subsystem). Organisiere Teams um Kontexte statt um technische Schichten, um echte crossfunktionale Teams zu bilden. Die kognitive Last steigt, je weiter links ein Kontext auf der Evolutionsachse liegt; Genesis-Kontexte schränken daher die Kapazität eines Teams für weitere Verantwortlichkeiten stark ein.

7. Inverses Conway Manöver anwenden: Forme die vorgeschlagene Teamstruktur so um, dass Kommunikationswege zwischen Teams der gewünschten Softwarearchitektur entsprechen statt dem aktuellen Organigramm.

8. Interaktionsmodi festlegen: Lege für jede Teamgrenze den Kollaborationsmodus fest (Zusammenarbeit, X-as-a-Service oder Facilitating) und setze klare Erwartungen an Schnittstellenverträge und Übergabepunkte. Die Interaktionsmodi aus Team Topologies lassen sich direkt auf die Beziehungen der DDD-Context-Map übertragen: Upstream/Downstream-Muster entsprechen X-as-a-Service, Partnership entspricht Zusammenarbeit und Open-Host-Service entspricht Facilitating.

9. Führungsstrategie definieren: Nutze Wardleys Strategien, um die Bedingungen zu identifizieren, die das gewünschte Ergebnis unvermeidlich machen, statt eine Abfolge von Schritten vorzuschreiben. Die Frage lautet nicht, was getan werden muss, sondern welches Umfeld geschaffen werden muss, damit die Zielarchitektur natürlich entstehen kann.

10. Einschränkungen und Risiken identifizieren: Überprüfe vorhandene technische Schulden, Plattformgrenzen und organisatorische Hürden, die die Zielarchitektur verhindern könnten, und halte Gegenmaßnahmen fest.

11. Migrations-Roadmap erstellen: Sequenziere die Architektur- und Teamänderungen in inkrementellen Schritten und priorisiere dabei Maßnahmen, die die wertvollsten Lieferströme zuerst freischalten. Sobald die strategische Ausrichtung abgeschlossen ist, empfiehlt es sich, für jeden Bounded Context ein C4-Modell zu erstellen, um die taktischen Implementierungsentscheidungen vorzubereiten.

Beispiel¶

Die folgende Walkthrough wendet die Methode auf ein Konferenzverwaltungssystem an.

Schritte 1 und 2: Personas, Wertschöpfungskette und Wardley Map — Zwei Personas treiben das System an: eine Sprecherin, die Sessionvorschläge einreicht und verwaltet, und eine Organisatorin, die Einreichungen bewertet und den Zeitplan veröffentlicht. Aus ihren Bedürfnissen ergibt sich eine Wertschöpfungskette mit sechs sichtbaren Aktivitäten: Session einreichen, CfP verwalten, Einreichung bewerten, Zeitplan erstellen und veröffentlichen, mit Sprecherinnen kommunizieren sowie Registrierung und Login. Unsichtbare Infrastruktur liegt darunter: ein zentraler Event-Planer-Service, Suchmaschine, Message Broker, Datenspeicher, Compute-Plattform und VMs.

Das Hinzufügen der Evolutionsachse ordnet die Einreichungs- und Zeitplanverwaltung in den Genesis- bzw. Custom-Built-Bereich ein, da sie die einzigartigen Fähigkeiten des Systems darstellen. Suche, Identität, Messaging, Speicher und Compute liegen im Produkt- oder Commodity-Bereich, da für alle fertige Lösungen verfügbar sind.

Schritte 3 und 4: Domänenmodellierung und Climate — DDD zerlegt die Wertschöpfungskette in fünf Kerndomänen als Bounded Contexts (Einreichungsverwaltung, CfP-Management, Session-Evaluation, Zeitplanmanagement, Messaging) und eine unterstützende Subdomäne (Identität und Zugang). Die Infrastrukturkomponenten werden zu generischen Subdomänen. Die Climate-Einschätzung bestätigt, dass Identitätsmanagement bereits ein reifer Produktmarkt ist: Eigene Entwicklung dort bietet keinen Wettbewerbsvorteil, weshalb die Lösung eingekauft oder ausgelagert werden sollte.

Schritte 5 und 6: Doctrine und Flow-Design — Die Doctrine-Bewertung zeigt, dass das Team aktuell nach technischen Schichten (Frontend, Backend, Datenbank) statt nach Business-Kontexten organisiert ist. Das Ziel ist der Wechsel zu crossfunktionalen Stream-Aligned-Teams, je eines pro Cluster verwandter Bounded Contexts. Es entstehen drei Stream-Aligned-Teams: eines verantwortet Einreichungsverwaltung und CfP-Management, ein zweites Session-Evaluation und Zeitplanmanagement, ein drittes Messaging. Ein Platform-Team verantwortet die Commodity-Infrastruktur: Suche, Identity Provider, Message Broker, Datenspeicher und Compute. Die Genesis-Kontexte der ersten beiden Teams tragen eine hohe kognitive Last, weshalb keines der Teams weitere Verantwortlichkeiten übernimmt.

Schritte 7 und 8: Inverses Conway Manöver und Interaktionsmodi — Die drei Stream-Aligned-Teams kommunizieren ausschließlich über die Services des Platform-Teams (X-as-a-Service). Kein Stream-Aligned-Team hängt für seine Lieferung direkt von einem anderen ab. Das Platform-Team stellt stabile Schnittstellen bereit, die Stream-Aligned-Teams konsumieren sie ohne Koordinationsaufwand. Diese Kommunikationsstruktur wird in Teamgrenzen und API-Verträgen festgeschrieben, bevor Code bewegt wird. Das folgende Diagramm zeigt, wie DDD-Context-Map-Beziehungen auf Team-Topologies-Interaktionsmodi abgebildet werden.

Schritt 9: Führungsstrategie — Statt einer Migrationsabfolge identifiziert die Strategie die Bedingung, die Fast Flow unvermeidlich macht: Jeder Bounded Context muss unabhängig auslieferbar sein. Die Teamrestrukturierung und die Schnittstellenverträge sind die Hebel; die Migrations-Roadmap sequenziert sie so, dass diese Bedingung so früh wie möglich entsteht, beginnend mit den Services des Platform-Teams, damit sich die Stream-Aligned-Teams sofort entkoppeln können.

Quellen¶

• 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

Gilt für: Architektur für Flow · Team Topologies · Domain-Driven Design · Inverses Conway Manöver · Bounded Context · Kognitive Last · Stream-Aligned Team