Conway’s Law
Conway’s Law beschreibt einen fundamentalen Zusammenhang zwischen Organisationsstruktur und Software-Architektur:
„Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu erzeugen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.“
– Melvin E. Conway, 1968
In der Alltagssprache heißt das:
Dein System sieht strukturell aus wie deine Organisation.
Die Art, wie Teams kommunizieren, spiegelt sich in der Struktur deiner Software wider.
1. Was bedeutet das praktisch?
Conway beobachtete, dass:
- Module, Komponenten und Schnittstellen dort entstehen, wo Menschen kommunizieren,
- komplexe Systeme dort fragmentiert werden, wo die Organisation in Gruppen geteilt ist,
- Kommunikation und Abhängigkeiten im Code abbildbar sind wie im Org-Chart.
Das heißt nicht nur, dass ein Org-Chart kopiert wird –
sonder dass Kommunikations- und Koordinationsaufwand direkt auf die technische Struktur durchschlägt.
2. „Conway’s Law revisited“ – moderne Forschung
Neuere Arbeiten gehen über die einfache Aussage hinaus:
🔎 Task-Level-Perspektive
Ein Artikel in IEEE Software zeigt:
Ein genauerer Blick auf Conway’s Law lohnt sich auf Task-Ebene statt nur auf Architektur-Ebene.
Das bedeutet:
- Nicht nur Team-Strukturen beeinflussen Architektur,
- sondern auch die Aufgaben, die Entwickler tatsächlich bearbeiten.
Teams, die gemeinsam an Aufgaben arbeiten, erzeugen technische Strukturen, die ihre koordinativen Abhängigkeiten widerspiegeln.
In der Praxis heißt das:
Wenn Entwickler A und B (oder Teams) regelmäßig zusammenarbeiten, werden ihre Code-Artefakte tendenziell stärker gekoppelt.
🔢 Mathematische Modellierung (2023)
Auch aus einem mathematischen Blickwinkel gibt es neue Arbeiten, die Conway’s Law formal mit Graphentheorie modellieren.
Dort wird aufgezeigt, wie Organisations- und Systemstruktur als abstrahierte Graph-Homomorphismen zueinander stehen – was Conway’s ursprüngliche Beobachtung präziser und messbar macht.
Das ist vor allem wertvoll, wenn man mit automatisierten Analysen (z. B. Social/Tec Network Analysis) das Spiegeln tatsächlich quantifizieren möchte.
3. Warum es relevant für Architektur ist
💡 Ausgangspunkt: Kommunikation formt Systeme
Conway’s Law zeigt:
Architektur wird nicht nur „entworfen“ –
sie wächst aus den Kommunikationsmustern heraus.
Wenn du versuchst, eine modulare Architektur zu erzwingen,
aber Teams und ihre Kommunikationswege bleiben ungeordnet, dann entsteht häufig ein distributed monolith – ein System, das zwar technisch aufgeteilt ist, aber organisatorisch stark gekoppelt bleibt.
4. Konsequenzen in der Praxis
📌 Teams und Architektur müssen gemeinsam gedacht werden
Das bedeutet:
- Team-Struktur sollte den gewünschten Architektur-Grenzen entsprechen
- Verantwortung für Module und Dienste klar zugeordnet werden
- Kommunikationswege bewusst gestaltet werden
Die Inverse Conway Maneuver-Idee besagt:
Wenn du eine bestimmte Architektur willst,
dann stelle Organisation & Kommunikation so auf, dass sie diese Architektur begünstigen.
5. Beispiele im Alltag
Microservices vs. Teams
Microservices scheitern oft, weil:
- Teams nicht wirklich autonom sind
- Kommunikationsgrenzen falsch gesetzt sind
- Architektur „von oben“ erzwungen wird, ohne Team-Alignment
Erfolgreiche Microservice-Organisationen:
- organisieren Teams um Business Capabilities
- minimieren notwendige koordinative Abhängigkeiten
- reduzieren Kommunikationsbarrieren
Das ist direkte Anwendung von Conway’s Law in der Organisations- und Architekturplanung.
6. Fazit
Conway’s Law ist mehr als ein „witziges Zitat“.
Es ist eine empirisch gestützte Hypothese, die belegt:
- technische Struktur spiegelt organisatorische Kommunikation
- Alignment von Teams und Architektur verbessert Produktivität und Qualität
- moderne Interpretationen ermöglichen sogar messbare Modellierung
Kurz:
Architektur folgt nicht nur dem Code –
Architektur folgt der Art und Weise, wie Menschen zusammenarbeiten.
Empfohlene Quellen
- Melvin Conway – „How Do Committees Invent?“ (1968)
- Conway’s Law Revisited (Task-Level Evidence, IEEE Software)
- Conway’s Law revisited from mathematical viewpoint (Graph Theory)