Ein Werkzeugkoffer für Architektur-Reviews
Architektur-Reviews decken Risiken in Softwarelösungen auf und sichern Technologie- und Entwurfsentscheidungen ab. Das Instrumentarium an Herangehensweisen und Werkzeugen reicht von Workshop-basierten Durchsprachen bis hin zu Tool-gestützten Analysen des Quelltextes oder des laufenden Systems mit Metriken. Die Methoden sind teilweise seit 20+ Jahren im Praxiseinsatz, d.h. wir können auf einen reichen Erfahrungsschatz zurückgreifen. Gleichzeitig dreht die Welt sich weiter. In diesem Beitrag erfahren Sie, mit welchen Mitteln Sie und Ihr Team ein Softwaresystem bzw. dessen Lösungsarchitektur fundiert, angemessen und zeitgemäß beleuchten.
Unter einem Review (dt. Kritik, Rezension) verstehen wir ganz allgemein die Bewertung eines Gegenstandes. Dabei ist spannend, wer das macht (der oder die Reviewer und deren Hintergrund), was wir uns genau anschauen wollen (der Betrachtungsgegenstand) und wann das passiert (der Zeitpunkt des Reviews). Nehmen wir als Beispiel die Planung einer anstehenden Hochzeitsfeier. Das glückliche Paar schaut gemeinsam mit ein paar Freunden und Freundinnen drauf. Oder fragt die kritische Schwiegermutter als externe Expertin? Die Reviewer könnten das große Ganze betrachten oder auf einzelne Aspekte fokussieren – ein typischer Hotspot (also ein risikobehafteter Bereich im Betrachtungsgegenstand), im Beispiel: die Tischordnung. Eine Betrachtung vor der Durchführung kann ggf. Risiken aufdecken und größeres Konfliktpotenzial verhindern. Nach der Feier sind alle Beteiligten zwar schlauer, aber die Erkenntnisse sind “post mortem” weniger wertvoll …
Warum Softwarearchitektur reviewen?
Die Motivation bei einem Architektur-Review ist vor allem, Risiken aufzudecken und getroffene Entscheidungen abzusichern. Auch hier ist interessant, wer das Review durchführt, was genau beleuchtet wird und auch der Zeitpunkt ist spannend. Und ob das Ganze eine einmalige Geschichte ist oder Reviews mehrmals, ggf. sogar kontinuierlich die Entstehung und Weiterentwicklung der Software begleiten.
Verlassen wir also das Hochzeitsbeispiel. Bei einem Architektur-Review ist die Architektur der Softwarelösung der Betrachtungsgegenstand. Viele Definitionen von Softwarearchitektur (vgl. z.B. [1]) drehen sich um den Begriff der (Architektur-) Entscheidungen. Das sind grundlegende und im weiteren Verlauf nur schwer änderbare Lösungsaspekte. Typische Hotspots sind hier Zerlegungsfragen (beispielsweise der Architekturstil) und die Technologieauswahl (z.B. Programmiersprachen, Frameworks, Persistenz). Abbildung 1 zeigt diese und weitere Themenbereiche für Architekturfragestellungen sowie wichtige Einflussfaktoren, die Sie und Ihr Team beim Entwurf berücksichtigen sollten bzw. die bei einem Review überprüfbar sind. Passen die Entscheidungen zu den Einflüssen?
Einfach ad hoc drauflos zu bewerten ("Das macht man so nicht mehr!", "Das solltet Ihr besser schneiden ...") ist zumindest bei wichtigen Vorhaben kein guter Plan. Review-Expertinnen und Experten nutzen einen Werkzeug- und Methodenkoffer. Dieser steht auch interessierten Entwicklungsteams offen, die ihre Lösung selbst bewerten wollen – nicht jedes Review muss von außen, also durch Team- oder Projektfremde, durchgeführt werden.
Wie bei einem "echten" Werkzeugkoffer gilt: Bei einem konkreten Review kommen nicht alle Werkzeuge zum Einsatz. Es gilt das oder die passende(n) auszuwählen. Aber schauen wir erstmal, für welche Aktivitäten da etwas drin ist!
Was ist drin im Werkzeugkoffer?
Was ist das Hämmern, Schrauben, Sägen in einem Architektur-Review? Die wesentliche Tätigkeit ist die Analyse, das heißt das Beleuchten der Softwarearchitektur, die Betrachtung der getroffenen (oder beabsichtigten) Entscheidungen, der Strukturierung und der Konzepte. Dabei geht es vor allem um einen Abgleich, ein Gegenhalten der Architektur gegen andere Dinge, wie Abbildung 2 illustriert.
Bei Architektur-Reviews macht es einen großen Unterschied, ob die betrachtete Softwarearchitektur bereits (zumindest teilweise) umgesetzt ist. Denn mit einer Implementierung und einem laufenden System kommen konkretere, belastbare Fakten hinzu. Dies ermöglicht Messungen und den Einsatz von entsprechenden Software-Werkzeugen. Daher differenzieren wir zwischen qualitativer Analyse, die bereits früh erfolgen kann, und quantitativer Analyse, die sich auf das Messen mit Tools stützt. Abbildung 3 stellt diese beiden Ansätze gegenüber und arbeitet Stärken und Schwächen heraus.
Generell kommt die quantitative Analyse in Reviews erst dann ins Spiel, wenn es etwas zu (ver-)messen gibt. Etwa den Quelltext, formale Modelle (z.B. in UML) oder das laufende System. Werkzeuge für Architektur-Reviews sind aber keineswegs auf Software-Tools beschränkt. Tatsächlich nimmt Software nicht die Hauptrolle in einem modernen Werkzeugkoffer ein. Diese fällt der Review-Methodik zu.
Hier eine Liste von Review-Tätigkeiten, welche die Abgleiche aus Abbildung 2 konkretisieren, vor- und nachbereiten. Und für die es passendes Handwerkszeug gibt. Die Auflistung ist grob chronologisch, nicht alle Tätigkeiten sind immer nötig und einzelne Aspekte erleben auch Verfeinerungen im Review.
- Review-Ziel fixieren und absichern
- Maßgebliche Stakeholder identifizieren
- Review strukturieren, planen und durchführen
- architekturrelevante Anforderungen sichten und präzisieren
- Lösungsstrategie und -ansätze kommunizieren (ggf. identifizieren)
- Stärken und Schwächen herausarbeiten
- Kompromisse sichtbar machen
- Risiken aufdecken und bewerten
- Erkenntnisse aufbereiten und verdichten
- Ergebnisse kommunizieren
Grob strukturiert zerfällt unser Koffer mit Hilfsmitteln für diese Tätigkeiten in drei Bereiche: Methoden, Unterstützungsmaterialien (z.B. Vorlagen) und Software-Tools. Abbildung 4 visualisiert diese Aufteilung. Schauen wir mal, was in den Fächern zu finden ist!
Um dem Review einen Rahmen zu geben, bieten sich verschiedene publizierte Methoden zum Vorgehen an, also Herangehensweisen mit Schritten, ggf. Rollen und Ergebnistypen. Alle im linken Fach von Abbildung 4 genannten Vertreter sind offen zugänglich, ihr Einsatz frei von Lizenzkosten. Die Wirksamkeit steigt allerdings in der Regel mit der Erfahrung der am Review Beteiligten deutlich.
Grob unterteilen sie sich in recht allgemeine Bewertungsmethoden, die auf alle Qualitätsmerkmale passen und keinen spezifischen Aspekt (beispielsweise kein bestimmtes Qualitätsmerkmal, keine bestimmte System-Art oder Technologie) adressieren. Und auf der anderen Seite solche, die quasi den Review-Schwerpunkt schon mitbringen, zum Beispiel Kosten/Nutzen bei CBAM [2].
Die allgemeinen Methoden unterscheiden sich wiederum vor allem
- im grundsätzlichen Ansatz, d.h. ob sie z.B. über die architekturrelevanten Anforderungen oder die Lösung einsteigen
- dadurch, wer am Review beteiligt ist
- dadurch, wie groß das Rad ist, das sich dreht (Aufwand, Dauer).
Abbildung 4 zeigt im linken oberen Bereich nur eine kleine Auswahl dieser allgemeinen Methoden. Der Artikel unter [3] motiviert LASR als leichtgewichtige Alternative zum aus dem akademischen Umfeld stammenden, recht bekannten, aber auch aufwändigen ATAM. [4] stellt unterschiedliche Methoden kurz vor, u.a. TARA und DCAR.
Die spezielleren Methoden sind noch vielfältiger und mitunter Technologie-spezifisch. Abbildung 4 nennt exemplarisch einzelne, etwa die Architektur-Frameworks der großen Public-Cloud-Anbieter. Diese bringen neben Design-Prinzipien und Best Practices rund um ihre Plattform auch Methodik zur Bewertung der eigenen Lösung mit.
Einen Überblick über diese Cloud-Ratgeber finden Sie unter [5]. Ein anderer prominenter Vertreter spezifischer Methoden stammt vom OWASP (Open Worldwide Application Security Project [6]), das speziell für das Qualitätsmerkmal Sicherheit einiges im Gepäck hat.
Sowohl die allgemeinen als auch die spezifischen Methoden setzen den Rahmen, wie Sie und Ihr Team vorgehen. Innerhalb dieser Review-Tätigkeit helfen Unterstützungsmaterialien, die in Abbildung 4 im mittleren Bereich zu finden sind. Hierzu zählen Ablaufpläne, Check-Listen und Vorlagen – einige Review-Methoden (insbesondere die oben genannten) liefern dort einiges mit.
Eine besondere Rolle spielen Sammlungen oder Listen, die Sie und Ihr Team direkt beim Erarbeiten von Review-Ergebnissen unterstützen. Da es bei Reviews vor allem darum geht, Risiken aufzudecken, seien hier insbesondere Sammlungen von Standard-Risiken genannt. Hier gibt es System-Art- bzw. Technologie-spezifische wie die OWASP Top 10 Web Application Security Risks ebenso wie allgemeine, wie sie das Unterstützungsmaterial von LASR mitliefert (siehe Abbildung 5, beschrieben in [3]). Das Abarbeiten solcher Sammlungen oder Listen garantiert kein perfektes Review-Ergebnis. Die Inhalte fungieren als Ideengeber, befeuern ein Brainstorming und sichern zumindest ab, dass kein kritischer Aspekt gänzlich außen vor bleibt. Solche Sammlungen leisten auch beim Erheben der maßgeblichen Stakeholder oder der Top-Qualitätsziele gute Dienste.
Daneben sind auch generelle Hilfsmittel aus der Softwarearchitektur im Koffer, denn oftmals müssen im Rahmen eines Reviews Architekturansätze oder Einflüsse herausgearbeitet, konkretisiert und vorgestellt werden. Hier seien exemplarisch arc42 [7] als Gliederungsvorschlag für Architekturdokumentation sowie Vorlagen für ADRs (Architecture Decision Records, z.B. nach [8]) genannt. Derartige Gliederungen geben Orientierung im Entwurf und beim Entscheiden, sichern ab, dass Sie und Ihr Team an alles Typische denken und machen Ihre Lösung nachvollziehbarer und auch leichter bewertbar. Und sie ersparen Zeit und Aufwände, da Sie sich keine eigene Gliederung ausdenken müssen und die Beteiligten sich in vertrauten Strukturen und Begriffen schneller zurechtfinden.
Bei der Analyse einer Softwarelösung in Workshops mit qualitativen Mitteln setzen wir auf den Austausch und das Wissen und die Erfahrung in der Gruppe. Dabei bleibt ein Restrisiko (vgl. Abbildung 3), das sich mitunter durch Durchstiche, Prototypen und gezielte Messungen entschärfen lässt. Der Werkzeugkoffer hält auf der rechten Seite entsprechend auch Software-Tools bereit, mit denen sich Fakten etwa zur Effizienz oder Verfügbarkeit direkt erheben lassen – (prototypische) Implementierung vorausgesetzt.
Wie entscheide ich, welche(s) Werkzeug(e) ich verwende?
Je nach Zielsetzung des Reviews und Fortschritt im Vorhaben passen unterschiedliche Methoden und Werkzeuge. Generell lässt sich die Auswahl und zeitliche Abfolge am besten über die Beantwortung einiger Leitfragen bewerkstelligen, welche Sie in Tabelle 1 finden. Die Antworten in der rechten Spalte zeigen dabei die Bandbreite auf und haben beispielhaften Charakter.
Tabelle 1: Leitfragen zur Methoden- und Werkzeugfindung in Reviews
| Frage | Mögliche Antworten |
| Wo kommt der Impuls für das Architektur-Review her? | eigener Antrieb im Entwicklungsteam, Management, andere Organisationseinheit, Kunden oder Auftraggeber … |
| Was ist die Zielsetzung des Reviews? | Absichern einer Architekturvision, Aufdecken von Risiken, Erarbeiten von Handlungsfeldern für eine Überarbeitung … |
| Was (genau) ist der Betrachtungsgegenstand? | einzelne Anwendung, ein Teil einer Anwendung, eine Anwendungslandschaft, einzelne Entscheidungen, eine Plattform … |
| Wer ist am Ergebnis des Reviews interessiert? | wir als Entwicklungsteam, unser Management, ein externer Partner … |
| Wie reif ist der Betrachtungsgegenstand? | Konzept oder Idee, prototypisch oder teilweise implementiert, bereits im Markt oder in Produktion … |
| Wie viel Wissen um die Qualität des Betrachtungsgegenstandes ist da? | keines, einzelne Risiken oder technologische Schulden benennbar, eklatante Schwächen bereits bekannt … |
| Was soll der Fokus des Reviews sein? Lassen sich umgekehrt Themen in der Analyse vernachlässigen? | einzelne Technologien, Systemteile (z.B. das Frontend), Qualitätsmerkmale (z.B. Sicherheit) … |
| Wie nachvollziehbar ist die Architektur des Betrachtungsgegenstandes? | historisch gewachsen, von ausgewählten Leuten erklärbar, nachvollziehbar dokumentiert … |
Einen guten Rahmen für ein Review bieten allgemeine, qualitative Methoden, und Vertiefungen kommen gezielt dann zum Einsatz, wenn aufgedeckte Risiken oder Unsicherheiten das nahelegen. Das gilt insbesondere für aufwändige, quantitative Ansätze. Vermeiden Sie, Dinge zu vermessen, nur weil es geht. Eine schlanke Herangehensweise (vgl. [3]) bietet sich für ein frühes Review ohne große Beteiligung Team-Externer an. Hängen weitreichende Entscheidungen am Review-Ergebnis, liegen klassische, fundiertere Methoden zur Absicherung nahe. Für letztere ist ohne belastbare Erfahrung in Review-Methodik der Rückgriff auf Unterstützung unumgänglich.
Wohin geht die Reise?
Mit dem technologischen Fortschritt bei GenAI im Allgemeinen und KI-Agenten im Besonderen stellt sich die Frage, ob nicht auch Review-Tätigkeiten direkt oder zumindest mit Unterstützung solcher Werkzeuge durchführbar sind. Ein KI-Agent ist ein autonomes Softwaresystem, das mithilfe von künstlicher Intelligenz komplexe Aufgaben für Nutzer erledigt, indem es selbstständig Entscheidungen trifft, plant und handelt.
Im Codieren sind einschlägige Werkzeuge wie Microsoft Copilot oder Cursor schon ziemlich stark. Wie schlagen sie sich in einer Bewertung? Zur Illustration ein kleines Experiment: Ich habe Cursor [9] – also ein Software-Engineering-Werkzeug, das vor allem zum Coden eingesetzt wird – eine überschaubare Softwarelösung präsentiert (eine mittelgroße Lambda-Funktion für AWS in Go). Im Chat habe ich naiv die Frage gestellt: “Wie gefällt Dir mein Programm?” Das Ergebnis war eine ausführliche, etwas wohlwollende Einschätzung, die mich im ersten Augenblick tatsächlich überraschte.
Nach einer kurzen Analyse des Quelltextes, der Build-Skripte und der Konfiguration spuckte Cursor (unter der Haube unter anderem Claude, ChatGPT und Spezialwissen) einen Bericht mit Fakten über meine Softwarelösung aus (z.B. verwendete Technologien inkl. Versionen), eine Liste mit Stärken (beispielsweise Einhaltung konkreter Best Practices bzgl. AWS Lambda und Go, aktuelle Versionen der Frameworks) und Schwächen (z.B. unzureichende Fehlerbehandlung und zu wenige Tests). Schlussendlich hat sich das Werkzeug an einen Abgleich zwischen Best Practices und Umsetzung gemacht und zu einem gewissen Grad auch die Struktur bewertet.
Das Verblüffende an dem Experiment ist die Qualität des Ergebnisses trotz der sehr offenen Frage und des Rückgriffs auf nur einen schmalen Ausschnitt aus den Abgleichen in Abbildung 2. Tatsächlich ist noch einiges mehr möglich, wenn in der Analyse tatsächlich die Architektur in Form von Dokumentation explizit vorliegt (z.B. ADRs) und nicht vom Tool ausschnitthaft und mitunter irrtumsanfällig ermittelt werden muss. Oder wenn architekturrelevante Anforderungen in die Bewertung mit einbezogen werden und nicht nur Best Practices. KI-Agenten können externe Werkzeuge wie Datenquellen und andere Programme nutzen, um Ziele zu erreichen. Ausgestattet mit dem richtigen Wissen (vgl. Abbildung 4, insbesondere die mittlere Spalte mit dem Unterstützungsmaterial) werden KI-Agenten perspektivisch zu einer wertvollen Unterstützung. In der Analyse der betrachteten Lösung ebenso wie als Ideengeber für typische Risiken oder zur Erstellung exemplarischer Qualitätsszenarien.
Fazit
Der gezeigte Werkzeugkoffer für Architektur-Reviews bietet einen pragmatischen Einstieg, um Softwarelösungen fundiert und strukturiert zu hinterfragen. Wenn Sie sich mit seinen Methoden zumindest überblicksartig vertraut machen, halten Sie Aufwände für Workshops in einem angemessenen Rahmen und strahlen in der Durchführung Sicherheit aus. Ein Rückgriff auf die richtigen Vorlagen und der zielgerichtete Einsatz von Softwarelösungen ergänzen klar geleitete Workshops, Diskussionen und Deep Dives.
Für die Auswahl geeigneter Vorgehensweisen ist vor allem entscheidend, woher der Impuls für das Review kommt, was das Ziel ist und wie reif der Betrachtungsgegenstand bereits ist. Schärfen Sie Ihr Methodenrepertoire und bleiben Sie offen für neue Möglichkeiten, wie sie perspektivisch mit spezialisierten KI-Agenten bereits an die Tür klopfen. Sie ersetzen Reviews nicht, sondern ergänzen diese um weitere Werkzeuge.
[1] N. Rozanski, E. Woods: "Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives", Addison-Wesley, 2. Auflage 2011
[2] R. Kazman, M. Klein, P. Clements: "Making Architecture Design Decisions: An Economic Approach", Technical Report CMU/SEI-2002-TR-035, Carnegie Mellon University 2002
[3] S. Toth, S. Zörner: "Leichtgewichtige Software-Reviews mit LASR", Informatik Aktuell 2024
[4] S. Toth, S. Zörner: "Risikoanalyse mit leichtgewichtigen Softwarearchitektur-Reviews", heise online 2025
[5] A. Kaserbacher: "Architektur-Ratgeber in der Cloud", Informatik Aktuell 2023
[6] Open Worldwide Application Security Project
[7] arc42, Vorschlag zur Gliederung von Architekturdokumentation
[8] M. Nygard: Documenting Architecture Decisisons, Blog-Beitrag von 2011
[9] Cursor, KI-gestützter Code-Editor basierend auf Visual Studio Code
