methodatlas

Architecture Workshop-Methode

Risk Storming

Sammelt Risiken direkt auf einem Architekturdiagramm und macht Priorität, Wirkung und nächste Schritte sichtbar.

Das Team platziert das Architekturbild zentral und sammelt Risiken in einer stillen Phase. Danach werden die Karten geclustert, priorisiert und mit Ownern oder nächsten Schritten versehen. So entsteht aus einem Review ein konkreter Maßnahmenplan rund um die Architektur.

Kernfrage
Welche konkreten Ausfallszenarien sitzen wo in der Architektur, welche sind gemeinsam wesentlich, und wie reduzieren oder prüfen wir sie?
Risk Storming planenMethodenanleitung
Vergleich starten
Feedback gebenHilft dir diese Methode?
Teilnehmende
4-12
Zeit
90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.

Die Schritte bilden einen vollständigen methodischen Durchlauf.

Papierillustration zu Risk Storming.

  1. Kontext

    Geteilte Karte

    Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.

  2. Allein

    Risikostickies

    Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.

  3. Teilen

    Risikocluster

    Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.

  4. Einordnen

    Prioritätsbild

    Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.

  5. Behandeln

    Behandlungsplan

    Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.

  6. Review

    Risikoentscheid

    Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.

Neue Evidenz im Review ergänzen und Schätzungen samt früherem Stand versionieren.

Geeignet, wenn

Risk Storming macht Risiken direkt am Architekturartefakt sichtbar und verbindet sie mit Priorität und Handlungsbedarf. Es eignet sich für frühe Reviews, wenn Unsicherheiten neben der Struktur stehen sollen.

Ideal für

  • Architekturreview
  • Technische Roadmap-Risiken
  • Cross-Team-Plan-Check

Nicht gut für

  • Sehr frühe Discovery
  • Reines Brainstorming ohne Artefakt

Ergebnisse

  • Risikoentscheid

    Annotierte Architektur-Risikokarte mit Szenarien, betroffenen Elementen/Beziehungen, Evidenz, qualitativer Exposition, Maßnahmen, Ownern und Review.

Risk Storming · Arbeitsstruktur

Fiktives Beispiel

Fiktive Werte zeigen die tatsächlichen Fachfelder.

Risk Storming · Arbeitsstruktur
RisikoOrtSzenarioQualitätszielEvidenzExpositionBehandlungOwner/Review
R1 · Payment-LatenzEvidenz und Begründung ergänzen.Payment API → Checkout-PoolAPI langsam → Threads warten → Pool erschöpft → Abholung fällt ausVerfügbarkeit; p80-WartezeitLasttest: Pool95 %, Fehler 8 %HochPool trennen; GameDay ≤5 %Noor · 15.11.
R2 · Retry-SturmEvidenz und Begründung ergänzen.Checkout → Payment APITimeout → ungebremste Retries → Fremdsystem überlastetResilienz; PartnerlimitRetry-Limit ungetestetMittel/unklarRetry-Budget und Chaos-TestLea · 22.11.

  1. 1. Ort

    R1 · Payment-Latenz
    Payment API → Checkout-Pool
    R2 · Retry-Sturm
    Checkout → Payment API

  2. 2. Szenario

    R1 · Payment-Latenz
    API langsam → Threads warten → Pool erschöpft → Abholung fällt aus
    R2 · Retry-Sturm
    Timeout → ungebremste Retries → Fremdsystem überlastet

  3. 3. Qualitätsziel

    R1 · Payment-Latenz
    Verfügbarkeit; p80-Wartezeit
    R2 · Retry-Sturm
    Resilienz; Partnerlimit

  4. 4. Evidenz

    R1 · Payment-Latenz
    Lasttest: Pool95 %, Fehler 8 %
    R2 · Retry-Sturm
    Retry-Limit ungetestet

  5. 5. Exposition

    R1 · Payment-Latenz
    Hoch
    R2 · Retry-Sturm
    Mittel/unklar

  6. 6. Behandlung

    R1 · Payment-Latenz
    Pool trennen; GameDay ≤5 %
    R2 · Retry-Sturm
    Retry-Budget und Chaos-Test

  7. 7. Owner/Review

    R1 · Payment-Latenz
    Noor · 15.11.
    R2 · Retry-Sturm
    Lea · 22.11.

Alle Werte sind fiktiv.

Fachquelle · eigene Lehrdarstellung

Erster Schritt

Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.

Zur Methodenanleitung

Davor sinnvoll

Papierillustration zu C4 Model mit den zentralen Arbeitsschritten und einem sichtbaren Ergebnis.
Architecture
C4 Model

Liefert das aktuelle Architekturdiagramm, auf dem Risiken direkt markiert werden.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.
Architecture
Architecture Decision Record

Dokumentiert die abgenommene Risikoentscheidung und Diagrammänderung als Architekturentscheidung.

Papierillustration für RAID Log mit fachlich beschrifteter Arbeitsfläche.
Delivery
RAID Log

Überführt verbleibende Risiken und Trigger in ein laufendes Risikoregister.

Vertiefung

Zweck

Risk Storming macht Risiken direkt am Architekturartefakt sichtbar und verbindet sie mit Priorität und Handlungsbedarf. Es eignet sich für frühe Reviews, wenn Unsicherheiten neben der Struktur stehen sollen.

Funktionsweise

Das Team platziert das Architekturbild zentral und sammelt Risiken in einer stillen Phase. Danach werden die Karten geclustert, priorisiert und mit Ownern oder nächsten Schritten versehen. So entsteht aus einem Review ein konkreter Maßnahmenplan rund um die Architektur.

Im Detail

Risk Storming hilft, weil Risiken direkt an Abläufen, Datenflüssen und Systemstellen verortet werden und dadurch greifbarer werden als in losen Listen. Gute Anwendung verbindet Gefahr, Auswirkung und möglicher Schutzmaßnahme eng mit dem realen Entwurf. So entstehen fruchtbare Gespräche über Schwachstellen und Prioritäten, bevor Sicherheits oder Zuverlässigkeitsfragen zu spät entdeckt werden.

Durchführung

Bereite eine einfache Darstellung des relevanten Flows oder der betroffenen Architekturzone vor, damit Risiken an etwas Konkretem diskutiert werden. Besonders klärend ist die Stelle, an der ein kleiner Systemschritt unerwartet viele Angriffs oder Ausfallfolgen bündelt. Am Ende stehen wenige priorisierte Risiken, klaren Gegenmaßnahmen und offener Unsicherheit für spätere Vertiefung.

Die Methodenanleitung führt mit 6 Phasen, Zeitrahmen, 6 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen
RisikoArchitekturWorkshopValidierung
Quellen
Risk Stormingsimonbrown.jeWorkshop-Seite von Simon Brown, Schöpfer des C4-Modells; nennt Risk Storming als Technik seines Architektur-Workshops.
In Playbooks
Architekturqualität vor Umsetzung absichernVon den Leitplanken einer Architekturinitiative über priorisierte Qualitätsszenarien zu einer zur Diskussion gestellten Lösung.
Artefakt-Vorlagen
Risk Storming: ArbeitsvorlageGegenstand, Daten, Rollen, Ablauf und Review festlegen.
markdown

risk-storming-working-template.md

Gegenstand, Daten, Rollen, Ablauf und Review festlegen.

Risk Storming: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständiger Durchlauf Zeit: 90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

  • Materialien: Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog
  • Rollen: Architecture/Tech Lead · Entwickler:innen · Operations/Security · Domain/Product · Facilitator · Risk Owner
  • Vorab-Infos: Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
  • Gesamter Zeitbedarf: 90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.
  • Setup: Arbeitsfläche mit Kontext · Allein · Teilen · Einordnen · Behandeln · Review vorbereiten; Beispiel und eigene Daten trennen.

Für die Arbeitsschritte bereitstellen

Kontext: Geteilte Karte

  • Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
  • Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog

Allein: Risikostickies

  • Geteilte Karte

Teilen: Risikocluster

  • Risikostickies

Einordnen: Prioritätsbild

  • Risikocluster

Behandeln: Behandlungsplan

  • Prioritätsbild

Review: Risikoentscheid

  • Behandlungsplan

Risk Storming · Arbeitsstruktur

RisikoOrtSzenarioQualitätszielEvidenzExpositionBehandlungOwner/Review
R1 · Payment-Latenz
R2 · Retry-Sturm
  • R1 · Payment-Latenz: Evidenz und Begründung ergänzen.
  • R2 · Retry-Sturm: Evidenz und Begründung ergänzen.

Die leere Vorlage enthält nur Arbeitsimpulse.

Fachquelle · eigene Lehrdarstellung

Kontext: Geteilte Karte

Erwartetes Artefakt: Geteilte Karte

Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.

Eintrag:

...

  • Verstehen alle Elemente, Beziehungen und kritischen Qualitätsziele gleich?

Allein: Risikostickies

Erwartetes Artefakt: Risikostickies

Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.

Eintrag:

...

  • Enthält jeder Hinweis Auslöser, Ereignis und Auswirkung?

Teilen: Risikocluster

Erwartetes Artefakt: Risikocluster

Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.

Eintrag:

...

  • Bleiben unabhängige Szenarien getrennt und gemeinsame Ursachen sichtbar?

Einordnen: Prioritätsbild

Erwartetes Artefakt: Prioritätsbild

Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.

Eintrag:

...

  • Ist hohe Exposition mit Szenario und Evidenz begründet statt aus Punkten errechnet?

Behandeln: Behandlungsplan

Erwartetes Artefakt: Behandlungsplan

Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.

Eintrag:

...

  • Hat jede Maßnahme erwartete Risikowirkung und Nachweis?

Review: Risikoentscheid

Erwartetes Artefakt: Risikoentscheid

Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.

Eintrag:

...

  • Ist Akzeptanz durch befugten Owner und mit Reviewdatum dokumentiert?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/risk-storming/run-sheet

Alternativen und Nachbarn

Passende Alternativen mit Entscheidungshilfe, danach weitere verwandte Methoden.

Alle Methoden
Ein hypothetisches Scheitern macht konkrete Risiken, Frühwarnsignale und passende Maßnahmen sichtbar.
Decision Making
Pre-Mortem

Statt Risk Storming, wenn du vorab aus dem Scheitern heraus denken und Risiken früh sichtbar machen willst.

Papierillustration zu Failure Mode and Effects Analysis
Operations
Failure Mode and Effects Analysis

Statt Risk Storming, wenn du Fehlerarten, Wirkungen und Vorbeugung systematisch vorab durchdenken willst.

Papierillustration: Szenarien und Architekturentscheidungen sind mit den erkannten Risiken verbunden.
Architecture
ATAM (Architecture Tradeoff Analysis Method)

Prüft, wie Architekturentscheidungen wichtige Qualitätsziele unterstützen, und macht Risiken und Zielkonflikte sichtbar.

Vier Papierstationen verbinden Systemzweck, Qualitätsziele, Risikokarten und eine vertiefte Untersuchung mit einem Ziel- und Lückenprofil.
Architecture
LASR (Lightweight Approach for Software Reviews)

Hilft einem kleinen Team, die wichtigsten Qualitätsrisiken seiner Software einzuschätzen und gezielt weiter zu untersuchen.

Papierillustration der Methode Architecture Inception Canvas mit einer klaren Arbeitsstruktur.
Architecture
Architecture Inception Canvas

Bündelt Problem, Ziele, Stakeholder und Risiken zu einem Startbild, das frühe Architekturfragen sortiert.

Papierillustration von Request for Comments (RFC) mit dem methodenspezifischen Arbeitsmodell.
Architecture
Request for Comments

Bereitet größere Änderungen mit Motivation, Lösung, Alternativen und offenen Fragen revisionsfest auf.

Rahmenbedingungen und Herkunft
NiedrigWorkshop60-90 min

Steckbrief

Methodenform
Workshop-Methode
Teilnehmende
4-12
Zeit
60-90 min
Reifegrad
Established
Ursprung
Agile Community
Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.
Als Nächstes: Architecture Decision Record