From the hits in this blog, I can say that multi-cloud is more than a trend; now this leads to much of the thinking about how we build and deploy cloud-based solutions. Most changes in thinking, especially in the way we make architecture, happen through good old trials and errors. We learn from those who make mistakes. As usual, most of these mistakes can be avoided a second time. What is the biggest repeat error I see right now? This is really an old mistake under the guise of new technologies.

In a word, “think of a salesman.” Vendorthink is the practice of allowing suppliers to manage your architectural decisions, not the other way around. When the vendor dictates how the customer will use their technology to handle a corporate use case, the stage is ready for the multi-cloud to derail.

The best example would be to characterize parts of a multi-cloud architecture, such as security, management, operations, development, databases, etc., according to the way the provider or service provider defines this solution. Eventually, you’ll get a solution that is a list of vendor names versus a breakdown of specifics on how to optimize performance and meet business requirements.

Ironically, we know this problem when we see it, for example, with a security provider-defined multi-cloud security architecture. It is worrying when someone in IT uses vendor slides to define a solution instead of illustrating basic business requirements, and then forcibly incorporates technology into a solution framework. It’s like defining a common problem (“we need multi-cloud security”) and then jumping forward to a list of what a particular provider can do to address the problem.

What is missing are the steps between them. First, the staff of the enterprise must define the basic business requirements in order to form an abstract architecture that does not call specific suppliers by name. They then have to draw up a list of suppliers and the selection criteria and define the process for selecting, configuring and operating the technology. Finally, and most importantly, they can illustrate how the process proves that the chosen solution is the most optimized, which means that it provides the greatest value to the business at the lowest cost.

Yes, it’s a lot of work for an architectural layer. Now, multiply this by the other architectural layers you need to define, such as management, operations, storage, etc., and you’ll quickly see that fixing something the first time is a difficult task. It is much easier to go to a provider or service provider conference and choose something that seems logical than to formally define the problem.

Copyright © 2022 IDG Communications, Inc.

Previous articleGoogle Doodle for Teacher Thanksgiving, inspired by learning tools
Next articleTry these hidden photo tricks on your smartphone