Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
Was vorher fertig sein muss
Komponenten, Schnittstellen und Abhängigkeiten sind für den betrachteten Systembereich beschrieben. Bei bestehenden Systemen ist erkennbar, welche Angaben mit Code oder Systemkundigen abgeglichen wurden.
Die Analysefrage ist mit Produktverantwortlichen und Fachbereich abgestimmt. Die Beteiligten können typische Nutzungs- und Änderungsanforderungen benennen.
Mindestens eine fachkundige Person kann Komponenten, Schnittstellen und Änderungsfolgen beurteilen. Systemkundige Entwickler sowie Menschen aus Produkt und Fachbereich stehen für Rückfragen zur Verfügung.
Was vor Start vorliegen muss
Architekturunterlagen mit Versionsstand, Ziele für die Weiterentwicklung, Prüffälle, Befundprotokoll und verwendete Quellen.
Eine Person mit Erfahrung in Architekturanalyse; Entwickler mit Systemkenntnis; Produkt- und Fachverantwortliche für die Auswahl der Aufgaben. Moderation und Protokoll nach Bedarf ergänzen. Eine Fachperson kann die Analyse allein vorbereiten und durchführen. Auswahl, Gewichtung und zentrale Annahmen werden anschließend mit den Betroffenen abgeglichen; bis dahin gelten die Ergebnisse als Ersteinschätzung.
Kläre die Analysefrage und den betrachteten Fachbereich. Sammle Architekturunterlagen und stimme relevante Änderungsaufgaben mit Menschen ab, die das System und seine Nutzung kennen.
Plane Vorbereitung, die Abstimmung der Prüffälle, einen oder mehrere Analyseblöcke und die Ergebnisbesprechung. Anzahl und Schwierigkeit der Aufgaben sowie die vorhandenen Unterlagen bestimmen den Zeitbedarf. Die Zeitangabe für einen einzelnen Schritt betrifft den gewählten Arbeitsblock.
Eine gemeinsame Dokumentstruktur mit stabilen Szenario- und Befund-IDs anlegen. Fakten, Annahmen, technische Nachweise und Entscheidungen getrennt kennzeichnen.
Die eine Frage, die diese Methode beantwortet
Welche Änderungen erfordern unsere geplanten Aufgaben, und wie unterscheiden sich die Architekturvarianten dabei?
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
SAAM zeigt, welche Teile eines Systems bei einer geplanten Änderung angepasst werden müssten. Die Methode ordnet fachliche Aufgaben den zuständigen Komponenten zu, bewertet konkrete Änderungsfolgen und ermöglicht den Vergleich von Architekturalternativen auf derselben Grundlage.
Fiktives Lehrbeispiel
Dokumentiere die fachlichen Funktionen, betroffenen Komponenten und bewerteten Änderungsfolgen.
Beschreibe die Analysefrage, Systemgrenze und Ziele für die Weiterentwicklung. Liste die fachlichen Funktionen als gemeinsame Grundlage auf.
Weitere Versanddienstleister anbinden; Auftrag vorbereiten, Versand buchen, Status zuordnen.
Beschreibe Komponenten und Verbindungen je Variante. Ordne ihnen die fachlichen Funktionen zu und nenne Quellen sowie noch benötigte Informationen.
A: Das Auftragsmodul ruft Dienstleister direkt auf. B: Adapter übernehmen die Kommunikation und übersetzen Statuscodes. Die gemeinsame Schnittstelle ist noch zu prüfen.
Benenne die relevanten Qualitätsziele. Erkläre, nach welchen Kriterien ihr sie beurteilt und welche Aussagen diese Kriterien ermöglichen.
Änderbarkeit: betroffene Komponenten und Schnittstellen sowie nötige Tests. Der Aufwand wird später geschätzt.
Konkrete Aufgaben, Kontext, gewünschtes Ergebnis, Priorität und Auswahlbegründung erfassen.
T1: zweiten Paketdienst hinzufügen. T2: Sammelsendungen mit mehreren Paketnummern. Beide aus fiktiver Wachstumsplanung.
Halte je Aufgabe und Variante die erforderlichen Änderungen, Belege, Annahmen und Bewertung fest. Vereinbare nächste Schritte und Zuständigkeiten.
Bei passender Schnittstelle betrifft T1 in B den neuen Adapter und die Statusübersetzung. T2 erfordert in beiden Varianten weitere Anpassungen. Die Entwicklung prüft Schnittstelle und Tests.
Das Beispiel ist fiktiv. Es zeigt mögliche Änderungsfolgen; offene Annahmen und noch ausstehende Prüfungen sind gekennzeichnet.
Funktionen
Ziel
Einen gemeinsamen Bezugsrahmen für die Analyse schaffen.
Voraussetzungen für diesen Schritt
Durchführung
Ergebnis
Gemeinsame Liste fachlicher Funktionen
Funktionen beschreiben Aufgaben; Komponenten werden im nächsten Schritt zugeordnet.
Qualitätscheck
Beschreiben die Funktionen fachliche Aufgaben unabhängig von bestimmten Produkten? Ist sie für alle Varianten gleich verständlich?
Stolperfalle
Funktionen spiegeln nur die Module der bevorzugten Lösung. Formuliere die fachlichen Aufgaben unabhängig von der technischen Lösung und stimme sie mit Fachleuten aus dem Anwendungsbereich ab.
Zeitlicher Rahmen: Vorbereitung und fachliche Abstimmung; Zeitbedarf anhand der vorhandenen Unterlagen planen.
Zuordnung
Ziel
Architekturen auf derselben Beschreibungsebene verstehen.
Voraussetzungen für diesen Schritt
Durchführung
Ergebnis
Funktionen und zuständige Komponenten
Beschreibe zu jeder Komponente ihre Aufgabe und Verbindungen. Damit könnt ihr später den Weg einer Änderung nachvollziehen.
Qualitätscheck
Sind alle relevanten Funktionen zugeordnet? Sind Varianten gleich tief beschrieben?
Stolperfalle
Eine Variante erscheint einfacher, weil ihre Details fehlen. Beschreibe die Varianten in vergleichbarer Tiefe und benenne Informationen, die ihr für den Vergleich noch benötigt.
Zeitlicher Rahmen: Dokumentenanalyse und Architekturabgleich; nötige Rekonstruktion separat.
Qualitäten
Ziel
Bewertung auf fachlich relevante Kriterien ausrichten.
Voraussetzungen für diesen Schritt
Durchführung
Ergebnis
Qualitätsziele und Bewertungskriterien
Die Anzahl betroffener Komponenten zeigt, wie weit eine Änderung reicht. Für eine Aufwandsschätzung braucht ihr zusätzlich Angaben zu Umsetzung und Tests.
Qualitätscheck
Passen die Kriterien zu den Zielen für Nutzung und Weiterentwicklung? Sind strukturelle Hinweise und Aufwandsschätzungen getrennt?
Stolperfalle
Die Bewertung reduziert Qualität auf möglichst wenige Komponenten. Berücksichtige auch Zuständigkeiten, Schnittstellen, erforderliche Tests und die Sicherheit eurer Einschätzung.
Zeitlicher Rahmen: Gemeinsamer Kriterienabgleich vor der Aufgabenanalyse.
Aufgaben
Ziel
Begründen, welche Prüffälle die wichtigen Anforderungen abdecken.
Voraussetzungen für diesen Schritt
Durchführung
Ergebnis
Begründete Auswahl von Prüffällen
Beschreibe zuerst die gewünschte Änderung. Halte mögliche technische Lösungen als Optionen für die anschließende Analyse fest.
Qualitätscheck
Sind die Aufgaben konkret genug, um die betroffenen Komponenten Schritt für Schritt durchzugehen? Ist die Auswahl mit Menschen aus den betroffenen Bereichen abgestimmt?
Stolperfalle
Nur leicht unterstützte Aufgaben werden ausgewählt. Nimm wahrscheinliche und anspruchsvolle Änderungen auf und dokumentiere die Auswahlbegründung.
Zeitlicher Rahmen: Aufgabenabgleich mit Betroffenen; zusätzliche Interviews bei Wissenslücken.
Bewertung
Ziel
Die Eignung der Architektur anhand konkreter Änderungsfolgen begründen.
Voraussetzungen für diesen Schritt
Durchführung
Ergebnis
Bewertung und Änderungsfolgen
Die Analyse zeigt, welche Änderungen die Architektur voraussichtlich erfordert. Ergänzende Untersuchungen klären Codequalität, genauen Aufwand und tatsächliches Laufzeitverhalten.
Qualitätscheck
Lässt sich jede Bewertung anhand der betroffenen Komponenten und ihrer Quellen nachvollziehen? Sind Annahmen und ungeprüfte Folgen sichtbar?
Stolperfalle
Eine qualitative Einschätzung wird als verbindlicher Implementierungsaufwand weitergegeben. Kennzeichne die Schätzgrundlage und lasse ausführende Personen Aufwand, Tests und Migration separat prüfen.
Zeitlicher Rahmen: Analyseblöcke mit Ergebnisabgleich; technische Nachweise gesondert planen.
Was am Ende rauskommt
Ein Analysebericht mit Versionsstand: Fragestellung, Architekturvarianten, Prüffälle, Änderungsfolgen, Belege und nächste Schritte mit Zuständigkeiten.
Halte Architekturversion, Datum, Beteiligte und verwendete Belege je Bewertung fest. Kennzeichne überholte Befunde und bewahre frühere Versionen auf.
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 die Analysefrage, Systemgrenze und Ziele für die Weiterentwicklung. Liste die fachlichen Funktionen als gemeinsame Grundlage auf.
...
Beschreibe Komponenten und Verbindungen je Variante. Ordne ihnen die fachlichen Funktionen zu und nenne Quellen sowie noch benötigte Informationen.
...
Benenne die relevanten Qualitätsziele. Erkläre, nach welchen Kriterien ihr sie beurteilt und welche Aussagen diese Kriterien ermöglichen.
...
Konkrete Aufgaben, Kontext, gewünschtes Ergebnis, Priorität und Auswahlbegründung erfassen.
...
Halte je Aufgabe und Variante die erforderlichen Änderungen, Belege, Annahmen und Bewertung fest. Vereinbare nächste Schritte und Zuständigkeiten.
...
Trage eigene Angaben, Quellen und Annahmen in die leere Vorlage ein.
SEI: Software Architecture Analysis Method
Erwartetes Artefakt: Gemeinsame Liste fachlicher Funktionen
Funktionen beschreiben Aufgaben; Komponenten werden im nächsten Schritt zugeordnet.
Eintrag:
...
Erwartetes Artefakt: Funktionen und zuständige Komponenten
Beschreibe zu jeder Komponente ihre Aufgabe und Verbindungen. Damit könnt ihr später den Weg einer Änderung nachvollziehen.
Eintrag:
...
Erwartetes Artefakt: Qualitätsziele und Bewertungskriterien
Die Anzahl betroffener Komponenten zeigt, wie weit eine Änderung reicht. Für eine Aufwandsschätzung braucht ihr zusätzlich Angaben zu Umsetzung und Tests.
Eintrag:
...
Erwartetes Artefakt: Begründete Auswahl von Prüffällen
Beschreibe zuerst die gewünschte Änderung. Halte mögliche technische Lösungen als Optionen für die anschließende Analyse fest.
Eintrag:
...
Erwartetes Artefakt: Bewertung und Änderungsfolgen
Die Analyse zeigt, welche Änderungen die Architektur voraussichtlich erfordert. Ergänzende Untersuchungen klären Codequalität, genauen Aufwand und tatsächliches Laufzeitverhalten.
Eintrag:
...
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/saam/run-sheet
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
Konkret gefülltes Szenario, fiktives Beispiel
Ein Händler möchte weitere Versanddienstleister anbinden. Die Software erfüllt drei fachliche Aufgaben: Auftrag vorbereiten, Versand buchen und Lieferstatus zuordnen.
Variante A: Das Auftragsmodul ruft die Dienstleister direkt auf und verarbeitet deren Statuscodes. Variante B: Je Dienstleister übernimmt ein Adapter die Kommunikation. Eine Übersetzung ordnet die externen Statuscodes den internen Lieferzuständen zu.
Aufgabe T1: Einen zweiten Dienstleister für Standardpakete hinzufügen. Bei A müssen Auftragsmodul und Statusverarbeitung angepasst werden. Bei B könnten ein neuer Adapter und eine zusätzliche Statusübersetzung genügen. Dafür muss die gemeinsame Schnittstelle auch zum neuen Dienstleister passen; das ist noch zu prüfen.
Aufgabe T2: Sammelsendungen mit mehreren Paketnummern unterstützen. Beide Varianten brauchen dafür Anpassungen am Auftragsmodell und an der Statuszuordnung.
Bewertung: Für T1 kann Variante B die Änderungen auf den neuen Adapter und die Statusübersetzung begrenzen. Diese Einschätzung gilt unter der Annahme, dass die gemeinsame Schnittstelle passt. T2 betrifft bei beiden Varianten weitere Komponenten. Aufwand und Risiken der Umstellung untersucht das Team gesondert.
Nächster Schritt: Die Entwicklung prüft die gemeinsame Schnittstelle an einem Beispiel des neuen Dienstleisters und aktualisiert die Architekturübersicht. Das gesamte Beispiel einschließlich aller Befunde ist fiktiv.
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
Funktionen spiegeln nur die Module der bevorzugten Lösung.
Formuliere die fachlichen Aufgaben unabhängig von der technischen Lösung und stimme sie mit Fachleuten aus dem Anwendungsbereich ab.
Eine Variante erscheint einfacher, weil ihre Details fehlen.
Beschreibe die Varianten in vergleichbarer Tiefe und benenne Informationen, die ihr für den Vergleich noch benötigt.
Die Bewertung reduziert Qualität auf möglichst wenige Komponenten.
Berücksichtige auch Zuständigkeiten, Schnittstellen, erforderliche Tests und die Sicherheit eurer Einschätzung.
Nur leicht unterstützte Aufgaben werden ausgewählt.
Nimm wahrscheinliche und anspruchsvolle Änderungen auf und dokumentiere die Auswahlbegründung.
Eine qualitative Einschätzung wird als verbindlicher Implementierungsaufwand weitergegeben.
Kennzeichne die Schätzgrundlage und lasse ausführende Personen Aufwand, Tests und Migration separat prüfen.
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.
