Close

Evaluating Technology Solution Options

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

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.

Woman in front of 3 doors as a analogy for evaluating technology solution options

The Foundation for Evaluating Technology Solution Options

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.

Technology Decisions Refresher

In my prior article on technology decisions, I highlighted the five key dimensions that define “better,” when making better technology decisions. They are:

  1. specific business drivers,
  2. organization's strategy,
  3. technology vision,
  4. risk appetite, and
  5. technology operating environment.

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.

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.

Technology Guardrails

Operating Environment circa 1959

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.

The Process for Evaluating Technology Solution Options

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.

Process for Evaluating technology Solution Options

Here is a little more detail around that.

Validate Priorities

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.

Structure the Decision

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.

Gather Information

A fact-based analysis requires, well, facts! There are a variety of sources for gathering information:

  • Interviews. These are with subject matter experts both within and external to your organization
  • Google. Or your search engine of choice can return plenty of information.
  • Industry Analyst Research. If you organization has contracts with any research firm, they can be a great source of perspective. If not you can often acquire industry analyst research for technology products from a vendor who was rated well in the research as they are eager to share it. Industry research includes the big name brands as well as the cottage industry of sites that pop up around a business domain.
  • Other Companies. If you maintain a network of peers in the industry (you should), then many times other companies will be willing to share their practices and lessons learned to help you gain some practical information. You are best off approaching companies that are not competitors.
  • Data. It is not always possible, but acquiring pertinent data – from industry numbers and surveys as well as internal sources (e.g., service desk ticket counts) – can help drive fact based analytics of the situation.

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.

Document analysis and recommendations

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.

Socialize the results

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.

Gain 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.

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 *