Conway's Law
Conway's Law besagt: Der Aufbau eines Produkts spiegelt den Aufbau der Organisation, die es gebaut hat. Wer in getrennten Teams arbeitet, die kaum miteinander reden, bekommt am Ende auch getrennte, schlecht zusammenpassende Produktteile.
Conway’s Law ist eine Beobachtung darüber, wie Firmen Technik bauen. Sie stammt von Melvin Conway, einem amerikanischen Informatiker, der sie 1968 aufschrieb. Sein Satz lautet verkürzt: Ein Produkt bekommt dieselbe Struktur wie die Gruppe von Menschen, die es entwickelt hat. Wenn vier Teams an einer App arbeiten und jedes Team für sich bleibt, entstehen fast zwangsläufig vier klar getrennte Bausteine. Und die Nahtstellen zwischen diesen Bausteinen sehen genau so aus wie die Kommunikation zwischen den Teams: gut, wenn die Leute täglich reden, holprig, wenn sie es nicht tun. Conway’s Law ist kein Naturgesetz, sondern eine Faustregel, die sich in der Praxis immer wieder bestätigt.
Warum Organigramme in der Software landen
Für Unternehmen ist das eine unangenehme Erkenntnis. Man kann eine technische Lösung nicht beliebig planen, wenn die Firma dazu nicht passt. Ein Unternehmen mit steifen Abteilungsgrenzen wird kaum ein flüssig zusammenspielendes Produkt hervorbringen. Die Grenzen der Abteilungen tauchen im Produkt wieder auf, nur diesmal als technische Bruchstellen.
Besonders sichtbar wird das bei alten, großen Konzernen. Banken haben oft eine App, in der sich Depot, Kredit und Girokonto völlig unterschiedlich anfühlen. Das liegt selten an schlechten Programmierern. Es liegt daran, dass drei getrennte Abteilungen mit eigenen Budgets und eigenen Systemen dahinterstehen. Der Kunde spürt das Organigramm der Bank, ohne es je gesehen zu haben.
Umgekehrt nutzen manche Firmen den Effekt bewusst. Man spricht dann von der „umgekehrten Conway-Methode“: Zuerst überlegt man, welche Struktur das Produkt haben soll. Danach baut man die Teams genau so um, dass diese Struktur entstehen kann. Die Organisation wird also zum Werkzeug der Technikplanung, nicht zu ihrem Hindernis.
Der Mechanismus hinter der Beobachtung
Der Kern ist Kommunikationsaufwand. Damit zwei Programmteile sauber zusammenarbeiten, müssen sich die Menschen dahinter über viele Details einigen. Welche Daten werden übergeben? In welchem Format? Was passiert bei einem Fehler? Solche Absprachen sind mühsam und brauchen Zeit.
Innerhalb eines Teams sind diese Absprachen billig. Man sitzt zusammen, fragt kurz nach, ändert etwas noch am selben Tag. Zwischen zwei Abteilungen an zwei Standorten kostet dieselbe Frage eine Woche und drei Meetings. Entwickler weichen dieser Mühe instinktiv aus. Sie definieren stattdessen eine möglichst starre, möglichst einfache Schnittstelle und lassen sich danach in Ruhe. Genau dort entsteht die Trennlinie im Produkt.
Eine passende Analogie ist der Bau eines Hauses durch zwei Firmen, die jeweils eine Hälfte übernehmen. Sie werden sich auf eine gerade Trennwand einigen, weil alles andere ständige Rücksprache verlangt. Ein verschachtelter, offener Grundriss über beide Hälften wäre möglich, aber nur mit sehr viel Abstimmung. Das Ergebnis zeigt am Ende, wie die Firmen miteinander umgegangen sind.
Von Microservices bis zu KI-Teams
In Tech-News taucht Conway’s Law oft auf, wenn es um Microservices geht. Damit meint man Software, die in viele kleine, eigenständig laufende Dienste zerlegt ist. Firmen wie Amazon oder Spotify haben dazu passend kleine, unabhängige Teams gebildet, die ihren Dienst allein verantworten. Diese Teamstruktur ist keine Randnotiz, sondern die Voraussetzung dafür, dass die Technik funktioniert.
Auch bei KI-Produkten sieht man den Effekt. Wenn eine Firma ein Team für das Sprachmodell, ein zweites für die Suche und ein drittes für die Benutzeroberfläche hat, merkt man das im Ergebnis. Der Chatbot beantwortet Fragen gut, findet aber Dokumente schlecht, oder umgekehrt. Fusionen sind ein weiterer Klassiker: Nach dem Zusammenschluss zweier Firmen bleiben oft jahrelang zwei getrennte Systemlandschaften bestehen, weil auch die beiden Belegschaften getrennt bleiben.
Ein häufiger Irrtum ist, Conway’s Law als Schuldzuweisung an einzelne Entwickler zu lesen. Es beschreibt kein Versagen, sondern eine strukturelle Kraft. Wer die technische Architektur ändern will, muss deshalb meist zuerst an der Zusammenarbeit ansetzen. Ein Umbau der Software allein hält selten lange, wenn die alten Abteilungsgrenzen bestehen bleiben.