Eine bekannte These von Melwin Conway, die als Conways Law bekannt geworden ist, rückt in letzter Zeit immer wieder im Rahmen von Diskussionen rund um agile Softwarearchitekturen in den Fokus.
Der grundlegende Aufhänger ist dabei immer wieder die Skalierung von Organisationsstrukturen (vornehmlich Entwicklungsteams) in der Größenordnung von Amazon, Google, Netflix, Spotify und Co. Vielfach wird dabei darüber philosophiert wie Softwarearchitekturstile agile Vorgehensweisen in solchen Größenordnungen unterstützen können.
Was Conways Law nicht erlaubt!
Was dabei gerne vergessen wird, ist, dass Conways Law in seiner ursprünglichen Form eine Unmöglichkeitsaussage ist und auch als solche verstanden werden muss.
Sofern man Conways Law für gesetzmäßig hält, bedeutet dies konkret, dass die Architektur eines Systems immer die Organisations- bzw. Kommunikationsstrukturen eines Unternehmens widerspiegelt. Es ist nicht möglich – egal wie hart man sich bemüht – ein „besseres“ Ergebnis als diese Struktur zu erzielen.
Dies soll jedoch nicht bedeuten, dass es sich dabei um eine gute Sache in dem Sinne handelt, dass eine solche Architektur grundlegend erstrebenswert ist. Im Gegenteil: den Architekten und Teams werden durch diese Strukturen auch immer wesentliche Freiheitsgrade im Entwurf und Design der Software genommen.
Was Architekten (nicht) tun sollten!
In agilen Softwareprojekten besteht somit eine Aufgabe der Architekten auch immer darin, Architekturen mit Blick auf die Organisations- und Kommunikationsstruktur des Unternehmens zu entwickeln. Letztlich bedeutet dies, dass sich die Umsetzung gewisser Softwarestrukturen nur durch Veränderungen in der Organisations- und Kommunikationsstruktur bewerkstelligen lassen. Die Aufgabe besteht daher vor allem darin, Agilität auf organisatorischer und unternehmerischer Ebene zu verstehen und zu unterstützen.
Architekten sollten daher Conways Law nicht als Rechtfertigung für Designentscheidungen nutzen. Es ist immer nur eine Vorbedingung, die sich durch organisatorische Veränderungen beeinflussen lässt. Letztlich muss die Architektur immer den fachlichen Anforderungen genügen und auf die unternehmerischen Ziele einzahlen. Dabei sollten Organisationsstrukturen unterstützen und stellen nicht in sich selbst das Ziel dar. Daher sollte Conways Law auch immer Berücksichtigung im Kontext organisatorischer Entscheidungen finden. Andernfalls erhält man nicht die notwendigen Architekturen, sondern nur die Architektur, die man aufgrund der Organisationsstruktur erhalten kann.
Fazit
Sofern man gewillt ist Conways Law als gesetzmäßig hinzunehmen, sollte man nicht versuchen es außer Kraft zu setzen, sondern es stattdessen für sich zu nutzen. Dabei besteht der größte Nutzen vor allem darin, keine Zeit und Geld zu verbrennen, indem man versucht technische Architekturen zu erschaffen oder durchzusetzen, die nicht im Einklang mit der Organisations- oder Kommunikationsstruktur im Unternehmen stehen. Diese Investitionen sollten stattdessen besser für notwendige Veränderung der Unternehmensstrukturen aufgewendet werden – die Softwarestrukturen werden sich gemäß Conways Law letztendlich automatisch mit verändern.
