Close

Identifying Solution Architecture Risk

Share on facebook
Share on google
Share on twitter
Share on email
Share on linkedin
Concept drawing of magnifying glass and many question marks signifying identifying solution architecture risks

Identifying solution architecture risk is a vital responsibility of a solution architect. We introduced the concept of solution architecture risk last time in our risk primer for solution architects, and this continues that journey, exploring how a solution architect identifies risk.

You may recall from the previous article that in this context, “risk” refers to potentially harmful outcomes related to any decisions made about the architecture during the solution design process. Also remember that risks are all about uncertainty: not what will happen, but what might happen.

In most cases, you expect a specific outcome based on your architecture design decisions, so what you seek to identify is:

  1. Risks where you already anticipate the outcome may be harmful, due to a decision you already know is detrimental but have no choice as a result of factors outside your control.
  2. Risks where a harmful outcome is possible if your outcome prediction is incorrect.

Identifying Solution Architecture Risks

So how does a solution architect identify architecture risk? We recommend the following for techniques during the architecture design process:

Review Assess Promote Prompt Visual for Identifying Solutionm Architecture Risk
Who doesn't love a mnemonic

  1. REVIEW. Review the architecture diagrams created for the solution. Follow your architecture use cases through the diagrams' connections and flows and determine what risks might be looming. If you have no architecture diagrams, add that as both a delivery and production risk!
  2. ASSESS. Assess your design against any guiding principles, standards, architecture patterns, reference architectures, non-functional requirements, or other technology guardrails in place at your organization.1If none exist, prioritize putting some in place. Among numerous other benefits, technology guardrails will have a material effect on reducing the risk the organization accepts as a result of technology solutions. Then do the same against industry standards and best practices.
  3. PROMPT. Every time you discuss or share your solution architecture design with any audience, prompt the audience to share any risks they anticipate based on the design. This may require you introducing them to what you mean by risk. Our risk primer for solution architects provides an introduction to the topic.
  4. PROMOTE. Consider each architecture decision you made and the associated risks. Your decision approach should include documenting and reviewing the benefits, impacts, and risks of each option. If it doesn’t, you might want to add that as a delivery and production risk: “Who knows? We’re winging it.” Assuming it does, promote those with material risks to your solutions risk register.

There you have it! RAPP your way through identifying solution architecture risk. Extra credit if you can get any of your stakeholders to beatbox in the background.

Solution Architecture Risk Prompts

In addition to these techniques for identifying solution architecture risk in general, there are some specific focus areas that most typically result in solution architecture risks.

You can use the prompts below to find those risks. Remember that the focus is risks that result from decisions you made designing the solution architecture.

Delivery Risks

Delivery truck stuck in the snow

  • New Vendor. This could be a product vendor, implementation partner, or even a new resource pool required to implement your solution. If a vendor is not already “tried and true” with your organization, you might face unexpected delivery challenges. The level of risk is a factor of the amount of delivery owned by the vendor and the results of your due diligence.
  • New technology. In addition to the same risks referenced above for a new vendor, you can add the risks that internal resources are not familiar with the new technology and how difficult it might be to configure and integrate into your environment is not yet understood.
  • Technology Dependencies. Any dependencies on components outside the scope of the solution (external frameworks, integration endpoints) could introduce delivery risks; especially if an independent effort is still completing functionality, you need for your solution to work (e.g., dependency on another technology project).
  • Resource Dependancies. Any dependancies on people who due to skills or subject matter expertise are critical to delivering this solution. The more critical they are for the delivery of your solution along with how “in demand” they are for other activities outside your solution will determine the risk.

Production Risks

Automobile factory production line
  • New things. Any new technology, architecture, integration, etc., is untried in your environment and thus requires new processes, skills, and learning. All of which can pose a risk. New also brings new benefits and capabilities, which is why you innovate in spite of the risk.
  • Old things. Conversely, older technologies can have risks related to aging support, agility in responding to changing needs, ability to integrate with emerging industry technologies, and challenges finding skilled resources interested in supporting legacy technologies.
  • Trading tomorrow for today. Often choices that are cheaper and more expedient for solving today's problem complicate addressing future needs.
  • Security issues. I mentioned in my introductory article that security is only a slice of the risk pie, but it is a critical slice!
  • *-ility issues. To keep this list of prompts succinct, I refer you to the Wikipedia's comprehensive list of non-functional requirement categories for a whole slew of prompts. Non-functional requirements specify how a solution should be built, installed, or operated to run optimally in your environment. Even if you haven't yet established them – tsk, tsk – you can use the category list to prompt your assessment.

If you see something, say something

Great. Now what? Well, after identifying solution architect risks, the solution architect needs to document and communicate the risks. We have a lightweight recommendation for that, which will be the topic of the next article on solution architecture risk registers.

Risk is just one of the topics included in our solution architecture training curriculum. Drop us a line at info@wittij.com, 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.

Share on facebook
Share on google
Share on twitter
Share on email
Share on linkedin
WittijConsultingLogo512x512_wpfav

Our reputation is our success. If we can do great things for you, we will. If we can’t, we’ll say so.

Leave a Reply

Your email address will not be published. Required fields are marked *