Architekturen sind lebendig. Sie sind abhängig von Anforderungen, die sich wiederum verändern. Diese Änderungen müssen sich in einer mitwachsenden Architektur widerspiegeln.

Eierlegende-Wollmilchsau-Architekturen schienen für viele Applikationen ein gangbarer Weg zu sein. Diese Architekturen führen zu wartungsintensiven, teuren Systemen. Der Grund ist, dass man mit einer vermeintlich allgemeingültigen Architektur Aufwände hat, die keinen Beitrag zur konkreten Problemlösung liefern.

Wir wollen keine Architektur-Blueprints für ein System. Blueprints sind generische Lösungen für Probleme. Sie definieren also Lösungen oder Teillösungen, bevor das Problem wirklich verstanden ist.

Insbesondere im späteren Lebenszyklus erodieren Architekturen und wachsen unkontrolliert durch Wartungs- und Reparaturarbeiten. Die Struktur geht verloren. Dadurch verschlechtern sich Wartbarkeit und Erweiterbarkeit. Anpassungen an neue Anforderungen werden schwieriger und die Zukunftsfähigkeit einer Applikation nimmt ab.

An diesem Punkt kommt die Applikation und mit ihr oft auch die zuständige IT-Abteilung in den Ruf, sie sei schwerfällig, fehleranfällig, und insgesamt gehe alles zu langsam. „Langsam“ ist in der IT-Branche synonym mit der negativen Eigenschaft „zu teuer“.

Diesem Umstand kann man frühzeitig entgegenarbeiten, indem man die Architektur kontinuierlich auf den Prüfstand stellt und daraus die notwendigen Schlüsse zieht.

Das KISS-Prinzip im Architektur-Kontext. Dahinter stecken für uns zwei Aspekte:

• Zum einen der Microservice-Gedanke. Dieser ist allgemein bekannt und er führt nach unserer Erfahrung zu guten Ergebnissen. Hier müssen wir das Rad nicht neu erfinden. Wir bauen Microservices, also kleinteilige und domänenspezifische Services, die unabhängig voneinander funktionieren und wachsen können. Bei mehreren Lösungsmöglichkeiten wählen wir stets die einfachste Alternative.
• Weiterhin benötigen wir ein Werkzeug, das unserer Microservice-Architektur einen langfristigen Erfolg beschert. Auch nach vielen Entwicklungs-Iterationen und Personalwechseln im Team darf die Architektur nicht erodieren. Sie soll minimalistisch und verständlich bleiben.

Es bedarf also einer regelmäßigen Reflektion über die sich kontinuierlich verändernde System- und Softwarelandschaft. Insbesondere in agilen Projekten mit mehreren Projekt-Teams hat sich der folgende Begleitprozess zur Sicherstellung einer kontrolliert wachsenden Microservice-Architektur bewährt.

Die Architektur wird nach diesem Vorgehensmodell permanent weiterentwickelt. Genau wie die Software wird sie regelmäßig an die funktionalen Anforderungen angepasst.

Zu Beginn wird einmalig eine Bestandsaufnahme der ggf. bereits bestehenden Architektur sowie der organisatorischen und technischen Projektstruktur und des Projektumfelds durchgeführt. In dieser sogenannten Ramp-Up-Phase wird außerdem geprüft, ob die nicht-funktionalen Anforderungen mit der bestehenden Systemlandschaft langfristig vereinbar sind.

Die Erkenntnisse aus der Ramp-Up-Phase werden in einem ersten Architektur-Review aufgearbeitet, um konkrete Möglichkeiten zur Optimierung aufzuzeigen.

Die im Review gesammelten Empfehlungen werden in Architektur-Workshops priorisiert und auf konkrete Architektur-Änderungsmaßnahmen heruntergebrochen. Im Workshop werden lediglich Maßnahmen beschlossen, die in der aktuellen Entwicklungs-Version sinnvoll umgesetzt werden können. Beschlossene Maßnahmen sollten sich aus neuen Anforderungen oder der Vereinfachung bestehender Systeme ableiten.

Die Umsetzung dieser Architekturänderungen erfolgt in den jeweiligen Projektteams als eingeplante Aufgabe bzw. Userstory in ihrem regulären Entwicklungsprozess. Dabei müssen verschiedene Entwicklungszyklen der Projektteams und Schnittstellenabhängigkeiten zwischen den betroffenen Systemen berücksichtigt werden.

Architektur-Review und -Workshop werden anschließend regelmäßig durchgeführt, um die Gesamtarchitektur den veränderten Anforderungen und Umgebungsbedingungen anzupassen.