Das Gesetz von Conway und die Gestalt von Organisationen

Was Conway tatsächlich sagte

Im April 1968 veröffentlichte die Zeitschrift Datamation „How Do Committees Invent?“ von Melvin Conway, einem Programmierer und Berater. Sein Fazit ist der Satz, der heute als Gesetz von Conway bekannt ist: Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe hervorzubringen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind. Der Name kam später: Fred Brooks zitierte den Artikel in The Mythical Man-Month (1975) und nannte die Idee Conway’s law.

Conways Argument ist präziser als das Schlagwort. Ein System besteht aus Subsystemen, die über Schnittstellen verbunden sind. Damit zwei Subsysteme sich verbinden, müssen die Menschen, die sie entwerfen, diese Schnittstelle ausgehandelt und vereinbart haben; sie müssen also kommuniziert haben. Wenn die Designer zweier Subsysteme nicht miteinander kommunizieren, gibt es keine Schnittstelle, auf die sie sich einigen könnten. Es gibt daher eine strukturerhaltende Entsprechung (Conway verwendete den mathematischen Begriff Homomorphismus) zwischen dem Graphen des Systems und dem Graphen der Organisation, die es entworfen hat. Sein Beispiel: Eine Auftragsforschungsorganisation hatte acht Personen, die einen COBOL- und einen ALGOL-Compiler schreiben sollten. Fünf wurden COBOL zugeteilt, drei ALGOL. Der COBOL-Compiler lief in fünf Phasen, der ALGOL-Compiler in drei.

Zwei weitere Punkte aus dem Artikel werden oft vergessen. Erstens stellte Conway ausdrücklich klar, dass „System“ weit gemeint ist: Es gilt für jedes entworfene Ding, nicht nur für Software. Zweitens betraf sein praktisches Fazit die Flexibilität. Weil der erste Entwurf selten der beste ist und weil eine Organisation ihre Struktur meist früh festlegt (sobald Teams gebildet sind, ist der Entwurf schon teilweise entschieden), forderte er, Designorganisationen schlank und flexibel zu halten und nach der Kommunikation zu organisieren, die der Entwurf tatsächlich braucht.

Die Belege: die Mirroring Hypothesis

Jahrzehntelang stützte sich das Gesetz von Conway vor allem auf Anekdoten. Seit den 2000er-Jahren haben Forschende es überprüft, meist unter dem Namen Mirroring Hypothesis: Die technischen Abhängigkeiten in einem Produkt entsprechen den organisatorischen Verbindungen (Kommunikation, gemeinsamer Standort, Anstellung) zwischen den Menschen, die es bauen.

Die bekannteste Softwarestudie stammt von Alan MacCormack, Carliss Baldwin und John Rusnak, 2012 in Research Policy veröffentlicht als „Exploring the duality between product and organizational architectures: a test of the mirroring hypothesis“. Sie verglichen passende Paare von Produkten mit ähnlichen Funktionen, eines von einer eng gekoppelten Organisation gebaut (ein kommerzielles Unternehmen mit einem Team am selben Standort) und eines von einer lose gekoppelten Organisation (eine verteilte Open-Source-Community): zum Beispiel zwei Finanzverwaltungspakete, zwei Textverarbeitungen, zwei Datenbanken sowie Linux im Vergleich mit kommerziellen Betriebssystemkernen. Modularität maßen sie über die Propagation Cost, den durchschnittlichen Anteil der Dateien eines Systems, den eine Änderung an einer Datei direkt oder indirekt betreffen kann. In jedem Paar war das Produkt der lose gekoppelten Organisation modularer, und im extremsten Paar betrug der Unterschied ein Mehrfaches. Die Autoren deuten dies als Beleg dafür, dass verteilte Teams, die sich nicht leicht abstimmen können, zu Entwürfen gedrängt werden, die weniger Abstimmung brauchen.

Eine Studie von Microsoft Research zu Windows Vista von Nachiappan Nagappan, Brendan Murphy und Victor Basili (2008) näherte sich der Frage von der Qualitätsseite. Kennzahlen, die die Organisation hinter jedem Binary beschrieben (wie viele Fachleute daran gearbeitet hatten, wie viele das Unternehmen verlassen hatten, wie weit die Beteiligten in der Managementhierarchie auseinanderlagen), sagten besser vorher, welche Binaries fehleranfällig waren, als herkömmliche Codemetriken wie Churn, Komplexität, Testabdeckung und Abhängigkeiten.

Die Belege sind nicht einhellig, und die ehrliche Zusammenfassung zählt. Eine Übersichtsarbeit von Lyra Colfer und Carliss Baldwin aus dem Jahr 2016 über 142 empirische Studien fand Spiegelung in Studien zu Branchen und Unternehmen häufig, aber nicht universell, und stellte fest, dass Studien zu offenen kollaborativen Projekten sie oft nicht stützten, vermutlich weil gemeinsame Code-Repositories, Issue-Tracker und offene Diskussion es verteilten Beteiligten erlauben, sich ohne die üblichen organisatorischen Verbindungen abzustimmen. Spiegelung ist eine starke Tendenz, kein Naturgesetz, und gute Werkzeuge und Praktiken können sie teilweise durchbrechen.

Kommunikationspfade und warum die Teamgröße zählt

Eine Gruppe von n Personen hat n(n − 1) / 2 mögliche Kommunikationspfade zwischen je zwei Personen. Die Zahl wächst ungefähr mit dem Quadrat der Gruppe: Ein doppelt so großes Team hat viermal so viele Pfade. Brooks erklärte mit derselben Arithmetik, warum zusätzliche Leute ein verspätetes Projekt noch weiter verzögern: Jede neue Person muss eingearbeitet werden und bringt neue Pfade mit, die alle pflegen müssen.

Architektonisch erklärt die Arithmetik zwei Dinge. Erstens kann ein einzelnes Team nicht unbegrenzt wachsen und dennoch ein gemeinsames Verständnis seines Codes behalten; ab einer bestimmten Größe zerfällt es in informelle Untergruppen, und nach dem Gesetz von Conway zerfällt der Code entlang derselben Linien, ob jemand diese Nahtstellen entworfen hat oder nicht. Zweitens zählt die Zahl der Pfade zwischen Teams ebenso wie die innerhalb von Teams: Wenn jedes Team mit jedem anderen sprechen muss, um eine Änderung auszuliefern, ist das System faktisch eine große, gekoppelte Einheit, egal wie viele Services es hat.

Das Inverse Conway Maneuver

Wenn Organisationen dazu neigen, Systeme hervorzubringen, die ihre Struktur spiegeln, können Sie diese Tendenz bewusst nutzen: Gestalten Sie die Teamstruktur und die Kommunikationspfade für die Architektur, die Sie wollen, und lassen Sie das System in diese Form hineinwachsen. Jonny LeRoy und Matt Simons nannten dies im Dezember 2010 in einem Artikel im Cutter IT Journal das Inverse Conway Maneuver, und es ist seither eine Standardtechnik in Microservice- und Plattformprogrammen.

In der Praxis heißt das: zuerst die beabsichtigten Grenzen festlegen (zum Beispiel Bestellungen, Zahlungen, Lieferverfolgung und Restaurant-Onboarding als getrennte Services), dann um jede ein langlebiges Team bilden, ihm die Verantwortung für Code, Daten und Deployment-Pipeline übertragen und dafür sorgen, dass Teams vor allem über veröffentlichte APIs und Events zusammenarbeiten statt über gemeinsamen Code oder gemeinsame Datenbanken. Wo Kontakt über Teamgrenzen hinweg wirklich nötig ist, machen Sie ihn explizit: ein Plattformteam, das ein Self-Service-Produkt anbietet, ein Enabling Team, das für begrenzte Zeit hilft.

Das Manöver hat Grenzen. Gegen die Struktur eines bestehenden Systems wirkt es nur langsam: Teams umzuorganisieren strukturiert keine eng gekoppelte Codebasis um, und eine Zeit lang werden die neuen Teams gegen die alte Architektur ankämpfen. Martin Fowler merkt an, dass es ein starres bestehendes System nicht schnell reparieren kann. Außerdem setzt es voraus, dass Sie die richtigen Grenzen kennen; ziehen Sie sie falsch und verfestigen sie dann in Teamstrukturen, wird das Gesetz von Conway den Fehler getreu reproduzieren und seine Korrektur teuer machen. Deshalb beginnen Teams oft mit einem modularen Monolithen und verschieben Grenzen, bevor sie sie organisatorisch verankern.

Kognitive Last des Teams

Das Gesetz von Conway sagt Ihnen, dass Teamgrenzen zu Systemgrenzen werden. Eine zweite Randbedingung sagt Ihnen, wie groß der Teil jedes Teams sein darf. Die kognitive Last des Teams, ein Konzept, das Matthew Skelton und Manuel Pais mit Team Topologies (2019; zweite Auflage 2025) in die Gestaltung von Softwareorganisationen eingeführt haben, ist die Gesamtmenge dessen, was ein Team im Kopf behalten muss, um das zu bauen, zu betreiben und zu ändern, was es verantwortet: die fachliche Domäne, den Code, die Infrastruktur, die Werkzeuge, die Rufbereitschaft.

Sie übernehmen aus der Psychologie die Unterscheidung zwischen intrinsischer Last (der inhärenten Schwierigkeit der Aufgabe, etwa die Domäne zu verstehen), extrinsischer Last (Aufwand, den die Umgebung auferlegt, etwa ein manueller Deployment-Ablauf oder ein undurchsichtiger Build) und lernbezogener Last (dem Lernaufwand, der künftige Arbeit verbessert). Ziel der Gestaltung ist es, die extrinsische Last zu minimieren, zum Beispiel durch Plattformen und Automatisierung, damit die Kapazität in die intrinsische und die lernbezogene Last fließt.

Für Architekten ist die Folge unmittelbar. Eine Service- oder Komponentengrenze sollte dem verantwortlichen Team einen Teil des Systems geben, den es vollständig verstehen kann. Verantwortet ein Team zwölf Services in vier Domänen, ist es überlastet, und entweder Qualität, Tempo oder die Gesundheit der Rufbereitschaft leiden, egal wie sauber der Code jedes Service ist. Umgekehrt kann eine Domäne, die so kompliziert ist, dass kein Stream-aligned Team sie bewältigen kann (eine Preis-Engine mit versicherungsmathematischen Modellen, ein Video-Codec), ein Spezialistenteam und eine klare Grenze um ihr Subsystem rechtfertigen.

Grenzen von der Teamstruktur prägen lassen

Zusammengenommen geben diese Ideen Architekten eine Reihe von Arbeitsregeln:

Richten Sie Grenzen an der Teamverantwortung aus. Jedes Modul, jeder Service, jeder Datenspeicher und jede Pipeline sollte genau ein verantwortliches Team haben. Geteilte Verantwortung heißt in der Praxis keine Verantwortung, und der Code wird widerspiegeln, was auch immer die letzte beitragende Person brauchte.

Minimieren Sie die Kommunikation, die jede Änderung braucht. Eine Grenze liegt an der richtigen Stelle, wenn die meisten Änderungen an einer fachlichen Fähigkeit von einem Team umgesetzt, getestet und deployt werden können. Achten Sie auf Änderungen, für die sich regelmäßig drei Teams abstimmen müssen: Sie zeigen, dass die Struktur des Systems und die Teamstruktur nicht übereinstimmen.

Machen Sie Schnittstellen zwischen Teams explizit und stabil. Schnittstellen zwischen Teams verdienen Versionierung, Dokumentation und Contract Tests; Schnittstellen innerhalb eines Teams können informell bleiben und sich frei ändern.

Überprüfen Sie beides gemeinsam. Umorganisationen sind Architekturentscheidungen; Architekturentscheidungen sind organisatorische Entscheidungen. Ein Architekt, der zu Teamänderungen nicht gefragt wird, oder eine Führungskraft, die umorganisiert, ohne den Code zu bedenken, ignoriert eine Kraft, die trotzdem wirkt.

Die Muster für Teamtypen und Interaktionsmodi und wie man sie weiterentwickelt, behandelt Team Topologies und soziotechnisches Design.