Likelihood and Severity. Two different measures for two different aspects of measuring risk in a modern digital application.

They are both measures of risk, but they measure different things. What is the difference between likelihood and severity? And why does it matter?

In this episode, I’ll discuss Likelihood and Severity, how they are different, and how they are both useful measures of risk in a modern digital application.

Links and More Information

The following are links mentioned in this episode, and links to related information:

•   Modern Digital Applications Website (https://mdacast.com)

•   Lee Atchison Articles and Presentations (https://leeatchison.com)

•   Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

•   Advising and Consulting Services by Lee Atchison (https://atchisontechnology.com)

•   Learning Path - Risk Management (http://leeatchison.com/classes/learning-path-risk-management/)

•   O’Reilly Learning Path Course (https://learning.oreilly.com/learning-paths/learning-path-microservices/9781492061106/)

Microservice architectures offer IT organizations many benefits and advantages over traditional monolithic applications. This is especially true in cloud environments where resource optimization works hand-in-hand with microservice architectures.

So it’s no mystery that so many organizations are transitioning their application development strategies to a microservices mindset. But even in the realm of microservices, building and operating an application at scale can be daunting.

Problems can include something as fundamental as having too few resources and time to continue developing and operating your application, to underestimating the needs of your rapidly growing customer base. At its best, failure to build for scale can be frustrating. At its worst, it can cause entire projects—even whole companies—to fail.

Realistically, we know that it’s impossible to remove all risk from an application. There is no magic eight ball — no crystal ball — that allows you to see in the future and understand how decisions you make today impact your application tomorrow. Risk will always be a burden to you and your application. But, we can learn to mitigate risk. We can learn to minimize and lessen the impact of risk before problems associated with the risk negatively impact you and your applications.

I’ve worked in many organizations, and have observed many more. Planning for problems is very hard and something most organizations fail to do properly. Technical debt is often a nebulous concept. Quantifying risk is the first step to understanding vulnerability. It also helps set priorities and goals. Is fixing one potential risk more important than another? How can you decide if the risks aren’t understood and quantified.

In this episode, we’re going to talk about how to measure risk, so that you can build, maintain, and operate large, complex, modern applications at scale.

There is a great quote by Donald Rumsfeld, twice former secretary of defense for the United States. It starts “Reports that say that something hasn’t happened are always interesting to me”.

He goes on to say: “because, as we know, there are known knowns, there’re things we know we know. We also know there are known...