Very often during working on software architecture there are discovered risks which may disturb the working of our system. Frequently we need to decide if we must implement a prevention mechanism for risk, or we can ignore a potential problem and deal with consequences. We need to make a risk analysis.
Think of consequences
What is the risk ? It is a possible problem which can occur in the future. We can imagine a lot of possible problems, and for each of them consider possible consequences and create stories in kind of “if something will occur, then…”. It is not efficient to play in-game “What may happen if…”, we get a flood of speculative scenarios which slows down our design process. I observe this many times during design software meetings, when attenders invent possible problems and force the team to check if projected software will be resistant for the case and in consequences change some parts of software architecture, very often it is bad to change. The solution is to start to talk about facts, not speculation.
One of the methods is to describe risk as a pair of the condition and consequence in the shape of the structured sentence: <condition>; might <consequence> i e.:
configuration file is corrupted; might disable cryptography on the satellite link with ground
There is no space on flash memory to save user message; might lost user’s important message, what breaks the rule of service agreement
How to reduce risks
Once we define a risk (pairs of a condition and a consequence) we can start to think how to reduce it. We have few options:
- Remove the condition
Sometimes it is possible to prevent occurrence the condition, or even better as a result of analysis condition may be assumed as impossible to occur.
- Reduce the impact
If we cannot exclude the occurrence of the condition, then we can try to reduce its consequences to an acceptable level.
- Reduce probability
When we agree that condition may occur and we cannot prevent it, then we can think of how to reduce the probability of the event. Maybe we can drop down the probability to the level so low that we can accept the cost of the problem.
- Reduce time frame
Sometimes we can reduce the possibility of condition occurrence to moments when it won’t hurt our system.
- Do nothing
We can check if we can accept the cost of possible consequences if we can then there is no need to find a solution.
NASA risk matrix
It would be good to have a method which can structured risks assessments. We can use the matrix used by NASA during Flight Readiness Review.
First, we need to define risk as was presented above, then we need to figure out the likelihood of the condition and an impact of the consequence. We use fuzzy set, not a strict numbers and for each set we assign score as presented below:
Condition probability score
- Not likely probability < 20%
- Low likelihood 20% <= probability < 40%
- Likely 40% <= probability < 60%
- Highly Likely 60% <= probability < 80%
- Near certainty probability => 80%
Impact of consequence score
NASA uses the table to assign a score to consequence, we can also use it as a good start point or modify it to better align our domain.
Get the risk assesment
Once we got scores for condition likelihood and for the consequence we find their cross point on the matrix. The number on founded square tells us about the importance of the problem, a higher number means more importance. If the risk is assessed into one of the red squares, then it is critical and we cannot move forward without reducing it into green or at least yellow colour.
Add risk analysis into your software architecture toolbox
Use the risk analysis as a tool which helps You during work on software design. When we introduce a structured method to handle the risks, then we get chance to be more efficient because we stop the endless discussion about possible problems, we can take reasonable decisions about risk and we can document them.
Summarize the method
- Define the risk as a sentence <condition>;might <consequence>
- Asset the risk with The Risk Matrix
- If we need to reduce the risk
a) use presented methods to reduce the risk
b) check again with the matrix if we reduce the risk to an acceptable level, if not then back to point a
- Write down the risk definition, decision and its reasons in documentation (architecture decision log is a good place to do it)
It may be worth to introduce a list of the risks ordered by their importance number taken from The Risk Matrix. The list can help us to take more reasonable design decisions in the way which more important risks have more impact on the design.
- 2017) Design It!: From Programmer to Software Architect. Pragmatic Bookshelf, . (
- 2014) ‘Guidelines for Risk Management’ [online]. Available at: <https://www.nasa.gov/sites/default/files/atoms/files/s3001_guidelines_for_risk_management_-_ver_g_-_10-25-2017.pdf>. Accessed: 16.09.2019 (