Conway’s Law beschreibt den Zusammenhang zwischen der Struktur einer Organisation und der Architektur der Systeme, die diese Organisation entwickelt.
Die bekannteste Formulierung lautet sinngemäß:
Organisationen, die Systeme entwerfen, erzeugen Designs, deren Struktur die Kommunikationsstrukturen dieser Organisationen widerspiegelt.
Das Gesetz geht auf den Informatiker Melvin E. Conway zurück, der diese Beobachtung 1968 veröffentlichte.
Conway’s Law besagt nicht, dass Softwarearchitektur ausschließlich durch Organisationen bestimmt wird. Es beschreibt vielmehr eine starke Tendenz: Die Art, wie Teams miteinander kommunizieren, beeinflusst die Grenzen, Schnittstellen und Abhängigkeiten technischer Systeme.
Beispiel:
Conway’s Law ist besonders relevant für:
Die zentrale Aussage ist: Architektur ist nicht nur eine technische Entscheidung, sondern auch eine organisatorische Folge.
Wenn eine Organisation stark in Silos aufgeteilt ist, entstehen häufig Systeme mit vielen Übergaben, schwerfälligen Schnittstellen und hoher Abstimmungsnotwendigkeit. Umgekehrt können gut geschnittene Teams dabei helfen, klarere Systemgrenzen zu schaffen.
Ein klassisches Beispiel ist der Übergang von einem Monolithen zu Microservices.
Wenn ein Unternehmen Microservices einführt, aber die Organisation weiterhin zentralisiert und funktional getrennt bleibt, kann das Ergebnis problematisch sein:
In diesem Fall entstehen zwar technisch mehrere Services, organisatorisch bleibt das System aber abhängig von denselben alten Kommunikationswegen. Die Architektur wirkt modern, aber die Arbeitsweise bleibt langsam.
Ein besserer Ansatz besteht darin, Teams so zu schneiden, dass sie fachliche Verantwortung übernehmen können. Ein Team besitzt dann beispielsweise einen klaren Geschäftsbereich inklusive Entwicklung, Betrieb und Weiterentwicklung der zugehörigen Services.
Das Inverse Conway Maneuver beschreibt den bewussten Versuch, die Organisationsstruktur so zu verändern, dass sie die gewünschte Systemarchitektur unterstützt.
Statt nur die Software umzubauen, wird auch die Teamstruktur angepasst.
Beispiel:
Das Ziel ist, dass Organisation und Architektur zusammenpassen.
Conway’s Law ist eine wichtige Grundlage für moderne Organisationsmodelle wie Team Topologies.
Dabei wird betrachtet, welche Teamarten es gibt und wie Teams miteinander interagieren sollen. Besonders wichtig ist die Idee, dass Teams möglichst klare Verantwortungsbereiche und definierte Interaktionsmuster haben sollten.
Typische Teamarten in diesem Zusammenhang sind:
Auch hier gilt: Die technische Architektur soll nicht isoliert betrachtet werden, sondern gemeinsam mit Teamgrenzen, Kommunikationsaufwand und kognitiver Belastung.
Aus Conway’s Law ergeben sich mehrere praktische Empfehlungen:
Conway’s Law wird manchmal missverstanden. Es bedeutet nicht:
Richtiger ist: Organisationsstruktur, Kommunikation und Architektur beeinflussen sich gegenseitig. Wer nur den Code ändert, aber die Arbeitsweise unverändert lässt, löst oft nicht das eigentliche Problem.
Eine bewusste Berücksichtigung von Conway’s Law kann helfen, folgende Ziele zu erreichen:
Wird Conway’s Law ignoriert, können typische Probleme entstehen:
Conway’s Law macht sichtbar, dass Softwarearchitektur und Organisationsstruktur eng miteinander verbunden sind. Systeme spiegeln häufig die Kommunikationswege der Menschen wider, die sie bauen.
Für moderne Softwareentwicklung bedeutet das: Wer die Architektur verbessern will, sollte nicht nur über Technologien, Module und Schnittstellen sprechen, sondern auch über Teams, Verantwortlichkeiten und Zusammenarbeit.
Das Ziel ist eine Organisation, deren Kommunikationsstruktur die gewünschte Architektur unterstützt, statt sie ungewollt zu behindern.