Architekturbewertung und ATAM

Warum eine Architektur bewerten

Jede Architektur ist eine Wette. Wenn ein Team einen Event Broker, eine Datenbank pro Service oder eine einzige Cloud-Region wählt, sagt es voraus, dass diese Entscheidungen die Performance, Verfügbarkeit, Sicherheit und Kosten liefern, die das Unternehmen braucht. Abschnitt 1.3 hat gezeigt, warum solche Wetten zählen: Die Kosten, eine strukturelle Entscheidung zu ändern, wachsen mit allem, was darauf aufgebaut ist, und einige der teuersten Fehlschläge der Softwaregeschichte waren Fehler der Anordnung, nicht einzelner Codezeilen. Die Architekturbewertung ist die bewusste Prüfung dieser Wette, bevor oder während das Geld ausgegeben wird.

Eine Bewertung stellt eine enge, praktische Frage: Welche Architekturentscheidungen gefährden, gemessen an dem, was dieses System leisten muss, diese Ziele? Sie ist weder ein Code-Review noch ein Schönheitswettbewerb zwischen Stilen noch ein Audit der Dokumentationsqualität. Sie arbeitet mit Entscheidungen und deren Folgen für Qualitätsmerkmale und kann daher lange vor dem ersten Code stattfinden, an einem Whiteboard-Entwurf oder an einer Reihe von Entscheidungsdokumenten, und sie lässt sich bei einem System wiederholen, das seit Jahren läuft.

Eine Bewertung hat auch Nutzen über die Ergebnisse hinaus. Stakeholder, die sich selten begegnen (Product Owner, Betrieb, Sicherheit, Finanzen, Entwicklung), müssen sich einigen, was am wichtigsten ist, und das legt oft widersprüchliche Annahmen offen. Der Architekt muss den Entwurf so klar erklären, dass Außenstehende ihn hinterfragen können, was die Dokumentation verbessert. Und die Organisation erhält eine Aufzeichnung bekannter Risiken, die sie bewusst akzeptiert hat, was etwas ganz anderes ist als Risiken, die niemand bemerkt hat.

Wann bewerten

Der beste Zeitpunkt für eine Bewertung ist, wenn genug entschieden ist, damit es etwas zu prüfen gibt, aber bevor diese Entscheidungen teuer rückgängig zu machen sind. In der Praxis gibt es mehrere natürliche Zeitpunkte, und reife Organisationen nutzen für jeden einen anderen Umfang der Bewertung.

Zu frühes Bewerten verschwendet Aufwand an Entscheidungen, die noch nicht real sind; zu spätes Bewerten macht aus Ergebnissen bloßes Bedauern. Eine nützliche Regel aus Fairbanks’ risikogetriebenem Modell (Abschnitt 1.8) gilt auch hier: Investieren Sie in die Bewertung im Verhältnis zum Risiko. Ein internes Werkzeug zweier Teams braucht keinen zweitägigen Workshop; eine nationale Zahlungsplattform schon.

ATAM: Ursprung, Zweck und Beteiligte

Die Architecture Tradeoff Analysis Method (ATAM) ist die bekannteste Bewertungsmethode. Rick Kazman, Mark Klein und Paul Clements vom Software Engineering Institute (SEI) der Carnegie Mellon University beschrieben sie im technischen Bericht ATAM: Method for Architecture Evaluation (CMU/SEI-2000-TR-004, August 2000). Sie ging aus der früheren Software Architecture Analysis Method (SAAM) hervor, die Kazman und Kollegen 1994 veröffentlichten und die sich vor allem auf Änderbarkeit konzentrierte. ATAM wird auch in Software Architecture in Practice von Bass, Clements und Kazman beschrieben, inzwischen in der vierten Auflage (2021).

Ihr Zweck wird oft missverstanden. ATAM vergibt keine Punktzahl und keine Bestehensgrenze für eine Architektur, und sie beweist nicht, dass ein System seine Anforderungen erfüllen wird. Sie zeigt, wo Architekturentscheidungen die Geschäftsziele gefährden und wo sie Abwägungen zwischen Qualitäten erzwingen, damit die Verantwortlichen entscheiden können, was zu tun ist. Der Name der Methode betont Abwägungen, weil die meisten interessanten Risiken dort liegen, wo eine Qualität auf Kosten einer anderen erkauft wird.

Drei Gruppen nehmen teil. Das Bewertungsteam, meist drei bis fünf Personen von außerhalb des Projekts, führt die Methode durch: eine Teamleitung, eine Bewertungsleitung, die moderiert, Protokollführende, die Szenarien und Abläufe festhalten, und Fragende mit Fachwissen zu bestimmten Qualitäten. Die Entscheidungsträger des Projekts sind der Architekt, die Projekt- oder Produktleitung und der Auftraggeber oder Kunde, der auf die Ergebnisse reagieren kann. Die Architektur-Stakeholder sind alle anderen Beteiligten: Entwicklung, Test, Betrieb, Sicherheit, Integration, Support und Vertretungen der Nutzer. Unabhängigkeit zählt: Bewerter, die das System entworfen haben oder dem Architekten unterstellt sind, finden weniger Risiken.

Das Vokabular der Analyse

Das Herzstück der Methode sind die Schritte 6 und 8. Für jedes wichtige Szenario bitten die Bewerter den Architekten, durchzuspielen, wie die Architektur reagiert, und sie bohren mit Fragen nach, die aus jeder Qualität stammen: Wie viele synchrone Aufrufe liegen auf diesem Pfad, was passiert mit laufenden Anfragen, wenn dieser Knoten ausfällt, wo ist diese Zugangsberechtigung gespeichert, was begrenzt die Queue? Jede Antwort wird mit fünf Begriffen eingeordnet, die weit über ATAM hinaus zum Standardvokabular geworden sind.

Nicht-Risiken verdienen mehr Aufmerksamkeit, als sie gewöhnlich bekommen. Festzuhalten, dass eine Entscheidung wegen einer bestimmten Annahme tragfähig ist (drei Replikate, eine vertraglich zugesicherte Antwortzeit eines Lieferanten, Traffic unterhalb einer bestimmten Grenze), macht aus einer vagen Beruhigung etwas, das sich später prüfen lässt. Ändert sich die Annahme, wird das Nicht-Risiko zum Risikokandidaten. Sensitivitäts- und Trade-off-Punkte sind nach der Bewertung ähnlich wertvoll: Sie sagen künftigen Maintainern, welche Parameter sie nur mit Vorsicht ändern sollten, und sie sind natürliche Orte für die automatisierten Prüfungen aus Abschnitt 11.3.

Der Utility Tree noch einmal

Abschnitt 2.8 hat den Utility Tree als Werkzeug zur Priorisierung von Qualitätsanforderungen eingeführt. Er entstand in ATAM und spielt innerhalb der Methode zwei unterschiedliche Rollen. In Schritt 5 bauen die Entscheidungsträger den Baum von oben nach unten auf: Nutzen, dann Qualitätsmerkmale, dann Verfeinerungen, dann konkrete Szenarien mit Bewertung (geschäftliche Bedeutung, technische Schwierigkeit). Die (H,H)-Blätter werden zur Tagesordnung für Schritt 6, weil sie am wichtigsten und am schwersten zu erreichen sind; dort verstecken sich Risiken am ehesten.

In Schritt 7 sammelt der größere Kreis der Stakeholder Szenarien von unten nach oben und stimmt über sie ab, ähnlich wie in einem Quality Attribute Workshop. Der Vergleich beider Sichten ist einer der aufschlussreichsten Momente einer Bewertung. Tauchen die wichtigsten Szenarien der Stakeholder bereits im Baum auf, verstehen die Entscheidungsträger den Zweck ihres Systems. Fehlt ein Szenario, das viele Stimmen erhält, etwa ein Betriebsszenario über Restaurant-Tablets, die offline gehen, haben die Entscheidungsträger einen blinden Fleck, und die Architektur womöglich auch. Solche Szenarien werden in den Baum aufgenommen und in Schritt 8 analysiert.

CBAM: Geld auf den Tisch legen

ATAM sagt Ihnen, wo die Risiken liegen; sie sagt Ihnen nicht, welche Abhilfen ihr Geld wert sind. Die Cost Benefit Analysis Method (CBAM), am SEI von Rick Kazman, Jai Asundi und Mark Klein entwickelt (erstmals 2001 veröffentlicht), baut auf den Szenarien einer ATAM auf, um diese wirtschaftliche Begründung zu liefern.

In groben Zügen nehmen die Stakeholder die priorisierten Szenarien und ordnen für jedes mehreren Antwortniveaus einen Nutzen (auf einer Skala von 0 bis 100) zu: schlechtester Fall, aktueller Stand, Ziel und bester Fall. Die Architekten schlagen Architekturstrategien vor und schätzen die Antwort, die jede erreichen würde. Der Nutzengewinn jeder Strategie wird an der Nutzen-Antwort-Kurve des Szenarios abgelesen und mit der Priorität des Szenarios gewichtet; über alle Szenarien summiert ergibt das den Nutzen der Strategie. Nutzen geteilt durch Kosten ergibt ein Kosten-Nutzen-Verhältnis (Value for Cost, VFC), und die Strategien werden im Rahmen des verfügbaren Budgets in der Reihenfolge ihres VFC gewählt und dann gegen Intuition und Randbedingungen auf Plausibilität geprüft.

Strategie B bringt mehr Nutzen pro Pfund, verfehlt aber die Wiederherstellungszeit von 15 Minuten, die die Restaurantverträge verlangen. Die Zahlen informieren die Entscheidung; sie treffen sie nicht. Der eigentliche Wert von CBAM liegt darin, dass es explizite, vergleichbare Schätzungen von Nutzen und Kosten erzwingt und offenlegt, wann eine Randbedingung und nicht ein Verhältnis entscheiden sollte. Seine Schwäche ist, dass Nutzen und Kosten Einschätzungen sind; Teams sollten sie variieren und prüfen, ob sich die Rangfolge ändert, genau wie Abschnitt 1.6 es für gewichtete Entscheidungsmatrizen empfiehlt. Abschnitt 11.8 zeigt, wie man aus solchen Schätzungen einen Business Case macht.

Kosten und Praxis

Eine vollständige ATAM kostet viel Arbeitszeit. Als grobe Veranschaulichung: Ein vierköpfiges Bewertungsteam, das jeweils zwei Tage in die Vorbereitung steckt (8 Personentage), eine eintägige Phase 1 mit drei Entscheidungsträgern (7), eine zweitägige Phase 2 mit zehn zusätzlichen Stakeholdern (34) und eine Woche Nacharbeit durch zwei Personen (10) ergeben rund 60 Personentage, bevor irgendetwas behoben ist. Für ein System, dessen Ausfall Millionen kosten würde oder das ein Jahrzehnt laufen soll, ist das eine günstige Versicherung. Für ein kleines Produktteam ist es unverhältnismäßig.

Mehrere Praktiken halten Bewertungen lohnend. Skalieren Sie die Methode: Bass, Clements und Kazman beschreiben eine leichtgewichtige Architekturbewertung, eine reduzierte ATAM für interne Teams, die sich in einem Tag oder weniger durchführen lässt, und manche Organisationen führen nur die Schritte 2 bis 6 mit einer Handvoll Personen durch. Bereiten Sie gründlich vor: Der größte Teil der Kosten einer schlechten Bewertung entsteht dadurch, dass man erst im Raum feststellt, dass niemand die Architektur beschreiben kann. Halten Sie die Bewerter unabhängig, aber informiert. Vereinbaren Sie vorab, wem die Ergebnisse gehören und wie sie weiterverfolgt werden, idealerweise als Entscheidungsdokumente und Backlog-Einträge mit Verantwortlichen. Und wiederholen Sie die Bewertung: Die Ergebnisse sind eine Momentaufnahme, und die Risiken ändern sich mit dem System und dem Geschäft.

Fachleute sind sich uneinig, welchen Platz die Methode heute hat. Kritiker sehen in ihr ein schwergewichtiges Relikt großer, vorab geplanter Projekte, das schlecht zu Teams passt, die viele Male am Tag deployen. Befürworter entgegnen, dass die Konzepte (Szenarien, Sensitivitäts- und Trade-off-Punkte, Risikothemen) genau das sind, was agilen Teams fehlt, wenn sie die Bewertung auslassen, und dass sich die Methode verkleinern lässt. Beide haben einen Punkt: Das volle Zeremoniell passt zu Systemen mit hoher Tragweite und langer Lebensdauer und zu großen Festlegungen, während das Vokabular und die Gewohnheit szenariogetriebenen Fragens überall hingehören. Abschnitt 11.2 behandelt das leichtere Ende.