Organisationen tun sich oft schwer, wenn es um die technische Erneuerung ihrer Softwaresysteme geht. Betrachten wir Conway’s Law, so kann es sich lohnen zuerst auf die Strukturen in der Organisation zu schauen, bevor ein großer technischer Umbau angestoßen wird.

Conway’s Law und Inverse Conway Maneuver

Vor über einem halben Jahrhundert hat Melvin Conway seine Beobachtungen in Organisationen in einem kurzen Satz zusammengefasst, der seitdem als Conway’s Law bekannt ist. Sinngemäß und in meinen Worten sagt dies aus, dass Organisationen beim Design von Systemen oft ein Abbild ihrer internen Kommunikationsstruktur erschaffen. Ich selber würde es noch etwas ausdehnen und die These aufstellen, dass Systeme ein ganzheitliches Abbild der Kommunikations- UND Organisationsstruktur sind. Conway’s Law trifft damit auch alle Softwaresysteme, die von Organisationen geschaffen werden. Dies hat unter anderem zur Folge, dass diese Organisationen Software nur schwer in ihrem technischen Aufbau anpassen können, da sie immer wieder das Abbild ihrer selbst anstreben.

Seit einigen Jahren (>2010) gibt es eine Bewegung, die aus Conway’s Law ableitet, dass man für erfolgreiche Anpassungen an Strukturen einer großen Software erst die Organisation anpasst, sodass diese besser auf die gewünschten Änderungen am technischen Aufbau passt. Dieser Ansatz wird Inverse Conway Maneuver oder Reverse Conway Maneuver genannt. Ziel ist es hier, die Organisation zu enablen, um die nötigen technischen Anpassungen leichter umzusetzen.

Aktueller Ansatz im Produktbereich

Betrachten wir unsere Software, die im Wesentlichen ein Java-Monolith aus den frühen 2000ern ist, stellen wir fest, dass diese technisch angepasst werden muss. Fachlich ist sie auf der Höhe der Zeit, unter der Haube steckt jedoch architektonischer Renovierungsbedarf. Soweit nichts Ungewöhnliches für eine 20 Jahre alte Anwendung. Eines der Probleme ist der technische Monolith, der sich, wie es Conway vorhergesagt hat, aus den Formen der Organisation der letzten 20 Jahre ergeben hat.

Unser Ansatz ist es nun, in Ableitung des Inverse Conway Maneuver, das großes Softwareprodukt zuerst organisatorisch in kleinere Produkte umzubauen. Wir nennen das aktuell „produktzentrierte Sicht“ und bilden dabei Teams, die mit einem Product Owner für Produkte statt für Module im Monolithen verantwortlich sind. Dies klingt vielleicht nicht nach viel Veränderung, da in vielen Fällen ähnliche Personengruppen an der gleichen Fachlichkeit wie vorher arbeiten. In der Realität ist aber genau das zu beobachten, was Inverse Conway sagt: Es bilden sich produktspezifische Dinge wie Dokumentationen, Fehlerboards, Architekturentscheidungen und vieles mehr. All dies wird einen Beitrag dazu leisten, dass Produkte besser aus dem Monolithen herausgelöst werden können. Ganz am Ende steht der Gedanke, dass das Herauslösen eines Produkts aus dem Monolithen später einfach nur noch eine logische Entscheidung ist und sehr organisch passieren kann.

Learnings aus Conway’s Law und Inverse Conway Maneuver

Aus meiner Sicht sind die Aussagen aus Conway’s Law und Inverse Conway Maneuver sehr wichtige Leitplanken für die Organisationsentwicklung. Als Anregung und Diskussionsansatz hier meine Top 3-Learnings:

  • Technische und Produktaspekte müssen bei organisatorischen Änderungen mit einfließen
  • Bei technischen Herausforderungen immer die Frage stellen „Welche Organisationsanpassung kann mein technisches Vorhaben bestmöglich unterstützen?“
  • Reflexion zum Lernen „Welche Software / Technik wird durch meine aktuelle Organisations- und Kommunikationsstruktur erzeugt?“

Es würde mich freuen, wenn Ihr Eure Gedanken dazu mit mir teilen würdet, sei es online in einem der intersoft Events oder über LinkedIn.

Weiterführende Quellen:

Conwa’s Law. Wikipedia: https://de.wikipedia.org/wiki/Gesetz_von_Conway