Very often during working on software architecture there are discovered risks which may disturb working of our system. Frequently we need to decide if we must implement prevention mechanism for a risk, or we can ignore a potential problem and deal with consequences. We need to make a risk analysis.
Think of consequences
What is a 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 occurred, then…”. It is not efficient to play in game “What may happen if…”, we get 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 change. The solution is to start to talk about facts, not speculation.
One of the method is to describe risk as a pair of condition and consequence in shape of 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 to think how to reduce it. We have few options:
- Remove the condition
Sometime 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 occurrence of the condition, then we can try to reduce its consequences to acceptable level.
- Reduce probability
When we agree that condition may occur and we cannot prevent it, then we can think of how to reduce probability of the event. Maybe we can drop down the probability to 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 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 method which can structured risks assessments. We can use matrix used by NASA during Flight Readiness Review.
First we need to define a risk as was presented above, then we need to figure out 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 table to assign score to consequence, we can also use it as 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 theirs cross point on the matrix. The number on founded square tells us about importance of the problem, 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 reduce it into green or at least yellow color.
Add risk analysis into your software architecture toolbox
Use the risk analysis as tool which helps You during work on software design. When we introduce 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 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 list of the risks ordered by theirs 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 (