In diesem Interview spricht Stefan Tilkov über die Wichtigkeit von aufeinander abgestimmten Organisationen, Architekturen und Prozessen in der Softwarearchitektur.

Erörterung zu Conway’s Law

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

W-JAX: Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Stefan Tilkov: Das vielleicht offensichtlichste Beispiel sind die vielen Web- und E-Commerce-Systeme, die oft durch eine Initiative einer Marketing-Abteilung entstanden sind und oft auch dort betreut wurden, während sich die restlichen Fachabteilungen mit der IT-Abteilung abstimmt, von ihr betreut wird oder sich mit ihr auseinandersetzt. In der Gesamtarchitektur spiegelt sich das dann auf einmal in einer Vielzahl wenig sinnvoller Redundanzen wider, die im Moment in vielen Unternehmen gerade aufgelöst werden.

Doch man findet die Effekte von Conway’s Law auch bei den vielen Querschnittsabteilungen, die sich verselbständigen und Systeme betreuen, die dann in einer Architektur als Fremdkörper auftauchen. Das können zentrale Datenbanken, monolithische Systeme oder Integrationsserver sein, die von einer Organisationseinheit regelrecht bewacht werden, sodass die Prozesse unglaublich aufwändig werden und jede Änderung mit massiven Schmerzen verbunden ist.

Aber auch wenn fast alles richtig gelaufen ist, bekommt man manchmal durch Unachtsamkeit frische Conway-Effekte: Es gab bei der Neuentwicklung eines großen Shopsystems eine schöne SCS-artige Architektur, bei der knapp zehn Teams hervorragend parallel arbeiten konnten, da die von ihnen realisierten Teilsysteme über wenige, standardisierte Schnittstellen miteinander kommunizierten, mit Hilfe von Redundanz auf Autonomie geachtet wurde, jedes Team volle Verantwortung für alle Schichten von Persistenz bis UI hatte – eigentlich eine wunderbare Struktur, bei der Architektur und Organisation aufeinander abgestimmt waren. Aber dann gab es die Initiative, für die Auslieferung von Frontend-Komponenten und -Assets ein zentrales Team aufzusetzen.

Das hat – wie jede Form der Zentralisierung – durchaus Vorteile, man muss z.B. alles nur an einer Stelle lösen. Es hat aber auch massive Nachteile – in diesem Fall konkret, dass das neu eingeführte zentrale Frontend-Team zum Bottleneck für alle anderen wurde. Die Architektur veränderte sich, mit allen Nachteilen, weil die Organisation sich im Zweifelsfall durchsetzt.

Also am besten das dringendste Problem identifizieren und sich zunächst auf dessen Lösung konzentrieren, anstatt gleich zu versuchen, alles auf einmal zu ändern.

W-JAX: Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Stefan Tilkov: Am wichtigsten ist aus meiner Sicht, sich darüber klar zu werden, welchen Kampf man für den wichtigsten hält, um sich nicht an X Fronten gleichzeitig aufzureiben (wenn mir die militaristische Metapher gestattet ist). Also am besten das dringendste Problem identifizieren und sich zunächst auf dessen Lösung konzentrieren, anstatt gleich zu versuchen, alles auf einmal zu ändern. In unserer Architekturarbeit, aber auch in unseren Entwicklungsprojekten versuchen wir in aller Regel als erstes, wenige globale Regeln in Verbindung mit viel lokaler Autonomie zu etablieren. Damit beschränkt man die Entscheidungsfreiheit bestehender Strukturen und Teams zwar, aber nicht in einem zu großen Maße. Gleichzeitig schafft man die Möglichkeit, schrittweise Verbesserungen einzuführen.

Der Software Architecture Track auf der JAX 2018

W-JAX: Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Stefan Tilkov: Ich würde es anders formulieren: Organisation, Architektur und auch Prozesse müssen aufeinander abgestimmt sein, sonst ist jede einzelne Facette – wie toll sie auch immer gestaltet sein mag – zum Scheitern verurteilt. Im Idealfall werden sie gemeinsam entwickelt. Ist das nicht möglich, z.B. weil eine Organisation schon da ist und nicht einfach geändert werden kann, müssen sich Zielarchitektur und -Prozesse daran orientieren, sonst werden sie nie Realität. Das Gleiche gilt auch andersherum.

W-JAX: Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert: Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Stefan Tilkov: Das ist aus meiner Sicht die ganz zentrale Erkenntnis in der Diskussion über die „richtige“ Architektur: Es gibt sie nicht. Man kann nur darauf hinarbeiten, einen Architekturrahmen zu definieren, der Evolution und Weiterentwicklung unterstützt. Das ist nach meinem Verständnis die zentrale Idee hinter Microservices, Self-contained Systems und ähnlichen Ansätzen.

W-JAX: Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Stefan Tilkov: Für mich ist die Rückkehr zu pragmatischen, einfachen, dem tatsächlich identifizierten Problem angemessenen Lösungen im Kleinen anstelle generischer, eierlegender Wollmilchsäue ein wichtiger Gedanke. Wenn ich Software so baue, dass die einzelnen Teile, aus denen sie besteht, nicht für die Ewigkeit perfekt sein müssen, sondern sich schnell und unkompliziert austauschen lassen, kann ich mich auf das Problem konzentrieren und genau das lösen. Passt die Lösung in 12 Monaten nicht mehr, werfe ich den einen Baustein im Zweifelsfall weg und entwickle ihn auf eine andere, bessere, vielleicht modernere Art neu.

Die ganz zentrale Erkenntnis in der Diskussion über die „richtige“ Architektur: Es gibt sie nicht.

W-JAX: Stefan, auf der W-JAX stellst du Patterns und Antipatterns von Microservices vor. Kannst du einmal ein Beispiel nennen, wann eine Microservices-Architektur eine gute Lösung, wann aber auch eher ein Irrweg darstellen kann?

Stefan Tilkov: Ein schönes Beispiel, ebenfalls aus der Praxis: Man entwickelt eine Microservice-Architektur, bestehend aus unzähligen, winzig kleinen Services, schneidet aber so, dass einzelne Services eine zentrale Rolle spielen und fast alle anderen von ihnen abhängen. Man kauft sich damit enorme Koordinationsprobleme ein und wundert sich, dass man statt einer agilen Architektur nur einen verteilten Monolithen bekommt, der sich vor lauter Container-Overhead auf einem 16GB-Entwickler-Laptop nur noch mit Mühe starten lässt. Im Prinzip ist das auch wieder eine Conway-Verletzung, weil man vergisst, dass ein zentraler Grund für Modularisierung eine gute Entkopplung und eine „Separation of Concerns“ ist. Das hat David Parnas übrigens schon Anfang der 70er gut erkannt …