Murphy meets Conway: Wenn Domain-Driven Design schief geht

Was passiert, wenn etablierte theoretische Modelle auf die Realität von Softwareprojekten treffen? Die komplexen Zusammenhänge zwischen Softwarearchitektur und Kommunikationsstrukturen in soziotechnischen Systemen stellen uns vor faszinierende Herausforderungen.

In diesem Artikel fassen wir zentrale Erkenntnisse zum Spannungsfeld zwischen Conways Law und Murphys Gesetz zusammen und stellen praktische Lösungsansätze vor, die in realen Projekten funktionieren. Die Grundlagen dieser Einsichten wurden im Rahmen der IT-Tage 2024 in Frankfurt präsentiert, wo AOE-CTO Daniel Pötzinger und Senior Solution Architect Stefan Rotsch einen Vortrag unter dem provokativen Titel „Murphy meets Conway“ hielten.

Warum Murphy’s Law immer wieder zuschlägt und IT-Projekte scheitern

Mehr als 70 % aller IT-Projekte verlaufen nicht wie ursprünglich geplant. Diese alarmierende Statistik verdeutlicht Herausforderungen, denen Unternehmen – insbesondere große Organisationen – bei der Umsetzung komplexer IT-Vorhaben häufig gegenüberstehen. Besonders gravierend sind die Auswirkungen in Großunternehmen, da hier selten die meist verschachtelten und ineinandergreifenden Kommunikations-strukturen optimal auf die gewünschte Lösungsarchitektur abgestimmt sind.

An dieser Stelle kommt das von Melvin E. Conway formulierte Gesetz ins Spiel und erklärt treffsicher dieses Phänomen. Conway hat nämlich herausgefunden, dass die Struktur eines (Software-)Systems zwangsläufig die Kommunikationsstrukturen der Organisation widerspiegelt, die es entwickelt hat. Einfach ausgedrückt: Wenn Teams in einem Unternehmen auf eine bestimmte Art und Weise miteinander kommunizieren – sei es durch Abteilungen, Silos oder informelle Netzwerke –, dann wird sich diese Struktur direkt in der Architektur der entwickelten Software widerspiegeln.

Dieses Verhaltensmuster birgt für IT-Projekte erhebliche Risiken und führt in der Praxis erfahrungsgemäß zu einer Reihe von Problemen:

• Hohe Kosten: Fehl- oder Nicht-Kommunikation zwischen Teams und Abteilungen kann zu ineffizienten Entwicklungsprozessen und unnötigen Anpassungen führen.

• Zeitverzögerungen: Unterschiedliche Erwartungen und schlecht koordinierte Schnittstellen erfordern zusätzliche Abstimmungsrunden und Nacharbeiten, was die Fertigstellung eines Projekts erheblich verzögern kann.

Integrationsprojekte scheitern oft daran, dass die Software die Bedürfnisse der User:innen nicht erfüllt. Dies gilt im Übrigen nicht nur für Integrationen, sondern ebenso für Neuentwicklungen und Migrationen: Wer am Bedarf der Nutzer:innen oder an den Anforderungen des Marktes vorbeientwickelt, riskiert den Erfolg des gesamten Projekts. 

Problemlöser Domain-Driven Design (DDD) – Ist es wirklich so einfach?

Komplexe Kontexte und Vorhaben erfordern eine mehrdimensionale und differenzierte Beobachtung und Bearbeitung. Ein möglicher Lösungsansatz findet sich im Domain-Driven Design. DDD legt besonderen Wert auf die enge Zusammenarbeit zwischen Entwicklungsteams und Fachabteilungen. Dieses Zusammenspiel ist besonders wertvoll in komplexen Projekten, bei denen die Synchronisation von Geschäftsprozessen und Softwarearchitektur eine zentrale Herausforderung darstellt.

Durch einen kontinuierlichen und strukturierten Austausch wird sichergestellt, dass sowohl technische als auch fachliche Anforderungen frühzeitig verstanden und effizient umgesetzt werden. Dies fördert eine klare, einheitliche Kommunikation und schafft ein gemeinsames Verständnis für die Domäne sowie die spezifischen Herausforderungen des Projekts. Infolgedessen verbessert sich nicht nur die Qualität der Softwarearchitektur, sondern auch die Wartbarkeit, Skalierbarkeit und Anpassungsfähigkeit der entwickelten Lösung, was langfristig zu einem nachhaltigeren und erfolgreicheren Softwareprodukt führt. 

Aber: Domain-Driven Design erfordert sowohl Disziplin wie auch ein klares Commitment und die richtige Umgebung. Wer DDD nur als Buzzword verwendet, ohne die dahinterliegende Philosophie zu verinnerlichen, wird eher mit zusätzlicher Komplexität kämpfen als mit echten Vorteilen. Man sollte daher genau abwägen, ob DDD zur jeweiligen Unternehmensstrategie und IT-Architektur passt.

Somit bleibt DDD zwar ein sehr guter Ansatz, aber eben kein Allheilmittel, wie die nachfolgenden Beispiele aus dem operativen Projektgeschäft eindrucksvoll belegen.

Beispiele aus der Praxis: Lernen aus Erfahrungen

Persönliche Praxiserfahrungen sind nicht nur greifbarer als die reine Theorie, sondern bieten auch die Möglichkeit, aus ihnen zu lernen, ähnlich gelagerte Fehler in zukünftigen Projekten zu vermeiden und neue, bessere Wege zu gehen. Nachfolgend fassen wir für Euch drei unterschiedliche Beispiele aus realen Projekten und die daraus resultierenden Learnings einmal zusammen.

1. Vom Monolith zu Microsilos

Werfen wir einen Blick auf die Transformation von einer monolithischen Architektur hin zu Microservices – einem Ansatz, der in der modernen Softwareentwicklung zunehmend an Bedeutung und Popularität gewinnt. Microservices ermöglichen es, große Systeme in kleinere, unabhängige Einheiten zu zerlegen, wodurch Teams mehr Autonomie erhalten und einzelne Services flexibler entwickelt, skaliert und gewartet werden können. 

Ein zentraler Aspekt bei der Gestaltung einer solchen Microservice-Architektur ist das Zusammenspiel zwischen Teamstruktur und Softwarearchitektur. Wenn sich die gewünschte Architektur allerdings nicht einstellt, kann dies ein Hinweis darauf sein, dass die Teams nicht genügend Autonomie besitzen, um die Services eigenverantwortlich zu gestalten. In diesem Fall kann das „Inverse Conway Maneuver“ ein wirksames Mittel sein: Statt darauf zu warten, dass die Architektur sich aus der bestehenden Organisation ergibt, müssen gezielt Rahmenbedingungen geschaffen werden, die den Teams mehr Entscheidungsfreiheit und Eigenverantwortung ermöglichen.

Allerdings bringt zu viel Autonomie auch Herausforderungen mit sich: So besteht das Risiko der Entstehung sogenannter Microsilos – isolierte Teams und Services, die fast schon zu autonom  agieren und dadurch die übergreifende Abstimmung und Zusammenarbeit innerhalb des Gesamtsystems erschweren. Dies kann zu einer ungewünschten, aber durch die Struktur der Software bedingten Fragmentierung der Organisation führen, bei der wichtige Synergien verloren gehen und technische sowie kommunikative Hürden den Projekterfolg gefährden.

Die beiden Referenten verdeutlichten, wie sich diese Problematik durch gezielte Maßnahmen abmildern lässt. Hierzu empfahlen sie eine klare Rollenverteilung innerhalb der Teams, um Verantwortlichkeiten präzise zu definieren und die Kommunikation zu fördern. Darüber hinaus betonten sie die Bedeutung eines übergreifenden Alignments, bei dem regelmäßige Abstimmungen, transparente Ziele und gemeinsame Standards sicherstellen, dass alle Teams trotz ihrer Autonomie auf ein gleiches gemeinsames Ziel hinarbeiten. So lassen sich die die Vorteile von Microservices effizient nutzen, ohne dabei die Risiken der Isolation einzelner Teams und Services aus den Augen zu verlieren. 

Die Herausforderung besteht also darin, die richtige Balance zu finden. Es braucht genügend Freiheit, um Innovationskraft und Geschwindigkeit zu fördern, aber auch klare Leitplanken, um ein kohärentes Gesamtbild zu gewährleisten. Die Kunst liegt darin, flexibel nachzusteuern und die Organisationsstruktur sowie Architektur kontinuierlich aufeinander abzustimmen.

2. Hand in Hand: Kommunikationsstrukturen und API-Design 

Ein weiteres Praxisbeispiel aus dem Vortrag war die enge Verknüpfung zwischen Kommunikationsstrukturen und API-Design. Daniel Pötzinger und Stefan Rotsch schilderten dabei das „Meeting-getriebene API-Design-Paradoxon“: Obwohl die Teams äußerst detailliert – bis auf die Ebene einzelner Datenfelder – ihre API-Struktur planten, setzten sie den falschen Schwerpunkt. Statt sich darauf zu konzentrieren, welche fachlichen Use Cases existieren und was die tatsächlichen Bedürfnisse der API-Konsumenten sind, lag der Fokus ausschließlich auf der reinen Datenstruktur. Dadurch entstand eine Architektur, die technisch präzise, aber praktisch wenig brauchbar war.

Dieses Phänomen tritt häufig auf, wenn sich Teams nicht ausreichend auf die Fachlichkeit fokussieren und stattdessen versuchen, Integrationsprobleme nachträglich zu beheben. Dies führt zu hoher Kopplung zwischen Services und einem erheblichen Mehraufwand bei der Integration.

Als Gegenmaßnahme betonten unsere beiden Referenten die Bedeutung eines API-First-Ansatzes, bei dem Domänenexpert:innen frühzeitig eingebunden werden, um sicherzustellen, dass fachliche Anforderungen direkt in das API-Design einfließen. Fachlich orientierte Domain-Events, die für eine lose Kopplung zwischen den Komponenten sorgen und klare Verantwortlichkeiten sollten bevorzugt als Integrationsmuster eingesetzt werden. Dieses Vorgehen reduziert nicht nur den Kommunikationsaufwand, sondern sorgt auch für eine bessere Skalierbarkeit der Systeme.

3. Auf halber Strecke stehen geblieben: Migrationsfallen

Ein weiteres Highlight war die Analyse typischer Herausforderungen bei Migrationsprojekten. Viele Unternehmen sehen sich mit der Aufgabe konfrontiert, veraltete Systeme durch moderne Lösungen zu ersetzen. Dieser Prozess wird jedoch unter anderem durch die nachfolgenden sogenannten Migrationsfallen erschwert:

• Hohe Abstimmungsaufwände: Insbesondere bei der Zusammenarbeit zwischen bestehenden und neuen Teams steigen die Kommunikationsanforderungen oftmals auf ein unvorhergesehen hohes Niveau. Dies führt nicht selten dazu, dass der erwartete Nutzen der Migration durch übermäßige Aufwände neutralisiert wird.

• Technische Fokussierung: In vielen Fällen konzentriert sich die Migration auf die Übertragung technischer Datenmodelle, ohne die fachliche Perspektive ausreichend zu berücksichtigen. Dies kann dazu führen, dass neue Systeme zwar technisch funktionieren, die fachlichen Anforderungen jedoch nicht erfüllen.

• Das Pareto-Prinzip – oder auch die 80/20-Regel: Häufig konzentriert man sich bei einer Migration darauf, die wichtigen 80 % der Funktionalität zu übernehmen, während die verbleibenden 20 % für „später“ vorgesehen werden – was in der Praxis oft bedeutet, dass sie nie migriert werden. Das Ergebnis: Die alte Legacy-Software bleibt für diese 20 % weiterhin im Betrieb, parallel zur neuen Lösung. Dadurch entsteht eine hybride Landschaft mit mehr Teams, mehr Services und doppeltem Aufwand für Wartung und Weiterentwicklung. Im schlimmsten Fall müssen Anpassungen sowohl im alten als auch im neuen System vorgenommen werden – und die angestrebte Vereinfachung wird durch zusätzliche Komplexität ersetzt.

Ein Tipp an dieser Stelle: Migrationsprojekte strategisch planen und dabei sowohl fachliche als auch technische Anforderungen kontinuierlich zu integrieren. Der Aufbau eines Kompatibilitäts-Layers kann helfen, die Koexistenz von Alt- und Neusystemen zu erleichtern und den Übergang schrittweise zu gestalten. Wichtig ist, dass Migrationsprojekte mit einem klaren Commitment gestartet werden: Eine Migration ist erst dann wirklich erfolgreich abgeschlossen, wenn die Legacy-Komponenten vollständig abgeschaltet sind. Nur ein Teil der Funktionen zu migrieren und den Rest auf unbestimmte Zeit in der alten Umgebung weiterzubetreiben, führt zu unnötiger Komplexität und doppeltem Aufwand. Eine erfolgreiche Migration bedeutet nicht nur, etwas Neues einzuführen, sondern auch konsequent Altes abzubauen.

Die Balance zwischen Technologie und Organisation halten

Die Referenten schlossen mit dem Fazit, dass technologische Entscheidungen niemals isoliert betrachtet werden sollten, sondern stets in engem Zusammenhang mit den organisatorischen Rahmenbedingungen stehen müssen, da letztendlich der Erfolg eines IT-Projekts darauf beruht, Technologie und Organisation untrennbar miteinander zu verbinden.

Die Handlungsempfehlungen für nachhaltige IT-Projekte noch einmal zusammengefasst:

• Continuous Integration der Fachlichkeit: Ein frühes Einbinden von Domänenexpert:innen und die Definition fachlicher Integrationsmuster, wie Domain Events, reduzieren Kopplung und Integrationsaufwände,  verhindern, dass Projekte in isolierten Übergangslösungen stecken bleiben, und sorgt für nachhaltige Weiterentwicklung.

• API-First-Strategie nach dem „High Cohesion, Low Coupling“-Prinzip : Jede API sollte klar definierte und zusammenhängende Funktionen anbieten und sollte so gestaltet sein, dass sie möglichst unabhängig von anderen APIs arbeiten kann.

• Moderierte Prozesse: Eine Balance zwischen technologischem Fortschritt und organisatorischen Strukturen ist entscheidend, um Komplexität zu meistern und langfristig handlungsfähig zu bleiben.

Hierbei wäre – richtig angewandt – der Softwareentwicklungs-Ansatz Domain Driven Design (DDD) durchaus sinnvoll, da er sowohl die strategische wie auch die taktische Sicht berücksichtigt. Auf strategischer Ebene bedeutet dies, klare Strukturen und Verantwortlichkeiten zu schaffen, etwa durch die Identifikation und Definition von Bounded Contexts oder die Etablierung gemeinsamer gleichlautender Zielbilder für alle Teams. Auf taktischer Ebene erfordert es präzise Methoden und Werkzeuge, die sicherstellen, dass technische Lösungen nicht nur funktional sind, sondern auch langfristig flexibel, wartbar und erweiterbar bleiben. Organisationen, die diesen integrativen Ansatz verfolgen, sind so in der Lage, den wachsenden Anforderungen der digitalen Transformation gerecht zu werden und gleichzeitig ein hohes Maß an Effizienz und Innovationskraft zu bewahren.

(lb/AOE)