What is Risk?
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.
Solution Architecture Risk Mantras
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 pie, just not the whole – to holistically managing the risk.
- A solution architecture without any risks does not exist. If even it were possible, it would be cost-prohibitive to derisk a solution comprehensively.
- Identifying risks does not create them. The risks are present, whether acknowledged or not. It is irresponsible to not perform due diligence to at least try to identify and understand the risks. Not doing so creates risk!
Solution Architecture Risk Categories
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 solution architecture decisions made by a solution architect while designing a solution. We categorize these risks into two types:
|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 XYZ 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 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.
That’s all for the primer! I will continue the discussion of risk next time in: Identifying Solution Architecture Risk.
Risk is just one of the topics included in our solution architecture training curriculum. Drop us a line at firstname.lastname@example.org, 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.