Having worked with, mentored, and interviewed countless technologists, I noticed that the default “go-to” understanding of risk is focused on information security risk because it is such a prevalent topic in most organizations. This understanding is too narrowly scoped to understand solution architecture risks effectively. This alternate offered by Wikipedia provides a more useful definition in the solution architecture context.
Risk can also be defined as the intentional interaction with uncertainty. Uncertainty is a potential, unpredictable, and uncontrollable outcome; risk is an aspect of action taken in spite of uncertainty.
Solution architecture risk isn’t only about security, nor is it inherently good or bad. A solution architect makes choices while designing an architecture without knowing the outcome of those choices. Uncertainties with possible outcomes that could have negative impacts on the organization need to be identified and managed. When the term “risk” is used in practice, it refers to those uncertainties.
"Risk" in the context of solution architecture risk refers to negative outcomes that might occur as a result of architecture decisions that do not have definitive outcomes. Very few things in technology - and in life - have 100% guaranteed outcomes, so there will always be risk to identify.
We train solution architects to understand these mantras about solution architecture risk. They are foundational in shifting thinking about risks from stomping out security issues – which is a slice of the pie, just not the whole pie – to holistically managing risk.
Risk professionals categorize risk to make it easier to manage. Operational risk is the prospect of loss resulting from inadequate or failed procedures, systems, or policies. Solution architecture risk refers to the operational risk that results from technology decisions made by a solution architect while designing a solution. We categorize these risks into two categories:
|Delivery Risks||These are the risks that might halt or delay the delivery of the solution (e.g. getting it deployed into production).|| The solution requires critical SME’s for this design that are currently dedicated to project Universe.|
Delays to Project Atlas could result in Flux Capacitor not being available in time for this solution to go live.
|Production Risks||These are the operational risks that will be present once the solution has been deployed into production.|| The solution uses an unsupported database platform (Pervasive SQL), which could result in extended downtime in the event of an issue.|
The vendor product’s lack of encryption for stored data could put the company at risk for a data breach
These should all be risks resulting from decisions made while designing the architecture and are the responsibility of the solution architect to identify, document, and communicate to the business partners relying on the solution.
Early in this article, we asserted that "there will always be risks to identify." This is correct, but depending on your organization's appetite for risk, some risks will be highly unlikely or inconsequential even if realized. How likely and impactful a risk needs to be before you identify and track it depends on the "risk appetite" of your organization. If your organization has a high-risk appetite, many unlikely or inconsequential risks won't impact the course of a design. In an organization with a low-risk appetite, even unlikely or inconsequential risks may need to be avoided.
Some organizations are risk-averse, while others are willing to take on more uncertainty in return for the possible benefits when they don't have negative outcomes. Ideally, your organization's risk function has published material on the organizations risk appetite. If not, you can determine this through conversations with management.
We recommend casting a wide net during design and identifying as many solution architecture risks as possible. The organization can decide later which of these are impactful enough to require more formal tracking going forward, but they will drive better design discussions now. This will ultimately result in a better design.
Hopefully, you now have a basic understanding of risk and, specifically, solution architecture risk. Solution architecture risk is a powerful tool when advocating for a better architecture as it often helps an architect transition from a "this is better" debate to a more productive, fact-based discussion. It is also a powerful approach to discuss technical topics with non-technical business users in a business context they will better understand.
I will continue the discussion of risk next time in: Identifying Solution Architecture Risk, where we will share some field tested techniques for ferreting out those risks!
Risk is just one of the topics included in our solution architecture training curriculum. Drop us a line at [email protected], call (401) 340-1400, or contact us to learn more. Like the tagline says, our reputation is our success. If we can do great things for you, we will. If we can’t, we’ll say so.