Any solution architecture is the end result of a series of technology decisions - some big and some small. Ideally, you make each decision intentionally, but once your solution makes it to production, the decisions were made: intentionally or not. I have provided some guidance on making better technology decisions in the past, and am now going to dig into our preferred method for evaluating technology solution options. While my focus is on the types of decisions that would be facilitated by a solution architect, the basic process is suitable for almost any decision.
You evaluate technology solution options to determine the best technology direction when faced with multiple potential choices. The scope of these options varies, from large-scale choices like which software or platform to use, to smaller ones, like the best approach for integrating two components of the solution.
In my prior article on technology decisions, I highlighted the five key dimensions that define "better," when making better technology decisions. They are:
Organization strategy, technology vision, risk appetite, and technology environment are mostly constant across all the technology decisions made in a given organization. They will shift over time as the organization evolves, but not across each technology decision. What will change for each technology decision are the specific business drivers, which brings me to requirements.
Understanding the specific business drivers is critical for evaluating technology solution options. You are never just evaluating the best solution, but the best solution for a specific problem. In some cases someone will have clearly documented the requirements, in others, they will not have. In both scenarios, I recommend you start with a Solution User Diagram. If the requirements are well documented, this enables you to validate your understanding of the requirements, and if they are not well documented, this is a quick way to document them sufficiently for most technology solution options analysis.
If you are evaluating solution options where a product or platform is being selected, it is important that you understand which key features or capabilities are important for the solution and even what the relative importance is of each.
If your organization has documented technology guardrails in place, these will provide you will easily consumable details about the technology vision and operating environment. If it does not, you will need to do some investigating. Contributing what you learn to a library of guardrails can be a great way to iteratively develop guardrails and optimize your activities around future decisions. In either case, you will need this information for a good technology decision.
If you have established technology principles as part of your technology guardrails activities, they serve double duty. First, they provide broad guidelines that will cover most technology decisions you need to evaluate. Secondly, they can act as dimensions against which you assess your options. Non-functional requirements can also provide great guidance around the operating environment, especially for a product-selection type technology solution options analysis.
In summary, when you are evaluating options, you perform research, talk to a lot of people, analyze what you learn, and present facts for decision making.
Here is a little more detail around that.
I mentioned the importance of the requirements above. Having requirements is important. Assigning priorities to those requirements is more important. (<-See what I did there?) You need to understand what are must-haves and what are nice-to-haves. For more complex assessments, I recommend applying a MoSCoW priority to each feature or capability. Beyond the requirements themselves, you will need to understand the relative priority of the other decision factors, like cost, time to market, etc.
Ideally, your organization has a standard structure for assessing technology solution options. If such is the case - kudos - proceed directly to the next step. If not, you should determine the structure you will use to arrive at a recommendation. In this case, "structure" does not refer to the document template, but to the dimensions of the evaluation. This will depend on your organization's standard decision process and what role the five dimensions I highlighted above play in it.
It will also depend on the nature of the decision you are making. If the functional capabilities of a solution are complex and critical, a weighted scoring matrix may be necessary. Perhaps your organization has established technology principles that also serve as the dimensions for technology solutions options analysis. It is useful to spend this time up front to establish the structure as you can then optimize your information gathering and analysis. You can always adjust to suit what you are learning as the analysis ensues.
A fact-based analysis requires, well, facts! There are a variety of sources for gathering information:
Now, if you are approaching this article with some critical thinking (and I hope you are), you are probably thinking those sources will not all - if any - provide unbiased facts. Bingo. It is your job to try to filter facts from fiction and present the facts.
Creating a clear document is a critical part of evaluating technology solution options. Even if you never showed the document to anyone, it is a powerful tool to help you work through the analysis and gather your facts. However, it is also critical for stakeholder engagement and decision making, whatever that approval process may be. I recommend you use a standard format for an options analysis, but that is a longer topic for another day.
Determining what you think is the best decision is only part of the challenge. Getting everyone else on board is the other! You know what they say about opinions (google it) - there will be many perspectives on the right decision. Hopefully, you included the right stakeholders in your analysis.
Perspective matters in solution architecture; each new opinion either causes you to refine your recommendation or refine your argument. Even if you did engage everyone you needed to as a part of the analysis, there are typically additional parties that need an opportunity to weigh in. This will, of course, depend on the culture and size of your organization and the magnitude of the decision, but my experience has been that there are typically a few socialization rounds for a complex options analysis before taking it for formal approval.
In most cases, the solution architect is not the decision-maker, so the last critical step is turning your fact-based recommendation into an approved decision. The specific will depend on the decision process for your organization, but it is most typically either bringing it to a decision board of some sort (e.g., an architecture review board) or presenting it to an executive for approval. In either case, if you have included the right people on your team and socialized with the rest, there should be no surprises at approval time.
That covers the basics of evaluating technology solution options, but I have plenty more to say on the topic. You can look forward to future topics on my recommended template for an options analysis and best practices for documenting technology decisions. In the end, the most important thing is that you have a process for technology solution options analysis that drives the right discussions and stakeholder engagement when making a technology decision.
