Leveraging Risk for Solution Architecture

This article wraps up our series on solution architecture risk and addresses the critical value of understanding and leveraging risk for better solution architecture. You can learn the basics in the other articles in this series: a primer on solution architecture risks, strategies for identifying solution architecture risk, and a method for managing a solution architecture risk register.

Competing Concerns

Competing forces pull a solution architecture design in different directions.

It is important to weigh them all when designing a solution:

• Functionality. What are the functions the solution is providing?
• Cost. How much will it cost to implement and operate?
• Time. How much time before the organization can begin receiving value from the operation solution? How long will it take to deliver?
• Risk. What solution architecture risk is this solution adding to the organization?

Not only do these forces pull the design in different directions, but usually addressing one requires trade-offs in another. For instance, a lower-risk solution architecture increases the cost or implementation time for the solution.

Management puts pressure on the cost and time concerns, and for the customers (internal or external), it's all about the functionality. As a result, functionality, cost, and time are usually top of mind for all people involved in designing and delivering a new solution. Risk, if discussed at all, tends to be focused on risks impacting project or agile pod delivery, which makes sense: the primary responsibility of the people who lead implementations is to deliver. In that role, functionality, cost, time, and delivery risk are critical concerns.

Enter the Solution Architect!

Solution architecture design involves making decisions by evaluating technology solution options to make the best architecture design choices. Usually, when an architect advocates for a better choice, what they mean - unless that choice costs less, is quicker to implement, or provides more functionality - is that it results in lower risk. If a solution architect is proposing a solution that is not (1) cheaper, (2) faster to implement, (3) more functional, or (4) lower risk, then the architect needs to step back and evaluate why they are proposing that solution in the first place. Either it isn't the right solution, or they aren't thinking comprehensively about the four forces.

Highlighting the risks to advocate for a better design can be a very powerful approach.

1. Often, the people preferring other designs aren't aware of the risks, and informing them of the risks can shift the direction of the design to a better outcome.
2. In other cases, the decision-makers will stay the course on a less architecturally sound design as they are not comfortable with cost, time, functionality trade-offs required. Still, at least it will be a fully informed decision, and the responsible people will be aware of the risks associated with the decision. Plus, the risks can be tracked and appropriate risk responses can be determined, which can reduce the impact of the risks.
3. Finally, analysis of the risks may result in a new or hybrid design choice that reduces some risks without impacting the other concerns (cost, time, functionality).

In any of these cases, the solution architect is leveraging risk to improve the outcome of the design.

Leveraging Risk

We feel strongly about leveraging risk for better solution architecture. Driving decisions with analysis and clear risk identification can shift conversations from emotional to fact-based which results in better decisions and better architectures.

I want to close by highlighting some key points:

• Architecture risks are present, whether identified or not. It is always better to be aware of them.
• Somebody needs to be on the lookout for architecture risks, especially production risks, when selecting and designing a solution as delivery processes often overlook them.
• Shining a light on the risks associated with solution architecture drives better architecture decisions, resulting in better solution architectures!

If you haven't already, you may want to check out the foundational articles in this risk series:

1. Solution Architecture Risk: A Primer. A "101" that introduces basic risk concepts and describes solution architecture risk.
2. Identifying Solution Architecture Risk. Techniques for identifying solution architecture risk.
3. Solution Architecture Risk Register. A method to track solution architecture risk, including determining risk responses.

Good luck driving better design, and please contact us if you think we can be of any assistance!