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

Lars Röwekamp:  Es ist für mich immer wieder faszinierend, feststellen zu „dürfen“, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist. Wir als open knowledge sind häufig bei großen Kunden mit klassischen Konzernstrukturen im Einsatz. Die dort vorherrschenden, sehr komplexen Organisations- und Kommunikationsstrukturen sorgen nicht selten dafür, dass von speziellen Architektur-Teams extrem umfangreiche und hoch generische, konzernweite Architekturen vorgegeben werden.

Die eigentlichen Anwendungen bzw. deren konkrete Fachlichkeiten werden dann via architekturspezifischer DSLs, XML-Konfigurationen oder irgendeinem anderen Voodoo-Ansatz auf mystische Art und Weise generiert. Was ursprünglich einmal gut gemeint war, führt in der Regel dazu, das selbst kleinste Features – dank Medienbruch – nur sehr umständlich umzusetzen sind und ein fachliches Debugging kaum noch möglich ist.

Als ich bei einem unserer größeren Kunden einmal Conway’s Law thematisiert habe, hat dieser das aktuelle Organisationsdiagramm und ein Schaubild der „gelebten“ Architektur gegenüber gestellt. Beide Schaubilder sahen sich erschreckend ähnlich und erinnerten eher an den U-Bahn-Fahrplan einer europäischen Großstadt als an ein strukturiertes und gut durchdachtes System.

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

Lars Röwekamp: Hier sprichst du ein sehr wichtiges Thema an. In vielen Unternehmen herrschen historisch bedingt Strukturen vor, die von den meisten Mitarbeitern einfach als von Gott gegeben hingenommen und somit nicht mehr hinterfragt werden. Es kommt daher nicht von ungefähr, dass sich gerade in großen Unternehmen immer wieder kleine Lab-ähnlich Teams herausbilden. Dies ist häufig die einzige Möglichkeit, legitim aus den vorgegebenen Strukturen auszubrechen. Projekte werden als Prototypen oder Proof-of-Concepts getarnt, da für diese weniger starre Auflagen gelten als für normale Software-Projekte.

In meiner Rolle als Architekt hinterfrage ich grundsätzlich den Nutzen bestehender Strukturen, Frameworks etc. Kann mir keiner der Beteiligten einen sinnvollen Grund für das Vorhandensein nennen – „das war schon immer so“ ist übrigens KEIN sinnvoller Grund – dann stelle ich das Konstrukt auf den Prüfstand und entsorge es gegebenenfalls.

Psychologisch gesehen sollte man hier natürlich mit einem gewissen Feingefühl vorgehen. Oftmals wird ein architektonisches Refactoring als eine Art Schuldeingeständnis für eine Fehlplanung der Vergangenheit interpretiert. Dies ist insbesondere dann der Fall, wenn sich spezielle Teams für die Architektur verantwortlich zeichnen und andere für die Implementierung der Anwendungen auf Basis dieser Architektur. Hier ist ein Finger-Pointing quasi vorprogrammiert. Es ist also wichtig zu vermitteln, dass Software lebt und Refactoring somit einen ganz natürlich Prozess darstellt, um auf geänderte Anforderungen bzw. einen geänderten Kontext zu reagieren.

Es ist faszinierend, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist

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?

Lars Röwekamp: Ich würde es eher so formulieren: Eine schlanke Unternehmensorganisation bzw. -kommunikation erhöht die Chancen, dass am Ende ein System herauskommt, bei dem die konkrete Fachlichkeit – also die jeweils umzusetzende Domäne (DDD lässt grüßen) – im Fokus steht und nicht eine unternehmensweite Architektur bzw. ein Rahmenwerk, in welches die Fachlichkeit irgendwie hineingepresst werden muss.

Wir haben in unseren Projekten häufig feststellen dürfen, dass fachlich organisierte Teams, im Vergleich zu rein technisch organisierten Teams, qualitativ bessere Software in kürzerer Zeit produzieren. Dies liegt nicht selten daran, dass ein Großteil der für die Implementierung der Software notwendigen Kommunikation direkt innerhalb des Teams stattfinden kann.

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?

Lars Röwekamp: Da gebe ich Jeff Sussna zu 100% recht! Leider wird in der Praxis die „Fähigkeit zum Redesign“ immer wieder gerne mit „generischen“ und somit scheinbar hoch flexiblen Systemen verwechselt, in denen am Ende mehr deklariert als programmiert wird.

Aber zurück zu der Aussage von Jeff Sussna: Nehmen wir einmal als Beispiel die wunderschöne Welt der Microservices. Ein gut durchdachtes Design sieht von Anfang an vor, dass die Schnittstellen der Services – egal ob synchrones REST API oder Messaging – sich im Laufe der Zeit verändern dürfen und dass einzelne Services oder ganze Service-Gruppen durch andere ersetzt werden können. Gut und richtig gemacht, ergibt sich am Ende eine Gesamtarchitektur als Choreographie des Zusammenspiels der einzelnen Services und nicht als Orchestration durch eine zentralen Instanz. Die Fähigkeit zum Redesign ist somit per Definition Bestandteil der Architektur.

Von Anfang an sollte man „tolerante“ Schnittstellen in seinem Design einplanen.

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

Lars Röwekamp: Wenn wir schon bei „Gesetzen“ sind, fällt mir sofort Postel’s Law ein: „Be conservative in what you do, be liberal in what you accept from others.“ Auch dieses Gesetz deckt sich stark mit der Aussage von Jeff Sussna, da es sinngemäß besagt, dass ich von Anfang an „tolerante“ Schnittstellen in meinem Design einplanen sollte, um so flexibel auf geänderte Anforderungen reagieren zu können.

Ebenfalls für extrem wichtig halte ich – nicht nur, aber vor allem auch bei lose gekoppelten Systemen, wie Microservices – ein gutes Domänen-Design. Mir wird leider nach wie vor viel zu viel über Technologie und zu wenig über eine geschickte Modularisierung der Fachlichkeit diskutiert. Gut durchdachte Bounded Contexts verbunden mit einem sauberen, zukunftssicheren Schnittstellendesign haben schon so manches Projekt zum Erfolg geführt.

W-JAX: Lars, auf der W-JAX hältst du unter anderem auch einen Talk zum Thema Serverless. Welchen Zusammenhang siehst du zwischen Serverless und der Theorie Conway’s?

Lars Röwekamp: Im Zusammenhang mit Serverless fällt auch immer wieder der Begriff NoOps. NoOps bedeuten in diesem Zusammenhang zwar nicht, dass gar kein operationaler Aufwand mehr notwendig ist. In Konsequenz benötigt man aber kein dezidiertes Ops bzw. DevOps Team. Auf die Spitze getrieben könnte man also soweit gehen und behaupten, dass dank Serverless keine Kommunikation mit anderen und somit auch keine Architektur mehr notwendig ist. Dies wäre allerdings ein wenig blauäugig, denn in der Praxis muss sich natürlich trotzdem jemand um die ursprünglich bei dem Ops- oder DevOps-Team aufgehängten Themen, wie Security, API Gateway etc. kümmern und die durch den Cloud-Anbieter für diesen Zweck zur Verfügung gestellte Infrastruktur konfigurieren und administrieren. Gleiches gilt für weitere, klassische Cross-Cutting-Aspekte, wie zum Beispiel verteiltes Logging und übergreifendes Monitoring.