The One Technology Cost You’re Not Measuring—That Could Save Millions If You Did

One of the biggest shifts to occur with the move to the cloud is how we pay for technology and applications. The industry has switched from all-you-can-process on a server with on-premise data centers to a variable, or utility compute model. According to a recent Apptio report, this means that “micro-optimizations can happen at the team level each and every day to change the shape of the cloud spend … It’s a world of OpEx (operational expenses) instead of CapEx (capital expenses), completely changing how finance is reported and managed.”

As a result, the traditional procurement model for expenses has been upended, putting the spending power in the hands of engineers who are developing and managing these applications and infrastructure with very little regard for what it’s costing the company in operational expenses. Everyone working in the technology trenches today is focused on the here and now for their specific area of ownership, ensuring the system gets through each day without an outage. No one is thinking about: Could we do what we are doing faster, better, smarter, i.e., more efficiently within the applications and processes?

Apptio, makers of software designed to assess and communicate the cost of IT services for planning, budgeting, and forecasting purposes, further describes the grim reality of this situation as “engineers making financial commitments to the cloud that affect the bottom line of their companies while finance teams struggle to keep up with the pace and granularity of spend.”

Most engineers do not control or fully understand the code they are writing; they are merely adding infrastructure to run whatever is promoted to production.

It’s not common practice in the industry to calculate the total costs for your technology environment for the hundreds of applications or technology your team is supporting. This needs to change. (Note: I am not talking about Robotic Processing Automation-RPA, using bots to automate digital tasks.) My approach is focused on the efficiency of applications, code, and processes, not efficiency through automation.

Why measuring the Total Cost of Code is important.

Applications are designed to make processes simple for the business user. It takes a lot of resources and complexity for an application to provide an answer, even if the response time is only a few seconds. Now, multiply this by thousands or millions of application requests per second across thousands of servers across your enterprise. It’s easy for things to become out of reach with so much going on simultaneously, and this relates to costs as well. If the servers running an application are supposed to last three years, but only last one because they are out of capacity—what is the true cost of that application? This is something CFOs and others need to know because they have budgets in place that need to be met.

An efficient, healthy system requires fewer resources to process the same workload than an inefficient system. Code optimization frees up even more resources.

Virtually any system has the potential to realize capacity rationalization by at least 30 to 40 percent and code-optimization may provide another 20 to 80 percent of cost savings.

This means the same workloads can be run on smaller servers, reducing cloud and licensing costs. The value of these savings is not simply short-term, but over extended periods of time as most applications now live for 5 to 20 years, or longer. It’s not just a matter of the bottom line, it’s the consideration of what could be done with this freed-up capital to further business KPIs today.

Imagine the Total Cost of Code over 20 years and consider: “Could we have made that code 20% more efficient, and, if so, how much could we have saved over 20 years?”

Then, there is the move to the cloud and the pay-as-you-go versus pay-upfront model that is running up costs to operate and maintain data systems faster than we can capture and analyze them. The Apptio report highlights how everyone loses when there is no transparency into the costs of cloud services:

• Engineering spends more than it needs to with little understanding of cost efficiency.
• Finance teams struggle to understand—and keep up with—what is being spent on the mind-boggling number of options (AWS alone has approximately 300,000 SKUs and additional thousands of new features per year).
• Leadership doesn’t have enough input into how much will be spent or the ability to influence priorities.
• Procurement isn’t a deliberate participant in its own outsourcing.

Estimating the savings, you will have if you optimize a piece of code before it makes your system inefficient (at best) or causes an outage (at worst) takes a bit more planning and insight. But it’s necessary if we want to keep up with the current rate of growth businesses are experiencing.

In my next article, I’ll talk about how we can measure the Total Cost of Code, thereby saving billions on inefficient processes. Are you with me?