Defining ‘value’ with cloud architecture

During the pandemic, I started learning how to rebuild and repair bicycles since there was a cycle shortage and buying new was limited and costly. With gyms closed, I began to fix bikes for friends and family to get them back on the road as well. 

Bike components are a good model for the concept of value. You can pay $50 to $1,000 for a bike wheel (if full carbon). The question is, what is the best value of that component based on your needs? How do you find the true best value?

Value is one of those words that means many things. However, in the terms of cloud computing architecture we can define it like this:

Value is the balance between money spent and the relative benefit we get for spending that money.

In cloud architecture, spending too little or too much is likely not the optimized choice. You need to find a place between the two extremes to optimize the configured cloud solutions and balance the costs with the core benefits that come back to the business.

Figure 1 provides a good visional depiction of this. Note that the blue cost line goes up and to the right, representing an increasing amount of money spent on cloud components, such as databases, security, governance, platforms, storage, etc. The other line depicts the benefits to the business, which rise as the cost goes up until about the center of the chart, then they taper off. 

IDG

Figure 1

At some point, spending more money does not return the same ratio of benefit to the business. This is one example of a few things that are not very well understood in the cloud architecture community right now:

You can create many cloud technology configurations and solutions that technically work but are not optimized for cost and value. They cost the business too much in terms of benefits that come back to the business. I see this mostly in organizations that are not optimizing existing assets such as mainframes but instead are force-fitting more hyped and emerging solutions. The cost will be much higher, and the value not as much.

Complexity is not value. Those deploying multiclouds may be considering the “value” of being able to leverage cloud services from two or more public cloud brands. However, they may not have factored in the operations costs of all those very heterogeneous cloud services. They may have the perception of value by having more choice, but that choice leads to operational complexity and systems that are more costly and difficult to secure. Again, cost is higher, and the benefits don’t increase in proportion.

Most organizations work within budgets and have to give and take. Spending more than you need to on one cloud service without obtaining the right amount of benefit means that you can’t spend on other cloud services you may need more—one that would provide a much greater benefit for the money spent.

This does not mean that emerging technology and complex multicloud solutions are never the best value. Obviously, this is problem-domain dependent, and the most optimized solution in terms of value will vary greatly from organization to organization.

I’m arguing that value is truly dynamic and should be understood in the context of cloud architecture and the trade-offs we all must consider. Although we can never be fully optimized as to value, getting close means serving the business better—in some cases, saving the business.

Now, I need to find a good value for a needed bike tire.