Conways Einbahnstraße
Im Jahr 1968 formulierte der US-amerikanische Informatiker Melvin Edward Conway eine wichtige Beobachtung im Softwarearchitektur-Management, die wir heute als Conway’s Law kennen:
“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”
Sehr frei übersetzt drückte er damit aus, dass eine Softwarearchitektur, die in einer Organisation entsteht, immer deren Struktur reproduziert.
Eine verbreitete Interpretation dieser Aussage besagt, dass sich eine Softwarearchitektur deshalb quasi ständig an die Organisationsstruktur anpasse. Weil jede Softwarearchitektur sich ständig fortentwickelt, entsteht sie sozusagen fortlaufend neu und würde damit die jeweils aktuelle Organisationsstruktur reproduzieren. Wenn dies so funktioniert, ließe sich eine Softwarearchitektur sogar bewusst beeinflussen.
Schauen wir uns das Ganze an zwei Beispielen aus der Praxis an:
Beispiel: Modularisierung eines Monolithen
Während meiner Zeit bei idealo vor einigen Jahren gab es genau so einen Fall: Das damalige Frontend war ein großer Monolith, der einerseits historisch gewachsen war (wie man so schön sagt) und andererseits tatsächlich von einer immer größer gewordenen Frontend-Abteilung entwickelt wurde und insofern die Organisationsstruktur tatsächlich reproduzierte. Dadurch wurde es immer schwieriger, an mehreren Teilen des Frontends zu entwickeln ohne sich dabei in die Quere zu kommen. Eine zeitlang war es so, dass alle Teile des Frontends, sogar die mobile Webseite, der Mailversand und das Backend der Mobile Apps nur gemeinsam deployt werden konnten.
Es war schnell klar, dass der Monolith in kleinere Module und später Services aufgebrochen werden sollte. Dazu organisierte idealo auch die ehemals große Frontend-Abteilung um und teilte sie in Teams, die jeweils für einen klaren Teilbereich verantwortlich waren. Damit verbunden war die Erwartung, dass sich der Monolith quasi von allein modularisieren würde. Immerhin war es für die neuen Teams wichtig, unabhängig entwickeln zu können, um zielgerichtet an ihren Zielen zu arbeiten. Die richtige Intention und Motivation war vorhanden und eine sinnvolle organisatorische Struktur ebenfalls. Es hätte also so einfach funktionieren sollen …
Es zeichnete sich jedoch bald ab, dass es nicht so einfach funktionieren würde. Der entscheidende Punkt war: Es ist entschieden aufwändiger eine bestehende Architektur zu verändern, als eine neue zu erschaffen. Auch nach Monaten waren die Teams nicht in der Lage, so unabhängig zu arbeiten, wie sich das alle Beteiligten wünschten. Um zu einer Architektur zu kommen, die eine unabhängige und schnelle Entwicklung ermöglichte, mussten die Ziele der Teams umpriorisiert und signifikante Aufwände für Architekturarbeit vorgesehen werden.
Letztendlich existiert der Monolith so nicht mehr und die Entwicklungsgeschwindigkeit ist erheblich gestiegen. Wir haben aus diesem Fall gelernt, dass das Aufbrechen von Softwarearchitekturen trotz Conway’s Law sehr aufwändig für eine Organisation sein kann.
Beispiel: Konsolidierung einer verteilten Servicearchitektur
Ein ganz gegensätzliches Beispiel erlebe ich in meiner derzeitigen Position bei Zalando. Als ich dort die Verantwortung für die Product Offer Platform übernahm, bestand diese aus einer bestimmten Menge von Services. Bald kam ein weiterer existierender Service dazu, der vorher von einem anderen Team verantwortet wurde. Er bildete entlang unserer Processing Pipeline einen Folgeschritt ab und so war es inhaltlich stimmig, ihn zu übernehmen. Etwas später kam noch ein weiterer Service von dem nächsten Downstream-System dazu, was inhaltlich ebenfalls sinnvoll war.
Die Softwarearchitektur bei Zalando basiert auf Microservices. Ein Prinzip für das Design von Microservices ist “Shared Nothing” bzw. genauer das Prinzip der Datenlokalität. Das bedeutet, dass jeder Service die Daten, die er verwendet, selbst lokal vorhalten sollte. Dies war bei unseren Services der Fall – auch bei den neu hinzugekommenen.
Was aus akademisch-architektonischer Sicht erstrebenswert scheint, hat in der Praxis einige handfeste Nachteile. Die Product Offer Platform ist zu einem großen Teil ein stream-basiertes System, das sehr große Datenmengen verarbeitet – sowohl vom Umfang her als auch von der Aktualisierungshäufigkeit. Wenn diese Daten von jedem Service selbst persistiert werden, so ist dies ein erheblicher Kostenfaktor, da wir nicht eine, sondern im konkreten Fall vier Datenbanken mit signifikanter Größe betreiben müssen (nebenbei erhöht das Persistieren in jedem Verarbeitungsschritt auch die Gesamtlatenz). Ein weiterer negativer Nebeneffekt der vielen Services bestand darin, dass die Business-Logik über die gesamte Pipeline verteilt und deshalb etwas schwieriger anzupassen war.
Ausgehend von diesen Effizienzüberlegungen wurde uns klar, dass die Services und insbesondere die Datenspeicher konsolidiert werden müssten. Obwohl wir nun organisatorisch für all diese Services verantwortlich waren, führte dieser Umstand auch hier nicht automatisch zu einer Vereinfachung der Architektur. Stattdessen haben wir eine Roadmap erarbeitet, wie wir in Schritten iterativ zu unserer Zielarchitektur kommen.
Die Herausforderung im modernen Architekturmanagement
Beide Beispiele zeigen anschaulich, dass Conways Law bei der Entstehung von Software in einer Organisation wirkt, bei der Veränderung bestehender Softwarearchitekturen jedoch sehr viel langsamer seine Wirkung entfaltet. Architektur ändert sich nicht einfach durch Änderung von Organisationsstrukturen. Architekturveränderungen erfordern in der Regel das Priorisieren von entsprechenden Aufwänden. Insofern ist Conways Law eher eine Einbahnstraße, die man beim Design neuer Software beachten, auf die man jedoch nicht bauen sollte, um Architekturen zu verändern.
Dies führt zu einer der aus meiner Sicht heute wichtigsten Herausforderungen in der digitalen Produktentwicklung: eine gesunde Balance aus Neuentwicklungen und dem Management bestehender Architekturen. Wie dargelegt, sind manchmal bedeutende Aufwände nötig um eine Architektur effizient und effektiv zu halten. Gleichzeitig bleibt dies eine kontinuierliche Aufgabe. Oftmals hört man von alter “Legacy Software”, die die Agilität in der Entwicklung einschränken würde – verbunden mit der Verheißung, dass alle diese Probleme gelöst wären, würde man nur diese Legacy loswerden. Tatsächlich ist es aber so, dass die neue Software von heute die Legacy von morgen ist. Gerade die hohe Geschwindigkeit, mit der wir neue Microservices bauen können, trägt dazu bei.
Architekturmanagement muss deshalb ein kontinuierlicher Prozess sein, der mit der Entwicklung neuer Business-Funktionalitäten gut ausbalanciert sein will. Organisationsstrukturen können hier helfen, aber nicht die Arbeit abnehmen.
Hinweise:
Jan Hegewald bloggt unter https://www.agil-gefuehrt.de über moderne Führung und Agilität. Und auf https://www.jan-hegewald.de finden Sie weitere Inhalten zu Themen rund um digitale Produktentwicklung. Auf LinkedIn können Sie leicht mit ihm Kontakt aufnehmen.
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Jan Hegewald hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:
Die agile Migration von Anwendungen
Aufwandsschätzung mal anders
Jan Hegewald
Jan Hegewald ist VP Engineering bei SumUp Ltd. in Berlin. Zuvor war er Director of Engineering für die Product and Category Experience bei Zalando SE und als Head of Technology B2B bei der idealo internet GmbH tätig.
Davor hat er lange Zeit für große Unternehmen individuelle IT-Systeme für kritische Kernprozesse konzipiert, gebaut und eingeführt. Außerdem beriet er unterschiedlichste Kunden zu Projekt-, Programm- und Portfolio-Managementmethodiken jeweils mit Sicht auf Prozesse, Organisation, Tools und persönliche Kompetenzen der Mitarbeiter.