Architecture Analyse-Methode
Prüft, wie Architekturentscheidungen wichtige Qualitätsziele unterstützen und wo Risiken oder Zielkonflikte entstehen.
ATAM untersucht eine Architektur anhand konkreter Situationen, etwa einer Lastspitze oder eines Ausfalls. Das Bewertungsteam klärt zuerst mit den Architekturverantwortlichen, welche Entscheidungen die wichtigsten Qualitätsziele unterstützen. Anschließend bringen weitere Beteiligte ihre Anforderungen ein. So entsteht ein begründetes Bild der Risiken, Zielkonflikte und offenen Fragen.
Wie unterstützt die Architektur unsere wichtigsten Qualitätsziele, und wo entstehen Risiken oder Zielkonflikte?
Die sechs Arbeitsabschnitte fassen die neun ATAM-Schritte zusammen. Plane zwei Bewertungsrunden, Analysen dazwischen und einen Ergebnisbericht.
Auftrag
Gemeinsamer Einstieg in Methode, Bewertungsziel und System. Entspricht den ATAM-Schritten 1 bis 3.
Ansätze
Architekturentscheidungen und eingesetzte Ansätze für die Qualitätsziele sichtbar machen. Entspricht ATAM-Schritt 4.
Utility Tree
Ein Utility Tree ordnet Qualitätsziele, genauere Anforderungen und konkrete Szenarien als Baum. Entspricht ATAM-Schritt 5.
Analyse
Die relevanten Entscheidungen systematisch durchgehen und Begründungen prüfen. Entspricht ATAM-Schritt 6.
Szenarien
Eine breitere Stakeholdergruppe ergänzt und priorisiert Szenarien. Die Architektur wird daran erneut untersucht. Entspricht ATAM-Schritten 7 und 8.
Bericht
Ergebnisse nachvollziehbar präsentieren und zu Risikothemen bündeln. Entspricht ATAM-Schritt 9 mit anschließender Übergabe.
Prüfe betroffene Szenarien erneut, sobald sich Architektur oder Qualitätsziele ändern. Halte den neuen Stand und noch ausstehende Nachweise im Bericht fest.
Geeignet für geplante oder bestehende Softwaresysteme mit mehreren wichtigen Qualitätszielen, etwa schneller Reaktion und hoher Verfügbarkeit. Für die Bewertung braucht ihr eine konkrete Architekturbeschreibung, klare Geschäftsziele und Menschen aus den betroffenen Bereichen.
Ein Utility Tree ordnet Qualitätsziele und Szenarien. Ergänzende Szenarien der Beteiligten und die Reihenfolge ihrer Prüfung sind begründet.
Begründete Aussagen zu Risiken und Zielkonflikten der untersuchten Architektur. Messbare Aussagen zu Performance, Sicherheit oder Verfügbarkeit werden durch passende technische Analysen ergänzt.
Eine Liste der nächsten Prüfungen und Entscheidungen, jeweils mit verantwortlicher Person und Termin.
Fiktives Lehrbeispiel
Halte Szenarien, Begründungen und nächste Schritte so fest, dass andere die Bewertung nachvollziehen können.
Beschreibe Bewertungsumfang, Architekturversion, Geschäftsziele, Rollen und Termine. Benenne auch Bereiche außerhalb des Auftrags.
Reservierungsdienst v0.8; Expansion; Latenz und verlässliche Platzvergabe.
Ordne Qualitätsziele, genauere Anforderungen und Szenarien im Utility Tree. Begründe je Szenario die geschäftliche Wichtigkeit und technische Schwierigkeit.
S1: 500 Buchungen/min, 95 Prozent binnen 2 s bestätigt. S2: Zonenausfall, Dienst binnen 60 s verfügbar. Beide Szenarien: hohe Wichtigkeit und Schwierigkeit; fiktive Anforderungen.
Notiere je Szenario die untersuchte Entscheidung, Begründung, Belege und Annahmen. Halte Risiken, begründet unkritische Entscheidungen (Non-Risks), Sensitivitäts- und Trade-off-Punkte fest.
R1: Nachweis zum Zonenausfall steht aus. Die nötige Anzahl bestätigender Systeme beeinflusst Antwortzeit und Ausfalltoleranz. Grundlage: fiktiver Entwurf.
Neue Szenarien, vertretene Perspektiven, Priorisierung und Änderungen an Analysebefunden festhalten.
Der Betrieb ergänzt S3: Wiederholte Anfragen sollen zur selben Buchung führen.
Risikothemen, Bezug zu Geschäftszielen, Grenzen und Folgeschritte mit Verantwortung und Prüftermin dokumentieren.
Zuverlässige Buchungen: Entwicklung und Betrieb prüfen Zonenausfall und den Umgang mit wiederholten Anfragen. Nachweise stehen aus.
Alle Beispiele sind erfunden. Zielwerte sind Anforderungen; erwartete Wirkungen und offene Nachweise sind ausdrücklich markiert.
Kläre Bewertungsauftrag, Geschäftsziele, Architekturstand und Beteiligte. Stelle ein erfahrenes Bewertungsteam zusammen und plane zwei Bewertungsrunden mit Zeit für Analysen dazwischen.
ATAM hilft, Architekturentscheidungen bei konkurrierenden Qualitätszielen abzuwägen. Dazu betrachtet das Team Geschäftsziele, Erwartungen der Beteiligten und technische Entscheidungen gemeinsam. Die Bewertung zeigt, welche Risiken weiter untersucht werden sollten.
Kläre mit dem Bewertungsteam den Auftrag und die Geschäftsziele. Lass das Architekturteam die wesentlichen Lösungsansätze vorstellen. Ordne Qualitätsziele und konkrete Beispielsituationen in einem Quality Attribute Utility Tree: einem Baum, der Ziele in prüfbare Szenarien aufgliedert. Analysiere die wichtigsten Szenarien technisch. Weitere Beteiligte ergänzen und priorisieren Szenarien für eine zweite Analyse. Halte Risiken, empfindliche Entscheidungspunkte und Zielkonflikte im Ergebnisbericht fest.
ATAM verbindet mehrere Termine mit Vorbereitung und technischer Analyse. Dafür braucht das Team eine verständliche Architekturbeschreibung, bekannte Geschäftsziele und Zugang zu den Verantwortlichen und betroffenen Fachleuten. Erfahrene Fachleute für Architekturbewertung untersuchen, wie einzelne Entscheidungen das erwartete Systemverhalten beeinflussen. Sensitivitätspunkte sind Stellen, an denen eine Änderung eine Qualität stark beeinflusst. Trade-off-Punkte betreffen mehrere Qualitäten und machen deren Abwägung nötig. Der Bericht hält begründete Risiken und Annahmen fest. Ergänze bei Bedarf Laufzeitmessungen, Sicherheitsprüfungen oder Codeanalysen als eigene Untersuchungen.
Vereinbare vorab, welche Entscheidungen und Systemteile bewertet werden. Besetze das Bewertungsteam und beteilige die Architekturverantwortlichen sowie die relevanten Fachleute. Beschreibe für jedes Szenario den Auslöser, die Einsatzbedingungen und die erwartete Systemreaktion. Halte fest, welche Belege jede Bewertung stützen. Eine Person kann Unterlagen und Szenarien vorbereiten. Für die vollständige Bewertung braucht es gemeinsame Prioritäten und mehrere fachliche Perspektiven. Plane Zeit für die Auswertung und die Rückmeldung der Beteiligten ein.
Die Methodenanleitung führt mit 6 Phasen, Zeitrahmen, 6 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.
Methodenanleitung öffnenDeine Einschätzung
Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.
Bereite das Gesamtvorhaben oder einen ausgewählten Analyseblock mit konkreter Frage, Unterlagen und Beteiligten vor.
Noch zu klären
Noch zu klären
Gesamtes Analysevorhaben Zeit: Mehrere Termine und Zwischenarbeit, nach Umfang zu vereinbaren
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
Beschreibe Bewertungsumfang, Architekturversion, Geschäftsziele, Rollen und Termine. Benenne auch Bereiche außerhalb des Auftrags.
...
Ordne Qualitätsziele, genauere Anforderungen und Szenarien im Utility Tree. Begründe je Szenario die geschäftliche Wichtigkeit und technische Schwierigkeit.
...
Notiere je Szenario die untersuchte Entscheidung, Begründung, Belege und Annahmen. Halte Risiken, begründet unkritische Entscheidungen (Non-Risks), Sensitivitäts- und Trade-off-Punkte fest.
...
Neue Szenarien, vertretene Perspektiven, Priorisierung und Änderungen an Analysebefunden festhalten.
...
Risikothemen, Bezug zu Geschäftszielen, Grenzen und Folgeschritte mit Verantwortung und Prüftermin dokumentieren.
...
Trage eigene Angaben, Quellen und Annahmen in die leere Vorlage ein.
SEI: Architecture Tradeoff Analysis Method
Erwartetes Artefakt: Auftrag, Ziele und Architekturstand
Zeige, welche Qualitätsanforderungen sich aus den Geschäftszielen ergeben. Benenne die Architekturansichten, die ihr noch benötigt.
Eintrag:
...
Erwartetes Artefakt: Relevante Architekturansätze
Beschreibe bei eingesetzten Produkten, wofür und wie ihr sie verwendet und welche Wirkung ihr erwartet.
Eintrag:
...
Erwartetes Artefakt: Priorisierte Qualitätsszenarien
Wichtigkeit und technische Schwierigkeit bleiben getrennte Angaben.
Eintrag:
...
Erwartetes Artefakt: Risiken, Non-Risks, Sensitivitäten und Trade-offs
Halte auch bei Non-Risks fest, für welche Bedingungen die Bewertung gilt. Benenne für offene Aussagen die noch erforderliche Prüfung.
Eintrag:
...
Erwartetes Artefakt: Ergänzte Szenarien und Befunde
Dokumentiere vertretene Perspektiven und ausgesparte Szenarien.
Eintrag:
...
Erwartetes Artefakt: Bericht mit Risikothemen und Folgeschritten
Der Bericht kann sowohl Änderungen als auch das Beibehalten einer Entscheidung begründen. Halte die daraus getroffenen Entscheidungen gesondert fest.
Eintrag:
...
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/atam/run-sheet
Passende Alternativen mit Entscheidungshilfe, danach weitere verwandte Methoden.
Wähle SAAM, um vor allem Änderbarkeit anhand konkreter Änderungsaufgaben zu bewerten.
Wähle LASR für eine erste Risikoeinschätzung im kleinen Team und die gezielte Untersuchung offener Fragen.
Sammelt Risiken direkt auf einem Architekturdiagramm und macht Priorität, Wirkung und nächste Schritte sichtbar.
Verbindet mehrere Sichten auf große Systeme und hält Cross-view-Informationen für das Gesamtbild fest.
Dokumentiert eine Architekturentscheidung mit Kontext, Alternativen und Konsequenzen, damit spätere Reviews nachvollziehbar bleiben.
Bündelt Problem, Ziele, Stakeholder und Risiken zu einem Startbild, das frühe Architekturfragen sortiert.
