⚡ Tl;dr
- Risk storming is a technique for collaborating with your team to identify risks in your software architecture visually.
- Risk storming is recommended as a collaborative workshop as diverse opinions and perspectives help identify the non-obvious risks.
🚀 Let’s kick-off
It’s important to realize that no software architecture, process or team is perfect, and there are always scenarios that can pose risks to your company. Considering these risks and actioning the important ones is an essential part of modern software engineering.
Risk storming is a technique developed by Simon Brown for collaborating with your team and visually identifying risks in your software architecture. Collaboration is key to risk-storming as diverse expertise and perspectives from your team help uncover the risks that may not be obvious to everyone.
🤔 Types of risks to consider
The types of risks you should consider can vary wildly, from human, to technical, so it’s important to consider a wide range of possible scenarios. Let’s run through some examples of areas where you can identify risks in your architecture.
People
- What happens if a person with tribal knowledge leaves the team?
- Do we have the skills in the team to maintain this moving forward?
- Could we need consultants in this area, and how much would that cost?
Process
- Are there important processes that people in the team aren’t trained on?
- Can the support team troubleshoot and resolve questions about this area?
- Are there sensitive processes or artifacts that could be compromised?
Operational
- Is there a budget for this service, and could it cause runaway cloud costs?
- Are there legal or compliance risks with storing data in this way?
- Is this impacted by things happening in other areas of the business?
Technology
- Do we depend on old technologies or libraries which could be deprecated?
- Is this stable and secure enough to satisfy our commitment to our customers?
- Is this technology the right tool for the job?
❗ Evaluating the priority of risks
To decide which risks are acceptable and which need to be addressed quickly, you should quantify each risk by evaluating their impact and probability.
The following matrix allows you to rank risks on a 1-9 scale and classify them into low, medium and high-priority groups. Simply multiply the probability and impact to get the final priority score.
You’ll likely want to focus on actioning the high-priority risks first and then the medium ones.
🖼️ Collaborative risk storming
Risk storming is recommended as a collaborative workshop with your team. Including a diverse set of opinions and perspectives helps identify and discuss the non-obvious risks which could go unnoticed otherwise.
You can run an in-person or remote workshop with your team with the following four steps.
Step 1. Draw a diagram of your software architecture
The first step is to gather your team members and draw diagrams of your software architecture. It’s recommended to draw multiple diagrams at different levels of detail as each diagram could have different risks associated with it.
The diagrams can include potential future state architectures that have not yet been built. Doing risk-storming upfront helps prevent these risks from being built and reduces possible re-work later.
We recommend using the C4 model as a simple structure to diagram your system and C4 model stickies as an easy way to use the C4 model with a whiteboard.
Tip: Add extra space to your diagram to allow risk sticky notes to be added afterwards.
Step 2. Individually write coloured risks on sticky notes
Each person should identify their risks and quantify them using the priority matrix above. Note the impact and probability scores on the sticky notes so others can comment. Then write the result on a green/orange/red coloured sticky note.
Each team member will have a different opinion which is why this is important to be an individual task. You don’t want to bias any opinions of the risks created.
Step 3. Add sticky notes to the diagram and discuss the risks
Ask everyone to add sticky notes to the diagram(s) wherever it makes the most sense based on the services or connections involved. Try to group sticky notes together if people create similar or matching risks, as this helps show the commonly identified risks.
Everyone should now evaluate the board and discuss the risks if needed. It’s helpful to discuss risks only reported by one person or where there is disagreement from the team about the impact or probability. You can prune or move risks on the diagrams after you have discussed them.
Step 4. Write up actions to address the high-importance risks
Review the final risks on the diagram and decide which are high priority and need resolution or mitigation. Create a plan with the team about how to mitigate these risks and assign tasks to people so they are scheduled to be worked on.
Methods to mitigate risks can be things such as running training sessions, doing implementation or refactoring work, or introducing new processes.
🏁 To wrap up
Risk storming is a powerful tool to identify and mitigate risks in your software architecture and collate different perspectives from your team. Doing it in advance can be great for building solutions that are low-risk and secure from the get-go.
Check out the official website for risk storming for more information.
Stay chill 🧊
