Software Architektur überprüfen – Qualität garantiert in 8 Schritten

Warum eine Software Architektur überprüfen? Das kann verschiedene Gründe haben: 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 Software Architektur werden idealerweise Risiken und Schwachstellen identifiziert und auf Problembereiche hingewiesen. Richtig eingeplant, kann eine solche Architekturbewertung das Projektrisiko einer Entwicklung enorm verringern.

Für die Einordnung einer Architekturbewertung in das gesamte Thema Software Architektur siehe hier: Software Architektur ist nicht komplex – Software Architektur einfach und klar.

Software Architektur überprüfen mit Methode

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 vereinfachten Überblick über die Methode:

Nachfolgend eine kurze Erläuterung der einzelnen Schritte gemäss obigem Flipchart:

1. Present ATAM

Der ATAM Leader präsentiert die Methode allen Beteiligten.

Die ATAM Methode ist so aufgebaut, 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).

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.

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 überprüfbar definiert:

Weitere Infos dazu in den folgenden Blogartikeln: Visuelle Erarbeitung von Software Qualities und Quality Attribute Workshop).

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.

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.

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.

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.

Idealerweise werden die Resultate in diesem Schritt in einem Radardiagramm mit den Qualitätsattributen und den Resultaten visualisiert. Damit kann eine qualitative und quantitative Bewertung oder ein fundierter Vergleich verschiedener Architekturansätze gemacht werden:

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.