Conway's Law

Definition

Conway's Law besagt, dass die technische Architektur eines Systems immer die soziale Kommunikationsstruktur der Organisation widerspiegelt, die es gebaut hat. Melvin Conway formulierte 1968: "Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu entwickeln, die Kopien der Kommunikationsstrukturen dieser Organisationen sind." Wenn vier getrennte Entwicklungsabteilungen an einem Compiler arbeiten, wird das Resultat garantiert ein 4-Phasen-Compiler sein - unabhängig davon, ob dies die technisch beste Lösung ist.

Systemmechanismus

Software-Schnittstellen (APIs, Module) erfordern menschliche Abstimmung (Meetings, Slack). Wenn Entwickler in demselben Team sitzen, ist die Kommunikationsoberfläche reibungslos; sie bauen Code, der stark gekoppelt ist (Monolith). Wenn zwei Teams in unterschiedlichen Zeitzonen sitzen und sich nicht leiden können, werden sie ihre Code-Module durch starre, asynchrone Schnittstellen voreinander abschirmen. Die Architektur (der Code) verhält sich also genau wie die Sozialstruktur (das Org-Chart).

Architekturbeispiel

Eine Firma möchte auf eine moderne Microservice-Architektur migrieren, um unabhängigere Deployments zu ermöglichen. Die Entwickler bleiben aber in ihren alten Funktions-Silos sitzen (ein dediziertes Frontend-Team, ein Backend-Team, ein Datenbank-Team). Das Ergebnis: Die angebliche "Microservice-Architektur" wird zu einem hochgradig eng gekoppelten, verteilten Monolithen. Jedes Feature erfordert weiterhin die Koordination aller drei Teams, weil der Code nach Schichten (Frontend/Backend) anstatt nach Domänen (Microservices) geschnitten wurde – Conway's Law hat gesiegt.

Organisationsbeispiel

Um Conway's Law zu seinem Vorteil zu nutzen, wendet man das "Inverse Conway Maneuver" an. Die Firma möchte, dass das Checkout-System und das Recommendations-System völlig unabhängig skalieren (Tech-Ziel). Anstatt nur Architektur-Vorgaben zu machen, ändert das Management die Organisationsstruktur: Sie formen zwei völlig autarke, cross-funktionale Teams (mit eigenen Produktmanagern, Backend- und Frontend-Entwicklern), die in separaten Repositories arbeiten. Die Teamgrenze erzwingt die gewünschte API-Grenze im System.

Diagnosefragen

1.Versuchen wir gerade, eine technische Architektur zu erzwingen, die völlig quer zu unseren existierenden Team- und Abteilungsstrukturen steht?

2.Wo gibt es im Code unsaubere Abhängigkeiten ("Spaghetti-Integration"), die eigentlich nur existieren, weil Team A und Team B keinen ordentlichen Eskalationskanal zueinander haben?

3.Passen die kognitiven Grenzen eines Teams (wie viel Geschäftslogik kann ein Team im Kopf behalten) noch zu den harten Grenzen ihrer Code-Module?

Diagramm

Warum dieses Konzept in Architektur hilft

Software-Architektur ist nie nur pure Technik; es ist Soziotechnisches Design. Wenn ein Architektur-Board Pläne zeichnet, die nicht zur Realität der Team-Kommunikation passen, ist der Plan wertlos. Moderne Ansätze wie "Team Topologies" betrachten Conway's Law nicht als Hindernis, sondern als mächtigstes Design-Werkzeug: Gestalte die Team-Interaktions-Muster (wie "Stream-Aligned" oder "Platform Teams"), um das exakt gewünschte Architektur-Ergebnis hervorzubringen.

Woran du das Konzept von ähnlichen Themen unterscheidest

Conway's Law ist eng verwandt mit *Interdependence* (Abhängigkeit), jedoch verbindet dieses Gesetz ganz ausdrücklich die menschliche/organisatorische Abhängigkeit (Sozialsystem) direkt mit der Code-Abhängigkeit (Technisches System).

Wie du das Konzept praktisch nutzt

Bekämpfe Conway niemals. Wenn die Code-Struktur ("Was wir bauen wollen") und die Org-Struktur ("Wer redet mit wem") im Konflikt stehen, gewinnt am Ende immer die Organisation. Wenn schnelle, unabhängige Featurereleases gefordert sind (Microservices), dann zerschlage zuerst die organisatorischen Silos (QA, Ops, Dev) und bilde vollständig domänenzentrierte, vertikale Produktteams. Die Architektur wird der neuen Kommunikationsstruktur automatisch folgen.

Erste Umsetzungsschritte

Achte auf implizite Kommunikation! Wenn alle Entwickler dieselbe Datenbank nutzen oder im selben Slack-Channel jedes Problem ad-hoc diskutieren, entsteht ungeplante Kopplung im Code, auch wenn das Org-Chart saubere Trennung suggeriert.

Woran du Wirkung erkennst

Wurde bei der Umstellung auf das neue Architekturparadigma (z.B. Data Mesh, Micro-Frontends) auch das Unternehmens-Organigramm auf den Prüfstand gestellt?

Quellen

Melvin Conway — How Do Committees Invent? (1968)

Matthew Skelton & Manuel Pais — Team Topologies (IT Revolution, 2019)

Wikipedia: Conway's Law