Conway‘s Law – Organisation und 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 Bestandssystem auch die umgebende Organisation berücksichtigt werden.
  • Zudem legt Conways Gesetz nahe bei einer Systemneuentwicklung gleichsam die Organisationsstruktur zu optimieren in denen das System entsteht.

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.

Der Begriff ‚System‘ bezieht sich dabei nicht nur auf die von einer Organisation genutzten IT-Systeme. Betrachten Sie ebenfalls die Produkte und Dienstleistungen als Systeme, welche ebenfalls unter das Gesetz von Conway fallen.

Conway's Law

Grundidee von Conway’s Law

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 Beobachtungen, 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.

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:

  • 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 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?

Werden wir nun konkret und betrachten das Gesetz von Conway anhand von zwei Beispielen.

Angenommen Sie werden beauftragt ein großes 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.

Nehmen wir nun an Sie sind Softwareentwickler und haben eine Funktionalität in einem Systemmodul realisiert. Einige Zeit später soll das System um 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, wer 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.

Ü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. 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.

Das könnte Sie auch interessieren

Leseempfehlungen

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

Dr. Christopher Schulz

Dr. Christopher Schulz

Business Analyst, Enterprise Architect & Projektmanager

c.schulz@palladio-consulting.de
+49 (0)176 / 493 478 89

Bitte akzeptieren Sie unsere Datenschutzerklärung.

2 + 14 =