Für die Überprüfung der Architektur eines IT Systems gibt es verschiedene Gründe: z.B. die Prüfung der Tragfähigkeit, der Skalierbarkeit, der Zukunftsfähigkeit oder die Untersuchung von Architekturproblemen oder auch der Vergleich von verschiedenen Entwürfen eines Systems.
Mit einer systematischen Prüfung einer Architektur werden idealerweise Risiken und Schwachstellen identifiziert und auf Problembereiche hingewiesen. Richtig eingeplant, kann eine solche Architekturbewertung das Projektrisiko einer Entwicklung enorm verringern.
Auswahl einer geeigneten Methode zur Architektur Überprüfung und Bewertung
Eine geeignete und bekannte Methode zur systematischen Überprüfung einer Architektur ist die ATAM Methode. Diese vom Software Engineering Institute (SEI) entwickelte Methode erlaubt die systematische Bewertung anhand von Qualitätsanforderungen sogenannten Quality Attributes (siehe dazu die folgenden Blogartikel Visuelle Erarbeitung von Software Qualities und Quality Attribute Workshop).
Die ATAM Methode
Das folgenden Flipchart welches ich als Präsentationsmittel am Anfang eines ATAM Reviews verwendet habe, gibt einen Überblick über die ATAM Methode:
Diese Übersicht ist etwas vereinfacht gegenüber der vom SEI beschriebenen Methode (https://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm).
Nachfolgend eine kurze Erläuterung der einzelnen Schritte gemäss obigem Flipchart:
1. Present ATAM
Der ATAM Leader präsentiert die Methode allen Beteiligten. Zeitaufwand ca. 2h.
Die ATAM Methode ist so gebaut, dass es zwei parallele Phasen gibt: Bei der einen Phase sind die Stakeholder des Systems involviert (im Flipchart gelb hinterlegte Schritte). Bei der anderen Phase sind alle Reviewteilnehmer sowie der Architekt oder das Architekturteam involviert (im Flipchart rot hinterlegte Schritte).
Stakeholder Phase
Die nachfolgenden Schritte werden nur mit dem Stakeholder Team durchgeführt.
2. Present Business Driver
Der Projektleiter oder eine andere geeignete Person präsentiert die Ziele (Business Driver), welche hinter dem zu entwicklenden System stehen. Das ist ein zentraler Schritt, damit alle Beteiligte den Fokus auf den Zweck und die Ziele des Systems nicht vergessen. Zeitaufwand je nach Grösse des Systems ca. 2..4h.
3. Identify Qualities
In diesem Schritt geht es darum die Qualitätsanforderungen der Stakeholder zu identifizieren. Das sind im Wesentlichen die nichtfunktionalen Anforderungen, welche für die verschiedenen Stakeholder essentiell sind.
4. Define Quality Attributes Scenarios
In diesem Schritt werden die aus Schritt 3 identifizierten Qualities weiter verfeinert und so definiert, dass diese überprüft werden können (siehe dazu die folgenden Blogartikel: Visuelle Erarbeitung von Software Qualities und Quality Attribute Workshop). Der Zeitaufwand für die Schritte 3 und 4 liegen je nach Grösse des Systems zwischen 4h und 2 Tage.
Architektur und Review Team Phase
Die nachfolgenden Schritte werden vom Architektur und Review Team durchgeführt.
5. Present Architecture
In diesem Schritt präsentiert der Architekt oder das Architekturteam die geplante oder schon gebaute Architektur des Systems. Die Teilnehmer dieser Präsentation notieren sich wichtige Designentscheidungen. Zeitaufwand max. 2h.
6. Identify & Analyse Architecture Decisions
Basierend auf der Präsentation in Schritt 5 sowie einem nachfolgenden Workshop werden möglichst komplett die expliziten und impliziten Architektuentscheidungen aufgelistet und basierend auf den Anforderungen welche das Projektteam berücksichtigt hat bewertet. Der Zeitaufwand für diesen Schritt liegt je nach Grösse des Systems zwischen 4h und 2 Tage.
7. Analysis
In diesem Schritt werden die Bewertungen aus dem Schritt 6 noch mit den Qualitätsszenarien des Stakeholder Teams ergänzt und auch hier wie in Schritt 6 dessen die Erfüllung bewertet. Der Zeitaufwand für diesen Schritt liegt je nach Inputs vom Stakeholder Team zwischen 4h und 2 Tage.
Die Bewertung wird systematisch mit folgenden Punkten angegeben:
Non-Risks: Gute Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung erreicht.
Risks: Problematische Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung nicht erreicht oder gar schlechter gemacht.
Sensitivity: Relevante Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung direkt positiv beeinflusst.
Tradeoff: Zu überprüfende Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung positiv gleichzeitig werden aber andere Qualities negtiv beeinflusst.
Basierend auf dieser systematischen Bewertung folgt der letzte Schritt:
8. Impact / Actions
Hier wird entschieden wie mit dem Resultat der Analyse umgegangen wird. Üblicherweise werden die Risiken genauer betrachtet und diese versucht zu eliminieren. Bei den Trade-Offs und Sensitivities ist sicher sinnvoll die entsprechenden Architekturentscheidungen nochmals zu überdenken. Nicht zu vergessen sind hier aber auch die Non-Risks. Diese "guten" Entscheidungen weisen explizit, auf gut überlegte Architekturarbeit hin. Dies ist ein wichtiger Aspekt gereade dann, wenn die Analyse für das Projektteam negativ belastet und wie eine Prüfung aufgefasst wird.