Wie Agile Transformationen und Domain-driven Design sich gegenseitig unterstützen können
Einen Elefanten zu halbieren, ergibt nicht zwei kleine Elefanten
In einer perfekten Welt kann jedes einzelne agile Team unabhängig und selbständig an einem eigenen Software-Modul/-Produkt arbeiten und seine Sprints isoliert planen. In der Realität sind die einzelnen Komponenten oft jedoch nicht streng genug entkoppelt, so dass es zu Seiteneffekten kommt, was dazu führen kann, dass die Sprints der Teams, die daran arbeiten, auch voneinander abhängen. Das führt zu ausuferndem Abstimmungsbedarf, unvorhergesehenen Quereffekten und Vorbehalten gegenüber der agilen Vorgehensweise. Grund dafür ist die soziotechnische Kopplung: Die Art und Weise, wie eine Software gestaltet ist, hat Einfluss auf die Organisation und umgekehrt. In diesem Artikel schauen wir uns diese Herausforderung genauer an und bauen eine Brücke zwischen Team-Organisation und Software-Architektur.
Woran scheitern agile Transformationen?
"Nur der, der sich die Gegenwart auch als eine andere denken kann als die existierende, hat eine Zukunft." (Reinhard K. Sprenger).
Die Vorteile von agilem Arbeiten liegen auf der Hand und überzeugen: schneller, flexibler, transparenter, näher am Kunden, motivierte und eigenverantwortliche Mitarbeiter:innen etc., und daher ist der Wunsch nach agilem, zukunftsorientiertem Arbeiten verständlich. Die agile Transformation wird ausgerufen und es muss irgendwo begonnen werden: eine verlockende "low-hanging Fruit" ist die Änderung der Organisationsstruktur, meist hin zu mehreren Scrum-Teams in der Software-Entwicklung.
Bei all dem guten Willen scheitern agile Transformationen jedoch oft an sehr unterschiedlichen Dingen. Häufig kann die Kultur nicht so schnell dem Wandel folgen, Widerstände bei den Führungskräften und Mitarbeiter:innen entstehen und es gibt unzählige weitere menschliche, oft irrationale Faktoren.
Neben diesen bekannten und meist auch berücksichtigten Faktoren und Risiken, die beispielsweise durch eine Change-Management-Begleitung nach Kotter [1], agile Transformations-Roadmaps und Coachings versucht werden einzufangen, kommt ein weiterer wichtiger Aspekt oft zu kurz: die technischen Rahmenbedingungen. Viele Scrum-Teams müssen sich zu sehr verbiegen, um bestehende technische Abhängigkeiten in ein strukturiertes agiles Setup zu zwängen und dieses zu bedienen. "Ihr arbeitet jetzt cross-funktional und unabhängig in einem Team. Bitte macht das selbstorganisiert." So oder ähnlich sind oft die Anforderungen des Managements an die Mannschaft, der dann auch oft ein externer Coach gegönnt wird – für das Menschliche. Wünschenswert wäre hier dann auch gleichzeitig ein externer Blick auf die IT-Landschaft - für das Technische.
Gut gemeint ist nicht gleich gut gemacht, vor allem bei Unternehmen, die bereits bestehende Systemlandschaften haben. Um schnell Dinge auszuprobieren, umzusetzen und inkrementell zu entwickeln, braucht ein Team Unabhängigkeit in vielerlei Hinsicht: Unabhängigkeit von langen Release-Zyklen der nicht-agilen Projekte, Unabhängigkeit zwischen dem Source-Code der einzelnen Module, klare Grenzen zwischen den Services mit definierten Schnittstellen, organisatorische Unabhängigkeit zwischen den Teams uvm. Sonst kann der gewünschte Flow nicht zustande kommen und gerade im beliebten Scrum-Umfeld überwiegen die Nachteile.
So beispielsweise auch bei einem mittelständischen Softwareunternehmen, das – angelehnt an das Spotify-Modell – mehrere Scrum-Teams etabliert hat und die vorhandenen technischen Abhängigkeiten durch organisatorische Termine lösen wollte. Allerdings waren die Abhängigkeiten in der Systemlandschaft so stark, dass kaum eine Anforderung von einem einzelnen Scrum-Team umgesetzt werden konnte. Das führt vor allem bei den Entwickler:innen zu Frust, da lange Wartezeiten, keine klare End-to-End-Verantwortung beim Testen und keine durchgehend unabhängigen und selbständigen Entwicklungszyklen daraus resultieren können.
Eine Umstrukturierung, um diese Abhängigkeiten zu lösen (z. B. die Annahme eines falschen Schnitts der Teams), kann auch nur bedingt zu Verbesserungen führen: Durch veränderte Teamstrukturen geht wieder Geschwindigkeit verloren, die Teams müssen sich neu aneinander gewöhnen und können veränderungsmüde werden. Die Konsequenz daraus, die oft in der Praxis zu beobachten ist, ist wachsende Ablehnung gegenüber der agilen Arbeitsweise. Alle Mühe, die in Kultur und Mindset fließt, ist vergebens bei unpassenden technischen Rahmenbedingungen. Allerdings ist auch die Alternative, zuerst oder parallel alle technischen Abhängigkeiten zu lösen, sowohl zeit- als auch kostenaufwändig und sollte nicht isoliert angegangen werden.
Der Artikel verdeutlicht im Detail die Herausforderungen agiler Transformationen bei bestehenden, eng gekoppelten Systemlandschaften, die Wechselwirkung zwischen Architektur und Organisation und wie man diesem Teufelskreis entkommen kann.
Soziotechnische Kopplung und ihr Einfluss auf die Unabhängigkeit von Teams
Die Wechselwirkung zwischen der Organisation bzw. den Teams und den Software-Komponenten bezeichnet man als soziotechnische Kopplung. Sie beschreibt die Tatsache, dass die Art und Weise, wie eine Systemlandschaft strukturiert ist, direkte Auswirkungen auf die Interaktionen, Kommunikation und Zusammenarbeit der Teams hat und umgekehrt.
Eine starke technische Abhängigkeit zwischen verschiedenen Modulen kann dazu führen, dass Teams in ihrer Arbeit aufeinander warten müssen bzw. voneinander beeinflusst werden, da sich Probleme und Änderungen in einem Modul auf andere auswirken, wenn sie technisch eng miteinander verzahnt sind. Umgekehrt beeinflussen Organisationsstruktur und Kommunikationswege zwischen Teams die technische Gestaltung der Systemlandschaft, da daraus technische Schnittstellen oder Abhängigkeiten zwischen technischen Modulen resultieren.
Beispiel: Angenommen, die Teams "Online-Shop" und "In-Exkasso" arbeiten an technisch entkoppelten Microservices, teilen sich aber eine Software-Bibliothek, die die Implementierung des Fachmodells der Auftragsverarbeitung enthält, so wird es regelmäßig zu Abstimmungsbedarf und ggf. sogar Synchronisation ihrer Sprints kommen, da bei Änderungen an diesem Shared Kernel beide Teams betroffen sind. Je mehr Code oder Schnittstellen sich die Teams teilen, desto enger muss die Zusammenarbeit gestaltet werden. Das kann so weit gehen, dass es sinnvoller sein könnte, sie zusammenzulegen.
Umgekehrt wird ein einzelnes Team, das sich um diese zwei Microservices kümmert, die Code-Basis nicht streng voneinander trennen. Warum auch? Man hat ja die Kontrolle über beide Services und kann so Redundanzen vermeiden, die innerhalb eines Teams keinen Vorteil bringen. Das mündet häufig in Microservices, die zwar in unabhängigen Laufzeitumgebungen deployt werden, jedoch in der Realität so eng verzahnt sind, dass dies gar keinen Vorteil bringt und sie viel besser in einer einzelnen Deployment-Einheit aufgehoben wären.
Diese Erkenntnis ist nicht neu und wurde bereits 1967 von Melvin E. Conway formuliert: "Any organization that designs a system […] will produce a design whose structure is a copy of the organization's communication structure." [2]
In dem Paper, in dem Conway diesen – mittlerweile als "Conway's Law" bekannten – Umstand beschreibt, stellt er auch klar, dass dies wechselseitig gilt: "This kind of a structure-preserving relationship between two sets of things is called a homomorphism. Speaking as a mathematician might, we would say that there is a homomorphism from the linear graph of a system to the linear graph of its design organization."
Eben dieser Homomorphismus (auch bekannt als Homomorphic Force) führt im Kontext von (vermeintlich) unabhängigen Teams und ihrer Arbeit an Software-Modulen zu soziotechnischer Kopplung.
Mittlerweile wurde Conway's Law von Carliss Y. Baldwin und Lyra Colfer als Mirroring Hypothesis in einer wissenschaftlichen Studie bestätigt [3].
Jetzt, wo wir wissen, dass die Beschaffenheit unserer Systemlandschaft das agile Arbeiten bzw. den Erfolg einer agilen Transformation beeinflusst – welche Möglichkeiten haben wir da, die Unabhängigkeit der Teams zu fördern?
Use the Homomorphic Force, Luke
Die Homomorphic Force ist Problem und Teil der Lösung zugleich. Einerseits erschwert sie das unabhängige Arbeiten in eng verzahnten Systemlandschaften. Andererseits eröffnet sie die Möglichkeit, die Systemlandschaft aktiv zu gestalten und durch ihre Entkopplung unabhängige, selbständige sowie agile Teams zu etablieren.
Dafür müssen wir zunächst aus der Vogelperspektive klären, wie die innere und äußere Beschaffenheit von Software-Modulen sein muss, um unabhängige und selbständige Teams zu fördern:
| Beschaffenheit der SW-Module | Team-Organisation |
| Die Systemlandschaft besteht aus in sich kohärenten, nach außen streng gekapselten und fachlich geprägten Software-Modulen. |
|
| Die Module exponieren/teilen ihr internes fachliches Modell nicht. |
|
| Die Kommunikation zwischen den Modulen entsteht nicht zufällig, sondern anhand einer dedizierten Strategie, die die Systemlandschaft berücksichtigt. |
|
Daraus folgt, dass es notwendig sein kann, die Software-Architektur zu ändern, falls sie diese Voraussetzungen nicht erfüllt, um den einzelnen Teams unabhängiges und selbständiges Arbeiten zu ermöglichen.
Mit Domain-driven Design existiert eine etablierte Herangehensweise zum Finden und Entkoppeln von fachlich geprägten Software-Modulen, was uns hilft, die vorhandene Architektur zu prüfen und zum Zweck der Förderung des unabhängigen Arbeitens einzelner Teams anzupassen.
Domain-driven Design als Weg, fachliche Domänen zu finden und zu entkoppeln
Der Begriff Domain-driven Design (kurz: DDD) stammt aus dem gleichnamigen Buch von Eric Evans aus dem Jahr 2003 [4]. Eine der zentralen Ideen hinter DDD ist dabei besonders einleuchtend: Software-Module und die Grenzen zu anderen Modulen sollten anhand der Fachlichkeit ihrer Domäne gestaltet werden. Anders ausgedrückt: Einzelne Module sollten in sich fachlich konsistent und nach außen streng gekapselt sein. Diese Module nennt Evans "Bounded Context (BC)". Jeder BC enthält ein fachliches Modell und arbeitet mit einer eigenen einheitlichen Sprache, der sogenannten "Ubiquitous Language". Das fachliche Modell sollte vor äußeren Einflüssen geschützt werden (streng gekapselt), damit es frei und sinnvoll – gemäß der spezifischen Fachlichkeit – gestaltet werden kann (in sich kohärent). D.h., es soll weder von Änderungen in Fachmodellen anderer BCs noch durch technische Belange berührt werden.
Die innere Beschaffenheit eines BC beschreibt Evans im Rahmen des taktischen Designs. Da wir uns jedoch mit der Interaktion zwischen Teams und den BCs, an denen sie arbeiten, beschäftigen, fokussieren wir uns auf das strategische Design. Das strategische Design gemäß DDD beschreibt unter dem Begriff der "Context Map" eine Topologie der BCs. Sie umfasst einige Strategien für die Kommunikation zwischen verschiedenen BCs.
Wenn wir uns nun an die Anforderungen hinsichtlich der inneren und äußeren Beschaffenheit der Software-Module erinnern, die es agilen Teams erlauben, unabhängig und selbstbestimmt arbeiten zu können, sehen wir, dass eine gemäß dem strategischen Design angelegte Systemlandschaft sie erfüllt:
- BCs sind in sich fachlich kohärent und nach außen streng gekapselt.
- Sie exponieren ihr fachliches Modell nicht.
- Die Kommunikation zwischen BCs entsteht nicht zufällig, sondern anhand einer dedizierten Strategie gemäß einer Context Map.
Wenn also einzelne agile Teams jeweils an eigenen Software-Modulen, die die Voraussetzungen eines BCs erfüllen, arbeiten und deren Kommunikation (zwischen Teams und Software Modulen) untereinander anhand einer Context Map geplant ist, erhöhen wir damit die Unabhängigkeit zwischen ihren jeweiligen Sprints.
Kommunikationsstrategien im Rahmen einer Context Map
Im Folgenden werden die einzelnen Strategien, gemäß denen die Zusammenarbeit zwischen Scrum-Teams und ihrer BCs im Rahmen einer Context Map organisiert werden kann, vorgestellt. Diese Strategien haben einen unterschiedlichen Grad an Unabhängigkeit, bieten aber einen Ansatz, um den menschlichen organisatorischen Teil mit dem technischen Teil zu verknüpfen.
Shared Kernel
Wenn zwei Teams sich einen Teil des Fachmodells teilen, kann dieser in einen Shared Kernel (SK) ausgelagert werden. Beide Teams sind für diesen verantwortlich und stimmen sich regelmäßig dazu ab. Das führt zu einer sehr engen Kopplung zwischen den Teams und sollte wenn möglich vermieden werden. Häufig handelt es sich hierbei um einen Zwischenschritt, wenn neue Teams gegründet werden, die zugehörigen Software-Module aber noch getrennt werden müssen.
Ziel sollte sein, den Shared Kernel so klein wie möglich zu halten und zeitnah in die referenzierenden BCs aufzulösen. Diese Strategie ist unbedingt zu vermeiden, wenn viel "Politik" bzw. Konkurrenz zwischen den Teams im Spiel ist, da sonst der regelmäßige Abstimmungsbedarf schwer zu bewältigen ist und die Kommunikation schnell toxisch wird. Die Teams müssen sich als Partner verstehen.
Conformist
Hier übernimmt ein Team das Fachmodell (und die Ubiquitous Language) eines anderen Teams (oder einen Teil davon). Dabei werden die Teams in zwei Kategorien unterteilt: Upstream und Downstream. Das Upstream-Team ist Besitzer des Fachmodells, während das Downstream-Team sich anpassen muss. Diese Strategie kann sinnvoll sein, wenn ein Team weite Teile der Fachlichkeit eines anderen Teams wiederverwenden kann und keinen Nutzen aus einer eigenen Variante zieht.
Anders als beim SK liegt die Verantwortlichkeit aber eindeutig beim Upstream-Team, das seine Sprints somit unabhängig vom Downstream-Team planen kann. Letzteres muss etwaige Auswirkungen durch Änderungen am Fachmodell in seinen Sprints einplanen. Upstream-Teams arbeiten häufig innerhalb der Core Domain des Unternehmens, wo der Hauptnutzen für die Kund:innen entsteht bzw. hauptsächlich das Geld verdient wird. Daher sind ihre Unabhängigkeit, Schnelligkeit/Time-To-Market und Reaktionsfähigkeit wichtig, da in der Core Domain der Wettbewerbsvorteil erarbeitet wird. Mit dem SK hat diese Strategie gemein, dass Teams, die sie nutzen, sich sehr eng aneinander binden.
Customer/Supplier
Diese Strategie bietet einem Downstream-Team (Customer) die Möglichkeit, Anforderungen an ein Upstream-Team (Supplier) zu stellen.
D. h., das Customer-Team nutzt Services, Daten oder Teile des Fachmodells des Supplier-Teams, kann nun aber Änderungen anfragen, die letzteres in seine Sprints einplant. Wie häufig Änderungen vom Supplier eingeplant und bis wann sie umgesetzt werden müssen, sollte dabei zwischen den Teams ausgehandelt werden, so dass eine gute Planbarkeit der jeweiligen Sprints bestehen bleibt. Wichtig dabei ist, dass das Customer-Team kein "Veto-Recht" haben sollte (d. h. Änderungen des Suppliers nicht ablehnen darf), da das Supplier-Team weiterhin Upstream ist und daher frei und unabhängig agieren können muss.
Open-Host-Service
Wenn ein Team einen generischen Service bereitstellt, der von anderen Teams/Anwendungen konsumiert wird, lässt sich dies als Open-Host-Service (OHS) realisieren. Charakteristisch für OHS ist, dass es ein universell nutzbares Fachmodell bereitstellt, welches über eine Published Language (PL) abgerufen werden kann. Ein gängiges Beispiel wäre ein SOAP-WebService, dessen PL über eine WSDL dokumentiert ist. Dabei ist das Team, das sich um den OHS kümmert, in der Regel Upstream, da es über Änderungen im Fachmodell und PL entscheiden kann. Die konsumierenden Teams sind Downstream und müssen sich an diese Änderungen anpassen.
Anticorruption Layer
Bei den bisherigen Strategien gab es immer Teams (meist Downstream), die Änderungen anderer Teams in ihren Sprints einplanen müssen. Wenn z. B. ein OHS sein Fachmodell ändert, müssen die konsumierenden Teams darauf reagieren (ggf. sofort, wenn die API des OHS nicht versioniert ist). D. h., die Upstream-Teams können dank dieser Strategien bereits frei sprinten, die Downstream-Teams aber nicht. Hier kommt der Anticorruption Layer (AL) ins Spiel, in dem Downstream-Teams eine Schicht etablieren, in der sie das eingehende Fachmodell in ihr eigenes übersetzen. Dadurch beschränken sie den durch Änderungen in Upstream-Bounded-Contexts, zu denen sie in Beziehung stehen, entstehenden Aufwand auf den AL. Das eigene, interne Fachmodell bleibt geschützt und kann weiter unabhängig und selbständig bearbeitet werden. AL können gut mit anderen Strategien kombiniert werden und für eine größtmögliche Unabhängigkeit als eigene Services deployt werden.
Separate Ways
Wenn zwei BCs keine Verbindungen zueinander haben, gehen sie Separate Ways. Dadurch können die Teams komplett unabhängig voneinander arbeiten. Manchmal lässt sich dies erreichen, indem Teile eines BCs in einen anderen umgezogen oder Teile eine Fachmodells redundant in beiden BCs gepflegt werden.
Soziotechnische Kopplung innerhalb der Context Map
Die Context Map trägt dem Umstand Rechnung, dass die einzelnen Module einer Systemlandschaft zueinander in Beziehung stehen und dies auch Einfluss auf die Zusammenarbeit zwischen den jeweils verantwortlichen Teams hat. Die einzelnen Strategien haben daher auch einen unterschiedlich hohen Grad an soziotechnischer Kopplung.
Die Strategien mit hoher soziotechnischer Kopplung führen auch zu den zuvor gezeigten Effekten. Insbesondere gefährden sie die Unabhängigkeit der Sprints und erhöhen die Anzahl notwendiger Absprachen/Meetings. Aber gegenüber einer Team-Organisation, die keiner dedizierten Strategie folgt, haben auch die eng gekoppelten Strategien den Vorteil, dass die Verantwortlichkeiten geklärt sind und insbesondere die Upstream-Teams vor äußeren Einflüssen verteidigt werden und somit unabhängig und selbständig sprinten können.
Denn eine Sache ist klar: Lose Kopplung wird zwar angestrebt, ist aber nicht immer möglich. In streng regulierten Branchen ist es z. B. notwendig, dass Teams sich (Teil-)Fachmodelle teilen, welche die gesetzlich vorgegebenen Regularien abbilden. Eine dedizierte Context Map bietet in so einem Szenario den Vorteil, dass nun klar ist, welches Team auf welche Weise Änderungen durchführen darf und wie andere Teams darauf reagieren müssen.
Zusammenfassung und nächste Schritte
Wie in den vorigen Abschnitten gezeigt wurde, ist es bei agilen Transformationen wichtig, auch immer eine Bestandsaufnahme auf technischer/Systemlandschafts-Ebene durchzuführen und eine Roadmap für den technischen bzw. architekturellen Anpassungsbedarf zu entwickeln, um eine ganzheitliche Herangehensweise zu ermöglichen. Umgekehrt ist bei technischen Anpassungen zu empfehlen, auch immer einen Blick auf die Organisationsstrukturen zu werfen und gegebenenfalls eine Change-Begleitung zu haben.
Zusammengefasst sollte also das große Ganze nicht einfach in zwei Teile geschnitten und isoliert betrachtet werden, sondern Hand in Hand angegangen werden: Bestenfalls durch enge Zusammenarbeit der Architektur mit der Organisationsentwicklung.
Das Finden der richtigen Bounded Contexts und zugehöriger Teams ist eine gemeinschaftliche Aufgabe für Entwicklung, Fachseite und weitere relevante Stakeholder. Es existieren viele Methoden, um dies in der Praxis umzusetzen. Eine stetig wachsende Community stellt einen Leitfaden bereit, in dem diese Methoden vorgestellt und ihre Anwendung in Schritt-für-Schritt-Anleitungen erklärt werden [5]. Hier bekommen interessierte Teams/Unternehmen alle nötigen Werkzeuge und Erklärungen an die Hand, die sie für den Beginn ihrer Reise zu einer harmonisierten Team- und Anwendungs-Architektur benötigen.
Darüber hinaus ist das Buch "Team Topologies" von Manuel Pais und Matthew Skelton sehr zu empfehlen, da es einige der Themen, die in diesem Artikel angerissen wurden, weiter vertieft [6].
Die Erkenntnis, dass Software-Architektur und Team-Organisation Hand in Hand gehen müssen und eine Agile Transformation selten funktioniert, ohne dass auch die Systemlandschaft analysiert und ggf. angepasst wird, ist dabei der erste Schritt. Wir hoffen, dass dieser Artikel helfen wird, diese Erkenntnis reifen zu lassen.
- J. P. Kotter: Accelerate: Building Strategic Agility for a Faster-Moving World, 2014
- M. E. Conway: How do committees invent?
- L. Colfer, C. Y. Baldwin: The Mirroring Hypothesis: Theory, Evidence and Exceptions
- E. Evans: Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley, 2003
- Github: Domain-Driven Design Starter Modelling Process
- M. Pais, M. Skelton: Team Topologies. IT Revolution Press, 2019
