Conway‘s Law – Organisation & Systeme perfekt aufeinander abstimmen

Management Summary

• Laut Conway’s Law haben die Kommunikationsstrukturen einer Organisation einen erheblichen Einfluss auf die von der Organisation entwickelten und genutzten Systeme.
• Eigentlich ist das Law of Conway eine Beobachtung, die zunächst von Melvin Edward Conway 1968 in einem IT-Magazin publiziert, später wiederkehrend bestätigt und schließlich zum Gesetz erhoben wurde.
• Nach dem Gesetz von Conway sollte bei der Analyse eines Bestandssystems auch die umgebende Organisation berücksichtigt werden.
• Zudem legt Conways Gesetz nahe bei einer Systemneuentwicklung gleichsam die Organisationsstruktur zu gestalten in denen das System entsteht.
• Das ‚Inverse Conway Maneuvre‘ ist diese gezielte Anlage von Organisationsstrukturen zwecks Optimierung des Systementwurfs & -betriebs. Aufgrund der Unternehmenskultur, informeller Kommunikation sowie zwischenmenschlicher Bindungen ist der Erfolg dieses Umkehrmanövers nicht garantiert.

Was besagt das Gesetz von Conway?

Frei ins Deutsche übersetzt besagt Conway’s Law:

„Jede Organisation die ein System entwirft, wird zwangsweise einen Entwurf erstellen,
der eine Kopie ihrer Kommunikationsstruktur ist.“

Demnach haben die existierenden Kommunikationsstrukturen in einer Organisation einen erheblichen Einfluss auf die von der Organisation hervorgebrachten und eingesetzten Systeme. Ganz gleich ob mit guten oder schlechten Design – ein System ist immer die Reproduktion der Interaktionsbeziehungen seiner erschaffenden Akteure.

Der Begriff ‚System‘ bezieht sich dabei nicht nur auf die von einer Organisation genutzten IT-Systeme. Auch Produkte und Dienstleistungen sind Systeme, welche unter das Gesetz von Conway fallen. Beachten Sie zudem, dass Conway’s Law nichts über die Qualität und Strukturen eines Systems aussagt, sondern nur über die Zwangsläufigkeit ihres Entstehens. Last but not least unterscheidet das Gesetz nicht zwischen formalen und informalen Kommunikationsstrukturen.

Wer ist dieser Conway und von wann stammt das Gesetz?

Urvater des Gesetzes von Conway ist Melvin Edward Conway, ein Informatiker und Computerwissenschaftler aus den USA. 1968 reichte Conway den Artikel ‚How Do Committees Invent?‘ erfolgreich beim damals führenden IT Magazin Datamation ein. Im heute noch einsehbaren Beitrag schildert Conway seine empirischen Observationen bestehender Systeme, verwendete dabei jedoch nicht den Begriff Gesetz.

Frederick P. Brooks, ebenfalls Informatikwissenschaftler, griff Conways Schilderungen in seinem Bestseller ‚Vom Mythos des Mann-Monats: Essays über Software-Engineering‘ auf, kreierte den Begriff Conway’s Law und machte damit Conway und seine Observation weltweit populär.

Heute – über 50 Jahre nach Prägung des Gesetztes – hat es Mel Conway laut Angaben auf seiner Webseite immer noch nicht ganz überwunden, dass der Harvard Business Review seinen Artikel 1967 aufgrund fehlender Beweise ablehnte. Dies tut der Popularität seiner Beobachtung keinen Abbruch. Gerade mit der (Weiter-)Entwicklung von immer mehr IT-Systemen im Zuge der Digitalisierung erlebt Conway’s Law ein Revival.

Wie sicher ist Conways Gesetz?

Seit 1968 wurden mehrere Studien zum Law of Conway unabhängig voneinander durchgeführt. Alle belegen Melvin Conways Beobachtung und untermauern damit die Abhängigkeit zwischen Systementwurf und der umgebenden Organisationsstruktur. Eine Auswahl von Beispielen für den Umstand, dass Conway’s Gesetz nicht nicht erfüllt werden kann:

• In einer Studie belegte die Harvard Business School für 12 Produkte aus 5 Domänen die Kopplung zwischen den Entwicklungsorganisationen und der Produktmodularität.
• Microsoft errechnete in einer hauseigenen Untersuchung aus der Komplexität der Windows Vista Entwicklungseinheiten die Komplexität und Fehlerquote des Betriebssystems.
• Rebecca M. Henderson und Kim B. Clark belegten in einer Studie, dass Architektur-ändernde Produktinnovationen, die Änderung von Wissens- & Firmenstruktur erfordert.

Auffällig an den Untersuchungen ist, dass nicht nur die Kommunikation zwischen den beteiligten Systementwicklern, sondern auch die übergreifenden Organisationsstrukturen einschließlich Fachbereiche, Partnerfirmen, Rechtsabteilung etc. maßgebend für die Systementwürfe sind.

„Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.“

– Melvin Edward Conway, US-Amerikanischer Informatikwissenschaftler

Was bedeutet Conway’s Law in der Praxis?

Betrachten wir das Gesetz von Conway anhand von zwei Beispielen.

Angenommen Sie werden beauftragt ein großes neues Softwaresystem zu entwickeln. Unter Ihrer Führung arbeiten drei Entwicklerteams. Das Gesetz von Conway besagt, dass…

• das resultierende System wahrscheinlich aus drei Subsystemen besteht, welche jeweils von einem Entwicklerteam umgesetzt wurden, sowie
• die Umsetzung und Qualität der Subsystem-Schnittstellen die zwischenmenschliche Kommunikation der Entwicklerteams widerspiegelt.

Gehen wir nun davon aus, Sie sind Softwareentwickler und haben eine Funktionalität in einem Systemmodul realisiert. Einige Zeit später soll das existierende System durch eine fachlich ähnliche Funktion ergänzt werden.

• Setzen Sie die neue Funktion um, so ist es wahrscheinlich, dass Sie das bestehende Systemmodul einfach funktionell ergänzen.
• Setzt Ihr Entwicklerkollege die neue Funktion ohne ein vorangehendes Briefing durch Sie um, so ist es wahrscheinlich, dass er ein zusätzliches Systemmodul programmiert, da er befürchtet, die bestehende Funktionalität zu beeinträchtigen.

Der Systementwurf ist damit hochgradig davon abhängig, welche Person die Funktion mit welchem Vorwissen umsetzt.

Weitere Fälle für Conways Gesetz finden Sie im lesenswerten Beitrag Praxis-Check Software-Architektur: Conway’s Law auf der Spur.

Sarah Novotny: Don’t Forget Conway’s Law (8 min)

Wie lässt sich Conway‘s Law nutzen?

Verstehen Sie Conway’s Law als einen Appell. Konzentrieren Sie sich bei der Analyse und Entwicklung nicht nur auf Systeme und ihre Technologie, sondern auf die umgebenden Menschen inklusive ihrer Aufbau- und Ablauforganisationen. Betrachten Sie das gesamte Soziotechnische System.

Überlegen Sie zudem, ob sich das neu zu erstellende System immer zwingend an die (starre) Organisationsstruktur, sondern die (agile) Organisationsstruktur besser an das gewünschte System anpassen sollte. So setzen beispielsweise Amazon und Netflix auf viele kleine autonome Teams, die jeweils für einen Teil des Systems die Gesamtverantwortung tragen.

Conway selbst schlägt 2012 in der Publikation Conway’s Law Revisited. Successfully Aligning Enterprise Architecture einen „Grüne-Wiese-Ansatz“ (Clean Slate Approach) für die Anwendung seiner Beobachtung vor.

Neugründung: Clean Slate Approach

1. Definieren Sie das Unternehmensleitbild.
2. Ermitteln Sie die Geschäftsprozesse.
3. Adaptieren Sie die Geschäftsprozesse, damit sie zum Unternehmensleitbild passen.
4. Strukturiere Sie die IT-Organisation so, dass sie die angepassten Geschäftsprozesse unterstützt.

Wir stellen diesem Ansatz ein Vorgehen für bestehende Organisationen zur Seite.

Bestandsorganisation: Brownfield Approach

1. Ermitteln Sie die Struktur der IT-Organisation, die Geschäftsprozesse und das Unternehmensleitbild.
2. Prüfen und aktualisieren Sie das Unternehmensleitbild
3. Adaptieren Sie die Geschäftsprozesse, damit sie zum Unternehmensleitbild passen.
4. Re-Strukturiere Sie die IT-Organisation so, dass sie die angepassten Geschäftsprozesse unterstützt.

Fazit

Aus Beobachtungen können über die Jahre Gesetze werden, zumindest beweist dies Conway’s Law. Uns dienen seine Beobachtung als Aufruf in IT-Projekten immer das gesamte Soziotechnische System in Betracht zu ziehen.

Ob nun Organisationsgesetz oder regelmäßig wiederkehrendes Strukturmuster – des Pudels Kern hat Melvin Conway mit seiner These laut einhelligem Echo getroffen und sich ganz nebenbei für Wissenschaftler, Manager und Systementwickler unsterblich gemacht.

Leseempfehlungen

• Beine, G.: Soziotechnische Welten – Conway hat immer recht, ITSpektrum 04/2022
• Bevan, N.: Usability Issues in Web Site Design, Serco Group, 1999 (letzter Abruf: 10.12.2024)
• Brooks, P. F.: Vom Mythos des Mann-Monats: Essays über Software-Engineering
• Vom Mythos des Mann-Monats: Essays über Software-Engineering, MITP, 2008
• Conway, M. E.: Mel Conway’s Homepage (letzter Abruf: 10.12.2024)
• Conway, M. E.: How do Committees Invent?, Datamation. 14 (5): 28–31, 1968 (letzter Abruf: 10.12.2024)
• Schlosser, H.: Praxis-Check Software-Architektur: Conway’s Law auf der Spur, jaxenter 08/2017 (letzter Abruf: 10.12.2024)
• Soffner, T., Cremer, B.: Inverse-Conway-Maneuver: How to speed up product development teams successfully (letzter Abruf:10.12.2024)

Ob Optimierung oder Neuentwicklung – wir helfen Ihnen beim Verzahnen von Business und IT.
Kontaktieren Sie uns!

Bitte akzeptieren Sie unsere Datenschutzerklärung.