Application Development: A Risky Business

Mitigating Risk by Design

Photo by Julia Caesar via Unsplash.com

Introduction

Application design is an integral part of the application development process and is the main factor distinguishing great applications from those that are just “good enough”. As the first step in the development process design can either start an application on a path to success or ruin. Applications that do not meet their intended purpose, those that are plagued by defects, and those whose behavior is often unpredictable generally suffer from insufficient or poorly executed design.

Developers who produce poor applications often skip the design process either because it “wastes too much time” or is “overkill” for the task at hand. Conversely, but not surprisingly, mature developers always perform some level of design, regardless of the size of the application. In fact, one of the traits that distinguishes an average developer from a great developer is the latter always performs some level of design before starting to code. Another is that great developers use design and development techniques and tools that are at an appropriate level for the application in question.

“I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign … The problem is that at a lot of big companies, process becomes a substitute for thinking.”

Elon Musk

Application design utilizes many different techniques to map out what an application is to accomplish and how it will go about it. These include use cases, user stories, end user interviews and polling, UML diagrams, tools such as Jira or Trello, database design and diagramming tools, and even plain old flowcharts.

However, a technique that is often overlooked, but one with the potential of producing valuable results is that of risk mapping. Very simply risk mapping is an exercise that identifies the events that could have a negative impact on the application, the organization that developed and runs it, or the individuals using it. Once identified an assessment of impact, probability, and timeframe is conducted. This results in an action plan to address each risk if it occurs.

The value of incorporating risk mapping into the application design process is:

1. Preparedness — Identifying and preparing for what could go wrong lessens the impact of a risk if it should occur.
2. Agility — Addressing high probability/high impact risks during the development process has the potential of eliminating the risk. Similarly, preparing for a low probability/low impact risk saves resources by postponing resolution to the point in time when is is needed.
3. Economy — As a byproduct of agility, doing the right thing at the right time, expends resources at the point in time when the effort is required. Addressing a risk too early takes resources away from other higher priority requirements. Addressing them too late means the risk has probably already materialized and the costs associated with it will be accrued in addition to the cost of resolving it.

What is Risk?

Risk is the probability of a set of conditions taking place that increase or decrease the value associated with some thing. Although this definition includes the probability of an increase in value risk is generally used to ascertain the the opposite, negative outcome.

Risk Attributes

A overly simplistic identification of risk is one that merely identifies a condition and its outcome. For example, the loss of brand reputation in the event that a website is hacked. However, properly categorizing risk requires a more nuanced approach.

Any given risk has the following attributes:

• A concise name that identifies what the risk is. For example, “Low website registration rate”.
• Concise impact statement describing what will happen if the risk materializes. For example, “Results in unrealized revenue jeopardizing the profitability and viability of the product”.
• The conditions that must be met for the risk to be materialized. For example, “Poor performance. Overly complicated user interface. Non-intuitive user interface”.
• The probability that the risk will actually occur. This is based on the conditions associated with the risk and is actually the aggregated probability of all conditions.
• The relative impact associated with the risk. This is a quantifiable measure of the risks impact compared to other risks. For example, on a scale of 1-to-10, where 1 is the lowest impact and 10 is the highest, the “Low website registration rate” risk would be higher than a risk of “Key open source library the application is based on becomes unsupported”.
• The time horizon the risk could take place in if it should occur. Our example of “Low website registration rate” is a near-term risk while the “Key open source library the application is based on becomes unsupported” is a long-term risk.

Together these attributes define what the risk is, it’s impact if it should occur, the likelihood that it will occur, and its estimated time of arrival.

What is Risk Mapping?

Risk Mapping Process

Risk mapping is one technique in a larger risk management strategy. It can take place during or after design and its value typically increases with the size and complexity of the application. It is designed to:

1. Identify risks associated with a particular asset or activity, like the development and deployment of a new application.
2. Assess risk attributes including its potential impact, the probability of it occurring, and the timeframe when it is most likely to take place.
3. Planning, which takes the attributes of a risk into account to determine how and when to mitigate its effects.
4. Implementation, which puts the predefined mitigations into effect.

Identify Risks

Identifying risk is an exercise centered on determining what could go wrong. At this stage of the risk mapping process it is more important to come up with a comprehensive list of risks rather than to attempt to filter them. Until risk attributes have been identified any attempt at filtering is premature. In addition, no matter how trivial or even absurd a risk might seem the act of noting it increases the your ability to identify other risks.

The key questions driving the identification process are:

1. What is the definition of success associated with the asset or activity? Understanding what success means makes it possible to understand what are the key elements that are needed to achieve it.
2. What are the key elements of the asset or activity required for it to operate in a way that achieves its desired value? Knowing what elements are key to supporting the success of an asset or activity allows a set of risks to be identified dealing with the impact of them being impaired or becoming unavailable.

Assess Risk

Recall that a risk have various attributes associated with them including probability of occurrence, impact if it does occur, and the timeframe it is most likely to occur in if it does materialize. Identifying values for these attributes is an essential precursor to the planning phase of Risk Mapping.

Two pitfalls to watch our for during assessment are employing an overly complex approach to the determination of attribute values and being inconsistent in the way attributes are derived. These are opposing concerns which can be balanced by creating a simple scoring system that is uniformly applied to each risk when determining its attributes. These don’t need to be exhaustive or even 100% accurate. It’s merely enough that they be close and consistent.

Planning

This phase of Risk Mapping uses the attributes defined in the assessment phase to prioritize risks and determine what mitigations are required to either lessen, eliminate, or transfer their impact. Prioritizing risks allows the task of defining mitigations to be performed with an appropriate level of effort at the proper point in time. In other words, in an agile manner.

Example Risk Map Spreadsheet

Risk prioritization is accomplished multiplying the risk probability with its relative impact to rank risks from highest to lowest. Risks with the highest rank will generally be those with the highest probability and relative impact while those with the lowest rank will have low probability and low relative impact. Ranking can be further refined by conducting a secondary ordering based on the time horizon a risk is expected to occur in.

Implementation

The goal of the implementation phase is to either implement mitigations as part of application development or to prepare them in the event they are needed in the future.

This decision is based on the ranking of the various risks. Addressing risks with the highest rank during application development may be appropriate given that they have either a high probability of occurring or their impact is high should they occur. In either case implementing mitigations early is a cost avoidance strategy.

On the other hand, the implementation of risks with a lower rank may be deferred until the risk materializes. This defers the cost of mitigation until the point in time it is needed. It’s also an effective strategy to couple the conditions with application monitoring to determine when the probability of a risk occurring begins to increase. This allows the mitigation to be put into place just-in-time. The just-in-time strategy defers the cost of the mitigation, but avoids the impact of the risk since it is resolved before it occurs.

Conclusion

Incorporating Risk Mapping to identify and either address or plan risk mitigations is an effective technique to manage cost and effort when bad things happen to applications. Planning for risk also supports the goal of making applications more resilient to improve the value they deliver to the end user. After all, at the end of the day applications and the experience they deliver is about the user.

I hope your find this information useful and I look forward to any questions and comments you might have. Have a good day and go do great things!

What is Chingu?

Come join us at Chingu.io to get out of “Tutorial Purgatory” by joining one of our remote Voyage project teams to build apps, refine “hard” skills, and learn new “soft” skills. We help Developers bridge the gap between what they’ve learned and the skills employers are looking for.