Many IT mistakes track back to insufficient planning and rushing to a physical architecture. Let’s go back to the basics.

Understand the difference between logical and physical cloud architecture
Thinkstock

Throughout my career as a practitioner and teacher of cloud architecture and general enterprise architecture, I’ve focused on the distinction between logical and physical architectures.

It’s no secret what they comprise: A logical architecture is a structure of technology concepts that does not name specific technologies or brands, while a physical architecture does contain specific technologies and brands.

When I design a cloud computing architecture, I first ask what problems need to be solved. I then determine what an acceptable solution will require. Next, I list the items that need to be part of the architecture and their relationships to each other: databases, middleware, encryption, storage, compute, application development, etc. Again, no specific technologies, only technological concepts that can contribute to solving the overall problems.

The primary benefit to this approach is that it allows the architect to think more objectively about an overall technical solution. When you name a specific technology or brand of technology, you’ll build the solution around what works with that specific product and brand.

We’ve been making this mistake with public cloud providers for years. We pick a specific provider before understanding the core business and technical requirements (aka, the problems the technology must solve), and then we continue with a solution that’s native to that specific cloud provider. By choosing the brand too early in the process, we must then choose technology that fits within the constraints of a single cloud provider. Best case, the solution will run on underoptimized technology. To fully optimize a solution, we need to choose the best technology for the job and then choose the best providers.

This is the biggest mistake I see architects make these days: picking public clouds before they know and understand the problem. It happens most often with cloud-based databases that limit the brands of middleware, business intelligence systems, database admin tools, etc. Limiting your choices too early in the planning process almost always becomes a mistake.

Sadly, companies often end up with a cloud architecture that works. “It works” does not describe an optimal solution. The functional-yet-less-optimal architecture will deliver far less value than one that leverages the right technology to solve the specific business problems at hand.

To recap, a logical architecture contains a list, configuration, and interrelationships with technology as concepts. Once you have a logical architecture with conceptual solutions to specific problems, then and only then do you move to the physical architecture.

In other words, map conceptual technologies in the logical architecture to actual technologies in the physical. The physical architecture becomes the ultimate solution candidate, but the technology must still be verified with testing before you move to any sort of deployment.

There will still be bumps in the road with this process. For instance, you may define a technology concept in the logical architecture that does not exist. Specific technologies on the market may lack certain options and features, such as a database that doesn’t have built-in risk analytics for the type and model of database you logically defined. You’ll need to adjust, but these issues are the exception rather than the rule.

Also, cloud architects need to have a working knowledge of general technology concepts as well as actual technologies that can map to these concepts.

If you do logical architecture planning before committing to a specific technology, you’ll make better decisions. This also removes the “architects are people” factor since most architects have technology preferences and favorites. They could have a bias for a specific cloud provider, database, security approach, etc., which ends up being a solution that works but is far more expensive than a more optimized one.

Keep in mind that your goal as a cloud architect—or as anyone who defines business solutions from technology—is to create a solution that returns the most value to the business. Use the logical architecture approach first to give yourself a greater chance to reach that goal.

David S. Linthicum is an internationally recognized industry expert and thought leader. His views are his own.

Copyright © 2022 IDG Communications, Inc.