Der Spiegel der Organisation – Conways Gesetz und die Empirie des Mirroring

Der Aufhänger

Ein Unternehmen gründet drei Teams: Frontend, Backend, Datenbank. Achtzehn Monate später hat das System – Überraschung – drei Schichten, und jede neue Funktion braucht drei Tickets, drei Sprint-Plannings und eine Abstimmungsrunde. Ein anderes Unternehmen gründet fünf Teams entlang von Geschäftsfähigkeiten: Katalog, Warenkorb, Bezahlung, Versand, Konto. Sein System zerfällt in fünf Dienste mit schmalen Schnittstellen.

Zufall? Melvin Conway hat 1968 behauptet: nein. Seine These ist als „Conways Gesetz" bekannt und wird in Architekturdiskussionen oft zitiert. Ich bin der Meinung, dass der Originalaufsatz dagegen eher selten nachgelesen wird. Dieser Artikel fragt deshalb zweierlei: Was hat Conway tatsächlich geschrieben? Und was sagt die empirische Forschung der folgenden Jahrzehnte – stimmt das „Gesetz", und wo hat es Ausnahmen?

Das Kernkonzept: Was Conway wirklich schrieb

Der Aufsatz heißt How Do Committees Invent? und erschien im April 1968 in der Zeitschrift Datamation. Seine Schlussfolgerung formuliert Conway selbst als „basic thesis": Organisationen, die Systeme entwerfen (in einem weiten Sinn des Wortes), sind gezwungen, Entwürfe hervorzubringen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.

Drei Details dieser Formulierung werden in der populären Wiedergabe oft verschliffen:

1. Kommunikationsstruktur, nicht Organigramm. Conway spricht von den Kommunikationsstrukturen. Das formale Organigramm ist nur eine Annäherung daran; wer täglich miteinander spricht, zählt mehr als Linienzugehörigkeit.
2. „Constrained" – eine Einschränkung, kein Naturgesetz im physikalischen Sinn. Conway argumentiert, dass zwei Teilsysteme nur dann sauber über eine Schnittstelle zusammenarbeiten können, wenn ihre Entwerfer miteinander kommunizieren. Wo keine Kommunikation stattfindet, entsteht auch keine fein abgestimmte Schnittstelle.
3. Ein mathematischer Kern. Conway modelliert System und Organisation jeweils als Graphen und beschreibt die Beziehung als strukturerhaltende Abbildung – im Text ausdrücklich als Homomorphismus bezeichnet: vom Graphen des Systems zum Graphen der Entwurfsorganisation.

Sein bekanntestes Beispiel: Eine Auftragsforschungsorganisation hatte acht Leute, die einen COBOL- und einen ALGOL-Compiler bauen sollten. Fünf wurden dem COBOL-Projekt zugeteilt, drei dem ALGOL-Projekt. Der resultierende COBOL-Compiler lief in fünf Phasen, der ALGOL-Compiler in drei.

Weniger bekannt, aber für die Praxis wichtiger, ist Conways Folgerung: Weil der zuerst entstehende Entwurf fast nie der bestmögliche sei, müsse sich das vorherrschende Systemkonzept womöglich ändern – und deshalb sei Flexibilität der Organisation wichtig für gutes Design. Conway beschreibt also nicht nur ein Phänomen, sondern eine Gefahr: Eine früh fixierte Organisation zementiert einen frühen, vermutlich suboptimalen Entwurf.

Von der Anekdote zur Hypothese: das Mirroring

Conways Aufsatz ist ein Argument mit Beispielen, keine empirische Studie. Die Organisations- und Innovationsforschung hat die Idee später unter dem Namen Mirroring-Hypothese aufgegriffen: Organisatorische Verbindungen (Kommunikation, räumliche Nähe, gemeinsame Anstellung) sollen den technischen Abhängigkeiten im Produkt entsprechen. Damit wird die These prüfbar – man kann Abhängigkeiten im Code und Strukturen in Organisationen messen und vergleichen.

Beispiel 1: Fünf Produktpaare und der Faktor acht

Alan MacCormack, Carliss Baldwin und John Rusnak (Research Policy, 2012) testeten die Hypothese mit gepaarten Produkten: jeweils ein Produkt aus einer eng gekoppelten Organisation (ein kleines, fest zugeordnetes Team, meist innerhalb eines Unternehmens) und ein funktional vergleichbares Produkt aus einer lose gekoppelten Organisation (eine verteilte Open-Source-Gemeinschaft). Entscheidend war dabei die Organisationsform des Entwicklerteams, nicht die Lizenz – einige der eng gekoppelten Produkte wurden später selbst quelloffen. Die Stichprobe umfasste fünf Paare aus Finanzsoftware, Textverarbeitung, Tabellenkalkulation, Datenbank und Betriebssystemkern; da Linux sowohl mit Solaris als auch mit XNU verglichen wurde, ergeben sich sechs Vergleiche.

Gemessen wurde die Modularität über die Propagation Cost: den Anteil der Systemelemente, die im Mittel betroffen sein können, wenn man ein zufällig gewähltes Element ändert – berechnet aus den Abhängigkeiten zwischen Quelldateien.

Das Ergebnis laut Abstract: In allen untersuchten Paaren war das Produkt der lose gekoppelten Organisation signifikant modularer. Die Unterschiede waren erheblich – bis zu einem Faktor acht im Potenzial, dass sich eine Änderung in einer Komponente auf andere ausbreitet. (Die Tabelle der Arbeitspapier-Fassung weist als größtes Verhältnis der Propagation Cost etwa 6 : 1 aus – 47,14 % gegenüber 7,74 % beim Paar Finanzsoftware; die Zahlen der Zeitschriftenfassung können abweichen.)

Wichtig ist, was die Studie nicht zeigt: Sie beobachtet eine Korrelation in einer kleinen Stichprobe. Ob die Organisation die Architektur verursacht oder ob modulare Produkte eher verteilte Gemeinschaften anziehen, lässt sich aus fünf Paaren nicht sicher trennen.

Beispiel 2: 142 Studien – häufig, aber nicht universell

Lyra Colfer und Carliss Baldwin (Industrial and Corporate Change, 2016) haben die Literatur systematisch ausgewertet: 142 empirische Studien, gegliedert in Branchen-, Unternehmens- und Studien zu offenen kollaborativen Projekten.

Ihre Befunde:

Die Erklärung der Autoren für die Ausnahme: Digitale Technologien ermöglichen neue Koordinationsformen, mit denen Gruppen vom klassischen Mirroring abweichen können, wie man es aus Unternehmen kennt. Das ist eine Deutung, kein kausaler Nachweis. Ich bin der Meinung, dass Versionsverwaltung, öffentliche Issue-Tracker und für alle lesbarer Code plausible Kandidaten dafür sind, einen Teil dessen zu ersetzen, was sonst direkte Kommunikation leisten müsste.

Beachten Sie den Unterschied zu Beispiel 1: Dort bestätigt Open Source die Hypothese – lose gekoppelte Gemeinschaften bauen modularere Produkte. Die Ausnahme bei Colfer und Baldwin betrifft etwas anderes: In offenen Projekten decken sich die technischen Abhängigkeiten häufiger nicht mit den organisatorischen Verbindungen.

Zwei weitere Begriffe aus der Arbeit sind für Architekten nützlich:

• Die Mirroring-Falle: Unternehmen, die auf ihre aktuelle technische Architektur fixiert sind, können Opfer architektonischer Innovationen werden, die außerhalb ihrer Grenzen entstehen.
• Partielles Mirroring: In technologisch dynamischen Branchen sei es vermutlich überlegen, Wissensgrenzen weiter zu ziehen als operative Grenzen – also mehr zu wissen, als man selbst baut.

Beispiel 3: Organisationsstruktur als Qualitätsprädiktor bei Windows Vista

Wenn Kommunikation und Architektur zusammenhängen, sollte die Organisation auch etwas über Fehler verraten. Nachiappan Nagappan, Brendan Murphy und Victor Basili (Microsoft Research, Technischer Bericht MSR-TR-2008-11) untersuchten das an Windows Vista. Sie definierten acht organisatorische Metriken – etwa wie viele Ingenieure an einer Binärdatei arbeiteten, wie viele davon das Unternehmen verlassen hatten, wie weit die Verantwortung über die Organisationshierarchie verteilt war.

Laut Abstract waren diese Metriken statistisch signifikante Prädiktoren für die Fehleranfälligkeit von Binärdateien. Präzision und Recall bei der Identifikation fehleranfälliger Binärdateien lagen signifikant höher als mit klassischen Metriken wie Code-Churn, Komplexität, Testabdeckung, Abhängigkeiten oder Pre-Release-Fehlern. Im Bericht werden über 50 zufällige Aufteilungen in Trainings- und Testdaten eine mittlere Präzision von 87 % und ein mittlerer Recall von 84 % berichtet.

Die Grenze: Es handelt sich um ein Produkt in einem Unternehmen. Ob das Ergebnis auf andere Organisationen übertragbar ist, zeigt die Studie selbst nicht.

Beispiel 4: Der Preis der Entfernung

James Herbsleb und Audris Mockus (IEEE Transactions on Software Engineering, 2003) untersuchten bei einem großen Telekommunikationsprojekt, wie lange Änderungen dauern. Ihr zentraler Befund: Über Standorte verteilte Arbeitspakete brauchten etwa zweieinhalbmal so lange wie vergleichbare Arbeitspakete, deren Arbeit an einem Ort stattfand. Als Mechanismus legen die Daten nahe, dass verteilte Arbeit mehr Personen einbezieht und die Zahl der Beteiligten stark mit der Bearbeitungsdauer zusammenhängt. Berücksichtigt man in der Regression die Zahl der Beteiligten (sowie Umfang, Verteilung über Module und Schweregrad), ist der Standort-Effekt nicht mehr signifikant – die Verzögerung läuft also über die Zahl der Beteiligten.

Das ist die Kehrseite von Conways These: Wo Architektur Schnittstellen erzwingt, die quer zu den Kommunikationswegen liegen, zahlt man mit Koordinationszeit.

Framework: Das „Inverse Conway Manöver"

Wenn die Organisation die Architektur prägt, kann man den Hebel umdrehen. Das Technology Radar von ThoughtWorks führte 2014 die Technik „Inverse Conway Maneuver" im Ring „Trial": Man solle Team- und Organisationsstruktur so weiterentwickeln, dass sie die gewünschte Architektur fördert.

Eine praktische Übersetzung in vier Fragen:

Die Empirie mahnt allerdings zur Bescheidenheit. Colfer und Baldwin finden Mirroring häufig, aber nicht universell, und erklären die Ausnahmen in offenen Projekten mit neuen, digital ermöglichten Koordinationsformen – das Manöver ist also kein Mechanismus mit garantierter Wirkung. Ich bin der Meinung, dass es am besten als Hypothese verstanden wird, die man an Metriken (Abstimmungsaufwand, Durchlaufzeit, Kopplung im Code) überprüft.

Die Erkenntnis zum Mitnehmen

• Conways These ist eine Beobachtung über Kommunikation, nicht über Organigramme – und sie ist empirisch häufig, aber nicht ausnahmslos bestätigt.
• Architekturentscheidungen sind Organisationsentscheidungen. Wer einen Schnitt im System plant, sollte prüfen, ob die Teams, die beide Seiten bauen, entsprechend miteinander sprechen – oder eben nicht sprechen müssen.
• Verteilung kostet Zeit – über die Zahl der Beteiligten. In der Studie von Herbsleb und Mockus dauerten standortübergreifende Arbeitspakete etwa zweieinhalbmal so lange, weil mehr Personen beteiligt waren. Ich bin der Meinung, dass Schnittstellen deshalb dort liegen sollten, wo ohnehin wenig Abstimmung nötig ist.
• Werkzeuge können den Spiegel trüben. In offenen Projekten weicht die Kopplung im Code häufiger von den organisatorischen Verbindungen ab – vermutlich, weil Versionsverwaltung und öffentliche Kommunikation einen Teil der direkten Abstimmung ersetzen. Lose gekoppelte Gemeinschaften bauen zugleich eher modulare Systeme.
• Starre Organisation zementiert frühe Entwürfe. Organisatorische Beweglichkeit ist eine Architekturqualität.

Querverweise im Vault

• Das Versprechen, das keiner halten kann: Zwei-Phasen-Commit, Sagas und das Ende der verteilten Transaktion – wenn Dienstgrenzen Teamgrenzen folgen, werden Transaktionen über Teamgrenzen hinweg zum Problem.
• Das Logbuch der Wahrheit: Event Sourcing und CQRS verstehen – Ereignisse als schmale Schnittstelle zwischen Teams.
• Wie Maschinen sich einig werden: Verteilter Konsens von FLP über Paxos zu Raft – Koordination zwischen Maschinen als technisches Gegenstück zur Koordination zwischen Menschen.
• Der lange Schwanz der Latenz: Tail Latency und warum Mittelwerte in der Cloud lügen – auch Fan-out über viele Teams hat einen langen Schwanz.

Zum Nachdenken

Zeichnen Sie die Kommunikationswege Ihres Teams der letzten vier Wochen auf – nicht das Organigramm, sondern wer tatsächlich mit wem gesprochen hat. Legen Sie dieses Bild neben das Abhängigkeitsdiagramm Ihres Systems: Wo stimmen beide überein, und wo erzwingt Ihre Architektur Gespräche, die Ihre Organisation gar nicht führt?

Faktenprüfung

Automatisierte KI-Prüfung gegen Primärquellen; keine menschliche Fachprüfung.

Geprüft wurden 58 Aussagen (24 harte Fakten, 8 Zitate bzw. zugeschriebene Formulierungen, 11 Quellenzuschreibungen, 15 Synthese-Aussagen). 8 Stellen wurden korrigiert oder abgeschwächt. Die wichtigsten Korrekturen:

• Die Anteile 70 % / 22 % / 8 % bei Colfer und Baldwin beziehen sich nur auf die deskriptiven Branchen- und Unternehmensstudien, nicht auf alle deskriptiven Studien.
• Der Mechanismus bei Herbsleb und Mockus wurde präzisiert: Der Standort-Effekt verschwindet, wenn man die Zahl der Beteiligten berücksichtigt.
• Ein innerer Widerspruch wurde aufgelöst: Open Source bestätigt bei MacCormack et al. die Mirroring-Hypothese, während Colfer und Baldwin in offenen Projekten häufiger Abweichungen finden – zwei verschiedene Aussagen, die der Entwurf vermischt hatte.

Quellen und zum Weiterlesen

1. Conway, M. E. (1968): How Do Committees Invent? Datamation, April 1968. https://www.melconway.com/Home/Committees_Paper.html
2. MacCormack, A., Baldwin, C., Rusnak, J. (2012): Exploring the duality between product and organizational architectures: A test of the "mirroring" hypothesis. Research Policy 41 (8), 1309–1324. https://doi.org/10.1016/j.respol.2012.04.011 – Arbeitspapier: https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf
3. Colfer, L. J., Baldwin, C. Y. (2016): The mirroring hypothesis: theory, evidence, and exceptions. Industrial and Corporate Change 25 (5), 709–738. https://doi.org/10.1093/icc/dtw027
4. Nagappan, N., Murphy, B., Basili, V. (2008): The Influence of Organizational Structure on Software Quality: An Empirical Case Study. Microsoft Research, MSR-TR-2008-11. https://www.microsoft.com/en-us/research/publication/the-influence-of-organizational-structure-on-software-quality-an-empirical-case-study/
5. Herbsleb, J. D., Mockus, A. (2003): An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering 29 (6), 481–494. Preprint: https://mockus.org/papers/delay.pdf
6. ThoughtWorks Technology Radar: Inverse Conway Maneuver (Trial, Juli 2014). https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

← All articles