What it is
After confirming the product strategy and prioritizing the architecture characteristics, it’s time to look at the system’s design and ask: what could go wrong here? Risk-storming answers that question collectively. Instead of relying on a single architect’s intuition, the technique gathers the whole team (engineering, product, security, operations) in front of the application’s diagrams to identify risks independently and then consolidate them.
The outcome is not a risk document aging in a wiki. It is a living list, prioritized by impact and probability, that feeds directly into the architectural stories of the next stage.
The risk-storming technique was created by Simon Brown and is documented at RiskStorming.com. AARM incorporates it as the third stage of the cycle, connected to business strategy.
How to facilitate the session
-
Use the application’s architecture diagrams
Use one or more (C4) diagrams to show what you are planning to build or change. The diagram is the map on which risks will be pinned.
-
Identify risks individually
Gather people in front of the diagrams and ask them to identify, in silence, what they personally consider risky. Each risk goes on a sticky note, color-coded according to the prioritization matrix.
-
Pin the risks on the diagrams
Ask everyone to place their sticky notes on the diagrams, right next to the area where the risk was identified. Clusters of notes reveal the architecture’s hot spots.
-
Review and summarize the risks
Consolidate the result, paying special attention to the risks only one person identified, and to those where the group disagrees on priority. That is where the most valuable conversations live.
Prioritization matrix
Each risk gets an impact score and a probability score, from 1 to 3. The product of the two defines the priority, and the sticky note’s color in the session.
| Probability → | |||
|---|---|---|---|
| Impact ↓ | Low · 1 | Medium · 2 | High · 3 |
| Low · 1 | 1 | 2 | 3 |
| Medium · 2 | 2 | 4 | 6 |
| High · 3 | 3 | 6 | 9 |
AARM Toolkit
The complete kit of fillable templates for the 4 stages: strategy canvas, ilities matrix, risk-storming board, architectural story, ADR and backlog.
Common mistakes
- The architect speaks first. When the most senior person presents their risks before the individual round, they anchor the group and the session becomes validation, not discovery. Silence first, discussion after.
- Outdated diagram. Risks pinned to an architecture that no longer exists produce useless stories. Update the C4 before scheduling the session, or draw it together, at the opening.
- Discarding the lone risks. The risk only one person saw usually comes from someone who knows a corner of the system the others ignore. It is exactly the kind of risk the technique exists to capture.