Was und wofür ist eine Architektur-Review?

In den letzten Monaten kamen immer häufiger Anfragen nach Architektur-Reviews bei mir an. Grund genug, meine Erfahrungen aufzuschreiben und zur Diskussion zu stellen. Dabei beschreibe ich die drei Ws:

1. Wofür wird ein Architekturreview gemacht?
2. Was ist eine Architektur?
3. Wie wird ein Architekturreview durchgeführt?

Natürlich ist das Thema zu umfangreich, um in einem Blogpost wie diesem vollständig behandelt zu werden. Daher kann ich zunächst viele Themen nur anteasern. Für weitere Informationen verweise ich auf die Literatur und freue mich über eine rege Diskussion.

Ein weiterer Anreiz das Folgende zu lesen: Vieles gilt bei einer Analyse einer existierenden Architektur genau wie bei einer Neuentwicklung. Der Artikel ist quasi wiederverwendbar. Während es bei der Entwicklung aber auf das richtige Maß ankommt (Just enough Software Architecture) ), ist das Kind bei der Review bereits in den Brunnen gefallen.

Welche Ziele kann eine Architektur-Review haben?

Es gibt verschiedene Gründe, warum unsere Kunden nach Architektur-Reviews fragen. Der naheliegenste (und naivste) ist, von einer dritten Person einen beruhigenden Stempel zu bekommen: „Die Architektur ist gut.“

So einfach ist es in der Regel natürlich nicht. Es fängt schon damit an, dass die Anfragen zu ganz unterschiedlichen Zeiten des Anwendungs-Lifecycle kommen. Hier eine Liste an Beispielen:

• Am Anfang der Entwicklung: Das Team oder ein interner oder externer Architekt hat sich etwas ausgedacht. Ist das in Ordnung?
• Die Anwendung ist im Betrieb: Wir haben Probleme in unserer Anwendung. Liegt das an der Architektur? Was müssen wir ändern?
• Die Anwendung ist relativ alt, die Frage nach Weiterentwicklung oder Neuentwicklung stellt sich.
• Die Architektur ist gar nicht bekannt, die Review ist eigentlich eine nachträgliche Dokumentation

Entsprechend ergeben sich verschiedene mögliche Ziele, die eine Architektur-Review haben kann:

• Beruhigung des Auftraggebers hinsichtlich Qualität, Umfang und Nutzen
• Sicherstellen der richtigen Architekturentscheidungen bezüglich aktueller oder neuer Anforderungen
• Entscheidungshilfen für die Weiterentwicklung/Umbau/Neuentwicklung einer Anwendung

Wenn eine Architektur bewertet wird, kann man sich von zwei Seiten nähern: Entweder man prüft, ob die Architektur „gut genug“ ist, also die Anforderungen an sie erfüllt. Oder man beschreibt die Eigenschaften, die die Architektur hat und stellt dann Vor- und Nachteile gegenüber. (Bemerkung: Könnte man von Top-Down/Bottom-Up sprechen?)

Begriffsklärung: Was bedeutet Architektur?

Der Nachteil an dem Begriff „Architektur“ ist, dass jeder davon redet, aber etwas Unterschiedliches meint. Wenn eine Anfrage nach einer AR kommt, muss daher zunächst eine Begriffsklärung erfolgen. Selbst wenn es halbwegs einheitliche Definitionen gibt (siehe z. B. Wikipedia ), helfen diese beim gegenseitigen Verständnis wenig, weil die in den Definitionen benutzen Abstraktionen zu allgemein sind.

Wenn ich mir über Architektur Gedanken mache oder darüber rede, befindet sich immer ein Elefant im Raum, den man einmal für alle klar machen sollte: der Rahmen, in dem wir über Architektur denken und reden. Ignoriert man dies, führt das nahezu zwangsläufig zu Missverständnissen und enttäuschten Erwartungshaltungen.

Hier sind einige Konzepte, deren Bedeutung für den Auftrag festgelegt werden sollten:

Systemarchitektur vs Softwarearchitektur

Als erstes möchte ich die Flughöhe bzw. den Umfang von Architektur festlegen. Bei einer Systemarchitektur betrachte ich (wie der Name sagt) das Zusammenspiel verschiedener Systeme. Und schon muss ein weiterer Begriff definiert werden: Ein System ist, kurz gesagt, ein klar abgegrenztes Softwarepaket mit definierten Schnittstellen. Das kann also genauso ein ERP-System sein wie ein Microservice. Damit kann schon ein System einen sehr unterschiedlich großen Umfang haben. Eine Systemarchitektur wird manchmal auch als Makroarchitektur bezeichnet.

Bei einer Softwarearchitektur betrachte ich die Code-Komponenten, die i. d. R. innerhalb eines Prozesses laufen, und analysiere oder beschreibe das Zusammenspiel. Auch hier gibt es definierte Schnittstellen, und der Übergang zwischen System- und Softwarearchitektur ist nicht immer klar. In einer typischen 3-Tier-Anwendung laufen die UI- und die Backend-Komponenten zwar in getrennten Prozessen (und häufig auch Sprachen), bilden aber aus höherem Abstraktionslevel gesehen zusammen mit der Datenbank ein System. Im „Handbuch moderner Softwarearchitektur“ wird auch das Zusammenspiel von (in getrennten process-)Komponenten als Softwarearchitektur bezeichnet.

Auf unterster (Code-)Ebene kann man ebenfalls in Komponenten oder Schichten trennen und die Zusammenhänge beschreiben. Hier werden Metriken erstellt, mit denen die Wartbarkeit gemessen werden soll. Dafür gibt es Tools , die in die CI/CD-Pipeline eingebunden werden können und eine langfristige Verschlechterung verhindern sollen. Die Architektur, die sich hier befindet, wird manchmal auch als Mikroarchitektur bezeichnet.

Architektur-Patterns

Egal auf welcher Ebene man sich befindet: Das Wesentliche einer Architektur-Review ist das Analysieren und Erkennen von Patterns und zu verstehen, wie diese Patterns die Anforderungen an die Software erfüllen.

Auf Codeebene dürften jedem die Entwurfsmuster der Gang-of-Four bekannt sein. Diese Patterns stellen, „[…] eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist“. Für verschiedene Programmiersprachen gibt es wiederum eigene Patterns oder Beschreibungen, wie allgemeine Patterns am besten in der jeweiligen Sprache umgesetzt werden können (Idiome). Es geht also darum, Code so zu strukturieren, dass Erfahrung wiederverwendet wird.

Anwendungen werden aus verschiedenen Komponenten zusammengebaut. Daher stellt sich in Softwaresystemen die Frage, wie die Komponenten zusammen funktionieren. Dabei ist aber nicht nur die Interaktionsweise und damit Abhängigkeit zwischen den Komponenten relevant, sondern auch Problemstellungen wie Deploybarkeit, Skalierbarkeit oder Versionierbarkeit. Beispiele für Patterns – oder Architekturstile – die diese Fragen beantworten sind z. B. Monolithen, Microservices oder SOA. Die Interaktionsweisen können zum Beispiel mit Client-/Server- oder Eventsourcing-Patterns implementiert werden.

Für bestimmte Arten von Softwaresysteme gibt es weitere Sammlungen von Patterns, zum Beispiel für Enterprise-Integration-Patterns (EiP) für die Integration von Softwarekomponenten oder -systemen. Wie der Name schon sagt, geht es dabei eher um die Integration von (Enterprise-)Systemen. Tatsächlich ist ein Großteil der Patterns aber so abstrakt, dass sie auch innerhalb eines Systems zur Anwendung kommen (z. B. gibt es Message Endpoints in jeder Anwendung, die APIs anbietet).

Level bzw. Views

Wie schon gesagt, gibt es bei der Betrachtung von Architekturen verschiedene Gesichtspunkte zu berücksichtigen. Bei Patterns sind dies die Probleme oder Aspekte, die auf unterschiedliche Arten gelöst werden können. Je nachdem, welche Probleme man analysieren oder lösen möchte und je nach Detailierungsgrad, ergeben sich verschiedene Sichtweisen, Modellierungs- oder Dokumentationssprachen:

• Komponenten: Interaktion, Verteilung, Deployment
• Fachlichkeit: Bounded-Context, Interaktionsdiagramme, Klassendiagramme
• Code: Design Patterns, Packages, Layer, Metriken

Eine andere Darstellung ist z. B. das 4+1-Sichtenmodel .

Vorgehensweise

Nachdem zunächst beschrieben wurde, was eine Architektur sein kann, die reviewed werden soll, kommen wir jetzt zum Vorgehen, also dem Wie. Im Prinzip bietet sich ein klarer Ablaufplan an. Wie aber später (siehe Dokumentation) beschrieben wird, ist eine häufige Interaktion mit dem Auftraggeber sinnvoll. Dadurch ergeben sich kurze Feedbackzycklen, so dass auch Änderungen oder neue Einsichten eingearbeitet werden können. Das passiert bei einer Entwicklung einer Architektur eher als bei einer reinen Review, aber da letzteres i. d. R. mit einem Zweck verbunden ist, gibt es auch hier externe veränderliche Einflüsse.

1. Auftragsklärung: Ziel und der Umfang der Review
2. Erfassen der Anforderungen an die Architektur inkl. Priorisierung
3. Analyse und Verstehen der Architektur
4. Sichtung der Architekturentscheidungen und ggf. der Alternativen
5. Bewertung der Architektur hinsichtlich der Anforderungen
6. Zusammenstellen der Ergebnisse und ggf. Empfehlungen zum Umgang
7. Stempel drauf

Input

Um eine Review durchführen zu können, werden verschiedene Daten und Informationen benötigt. Die genauen Details hängen von Level der Architektur ab, der zu untersuchen ist. Allgemein benötigt man vom Auftraggeber aber folgende Informationen:

• Existierende Dokumentation: Beschreibungen zur Architektur, evtl. ADRs (Architecture Decision Records)
• Code: Je nach Betrachtungslevel muss der Code zur Verfügung stehen, um Codeanalysen durchführen zu können oder fehlende Dokumentation zu ersetzen.
• Anforderungen: Diese werden benötigt, um die Ziele der Architektur abzugleichen.
• Ansprechpartner: Je nach Komplexität kann es sinnvoll sein, mit verschiedenen Stakeholdern der Architektur zu sprechen (inkl. den Entwicklern, die sie entwickelt haben oder verwenden müssen).

Eventuell lohnt es sich, Teamstrukturen und einige Prozesse wie Build und Deployment oder Release-Strategien genauer anzusehen. Häufig stehen diese in Wechselwirkung mit der Architektur (siehe Conways-Law ).

Auf eine Architektur wirken immer bestimmte Anforderungen, ob diese nun erfüllt werden oder nicht. Um die Qualität beurteilen zu können, müssen also die Ziele der Architektur beschrieben werden. Ein gute Beschreibung davon haben Kollegen in Auf dem Weg zur High-level-Zielarchitektur beschrieben. Ein wesentlicher Punkt ist auch der Detailierungsgrad: Häufig reicht es beispielsweise nicht aus, eine bestimmte Reaktionszeit zu fordern oder Erweiterbarkeit. Je nach Komponente muss man häufig genauer unterscheiden, welcher Teil schnell eine Antwort liefern muss, wo Skalierbarkeit wichtig ist, oder wo externe Entwickler Plugins bereitstellen können sollen. Einige Anforderungen beeinflussen oder widersprechen sich, so dass gegebenenfalls ein Abwägen stattfinden muss. In einer Review ist das insofern von Bedeutung, als dass die Vor- und Nachteile der gewählten Architektur im richtigen Level gegenüber gestellt werden müssen.

Dokumentation

In der Regel möchten die Auftraggeber eine Dokumentation der Ergebnisse der Architektur-Review. Wie sich aus den vorigen Ausführungen ergibt, kann es nicht „das“ Template für solche Analysen geben. Stattdessen kann die Dokumentation iterativ erstellt werden, um den Auftraggeber frühzeitig einzubeziehen und Mithilfe seines Feedbacks die Erwartungshaltung von vornherein abzustimmen.

Zunächst ist die Struktur festzulegen: Diese beinhaltet die vorläufigen Überschriften und eine kurze Beschreibung, was in den Kapiteln beschrieben wird. Während der Analyse einer Architektur können sich die Erwartungen des Auftraggebers ändern, eine andere Herangehensweise anbieten. Zudem können sich die Schwerpunkte verlagern. Deswegen kann oder muss die Struktur natürlich bei Bedarf angepasst werden, was durch ein interaktives Vorgehen mit kurzen Zyklen unterstützt wird.

Auch die Art der Diagramme sollte mit dem Auftraggeber abgestimmt werden. Eine gute Auswahl der Graphiken ist sehr schwer und abhängig davon, was gezeigt werden soll. Die Herausforderung besteht häufig darin, mehrere Aspekte der Architektur in einem Bild auszudrücken. Häufig werden dafür Graphiken mit mehreren Layern vorgeschlagen, die ein- oder ausgeblendet werden können. Eine andere interaktive Darstellungsweise ist in Details hinein zoomen zu können. Beide sind natürlich nur insoweit verwendbar, als zum Beispiel dynamische Visiodiagramme als Bestandteil der Dokumentation akzeptabel sind. Ist eine statische Dokumentation nötig, müssen die relevanten Ausschnitte ausgewählt und dupliziert werden.

Eine von mir gerne verwendete Art von Diagrammen ist die von C4 . Einerseits gibt diese eine vernünftige Struktur vor, andererseits ist diese so allgemein, dass sie an die meisten Anforderungen und Architekturfragen angepasst werden kann. Wie die Cs (Context, Container, Component, Class) beschreiben, werden dabei alle Abstraktionsebenen abgedeckt.

Zusammenfassung

Keine Architektur-Review ist wie die andere: Sie kann unterschiedliche Ziele verfolgen und sich auf verschiedene Bestandteile und Detailgrade eines Softwaresystems beziehen. Je nachdem können unterschiedliche Tools, Analyse- und Dokumentationswerkzeuge verwendet werden. Das grundsätzliche Vorgehen ist allerdings ähnlich. Es empfiehlt sich eine häufige Interaktion mit den Stakeholdern.

Weiterführende Links

https://www.heise.de/developer/artikel/Was-ist-Systemarchitektur-4931898.html
https://github.com/clarkware/jdepend
https://www.langlebige-softwarearchitekturen.de
https://www.ionos.de/digitalguide/websites/web-entwicklung/was-sind-design-patterns/