Gesetz von Conway

Das Gesetz von Conway ist eine nach dem US-amerikanischen Informatiker Melvin Edward Conway benannte Beobachtung, dass die Arbeitsergebnisse von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind. Es wurde von Conway 1968 folgendermaßen formuliert:

“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

– Melvin E. Conway^[1]

Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen.

Studien

Eine Studie der Harvard Business School kam zu dem Schluss, dass es starke Hinweise für die Korrektheit des Gesetzes von Conway gibt. Bei allen von ihnen untersuchten 12 Produkten aus 5 unterschiedlichen Anwendungsgebieten (Finanzmanagement, Textverarbeitung, Tabellenkalkulation, Betriebssystem, Datenbanksystem) korrelierte die Kopplung der sie entwickelnden Organisationen mit der Modularität der Produkte.^[2]

Weitere Studien konnten ebenso eine Relation zwischen der Architektur eines Produktes und den Charakteristiken der es umsetzenden Organisation belegen:

• Eine Microsoft-Research-Studie errechnete aus der Komplexität der mit der Entwicklung von Microsoft Windows Vista betrauten Organisationseinheiten von Microsoft die Komplexität und Fehlerquote von Windows Vista.^[3]
• Rebecca M. Henderson und Kim B. Clark konnten belegen, dass Produktinnovationen, welche die Architektur des Produktes ändern, eine Änderung der Wissensarchitektur und Firmenstruktur benötigen.^[4]
• James D. Herbsleb und Rebecca E. Grinter kamen zu dem Schluss, dass die Arbeit an einem modularisierten System derart verteilt werden sollte, dass die Trennung der Entwicklung der Aufteilung der Module entspricht. Umgekehrt sollte die Entwicklung nur dann aufgeteilt werden, wenn die zu entwickelnden Produkte (oder Produktteile) gut verstanden werden, Pläne, Prozesse und Schnittstellen etabliert und stabil sind.^[5]

Beispiele

Angenommen, ein Unternehmen wird mit der Umsetzung eines großen Softwaresystems beauftragt. Das beauftragte Unternehmen hat drei Entwicklergruppen, E1, E2 und E3, die in dem Projekt zusammenarbeiten. Das Gesetz von Conway besagt nun, dass das entwickelte Softwaresystem wahrscheinlich aus drei großen Subsystemen S1, S2 und S3 bestehen wird, die in einer jeweils anderen Entwicklergruppe umgesetzt werden. Wichtiger noch, die Qualität und Art der Schnittstellen zwischen den Subsystemen (S1–S2, S1–S3, S2–S3) werden der Qualität und Art der zwischenmenschlichen Kommunikation zwischen den entsprechenden Entwicklergruppen (E1–E2, E1–E3, E2–E3) entsprechen.

Dasselbe gilt auch im kleineren Rahmen: Angenommen, der Softwareentwickler E1 hat die Klasse K1 für die Funktionalität F1 umgesetzt. Später soll die Funktionalität F1 um eine ähnliche Funktionalität F2 erweitert werden. Setzt der Softwareentwickler E1 diese Funktionalität um, so wird er einfach die Klasse K1 um diese Funktionalität erweitern. Setzt ein Softwareentwickler E2 aus einer anderen Gruppe diese Funktionalität um, so wird er wahrscheinlich befürchten, die bestehende Funktionalität zu beeinträchtigen, und daher die Funktionalität F2 in einer (Sub-)Klasse K2 umsetzen. Das Design der Applikation ist daher hochgradig davon abhängig, wer die Funktionalität umsetzt.

Beispiel für Systemversagen

Ein Beispiel für das Scheitern eines Systems, das durch das Gesetz von Conway beschrieben werden kann, ist der Absturz des Mars Climate Orbiters. Er wurde dadurch verursacht, dass das Entwicklungsteam von Lockheed Martin in der Navigationssoftware das angloamerikanische Maßsystem, das NASA-Entwicklungsteam hingegen das internationale Einheitensystem für die Berechnungen der Steuerung der Sonde zur Erreichung der vorgesehenen Umlaufbahn um den Mars verwendete.^[6][7] Von NASA-Seite wurde der Absturz allerdings weniger dem Fehler selbst, als dem Versagen der Kontrollmechanismen zugeschrieben.^[8]

Ähnliche Erkenntnisse

Frederick P. Brooks bietet in seinem Buch The Mythical Man Month im Kapitel „Why did the (mythical) Tower of Babel Fail?“ die Analogie, dass trotz klarer Zielvorstellung, genügend Personal, Rohstoffen und Zeit, sowie ausgereifter Technologie, Projekte an Kommunikationsproblemen und den daraus resultierenden Organisationsveränderungen scheitern können. Brooks stellt weiter fest, dass sich bei mangelnder Kommunikation zwischen Teams in der Softwareentwicklung funktionelle oder terminliche Misserfolge ergeben.^[9]

James O. Coplien und Neil B. Harrison vertreten in ihrem Buch Organizational Patterns of Agile Software Development die Ansicht, dass ein Projekt problematisch umzusetzen sei, wenn die Aufteilung der es umsetzenden Organisation (z. B. in Teams, Abteilungen oder Unterabteilungen) nicht den wichtigsten Teilen des umzusetzenden Produktes, und die Beziehungen zwischen den Organisationsteilen nicht den Beziehungen zwischen den Produktteilen entsprächen. Darum sei es wichtig, die Organisation kompatibel mit der Produktarchitektur zu machen.^[10]

Grüne-Wiese-Ansatz

Um für das umzusetzende Produkt geeignete Kommunikationsstrukturen zu bekommen, und dadurch gemäß dem Gesetz von Conway geeignete Produktmodule zu bekommen, schlägt Melvin Conway folgenden „Grüne-Wiese-Ansatz“ (englisch clean slate approach) vor:^[11]

1. Definiere das Unternehmensleitbild.
2. Ermittle die Geschäftsprozesse.
3. Adaptiere die Geschäftsprozesse, damit sie zum Unternehmensleitbild passen.
4. Strukturiere die IT-Organisation so, dass sie die angepassten Geschäftsprozesse unterstützt.

Zitate

Eric S. Raymond, einer der Gründer der Open Source Initiative, schreibt im New Hacker’s Dictionary, der gedruckten Version des Jargon Files, dass bei der Entwicklung eines Compilers durch vier Gruppen ein 4-pass-Compiler herauskommen wird.^[12]