Which architectural option?

Introduction

For the last 2 decades I have been designing solutions with different technologies. You will quite often hit a situation where there are multiple architecture options for a solution. Deciding on the best architecture option is not always straight forward as each option with have different strengths and weaknesses.  Therefore, I cannot stress how important it is that you create a Key Design Decision document (KDD). The goal of the KDD is to present the different architecture options in a balanced way, make a recommendation and ultimately make a decision.   

 The Key Design Decision (KDD) to the rescue!

The KDD should be no more than one page and link to other documents where required. It allows the author to document the high-level information around the requirement. The KDD contains the following information:

·        Background: The goal of this field is to outline any relevant information that provides context around the requirement that follows. It should also set the scene around the components that currently interact with the requirement.

·        Requirement: This can be a new requirement or explain a problem with the existing solution. 

·        Options: This is where most of the time is spent. For each option there will be a description and a list of pros and cons. I always specify option 1 as “do nothing”, as sometimes we forget that not making a change may be the best option. Each pro/con will be looking at a different aspect of the option. The number of aspects to cover will be dependent on the requirement. On each option the aspect will fall under a pro or con, therefore, it is always good practice to check you have the same number of pros/cons for each option. The most important thing to remember, is that each aspect position is relative to the other options. This allows the options to be presented in an equal way and a high-level view to be taken. Each pro/con should take a position with a supporting statement. The supporting statement is important for review and further discussion. I would recommend adding the following aspects on each option but remember to consider others that are applicable to your situation.

o  Address requirement – Does the option address the problem, and this should be yes, partial or no. This field allows reflection on the option and allows the Solution Architect (SA) to be creative around the requirement.

o  Tactical / Strategic – This should be a simple yes or no, followed by a supporting statement. 

o  Complexity – Complexity can often be difficult to calculate but remember this is relative to the other options.

o  Development Cost/Effort – Since an option may span multiple teams/disciplines it is good practice to break this up by team. This can be helpful when certain disciplines are at delivery capacity. To keep things simple, I would recommend using low, medium and high as the values.  

o  Business Cost/Effort – Again, this should be low, medium, or high however, you can be more specific if required.

·        Recommendation – This should recommend one or more options and highlight the key pros, that support that recommendation over the others. There can be more that one option as the SA could be recommending interim states.

·        Decision – It is a common mistake to mix the recommendation and decision together as there should be a separation of concerns between the two statements. The decision makers can be an individual or group of people. The decision can either agree with the recommendation or decide to implement one of the other option/s. The decision is typically made by the Product Manager or architectural governance.

 Summary

A Key Design Decision (KDD) can be used on small and large projects with the only difference being  the governance around the decision process. It provides a framework for those situations where there is more than one option available.

It can also be used to qualify if anything should be done, this would result in two options, and these would be: -

Option 1 – Do Nothing

Option 2 – Do Something

Architecture options are best discussed with more than one person and the KDD facilitates those discussions and speeds up the final decision.