Gesetz von Conway

Das Gesetz von Conway widmet sich den Zusammenhängen zwischen Kommunikationsstruktur und Software-Architektur. Es gilt also in erster Linie für die Software-Entwicklung, scheint aber auch für andere Anwendungsgebiete korrekt zu sein. 

Gesetz von Conway

Das Gesetz von Conway widmet sich den Zusammenhängen zwischen Kommunikationsstruktur und Software-Architektur. Es gilt also in erster Linie für die Software-Entwicklung, scheint aber auch für andere Anwendungsgebiete korrekt zu sein. 

Wir empfehlen zum Thema Change Management
PM Welt 2023: Mutig handeln in unsicheren Zeiten

Wie gehe ich mit den Herausforderungen fehlender Planbarkeit und Unsicherheit um? Welche Kompetenzen, Methoden und Tools sind gefordert, um sich mutig und sicher den Herausforderungen der Zukunft zu stellen? Diese und weitere spannende Themen erleben Sie am 4. Mai 2023 in München bei der PM Welt, unserer Projektmanagement-Konferenz. Seien Sie dabei! Mehr Infos

Was ist das Gesetz von Conway?

Im April 1968 veröffentlichte der US-amerikanische Informatiker Melvin Edward Conway im Computer-Magazin "Datamation" seine Erkenntnisse zu den Zusammenhängen zwischen Kommunikationsstruktur und Software-Architektur. Der zentrale Satz seines Artikels wurde bekannt als "das Gesetz von Conway" (englisch "Conway's Law"):

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

"Jede Organisation, die ein System (allgemein definiert) entwickelt, wird etwas designen, dessen Struktur eine Kopie ihrer eigenen Kommunikationsstruktur ist." (eigene Übersetzung)

Mit diesem Gesetz beschrieb Conway die Notwendigkeit, dass Organisationsstrukturen und Software-Architektur im Zusammenhang betrachtet werden müssen und nicht beliebig unabhängig voneinander gestaltet werden können. Er hatte beobachtet, dass Software die Strukturen widerspiegelt, in denen sie entwickelt wird. Demnach entwickelt eine Firma mit einer chaotischen Kommunikationsstruktur Software, deren Strukturen ebenfalls chaotisch sind.

Conway's law: Modernisieren Sie Software und Organisation gemeinsam!

Schlägt sich auch Ihre IT mit störanfälligen Altsystemen herum? Der Aufwand für eine neue Software-Architektur ist enorm, doch wie Peter Rubarths Bericht zeigt, kann ein solcher Change gelingen – wenn man die Conway Rückkopplung beachtet.

Weiterlesen
CONWAY IN DER ANWENDUNG

Nutzen für die Transformation

Das Gesetz von Conway hat in unterschiedlicher Form Eingang in die Praxis gefunden. Insbesondere im Kontext der agilen Software-Entwicklung wurde die Idee kleiner und unabhängiger Teams populär, welche Verantwortung für alle Aspekte eines Bereichs übernehmen und voneinander unabhängige Codebasen betreiben: Schlanke und klare Strukturen, die Abhängigkeiten zu anderen Teams und Bereichen so gut es geht vermeiden, sollen zu einem ebensolchen Code führen.

Ein Beispiel für solche Strukturen ist das Unternehmen Europace, das einen virtuellen Marktplatz für Immobilienfinanzierungen betreibt. Im Zuge eines Changes gelang es dem Unternehmen – unter Berücksichtigung des Gesetzes von Conway und darauf aufbauender Überlegungen –, seine IT-Altsysteme zu modernisieren und dabei gleichzeitig die Teamstruktur zu verbessern (siehe "Conway's law: Modernisieren Sie Software und Organisation gemeinsam!"), indem es die Kernkomponenten ihrer Software einzelnen Mission Teams zuwies (Bild 1).

Software-Komponenten und Teamaufteilung vor dem Change
Bild 1: Der neue Zuschnitt der Entwicklungs-Teams bei Europace ohne gegenseitige Abhängigkeiten

Umgekehrtes Conway Manöver

In den vergangenen Jahren wurde unter dem Namen "umgekehrtes Conway Manöver" (auf English "Reverse" oder "Inverse Conway Manoeuver") die Idee populär, den von Conway beschriebenen Zusammenhang von Organisationsstruktur und Software-Architektur zu nutzen, um über eine gezielte Gestaltung von Teams Einfluss auf die entstehende Software-Architektur zu nehmen.

Vorschaubild

Digitalprojekte – seit Jahren auf dem Vormarsch und durch Corona für viele Unternehmen aktuell überlebensnotwendig. Doch was tun, wenn das Projekt in einer ernsthaften Krise steckt? Jens M. Woehe gibt Tipps zur Rettung von Digitalprojekten.

Weiterlesen
MEHR ZUM THEMA

Dazu wird die Struktur der Teams so designt, dass die von diesen geschaffene Software-Architektur der technologischen Strategie entspricht. Die Struktur der Software soll also beispielsweise zu technisch und fachlich sauber voneinander abgegrenzten Komponenten führen, um eine reibungslose Weiterentwicklung langfristig zu unterstützen.

Bei einer geplanten Transformation einer Organisation sollten die Teamstruktur und die Software-Architektur gemeinsam betrachtet und die Wechselwirkungen bei der Planung des Change berücksichtigt werden. So kann die Transformation durch eine neue Struktur einen Impuls auf die Struktur der Software auszuüben. Die Tabelle 1 zeigt drei Optionen für eine parallele Transformation von Organisationsstruktur und Veränderung der Software.

Conway Rückkopplung

Bei der Conway Rückkopplung handelt es sich um eine Beschreibung des agile Coaches und Autors Peter Rubarth: Seiner Beobachtung nach kann es passieren, dass formal unabhängige Teams aneinander "gekettet" werden, weil sie Kernkomponenten der Software gemeinsam verwenden. Demnach hat der Ist-Zustand der Software einen Rückkopplungseffekt auf die tatsächlichen Kommunikationsstrukturen der Teams: Je abhängiger die Komponenten voneinander sind, desto mehr Abstimmung ist unter den Teams erforderlich.

Die Conway Rückkopplung bezeichnet damit die Notwendigkeiten, welche eine existierende Software-Architektur Teams bei der Zusammenarbeit untereinander aufzwingt. Ohne gezielte Gegenmaßnahmen hat diese Rückkopplung das Potenzial, die erhoffte positive Wirkung des organisatorischen Change nicht nur zu negieren, sondern die Gesamtsituation in Bezug auf Produktivität und Reaktionsgeschwindigkeit sogar zu verschlechtern.

Tabelle 1: Handlungsoptionen für eine Transformation unter gleichzeitiger Berücksichtigung von Organisations- und Softwarestruktur
Option Beschreibung Vorteile Nachteile
Erst Organisation, dann Software Change der Struktur und Veränderung der Software
aus der neuen Organisation Struktur heraus
  • Neue Struktur wirkt in Richtung der gewollten Software-Architektur
  • Neue Struktur kann weitere angestrebte Effekte entfalten
  • Conway Rückkopplung durch die bisherige Software-Architektur
  • Effekt behindert Entfaltung des angestrebten Nutzens des Change
Erst Software, dann Organisation  Veränderung der Software und Change der Organisation,
wenn Softwarestruktur Zielbild erfüllt
  • Vermeidung der Conway Rückkopplung
  • Organisatorische Veränderung einfacher durch dann schon passende Software-Architektur (falls erfolgreich)
  • Umsetzung des organisatorischen Change später und abhängig vom Erfolg der Anpassung der Software
  • Wirkung des Gesetzes von Conway in ursprünglicher Form behindert erfolgreiche Umsetzung
Software in einer separaten Struktur,
dann Übergabe und Anpassung
der Organisation 
Veränderung (oder Neuentwicklung) der Software einer (temporären) Organisation; Change der Organisation und Übergabe, wenn Software bereit
  • Betrieb der bisherigen Software vgl. ungestört
  • Fokus auf neue Software in der temporären Struktur
  • Design der temporären Struktur passend zum Gesetz von Conway möglich
  • Parallelstruktur ist teuer
  • Übergabe der Software kann schwierig werden
  • Löst das Problem nicht, dass alte Software und neue Organisationsstruktur nicht passen

Bewertungen

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
Gesamt
Bewertungen 1
Kommentare 0