Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.
Application split impact as a strength in risk assessment
An application can be considered as a whole in its purpose of servicing one area of the business, yet it is composed of multiple technical and functional parts. In other words, an application is not about one single feature.
The ability to split an application into its main features, or groups of features or functional domains, is critical to map the occurrences of risky situations. Indeed, considering that every single piece of code or software construct is equivalent with regards to the risk an application incurs is valuable for objective comparison. Yet it misses the point that they serve different features and that these features are not equal, would they fail in operations. For instance:
- The very location where the violations occur is key as it might be in a piece of code or in a construct that is supporting a non-critical feature that does not handle any sensitive data. Or, on the contrary, is supporting a mission-critical feature that does handle sensitive data with a customer-facing front-end over the Internet.
- Likewise, a piece of code or software construct that is involved in many such critical features creates a much higher risk even though it is still occurring in one location.
- Taking the context into account will help provide a better assessment than a purely objective one.
The same issue holds true when dealing with application upgrades as well. I faced a situation where the team in charge of evolving the application would complain about the huge difficulties to perform their task, saying it was, "terrible to maintain." Paradoxically, the compliance ratio with applicable coding and architectural practices were pretty good. Issues related to less than one tenth of a percent of the code. The real issue is that the few occurrences of non-compliance were located in the very part of the application they had to evolve regularly in response to business requirements. It all made sense once they knew that this small fraction of the code was the one that mattered.
As it is critical to know the kind of application we are dealing with to adapt the risk assessment accordingly, this mapping ability will provide context to the findings; it will -- or should I say must -- change the resulting risk level assessment.
A walk through
Let’s look at the following situation of four applications composed of 10 components each:
The color is designed to provide you with a risk assessment of each component of these applications, with green being the right place to be and red being the wrong one. Would you say the risk level is the same in these four cases?
Then, let us look at another situation:
And now this one:
They all look different and I assume you would like to be responsible for the application showing in the first row, and dread the responsibility for the application in the third row.
- All of them are based on the same number of defects (10 percent)
- Sample #1 uses a linear scale from green to red to show defect percent from 0 to 100
- Sample #2 uses a linear scale from green to red to show defect percent from 0 to 50, then a red plateau when more than 50 percent of defects
- Sample #3 uses a linear scale from green to red to show defect percent from 0 to 50, then a red plateau when more than 50 percent of defects with 3 modules that are more critical than the others
Does it mean there is no truth in it?
As for me, I would see an opportunity to deliver better risk assessment results:
What do you look for when assessing risk in an application?