Identifying Solution Architecture Risk

Dan Hughes
September 17, 2019
Identifying solution architecture risk

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 four techniques during the architecture design process.

Who doesn't love a mnemonic

The RAPP Risk Identification Technique

  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

These are prompts for the risks that might halt or delay the delivery of the solution.

  • 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 Dependencies. Any dependencies 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

These are prompts for operational risks that will be present once the solution has been deployed into production.

  • 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 [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.

Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
Copyright © 2024 Wittij Inc.
crossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram