Architecture Tradeoff Analysis Method (ATAM)

Der Zoologe Thomas Hunt Morgan begann 1908 in seinem Labor damit Fruchtfliegen (genauer: Drosophila melanogaster) zu züchten und systematisch zu untersuchen. Er erklärte so die grundlegende Struktur der Chromosomen. Andere folgten später seinem Beispiel, Drosophila wurde zum Modellorganismus in der Genforschung und Morgan Nobelpreisträger für Medizin.

ATAM als die mit Abstand bekannteste Review-Methode für Softwarearchitektur spielt eine ähnliche Rolle für die Architekturbewertung wie die Fruchtfliege für die Genetik. Das erkennt man zum Beispiel daran, dass andere Methoden sich in der Regel so vorstellen, dass sie zunächst die Unterschiede zu ATAM herausstellen. Es ist also lohnend, ATAM zu kennen.

Was ist ATAM?
Grober Ablauf der Methode, inkl. Diagramm
Wesentlichen Ergebnisse von ATAM
Was spricht für ATAM? Was dagegen?
Weitere Informationen zu ATAM

Was ist ATAM?

Die Architecture Tradeoff Analysis Method (kurz ATAM) entstand Ende der 90er-Jahre am Software Engineering Institute (SEI) der Carnegie Mellon Universität (CMU) und wurde 2000 in Form eines Technical Reports (TR) veröffentlicht. ATAM ist eine Analysemethode für Softwarearchitektur, wobei es insbesondere darum geht Kompromisse (engl.: Tradeoffs) zwischen konkurrierenden Qualitätszielen herauszuarbeiten. Neben den Risiken sind diese Kompromisse ein wesentliches Ergebnis der Analyse.

Ziel von ATAM ist es die Folgen von Architekturentscheidungen im Hinblick auf die Qualitätsanforderungen zu bewerten.
(aus CMU/SEI-2000-TR-004)

ATAM steigt über die Anforderungen in die Bewertung ein. Die Methode ist szenarienbasiert, das heißt alles dreht sich drum … Szenarien werden erhoben, priorisiert, durchgesprochen.

Als rein qualitative Bewertungsmethode ist ATAM früh anwendbar – ein laufendes Softwaresystem oder eine Implementierung in Form von Quelltext sind nicht erforderlich. Betrachtungsgegenstand sind die getroffenen Entscheidungen (oder Entscheidungskandidaten). Grundsätzlich lässt sich die Methode aber auch auf bestehende, ältere Systeme anwenden. Anlass könnte hier größerer anstehender Umbau oder Änderungen in zentralen Rahmenbedingungen sein.

Wie läuft eine Bewertung nach ATAM ab?

Der Ablauf von ATAM ist im Wesentlichen Workshop-basiert und gliedert sich in vier Phasen, von denen die mittleren beiden den Kern der Bewertungsmethode bilden. Die folgende Abbildung zeigt das Ganze schematisch. Für Phase 1 ist ein Workshop von ein bis zwei Tagen typisch. Für Phase 2 kommen weitere Stakeholder dazu.

Hier kurz einige Erläuterungen zu zentralen Konzepten und Begriffen in ATAM:

(Qualitäts-)Szenario – Eine beispielhafte Verwendung des zu betrachtenden Systems, und zwar so, dass ein Qualitätsmerkmal die Hauptrolle spielt. Kurzer Text, jeweils ein bis zwei Sätze.

Utility Tree (Deutsch etwa “Qualitätsbaum”) – Strukturierung der Qualitätsszenarien in einem Baum mit dem Begriff “Utility” (Deutsch etwa “Nützlichkeit”) als Wurzel, den Qualitätsmerkmalen als Knoten und den Szenarien als Blättern. Beispiel siehe unten.

Architekturansatz (Englisch: Architectural Approach) – Wichtige getroffene Entscheidung innerhalb der Architektur, um Ziele zu erreichen und Rahmenbedingungen einzuhalten. Dabei kann es sich etwa Strukturierungsthemen handeln (z.B. Wahl eines Architekturstils), eine konkrete Technologiewahl oder Make or Buy.

Was sind die wesentlichen Ergebnisse von ATAM?

Während des Ablaufs in ATAM entstehen verschiedene Artefakte. Neben den eigentlichen Ergebnissen wie Stärken und Schwächen der Softwarearchitektur, Risiken und Kompromissen gibt es auch wertvolle Zwischenresultate wie den Utility Tree als explizite Beschreibung der Qualitätsanforderungen in Form der Szenarien. Die folgende Abbildung zeigt einen solchen Utility Tree für die Deutsche Corona Warn-App als Beispiel.

Die in den Schritte 4, 6 und 8 herausgeschälten und beleuchteten Architekturansätze machen die Architektur nachvollziehbar, wie überhaupt der gesamte Prozess für ein besseres Verständnis der Architektur bei allen Beteiligten sorgt. Die folgende Abbildung zeigt beispielhaft die Struktur eines Ergebnisberichtes, wie er in einer ATAM-Bewertung abfallen kann.

Was spricht für ATAM? Was dagegen?

ATAM ist die mit Abstand bekannteste Bewertungsmethode, aber bei weitem nicht die einzige. Tatsächlich ist der hohe Bekanntheit oft ein Argument für den Einsatz; die Anwendung einer fundierten Methode strahlt gerade in Umfeldern mit wenig Erfahrung mit Architekturbewertung Sicherheit aus. Unabhängig davon punktet ATAM dadurch, dass es für alle Qualitätsmerkmale gleichermaßen geeignet ist. Die gute Einbindung der Stakeholder trägt zu Transparenz und Akzeptanz der Softwarelösung bei. Als qualitative Methode kann sie früh zum Einsatz kommen, und so Risiken zu einem Zeitpunkt aufdecken, wo ein Umsteuern noch verhältnismäßig einfach möglich ist.

Auf der anderen Seite steht ATAM oft als schwergewichtige Methode in der Kritik. Es sind relativ viele Dinge auf der Anforderungsseite zu tun, bevor es “zur Sache kommt”. Entsprechend steigen andere Bewertungsmethoden wie DCAR (Decision Centric Architecture Review) über die Lösungsseite (also die Architekturentscheidungen) ein, oder fokussieren bei der Anforderungsseite noch stärker als ATAM das macht. LASR fällt in diese Kategorie, der Ablauf dort ist aber wie bei ATAM an den Qualitätsszielen ausgerichtet.