3 signs of an overengineered enterprise cloud solution

Overengineering is the process of designing a product with more features than necessary. When deployed for its intended use, the product is unnecessarily complex, inefficient, or both. The increased costs, risks, and/or complexities of the system will eventually result in its failure.

Here are three signs of an overengineered cloud solution:

Sign #1: The lack of centralized command and control. The core problem for most enterprises is a lack of centralized planning. The pandemic sped up the use of cloud-based resources, and that caused many enterprises to rush through implementing their cloud solutions without proper planning or centralized command and control. When it comes to common services, operations, security, etc., too many choices and a lack of governance quickly lead to a hot mess that teams could make work in the narrow, but not in the wide.

For example, a public cloud is added to a multicloud deployment because a single development team said they needed a specific database that runs on a specific cloud. The addition happened without examining the cost, ops, and complexity of managing a public cloud that provides one service to one team.

Many cloud projects have subprojects that are decoupled from each other. Independent solution planning often results in different approaches and technologies. A lack of coordination between development and migration teams will not magically lead to a fully optimized meta-architecture for your cloud solution. Instead, the lack of central control and coordination will most often result in a solution with too many moving parts.

Sign #2: No single source of truth for enterprise data. The idea: Moving to cloud will finally provide us with the ability to centralize our data within a single go-to database (physical or abstract) to store important data such as customer, sales, or inventory.

The reality: With no centralized coordination around common database services, teams will stand up too many different types of databases during the move to cloud. You will never get to a single source of truth.

The development or migration teams often choose more databases with more differences than necessary. This just means more silos. On an individual basis, the teams’ decisions are often made for good reasons. However, the impact on the enterprise’s cloud deployment is too much complexity, thus increasing cost and risk.

Trekkies might recall Mr. Spock’s statement: “Logic clearly dictates that the needs of the many outweigh the needs of the few.” Someone with centralized authority needs to apply Spock’s logic to enterprise data and databases as they move to cloud.

Sign #3: The cloud solution costs much more than the status quo. Much like doctors take an oath to “do no harm,” those charged with selecting and configuring cloud and non-cloud technology should never end up with a cloud architecture that costs significantly more than the architecture’s prior state.

Although it’s common to spend more on a cloud solution than on its starting point, you must also factor in its many advantages to the business. A good rule of thumb for acceptable cost increase would be perhaps 10% to 15% more than its starting point, at most. However, I see end states that are 30% to 50% more costly, with no clear business benefits to justify the extra costs to build new in the cloud.

There is no one way to do cloud architecture, but the most successful cloud architects keep a close eye on centralized efficiency and cost optimization. Overengineering happens when we add too many unnecessary features just because we can. These features drive up the costs without a counterbalancing ROI. Value-added cloud architecture typically happens when the least amount of overengineering takes place.