Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
Risk Storming
Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
Vorbedingung
Was vorher fertig sein muss
Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog
Vorbereitung
Was vor Start vorliegen muss
Aktuelle C4-/Architekturdiagramme, Qualitätsziele und Constraints, Risiko-Stickies, Evidenz, Maßnahmen- und Entscheidungslog
Architecture/Tech Lead · Entwickler:innen · Operations/Security · Domain/Product · Facilitator · Risk Owner
Architekturgrenze, aktuelle Diagrammversion, Qualitätsziele und betrachteten Betriebszustand festlegen; notwendige Perspektiven einladen.
90–150 Minuten für eine Architekturansicht; Maßnahmenverfolgung separat.
Arbeitsfläche mit Kontext · Allein · Teilen · Einordnen · Behandeln · Review vorbereiten; Beispiel und eigene Daten trennen.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche konkreten Ausfallszenarien sitzen wo in der Architektur, welche sind gemeinsam wesentlich, und wie reduzieren oder prüfen wir sie?
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
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.
Risk Storming · Arbeitsstruktur
Fiktives Beispiel
Fiktive Werte zeigen die tatsächlichen Fachfelder.
| Risiko | Ort | Szenario | Qualitätsziel | Evidenz | Exposition | Behandlung | Owner/Review |
|---|---|---|---|---|---|---|---|
| R1 · Payment-LatenzEvidenz und Begründung ergänzen. | Payment API → Checkout-Pool | API langsam → Threads warten → Pool erschöpft → Abholung fällt aus | Verfügbarkeit; p80-Wartezeit | Lasttest: Pool95 %, Fehler 8 % | Hoch | Pool trennen; GameDay ≤5 % | Noor · 15.11. |
| R2 · Retry-SturmEvidenz und Begründung ergänzen. | Checkout → Payment API | Timeout → ungebremste Retries → Fremdsystem überlastet | Resilienz; Partnerlimit | Retry-Limit ungetestet | Mittel/unklar | Retry-Budget und Chaos-Test | Lea · 22.11. |
1. Ort
- R1 · Payment-Latenz
- Payment API → Checkout-Pool
- R2 · Retry-Sturm
- Checkout → Payment API
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. Qualitätsziel
- R1 · Payment-Latenz
- Verfügbarkeit; p80-Wartezeit
- R2 · Retry-Sturm
- Resilienz; Partnerlimit
4. Evidenz
- R1 · Payment-Latenz
- Lasttest: Pool95 %, Fehler 8 %
- R2 · Retry-Sturm
- Retry-Limit ungetestet
5. Exposition
- R1 · Payment-Latenz
- Hoch
- R2 · Retry-Sturm
- Mittel/unklar
6. Behandlung
- R1 · Payment-Latenz
- Pool trennen; GameDay ≤5 %
- R2 · Retry-Sturm
- Retry-Budget und Chaos-Test
7. Owner/Review
- R1 · Payment-Latenz
- Noor · 15.11.
- R2 · Retry-Sturm
- Lea · 22.11.
Alle Werte sind fiktiv.
- 1
Kontext
Geteilte Karte

Ziel
Geteilte Karte: Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.
Voraussetzungen für diesen Schritt
- 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
Durchführung
- Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.
Ergebnis
Geteilte Karte
Diagramm, Scope, Qualitätsziele und Annahmen gemeinsam lesen; Verständnisfragen schließen.
Qualitätscheck
Verstehen alle Elemente, Beziehungen und kritischen Qualitätsziele gleich?
Stolperfalle
Risiken werden auf einem veralteten oder unverständlichen Diagramm gesammelt. Version und offene Modelllücken markieren, bevor Risiken entstehen.
Zeitlicher Rahmen: 15–25 Minuten
- 2
Allein
Risikostickies

Ziel
Risikostickies: Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.
Voraussetzungen für diesen Schritt
- Geteilte Karte
Durchführung
- Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.
Ergebnis
Risikostickies
Jede Person identifiziert still konkrete Risikoszenarien und verortet sie an Element oder Beziehung.
Qualitätscheck
Enthält jeder Hinweis Auslöser, Ereignis und Auswirkung?
Stolperfalle
Stickies lauten nur ‚Security‘ oder ‚Datenbank‘. Szenario als Ursache → Ereignis → Wirkung formulieren.
Zeitlicher Rahmen: 15–25 Minuten
- 3
Teilen
Risikocluster

Ziel
Risikocluster: Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.
Voraussetzungen für diesen Schritt
- Risikostickies
Durchführung
- Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.
Ergebnis
Risikocluster
Hinweise nacheinander erklären, Duplikate clustern und unterschiedliche Perspektiven erhalten.
Qualitätscheck
Bleiben unabhängige Szenarien getrennt und gemeinsame Ursachen sichtbar?
Stolperfalle
Mehrheitsmeinung löscht seltene Fachperspektive. Duplikat nur bei gleichem Trigger, Pfad und Impact zusammenführen.
Zeitlicher Rahmen: 20–30 Minuten
- 4
Einordnen
Prioritätsbild

Ziel
Prioritätsbild: Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.
Voraussetzungen für diesen Schritt
- Risikocluster
Durchführung
- Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.
Ergebnis
Prioritätsbild
Exposition qualitativ aus plausibler Eintrittslage und Konsequenz begründen; Evidenz und Unbekanntes markieren.
Qualitätscheck
Ist hohe Exposition mit Szenario und Evidenz begründet statt aus Punkten errechnet?
Stolperfalle
Erfundene 1–5-Scores erzeugen Scheingenauigkeit. Kategorien mit konkreter Evidenz, Unsicherheit und roten Linien begründen.
Zeitlicher Rahmen: 15–25 Minuten
- 5
Behandeln
Behandlungsplan

Ziel
Behandlungsplan: Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.
Voraussetzungen für diesen Schritt
- Prioritätsbild
Durchführung
- Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.
Ergebnis
Behandlungsplan
Für wesentliche Risiken vermeiden, reduzieren, übertragen oder akzeptieren; Experiment/ADR und Owner setzen.
Qualitätscheck
Hat jede Maßnahme erwartete Risikowirkung und Nachweis?
Stolperfalle
‚Monitoring ergänzen‘ gilt ohne Signal und Reaktion als Lösung. Kontrolle, Messsignal, Stopregel und Verantwortliche konkretisieren.
Zeitlicher Rahmen: 15–25 Minuten
- 6
Review
Risikoentscheid

Ziel
Risikoentscheid: Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.
Voraussetzungen für diesen Schritt
- Behandlungsplan
Durchführung
- Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.
Ergebnis
Risikoentscheid
Rest-Risiko abnehmen, Diagramm/ADR aktualisieren und Trigger für erneutes Risk Storming festlegen.
Qualitätscheck
Ist Akzeptanz durch befugten Owner und mit Reviewdatum dokumentiert?
Stolperfalle
Risikoliste verschwindet nach dem Workshop. Register verlinken und bei Architektur-, Last- oder Incidentänderung neu prüfen.
Zeitlicher Rahmen: 10–20 Minuten
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
Annotierte Architektur-Risikokarte mit Szenarien, betroffenen Elementen/Beziehungen, Evidenz, qualitativer Exposition, Maßnahmen, Ownern und Review.
Datum, Team, Datenstand und Reviewtermin führen; frühere Fassungen erhalten.
- Aktuelles Architekturdiagramm
- Risiko-Stickies je Perspektive
- Risiko- und Maßnahmenregister
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
| Risiko | Ort | Szenario | Qualitätsziel | Evidenz | Exposition | Behandlung | Owner/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
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
risk-storming-beispiel.md
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Lehrbeispiel: Risk Storming · Arbeitsstruktur
| Risiko | Ort | Szenario | Qualitätsziel | Evidenz | Exposition | Behandlung | Owner/Review |
|---|---|---|---|---|---|---|---|
| R1 · Payment-Latenz | Payment API → Checkout-Pool | API langsam → Threads warten → Pool erschöpft → Abholung fällt aus | Verfügbarkeit; p80-Wartezeit | Lasttest: Pool95 %, Fehler 8 % | Hoch | Pool trennen; GameDay ≤5 % | Noor · 15.11. |
| R2 · Retry-Sturm | Checkout → Payment API | Timeout → ungebremste Retries → Fremdsystem überlastet | Resilienz; Partnerlimit | Retry-Limit ungetestet | Mittel/unklar | Retry-Budget und Chaos-Test | Lea · 22.11. |
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Geteilte KarteRisiken werden auf einem veralteten oder unverständlichen Diagramm gesammelt.In der Phase ansehen
- RisikostickiesStickies lauten nur ‚Security‘ oder ‚Datenbank‘.In der Phase ansehen
- RisikoclusterMehrheitsmeinung löscht seltene Fachperspektive.In der Phase ansehen
- PrioritätsbildErfundene 1–5-Scores erzeugen Scheingenauigkeit.In der Phase ansehen
- Behandlungsplan‚Monitoring ergänzen‘ gilt ohne Signal und Reaktion als Lösung.In der Phase ansehen
- RisikoentscheidRisikoliste verschwindet nach dem Workshop.In der Phase ansehen
Geteilte Karte
Risiken werden auf einem veralteten oder unverständlichen Diagramm gesammelt.
Version und offene Modelllücken markieren, bevor Risiken entstehen.
Risikostickies
Stickies lauten nur ‚Security‘ oder ‚Datenbank‘.
Szenario als Ursache → Ereignis → Wirkung formulieren.
Risikocluster
Mehrheitsmeinung löscht seltene Fachperspektive.
Duplikat nur bei gleichem Trigger, Pfad und Impact zusammenführen.
Prioritätsbild
Erfundene 1–5-Scores erzeugen Scheingenauigkeit.
Kategorien mit konkreter Evidenz, Unsicherheit und roten Linien begründen.
Behandlungsplan
‚Monitoring ergänzen‘ gilt ohne Signal und Reaktion als Lösung.
Kontrolle, Messsignal, Stopregel und Verantwortliche konkretisieren.
Risikoentscheid
Risikoliste verschwindet nach dem Workshop.
Register verlinken und bei Architektur-, Last- oder Incidentänderung neu prüfen.
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

