Zum Hauptinhalt springen

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)