Die beste Softwarearchitektur

Was ist überhaupt Softwarearchitektur ?

Ist es ein Systemdesign, mit dem ich bestimmte Regeln in einem System festlege oder klare Module designe? Oder sogar schon konkrete Klassen und Funktionen, die ich definiere?

Wenn wir Softwarearchitekturen aus der Perspektive der agilen Softwareentwicklung betrachten, kommen wir schnell zu dem Schluss, dass es kaum möglich ist, auf einer detaillierten Ebene Klassen und Module noch weit vor der eigentlichen Implementierung zu definieren, da sich Anforderungen Sprint für Sprint verändern können und sich auch die Applikation selbst im Laufe der Zeit immer wieder verändert.

Also was genau ist dann diese Softwarearchitektur, mit der wir vor Beginn einer Implementierung konkretisieren, wie ein System entwickelt wird?

Laut Ralph Johnson wird Softwarearchitektur definiert als: „Architektur ist der wichtige Kram, was auch immer das ist?!“

Diese Definition mag sicherlich zuerst ziemlich ernüchternd wirken und doch birgt sie eine Menge Wahres in sich.

Eine Softwarearchitektur stellt im Grunde die getroffenen Entscheidungen eines Softwareteams dar. Dabei geht es weniger darum, dass dokumentiert wird oder Diagramme gezeichnet werden, sondern mehr darum, dass das Entwicklerteam die Entscheidungen für ein Softwaredesign gemeinsam erarbeitet. Softwareentwicklerinnen und -entwickler, Designerinnen- und -Designer, Product Ownerinnen und -Owner, einigen sich so auf bestimmte Architekturentscheidungen wie REST oder GraphQL, Python oder JavaScript, zwei Services oder nur einer.

Dies lässt auch die Rolle einer Softwarearchitektin oder eines Softwarearchitekten in einem ganz anderen Licht erscheinen. Sie sind nämlich nicht dazu da im dunklen Kämmerchen eine Softwarearchitektur, mithilfe von UML und BPMN, zu designen und anschließend die Diagramme an das Softwareteam abzugeben. Die Rolle ist eher dafür vorgesehen, auf verschiedene Perspektiven einer Softwarearchitektur hinzuweisen und mit dem Team, und nicht für das Team, die Entscheidungen für die Softwarearchitektur zu treffen. Denn Implementieren wird es zuletzt das Team.

Welche ist den nun die beste Softwarearchitektur ?

Softwarearchitekturstile gibt es einige, wie beispielsweise Microservices oder Space-Based Architecture. Aber wie der Name schon verrät sind es eben nur Stile, die zur Entscheidungsfindung herangezogen werden können.

Das beantwortet auch eigentlich recht schnell die Frage, was die beste Softwarearchitektur ist – es gibt im Grunde nicht die beste Softwarearchitektur. Die Entscheidungen, die ein Team gemeinsam mit bestem Willen für eine Software trifft, ist die beste erdenkliche Softwarearchitektur für das Team und die bereitgestellten Anforderungen. Denn so werden alle Teamressourcen dazu genutzt, alle an der Entscheidungsfindung zu beteiligen und so die bestmögliche Architektur mit den verfügbaren Mitarbeiterinnen und Mitarbeitern zu entwickeln.

Würde man einem anderen Team genau dieselben Anforderungen bereitstellen, würden womöglich ganz andere Architekturentscheidungen getroffen werden. Jedoch wären diese Entscheidungen wieder die besten für das gesamte Team. Nur so ließe sich die zu entwickelnde Software von allen vorhanden Softwareentwicklerinnen und Softwareentwickler implementieren.

Nichtsdestotrotz gibt es einen Architekturstil, den ich während meiner Laufbahn kennengelernt habe und der sich über die Jahre bewährt hat. Vor allem entwickle ich kaum noch eine Applikation nicht mehr in diesem Architekturstil.

Die Rede ist von der domain-driven hexagonalen Architektur oder auch domain-driven Hexagon genannt. Der Architekturstil ist ein Mix aus Domain-Driven Design von Eric Evans, Clean Architecture und Clean Coder von Robert C. Martin und der Hexagonal Architecture, auch Ports und Adapters genannt, von Alistair Cockburn. Hierbei werden unterschiedliche Konzepte von namhaften Programmierern kombiniert, um klare Regeln und eine klare Struktur der Applikation zu erreichen, aber dennoch die einzelnen Architekturentscheidungen, wie REST oder GraphQL, Python oder NodeJS, dem Team zu überlassen.

Hier ein Bild des Domain-Driven Hexagon, welches schön veranschaulicht, wie klare Regeln definiert werden, jedoch genug Raum für Architekturentscheidungen gelassen wird.

Dies kann mit einem Beispiel aus dem Straßenverkehr verglichen werden. Es ist besser, wenn sich alle im Straßenverkehr an die selben Regeln halten als wenige zu haben, die ähnliche Regeln befolgen und sich dann allen anderen daran orientieren müssen. Welche Entscheidungen man im Straßenverkehr trifft, ist jeder und jedem selbst überlassen, in welche Richtung jedoch der Verkehr fließt, ist klar geregelt. Und so kommen wir zum folgendem Schlusssatz.

Eine Choreographie des Teams bezüglich der Architektur hat auf lange Sicht eine bessere Performance, als eine Orchestrierung der Architektur durch bestimmter Personen, die zwar die Architekturentscheidungen schnell voran treiben, dadurch aber restliche Teammitglieder vernachlässigt werden. Somit schaffen es orchestrierte Softwarearchitekturen auf Dauer Fluktuationen, einfache Änderungen und kürzere Implementierungszeiten nicht standzuhalten, wobei choreographierte Softwarearchitekturen anfangs durch den hohen Synchronisationsaufwand der Teammitglieder erst träge sind, jedoch aber nachhaltig zu immer schnelleren Ergebnissen führt, resilient gegenüber Fluktuationen ist und im allgemeinen es viel mehr Spaß macht miteinander etwas zu entwickeln als gegeneinander.