Der Erfolg eines Softwareprodukts hängt nicht nur von Technologie und Architektur ab – auch die Vorgehensweise und die organisatorischen Rahmenbedingungen für die Teams sind entscheidend. Strategic Design setzt genau hier an: Es hilft, diese Faktoren bewusst zu gestalten, statt sie nur als gegeben hinzunehmen. Doch häufig wird übersehen, dass Strategic Design eine eigene Disziplin ist, die zum Aufgabenbereich von Architekt:innen, Entwickler:innen und Product Ownern gehört.
Context Maps sind nur der Anfang
Strategic Design wird häufig auf Context Mapping (1) und die damit verbundenen strategischen Patterns reduziert. Der Begriff ist zwar fest im Domain-Driven Design (DDD) verankert und wird mit Patterns wie Conformist oder Anticorruption Layer assoziiert, doch Strategic Design ist mehr. Der Ursprung liegt im DDD (siehe 4), doch über die Jahre hat es sich weiterentwickelt und neue Ansätze und Methoden integriert. Es sollte als eigenständige Disziplin verstanden werden, die über DDD hinaus Wirkung entfaltet.
Context Maps sind ein guter Ausgangspunkt für das strategische Design, weil sie niederschwellig erstellt und leicht verständlich sind. Doch eine Context Map allein reicht nicht aus – ihr Nutzen hängt davon ab, wie gut sie die tatsächlichen Gegebenheiten widerspiegelt. Der Grundsatz gilt: “Easy to learn, hard to master.” Eine beispielhafte Context Map zu erstellen ist einfach, doch eine wirklich nützliche bleibt eine Herausforderung.
Bounded Contexts zu finden und zu gestalten, ist eine zentrale Herausforderung im Domain-Driven Design. In den letzten 20 Jahren haben sich dafür zahlreiche Methoden entwickelt, die unter dem Begriff Collaborative Modelling zusammengefasst werden. Dazu gehören Techniken wie EventStorming oder Example Mapping, die dabei helfen, fachliche Abgrenzungen zu erkennen und Kontexte bewusst zu gestalten. Jede dieser Methoden eröffnet eine spezifische Perspektive auf ein Problem – und in Kombination ermöglichen sie eine ganzheitlichere Betrachtung.
Doch Software entsteht nicht isoliert – sie ist Teil eines soziotechnischen Systems, in dem technische und soziale Strukturen untrennbar miteinander verbunden sind. Neben Technologie und Architektur spielen auch Teams, ihre Zusammenarbeit, Skills, Kommunikationswege und Entscheidungsprozesse eine entscheidende Rolle. Diese Faktoren beeinflussen nicht nur die Softwareentwicklung, sondern werden umgekehrt auch von ihr geprägt. Strategic Design hilft, diese Wechselwirkungen zu erkennen und aktiv zu gestalten, statt sie dem Zufall zu überlassen.
Was Context Maps wirklich sichtbar machen und was nicht
Bounded Contexts definieren nicht nur den Gültigkeitsbereich einer Fachsprache und eines Domänenmodells, sondern auch klare Zuständigkeitsbereiche für Teams. Context Maps machen diese Verantwortlichkeiten sichtbar, indem sie sowohl die Abhängigkeiten zwischen fachlichen Modulen und Services als auch zwischen den Teams greifbar machen.
Team-bezogene Implikationen sind allerdings nicht direkt auf der Context Map erkennbar – sie müssen bewusst interpretiert und hinterfragt werden. Welche Abhängigkeiten bestehen nicht nur auf fachlicher, technischer sondern auch auf organisatorischer Ebene? Wo können Spannungen oder Herausforderungen in der Zusammenarbeit entstehen? Eine Context Map liefert keine endgültigen Antworten, sondern eine Grundlage für die gezielte Analyse und Gestaltung dieser Strukturen.
Ein Beispiel
Zwei Teams sollen fachlich verwandte, aber eigenständige Kontexte entwickeln. Aufgrund dieser Nähe stehen ihre Ziele in gegenseitiger Abhängigkeit, sodass eine Partnership (2) als sinnvoll erscheint. Diese Entscheidung kann aus fachlichen Überlegungen getroffen werden – ob von den Teams selbst oder extern vorgegeben. Doch ob diese Partnerschaft tatsächlich funktioniert, hängt nicht nur von der fachlichen Nähe ab. Entscheidend für den Erfolg ist die tatsächlich erreichte Qualität der Kommunikation und Kollaboration zwischen den Teams.
Typische Stolpersteine:
- Gibt es einen niederschwelligen Austausch, oder entstehen Kommunikationsbarrieren?
- Erschweren räumliche Distanzen oder Zeitzonen eine enge Abstimmung?
- Sind Videocalls (Zoom, etc.) und digitale Tools (Miro, Figma …) ein gleichwertiger Ersatz für persönlichen Austausch – und sind sie für alle verfügbar (Lizenzen, Berechtigungen …)?
- Verhindern organisatorische Faktoren Ad-hoc-Abstimmungen, z. B. durch knappe Verfügbarkeit, parallele Projekte oder fehlende Ressourcen?
- Kommen noch zwischenmenschliche Herausforderungen hinzu, etwa unterschiedliche Arbeitsweisen, unklare Verantwortlichkeiten, Konflikte oder widersprüchliche Ziele?
Eine Context Map zeigt nicht nur fachliche Abhängigkeiten, sondern bietet einen Ansatzpunkt, um die Rahmenbedingungen der Zusammenarbeit systematisch zu hinterfragen. Sie hilft dabei, frühzeitig zu erkennen, ob eine gewählte Kooperationsform unter den gegebenen Voraussetzungen tragfähig ist – oder ob Anpassungen erforderlich sind, um sie erfolgreich zu machen.
Eine Basis für weiterführende Methoden
Strategic Design geht weit über Context Mapping hinaus. Eine Context Map ist ein hilfreiches Werkzeug, um Abhängigkeiten sichtbar zu machen, aber sie bildet nur einen Teilaspekt strategischer Entscheidungen ab. Strategic Design umfasst weit mehr als die Analyse von Schnittstellen – es bezieht die Gestaltung der Zusammenarbeit, Teamstrukturen und Entwicklungsprozesse mit ein.
Ein konkretes Beispiel für den nächsten Schritt ist Team Topologies (3). Während eine Context Map aufzeigt, welche Kontexte miteinander in Beziehung stehen, hilft Team Topologies, die passende Teamstruktur für diese Beziehungen zu gestalten. Wird eine Partnership als Muster identifiziert, stellt sich die Frage, ob eine enge Kollaboration zwischen den Teams organisatorisch möglich ist – oder ob ein anderes Interaktionsmodell wie X-as-a-Service die bessere Wahl wäre. Team Topologies bietet hier eine systematische Herangehensweise, um die Zusammenarbeit entlang des Wertstroms zu optimieren.
Ist das noch Strategic Design?
Strategic Design auf eine fest umrissene und abgeschlossene Praktik innerhalb von DDD zu reduzieren, verschenkt wertvolle Gestaltungsmöglichkeiten. Diese Sichtweise legt nahe, dass das Thema mit dem Blue Book (4) und nachfolgenden Publikationen bereits umfassend beschrieben wurde. Doch Strategic Design ist mehr als das – es ist eine eigenständige, evolvierende Disziplin, die weit über die klassischen DDD-Patterns hinaus Wirkung entfaltet.
Statt als Alternative zu Strategic Design zu konkurrieren, erweitern kollaborative Methoden wie EventStorming (5), Domain Storytelling (6) oder Team Topologies (3) dessen Werkzeugkasten. Sie ergänzen die etablierten Konzepte und ermöglichen es, strategische Entscheidungen im Zusammenspiel von Architektur, Teams und Geschäftsprozessen gezielt zu gestalten. Diese Perspektive macht deutlich: Strategic Design entwickelt sich kontinuierlich weiter und bleibt anpassungsfähig.
Strategic Design – lohnt sich das?
Ist das nicht alles zu abstrakt für den Alltag? Ganz im Gegenteil. Strategic Design ist keine separate Disziplin für Theoretiker, sondern ein natürlicher Teil der Entwurfsarbeit von Entwickler:innen, Product Ownern und Architekt:innen. Mit dem richtigen Instrumentarium wird diese Arbeit nicht komplizierter, sondern durch niedrigschwellige, kollaborative Methoden gezielt unterstützt. Natürlich kostet es Zeit, strategische Probleme frühzeitig zu analysieren – doch der Gewinn ist enorm: Fehlentscheidungen lassen sich vermeiden, und langfristig spart es Frust, Kosten und technische Umwege.
Du möchtest die im Artikel besprochenen Methoden praktisch anwenden? In unserem DDD Toolbox Training lernst du bewährte kollaborative Techniken wie EventStorming, Domain Storytelling, Example Mapping und Wardley Mapping kennen – praxisnah und interaktiv. Diese Methoden helfen dir, ein gemeinsames Verständnis der Anwendungsdomäne zu entwickeln und strategische Entscheidungen gezielt zu gestalten. Nach dem Training kannst du die passenden Methoden für deine spezifischen Anwendungsfälle eigenständig einsetzen.
Interessiert? Erfahre mehr und kontaktiere uns: DDD Toolbox Training
Quellen
[1] - Erläuterung von Context Mapping als Praktik: GitHub - ddd-crew
[2] - Erläuterung von ‘Partnership’: GitHub - ddd-crew
[3] - Überblick zu Team Topologies: teamtopologies.com
[4] - Domain-Driven Design - Tackling Complexity in the Heart of Software, Eric Evans, Addison Wesley 2004
[5] - Mehr zu EventStorming: Leanpub
[6] - Domain Storytelling: domainstorytelling.org