Architekturreview
Ein Architekturreview prüft, ob ein Entwurf seine wichtigen Ziele unter relevanten Bedingungen erfüllt. Szenarien und Nachweise halten die Bewertung nachvollziehbar.
- FrageEin konkretes Szenario prüfen.
- NachweisBeleg statt Behauptung.
- FolgeschrittBefund führt zu Handlung.
Einordnung
Warum das wichtig ist
Ein Entwurf wirkt plausibel, bis der Fehlerfall eintritt. Ein Review prüft Ziele an konkreten Abläufen und hält fest, was belegt ist und was fehlt. Risiken werden dabei nur benannt; wie du sie festhältst, zeigt Risikolog.
Dieser Baustein strukturiert Entwurfsprüfung und Befunde. Trade-off-Analyse vergleicht Optionen; Risikolog hält Unsicherheit und Folgeschritte fest.
Auf einen Blick · Review: Ziel bis Folgeschritt
Reviewbefund für verzögerte Zahlung
Das Team verfolgt den Bestellabschluss bei einer verzögerten Zahlungsantwort. Es prüft Statusmodell, Wiederaufnahme, Datenhaltbarkeit und Betriebsindikatoren.
So liest du das Bild
- Frage Erste Spalte der Zeilen, etwa „Wie wird Doppelbelastung vermieden?“.
- Nachweis Spalte „Nachweis“: Idempotenzschlüssel und Anbieterkennung, Metrik für offene Klärungen.
- Folgeschritt Spalte „Konkreter Folgeschritt“: „Verantwortlichen und Schwellwert festlegen“.
| Aspekt | Nachweis | Bewertung des Befunds | Konkreter Folgeschritt |
|---|---|---|---|
| Was zeigt der Shop? | Statusanzeige bei fehlender Antwort | „Zahlung wird geklärt“ im Test gesehen | Test mit verspäteter Antwort ergänzen |
| Wie wird Doppelbelastung vermieden? | Idempotenzschlüssel und Anbieterkennung | Wiederholung liefert vorhandene Zahlung | Kennungswiederholung im Integrationstest prüfen |
| Wie wird Betrieb informiert? | Metrik für offene Klärungen | Alarmgrenze fehlt | Verantwortlichen und Schwellwert festlegen |
Nutzen & Grenzen
Hilft, wenn
- Schwer umkehrbare Architekturwahlen profitieren von gemeinsamer Prüfung ihrer Folgen für Fachlichkeit, Entwicklung und Betrieb.
- Veränderte Qualitätsziele oder Betriebsbefunde begründen eine gezielte Neubewertung betroffener Annahmen.
Grenzen
- Hängt die Entscheidung vom Laufzeitverhalten ab, belegen Messungen oder Tests mehr als ein Diagrammreview.
- Meinungen ohne Bezug zu Anforderungen sind schwer zu priorisieren; jeder Befund gehört zu Szenario und möglicher Folge.
- Offene Befunde brauchen einen Platz; Unsicherheiten festhalten kann der Risikolog, Entscheidungen der ADR.
In der Praxis
- Prüfungsziel und Szenarien eingrenzen. Formuliere die Entscheidung oder Veränderung und wähle wenige relevante Qualitäts- und Fehlersituationen. Halte Annahmen und Randbedingungen fest. Das Ergebnis ist ein fokussierter Reviewrahmen.
- Beteiligte und Belege zusammenführen. Lade zuständige Perspektiven ein und stelle Diagramme, Messungen und Entscheidungen bereit. Trenne bestätigte Fakten von offenen Annahmen. Damit werden Entwurf und Betriebsrealität gemeinsam beurteilt.
- Befunde in nächste Schritte überführen. Ordne Risiken nach Auswirkung und Unsicherheit und weise Besitzer sowie Prüfmethode zu. Verfolge Ergebnisse bis zur Aktualisierung der Entscheidung oder des Entwurfs. Das Ergebnis ist ein nachvollziehbarer Abschluss mit Verantwortlichem und nächster Prüfung.
Ausführliche Erklärung lesen
Ein Architekturreview untersucht, ob ein Entwurf relevante Anforderungen, Qualitätsziele und Betriebsfolgen trägt. Es betrachtet ausgewählte Szenarien und verfolgt dabei Komponenten, Daten und Zustände. Ein Review zu einer folgenreichen Architekturentscheidung ordnet Fragen und Befunde ein; Qualitätsattribute geben dafür geeignete Prüfkriterien vor.
Das Ergebnis sind priorisierte Risiken, Annahmen und konkrete Nachweise oder Maßnahmen. Diagramme unterstützen die Diskussion, ersetzen aber keine Messung oder Umsetzung. Beteiligte aus Fachlichkeit, Entwicklung und Betrieb bringen verschiedene Folgen und Erfahrungen ein. Tiefe und Formalität richten sich nach Unsicherheit und Umkehrkosten. Jeder Befund braucht eine erkennbare Auswirkung, einen Besitzer und einen nächsten Prüfschritt. Vor Beginn sollten Zweck, Umfang und benötigte Entscheidung klar sein. Nach dem Termin gehören offene Befunde in den normalen Arbeitsfluss und werden bis zu ihrem Nachweis verfolgt.
ATAM (Architecture Tradeoff Analysis Method) bewertet Architektur anhand von Qualitätsszenarien und macht Zielkonflikte und Risiken sichtbar.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welcher Befund fehlt beim Betriebshinweis zu offenen Klärungen?
Lösung mit Begründung ansehen
Die Alarmgrenze fehlt. Der Folgeschritt lautet, Verantwortlichen und Schwellwert festzulegen.
AnwendenAuf eine neue Lage übertragen
Ein Review soll prüfen, ob eine wiederholte Zahlungsanfrage zweimal belastet. Wie formulierst du die Prüfung?
Lösung mit Begründung ansehen
Prüfe im Integrationstest, dass dieselbe Kennung nur die vorhandene Zahlung liefert. Beleg ist der Idempotenzschlüssel zusammen mit der Anbieterkennung.
BewertenEine Alternative abwägen
Das Team möchte den Entwurf nur anhand der Dokumentation prüfen. Was gewinnt und was verliert es?
Lösung mit Begründung ansehen
Das geht schnell, belegt aber nur Absichten. Tests und Betriebsindikatoren zeigen, ob der Verzögerungsfall tatsächlich funktioniert, und kosten zusätzlichen Aufwand.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
LASR: Lightweight Approach for Software Reviews
LASR strukturiert ein leichtgewichtiges Review in vier Schritte: Lean Mission Statement, Evaluation Criteria, Risk-based Review und Quality-focused Analysis. Ein knappes Leitbild klärt Zweck und Systemgrenze; anschließend priorisiert das Team Qualitätsmerkmale, untersucht risikoreiche Szenarien und analysiert den Entwurf entlang dieser Kriterien.
Im Shop beschreibt das Leitbild, für wen der Shop welche Bestellungen ermöglicht. Für den Checkout priorisiert das Team zuverlässige Zahlungsabwicklung und verständliche Rückmeldungen. Es verfolgt langsame Zahlungsantworten durch den Ablauf und prüft, wie Wiederholungen gegen doppelte Belastung abgesichert sind. Bei Bedarf vertieft es einzelne Belege mit Codeanalyse oder Tests.
Zum AusprobierenFühre das Shop-Review mit den vier LASR-Schritten durch: Formuliere das Leitbild, priorisiere Checkout-Qualitäten, verfolge das größte Zahlungsrisiko und analysiere den Entwurf an diesen Kriterien. Vertiefe einen unsicheren Befund bei Bedarf mit Codeanalyse oder einem gezielten Test.
Weiterführende Bausteine
Quellen
- SEI – ATAM: Method for Architecture Evaluation (öffnet in neuem Tab)Beschreibt die szenariobasierte Bewertung von Qualitätszielen, Risiken und Zielkonflikten.
- arc42 – Quality scenarios for architecture evaluation (öffnet in neuem Tab)Zeigt, wie Qualitätsszenarien Architekturreviews strukturieren und Risiken sichtbar machen.
- AWS – Well-Architected Framework Review Process (öffnet in neuem Tab)Beschreibt einen wiederholbaren Reviewprozess mit Maßnahmen aus erkannten Risiken.
- LASR · Lightweight Approach for Software Reviews (öffnet in neuem Tab)Vier Schritte vom Systemleitbild über Kriterien und Risiken zur qualitätsorientierten Analyse.