The biggest multicloud mistake people are making

I can tell by the hits on this blog that multicloud is more than a trend; it now drives much of the thinking about how we build and deploy cloud-based solutions. Most shifts in thinking, particularly pivots in how we do architecture, come about by good old trial and error. We learn from those who make mistakes. As usual, most of those mistakes are avoidable the second time around. What’s the biggest repeat mistake I see right now? It’s really an old mistake under the guise of new technology.

In one word: “vendorthink.” Vendorthink is the practice of allowing vendors to lead your architecture decisions rather than the other way around. When a vendor dictates how a client will use its technology to address an enterprise use case, the stage is set for multicloud to go off the rails.

The best example would be characterizing parts of a multicloud architecture, such as security, governance, operations, development, databases, etc., by how a vendor or service provider defines that solution. You’ll end up with a solution that is a list of vendor names versus a breakdown of specifics about how to optimize efficiency and meet the requirements of the business.

Ironically, we know this problem when we see it, for instance, with a security provider-defined multicloud security architecture. It’s disturbing when someone in IT uses vendor slides to define the solution rather than illustrating the core business requirements, and then force-fits a technology into a solution framework. It’s like defining an overall problem (“we need multicloud security”) and then skipping ahead to a list of what a specific vendor can do to address the problem.

What’s missing are the steps in between. First, enterprise staff needs to define the core business requirements to form an abstract architecture that does not call out specific vendors by name. Then they should produce a list of vendor candidates and the selection criteria, and define the process to select, configure, and operate the technology. Finally, and most importantly, they can illustrate how the process proves that the chosen solution is the most optimized, meaning it delivers the most value to the business for the least amount of cost.

Yes, this is a lot of work for a single architectural layer. Now, multiply this times the other architectural layers you must define, such as governance, operations, storage, etc., and you’ll quickly see that getting something right the first time is a daunting task. It’s much easier to go to a vendor or service provider conference and select something that seems logical rather than formally define the problems.

The reality: It’s easy to get things wrong and perhaps not even know that you did. In most of these types of architectural choices, the vendor-led solution does work—or is made to work. However, it will live on as an inefficient solution, and it drains value from the business rather than providing it.

How do you avoid vendorthink? It comes down to leadership and asking the right questions to ensure that the multicloud architecture, development, and migration teams all think in ways that will lead to the most optimized solution. Working against you are billions of dollars of vendor marketing, as well as the fact that many architects train with vendors to get vendor-oriented certifications. There’s nothing wrong with that unless it impairs your judgment to make completely objective decisions.

Vendorthink is an easy mistake to avoid. Unfortunately, it involves a lot of extra work, but it will pay off in the end.