Let Risk Be Your Guide

Shortly after the first stakeholder meeting on a new software project, I always feel a giant pit grow in my stomach. If I didn’t have that feeling, then I would be worried. Software worth building always has risks. You should feel a bit uncomfortable at the start of a new project. After all, if you knew everything at the outset and had no questions about what you were going to build, then why would an architect be needed?

We can use that slight sinking feeling in our guts to our advantage. Risk is an excellent indicator of what might prevent us from succeeding. To harness the power of our guts, write down all the things that worry you about the software system. Next, prioritize the items on your list so that the things likely to cause the most trouble are highest on the list. Finally, pick one of the top things you’re worried about and choose a design mindset to reduce the risk.

Gut feelings are a good start, but guts alone don’t give us much to go on. I don’t know about you, but I hate going to my boss with gut feelings. Hi, Will, so I’m not sure if it was the burrito I had for lunch or what, but I’ve got a bad feeling about how the system is going to scale as we add data. Gut feelings tell us there is something wrong, but we can do a much better job than just listening to our lower intestines.

Identify Conditions and Consequences

A risk is something bad that might happen in the future. If it already happened, then it’s called a problem. If it starts with what if…, then it’s pure speculation. We could play what if… all day and never get any closer to designing a useful architecture. Instead of speculating, we’ll use what we know about the architecture today to help us decide what to design next.

There are two parts to every risk. The condition is a fact about the world that is currently true. The consequence is something bad that might happen in the future as a direct result of the condition. We record risk statements using the simple template from A Construct for Describing Software Development Risks [Glu94], <Condition>; might <Consequence>.

Here’s a risk statement in the condition-consequence format.

There are many ways we could reduce or remove this risk:

• Reduce the probability. Hire catering to bring in food a few days a week, and hold an info session on responsible meal portions.

• Reduce the impact. Keep a supply of antacids in the office.

• Push out the time frame of the risk. Schedule meetings at lunch so people can eat burritos only for dinner.

• Remove the condition. Move the office to a new location. Change the shift schedule so that everyone works at night when the new restaurant is closed.

• Accept it and do nothing. Sometimes people eat too many burritos (mmmm… guacamole). We’ll deal with the repercussions if the risk converts into a problem.

Knowing the condition and the consequence creates hooks for deciding what to do about the risk. Compare our <Condition>; might <Consequence> risk with these other, less effective risk statements:

OK, enough about burritos. Let’s get back to software design.

Use Risk to Choose a Design Mindset

Software architecture design is an exercise in risk reduction. Every time you think, I’ve got a bad feeling about this, it’s a sign there’s a risk looming nearby. If you can pick a condition and consequence that captures the essence of your bad feeling, then we can use that information to guide our design activities.

Here are some example risks from a past project I worked on and the design activities the team used to reduce the risk:

The Model Training service was originally built for a different purpose; might overload it with new requests.

Design Mindsets: Understand, Evaluate

What we did: Talked to the team who built the Model Training service to understand scalability, ran experiments to measure throughput.

Data processing is time consuming and resource intensive; might not be able to finish processing jobs without failures.

Design Mindset: Explore

What we did: Brainstormed approaches for promoting reliability, researched job scheduling patterns, and sketched alternative designs that might reduce processing time.

A lot of data is needed to train a statistically significant model; might not be profitable due to data storage costs at scale.

Design Mindset: Make

What we did: Created a cost estimation model. The model demonstrated pros and cons of different design options to stakeholders. Pushed out the risk’s time frame by changing backlog priorities.

Stored data may contain sensitive customer information; might require stricter data isolation than we can provide.

Design Mindset: Evaluate

What we did: Rated available compute platforms based on how well each met our needs.

Engineering risks help us decide what to design. Design mindsets help us devise a strategy to decrease the risk. When facing a risk that must be reduced, first decide which parts of the risk you can address—condition, impact, probability, or time frame. Next, choose a design mindset. Here are some questions to help decide which design mindset might be appropriate:

Risks are the GPS for our design process. They tell us where we are, where we’re going, and how much we have left to design. With each loop through the think-do-check cycle discussed, think about the risks and use them to decide what to do next.

Shift to Passive Design Once Risks Are Reduced

In Just Enough Software Architecture: A Risk-Driven Approach [Fai10], George Fairbanks tells us that architects should work to reduce technical risks to the point where architecture is no longer the biggest source of risk in the system. Once we have reduced enough of the architectural risks, whatever that means for the software system, then our time is better spent elsewhere.

Once architecture is no longer the greatest source of risk in the system, shift from active design to passive design, as shown in the graph. With active design, we drive the design process in the pursuit of reducing risk. With passive design, we observe the architecture as it manifests in the working system and take corrective actions as necessary.

Don’t be tricked by the name. There is still a lot for an architect to do in passive design mode. We might correct errant documentation or improve missing documents. We’ll make minor adjustments to the architecture as new information emerges. We’ll teach our teammates about the architecture by pairing and reviewing code. Most importantly, we’re on the front line in the fight against architectural erosion and other issues, discussed.

Even with careful vigilance, architecture could reemerge as a significant risk. New risks might emerge. The implemented system could drift too far from our plans. We could learn that our assumptions about the world are wrong or that the world around us changed. When these things happen, switch back to active design and adjust the architecture based on the new realities.

Now that you know how to use risk to help you decide what to design, let’s pull together everything you’ve learned in this chapter by ceating an architecture design plan.