Gesetz von Conway

Conway’s Law – das System als unmittelbares Ergebnis der Organisation

Melvin Edward Conway – ein US-amerikanischer Entwickler – veröffentlichte 1968 im “Datamation”, einem der bekanntesten IT Magazine der damaligen Zeit, einen Artikel über “How Do Committees Invent”¹. Eine der Thesen lautete: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” Frei ins Deutsche übersetzt: “Jede Organisation, die im weitesten Sinne ein System entwirft, wird ein Design erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.”

Frederick Phillips Brooks Jr. – ein US-amerikanischer Computer und Software-Architekt – zitierte diese These als “Conway’s Law” in seinem Buch “The Mythical Man-Month: Essays on Software Engineering”.

Die Basis für das Gesetz von Conway

Das Gesetz von Conway fußt auf einer soziologischen Beobachtung: Nur wenn die Entwickler eines Moduls A mit den Entwicklern eines Moduls B zielführend miteinander kommunizieren, können die Module A und B wie gewünscht miteinander interagieren. Oder anders ausgedrückt: Das Zusammenspiel der Schnittstellen eines Systems hängt notwendigerweise von der sozialen Struktur einer Organisation ab. Eine mangelnde zwischenmenschliche Kommunikation führt zu einer mangelhaften Lösung.

Seit 1968 gab es verschiedene Studien und Erkenntnisse, die Conway’s Law belegen. Auffällig ist dabei, dass nicht nur die Kommunikation zwischen beteiligten Entwicklern maßgeblich ist, sondern auch die Organisationsstruktur als solche. Gibt es drei Entwicklergruppen E1, E2 und E3 wird es meist auch ein System mit drei Subsystemen S1, S2 und S3 geben, bei vier Gruppen vier Subsysteme etc.

Inverse Conway Maneuver als Handlungsempfehlung

In der Praxis lassen sich verschiedene Handlungen im Umgang mit Conway’s Law beobachten:

• Es wird ignoriert, da die Beteiligten glauben, die Beobachtung von Melvin Conway würde im konkreten Fall nicht zutreffen.
• Die Auswirkungen werden beschränkt, indem die Beteiligten versuchen, eine “Kollision” von Kommunikationsmustern und Softwarearchitektur zu vermeiden.

2010 veröffentlichten Jonny LeRoy und Matt Simons eine alternative Handlungsempfehlung: das Invervse Conway Maneuver² (oder kurz: ICM oder Inverse Conway). Statt die Gesetzmäßigkeit zu unterbinden, sollten Organisationen versuchen, sie aktiv zu nutzen. Dies gelingt, indem Kommunikations- und Organisationsstrukturen so gestaltet werden, dass sie der gewünschen Softwarearchitektur entsprechen. Statt eines Frontend- und eines Backend-Teams könnte es bspw. einzelne Funktionsteams geben, die sich um konkrete Features kümmern, die sowohl Frontend als auch das Backend tangieren³.

Impulse zum Diskutieren:

Da es sich bei den Erkenntnissen im eigentlichen Sinne gar nicht um ein Gesetz oder eine starre Regel, sondern um eine Beobachtung handelt, wie gut passt die Bezeichnung “Law” bzw. “Gesetz” in der Unternehmenspraxis?

Und wie wichtig ist der Faktor, dass das Gesetz zu einer Zeit entstand, als die Außengrenzen von Software noch Drucker und Eingabeterminal hießen und nicht wie heute bspw. Microservices and Cloud-Computing?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Hier finden Sie den Original-Text von How Do Committes Invent.
[2] In der Dezember-Ausgabe der Zeitschrift Cutter IT wurde ICM erstmals als Ansatz beschrieben. (In manchen Publikationen wird der Ansatz auch als  Reverse Conway Maneuver benannt.)
[3]  Eine Anpassung der Kommunikations- und Organisationsstruktur mag einfach klingen, in der Praxis ist dies häufig nicht so leicht umzusetzen, zumal die Konsequenzen gut durchdacht werden sollten. In manchen Organisationen können bspw. die bestehenden Macht- und sozialen Dynamiken die Umsetzung von Veränderungen erschweren. Diejenigen, die in der aktuellen Organisationsstruktur Macht und Einfluss haben, könnten widerstehen, wenn ihre Positionen oder Autorität in Frage gestellt werden. Dies kann dazu führen, dass wichtige Interessengruppen die Umstrukturierung blockieren oder sabotieren, selbst wenn sie aus technischen oder organisatorischen Gründen sinnvoll ist. Zudem haben Organisationen oft “historische Verpflichtungen” und somit eine Vielzahl von Legacy in Form von Software, Systemen und Organisationsstrukturen. Hier entsprechende Veränderungen durchzuführen, ist häufig mit erheblichen Kosten und Risiken verbunden.

Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog: