Architekturbewertung ist eine extrem vielseitige Praktik. In agilen Projekten kann sie sehr schlank für die iterative Steuerung von Architekturarbeit und Transparenz im Team genutzt werden, in großen und lang laufenden Projekten kann sie die größten Schwachstellen identifizieren und Überarbeitungsaufwände fokussieren. Bei Neuentwicklungen oder Migrationen steht oft die Frage im Raum ob man am richtigen Weg ist und Reviews geben Sicherheit. Risiken und Kompromisse werden sichtbarer und nebenbei entstehen klarer gefasste Anforderungen und Entscheidungen.
Es ist leicht Probleme an einem System zu finden. Die Frage ist ob diese Probleme schaden und wie sehr.
Architektur-Reviews können ad-hoc erfolgen oder eine der unzähligen Methoden nutzen, die seit den 90er Jahren entwickelt wurden und werden. In der Praxis ist es oft ein Mix an Methodikelementen der am zielführendsten ist. Unser wichtigstes Handwerkszeug sind die folgenden Methoden.
Die Architecture Tradeoff Analysis Method wurde am Software Engineering Institute (SEI) der Carnegie-Mellon Universität entwickelt und ist die ausgereifteste und bekannteste Reviewmethode für Architekturen. Sie detailliert und analysiert Architekturen über mehrere Workshops und wird für kleinere Reviews nur ausschnittsweise angewendet.
Die Cost-Benefit Analysis Method kommt ebenfalls vom SEI und konzentriert sich auf Kosten-Nutzen Bewertungen. Gerade beim Vergleich mehrerer Alternativen die unterschiedliche Qualität, aber auch Kosten haben kann die Methode zielgerichtet eingesetzt werden (Make vs. Buy vs. Legacy).
Der Decision Centric Architecture Review geht, anders als Szenario-basierte Verfahren, von den getroffenen Entscheidungen statt von detaillierten Anforderungen aus. Entscheidungen werden in der Bewertung dokumentiert und schrittweise analysiert, was die Bewertung gut skalierbar macht.
Neben den genannten Methoden gibt es noch viele weitere Einflüsse auf unsere Review-Praxis. Die TARA (Tiny Architectural Review Approach) bindet die Code-Ebene gut ein, ARID (Active Review for Intermediate Designs) kann z.B. bei API-Bewertungen helfen, Pre-Mortem Meetings sind iterativ gut anwendbar und sehr schlank und werkzeuggestützte Analysen (dynamisch und/oder statisch) geben tieferen Einblick bei speziellem Bewertungsfokus.
Wie groß Reviews angelegt werden sollten und welche Methoden sie nutzen, hängt von vielen Faktoren ab. Das folgende Bild zeigt die wichtigsten Faktoren im Überblick.
Für die konkrete Ausgestaltung einer Architekturbewertung ist es wichtig die Aspekte zu bestimmen die unter die Lupe genommen werden sollen. Isoliert oder auch gemeinsam könnten das z.B. die folgenden sein:
Qualitätsszenarien konkretisieren qualitative Anforderungen und sind in QAWs, ATAM und CBAM ein Thema. Sie ermöglichen die Architektur aus unterschiedlichen Blickwinkeln detailliert zu betrachten ohne sich zu verzetteln und sind gut geeignet um technische Kompromisse auch für technikfernere Stakeholder verständlich zu machen. Ähnlich wie User Stories haben auch Qualitätsszenarien einen typischen Aufbau:
In realen Reviews erarbeiten wir Qualitätsszenarien entweder in einem schnellen Brainstorming oder destillieren sie aus Einzelgesprächen (bei größeren Vorhaben). Die entstandenen Aussagen werden meist den übergeordneten Qualitätsmerkmalen (wie Security, Effizienz oder Modifizierbarkeit) zugeordnet. Der so entstandene Baum wird als „Utility Tree“ bezeichnet und bildet den Kern von Reviews die auf Qualität und Angemessenheit der Architektur ausgelegt sind. Startpunkt für einen solchen Baum kann die ISO 25010 sein.