Conway's Law, inversed

Bild: Unsplash / Paymo - Lizenz

Noch einmal zum Thema Conway's Law, jener von Melvin Conway definierten Gesetzmässigkeit, derzufolge Organisationen dazu tendieren, in ihrer IT-Systemlandschaft ihre Kommunikations- (oder Organisations-)struktur abzubilden. Da das problematisch (weil aus Softwarearchitektur-Sicht dysfunktional) ist, gibt es immer wieder Versuche, dieser Entwicklung gegenzusteuern. Der bekannteste derartige Ansatz trägt den Namen "Inverse Conway Maneuver", oder "Inverse Conway".

Erstmals formuliert 2010 von Jonhy Leroy und Matt Simons beruht Inverse Conway auf der Erkenntnis, dass Conway's Law in der Realität kaum zu vermeiden ist. Statt sich beim Versuch es zu verhindern aufzureiben wird stattdessen versucht es zu nutzen. Indem die Kommunikations- und Organisations-Strukturen bewusst so gestaltet werden, dass diese der gewünschten Software-Architektur entsprechen, wird diese herbeigeführt, bzw. gibt es keine Tendenz mehr, von ihr abzuweichen.

An einem Beispiel erklärt: würde ein Web-Shop von einem grossen Frontend-Team und einem grossen Backend-Team gebaut werden, wären laut Conways Law schwer weiterentwickelbare Frontend- und Backend-Monolithen die Folge. Kleine Teams, die in fachlichen Bereichen (Produkt-Suche, Produkt-Auswahl, Produkt-Bezahlung, etc.) jeweils Frontend und Backend verantworten, würden dagegen zu einer Struktur eigenständiger und vergleichsweise einfach weiterzuentwickelnder Module führen.

Aus Sicht einer agilen Produktentwicklung wäre eine derartige Konstellation grundsätzlich erstrebenswert, da sie die Aufwände für Planung, Abstimmung, Integration und Qualitätssicherung deutlich reduziert, wodurch für die eigentliche Weiterentwicklung mehr Kapazität zur Verfügung steht, die dazu auch noch früher, bzw. schneller genutzt werden kann. Das Ziel einer Liefer- und Reaktionsfähigkeit in kurzen Zyklen wäre damit einfacher erreichbar.

Wie alle scheinbar einfachen Lösungen ist aber auch das Inverse Conway Maneuver mit Vorsicht zu betrachten. In vielen Fällen kann das Ausmass technischer Komplexität in einem fachlich geschnittenen Modul so hoch sein, dass es für sein Team nur noch schwer zu beherrschen ist. Gleichzeitig würde eine dogmatische Befolgung von Inverse Conway die Nutzung der Effizienz- und Konsistenz-Vorteile verhindern, die durch Querschnitssysteme (z.B. gemeinsame Benutzerverwaltung) möglich werden.

Wie immer gilt also: es kommt darauf an. Das Inverse Conway Maneuver kann grossen Mehrwert stiften, wenn es mit Sinn und Verstand an der richtigen Stelle durchgeführt wird. Undifferenziert auf alles ausgerollt kann es zu Problemen führen, die schlimmstenfalls so schwerwiegend sind, dass sie die Vorteile wieder aufwiegen. Eine gute Idee wäre daher zu Beginn eine Umsetzung und Erprobung in nur einem Teil der Organisation, um so zu lernen, ob es auch in den anderen Teilen Sinn macht.

Ganz nebenbei: Mel Conway mag den Begriff Inverse Conway nicht. Das ändert zwar nichts am Konzept, es führt aber dazu, dass man sich bei seiner Einführung nicht zu offensiv auf ihn berufen sollte.

Should we call flying an "inverse gravity manoeuver"? https://t.co/mErFO5gK3d

— Mel Conway (@conways_law) April 7, 2021