Efficiency: The Most Important KPI You’re Not Thinking About

Every system strives to be more efficient, whether that’s a family, school, city, business, corporation or society. Inefficiency breeds waste, and no one likes waste. What if an application costs one thousand dollars to run but only needs to cost one hundred dollars to get the same results?

To increase efficiency, we must reduce the resources each application process or code uses, thereby lessening the burden on the server upon which everything is running. If you’re not using the capacity, you don’t need it, at least for now. However, we need to shift focus to the bigger, long-term capacity plays at hand if we want to make a real impact on efficiency. And we need to define a measurement standard for efficiency across the industry and over time.

More Cloud ReadingCloud Spending Infuriates Executives. Here’s How to Solve It.

Fuel Efficiency for Applications

There is a standard that exists that says one gallon of gas yields a certain number of miles, and this comparison holds true against any type of car built in any year by any manufacturer. Similarly, we need a “true MPG” measure for efficiency in technology.

By having a standard measurement of efficiency, each application and piece of code in the application can be assessed during the development life cycle. Similarly, we can measure existing applications in production to see which applications or servers have more efficient workloads and which ones need to be optimized.

Another important consideration these days is the cloud. If an application is not efficient, do we want to migrate it to the cloud since we know it will cost more?

What About the Cloud?

Many think the cloud capacity is endless, but it is not. Microsoft, Amazon and others have literally run out of resources in certain regions or data centers. Cloud-based services, such as Microsoft Azure, use terms like massive and enormous to describe the storage options available with their platform, as not only businesses but also entire American cities are trusting them with their information.

And these words may not be enough to describe the magnitude of the situation.

In 2019, the World Economic Forum reported that, in the coming years, common units of measure, such as megabytes, gigabytes and even terabytes, will begin to seem quaint — because the entire digital universe is expected to reach forty-four zettabytes by 2020. If this number is correct, it will mean there are forty times more bytes than there are stars in the observable universe.

Rather than worry about the future capacity of cloud storage, I think we should be worried about what impact the exponential growth in data and transactions will have on the efficiency of systems going forward.

When you buy the next application for your business and want to host that application in the cloud, where would you begin to look for cost estimates or comparisons to see what the monthly cost will be based on your business use? Often, application vendors do not know what their applications will actually do for your business.

Why? Because they are really good at building functionality for the business users and industry, but they are not infrastructure experts and cannot predict what your resource usage would be since each company has different workloads and growth rates. Therefore, they will provide you with the basic server requirements and say, “This should work for you.”

The challenge most organizations encounter is that after months or a year, the server is having performance problems or is out of resources. So they add more space, thereby decreasing efficiency by using more resources to process the same requests. My goal is to change this Groundhog Day scenario by instrumenting efficient scores across the organizations for all servers, applications and codes. If enterprises are successful in implementing controls with application development to only accept code that meets or exceeds the efficiency standard, then they will be able to reap the benefits.

The 20-Year View of Code

When developers write code for applications, 99.9 percent will never know or care how many resources that code uses or how much it costs once it’s in production. Most developers never know if this code is being called one time or ten million times in production, nor do they know how long the application will live — one day, 10 years or 20 years. 

But what if that piece of code could be 10 percent more efficient — or 50 percent? What is that code really costing us over the life of the application? What if your company writes applications that are used by other companies and your application is installed at one thousand other companies? What is the cost of that inefficient code across the one thousand implementations?

What would the impact on the customer experience be if that code could be faster? People are impatient and expect a quick response time. We are not thinking about the 20-year view when we ask someone to build a widget for us, but we need to start measuring efficiency just in case our application is successful. We need to set higher expectations around it. In the end, both the company and users benefit from an efficient application because it is faster, uses fewer resources and saves money.

As the amount of data grows over time, the code will use more resources to process each request, which costs more money. If we amortize and depreciate the cost of business equipment over time, why aren’t we considering these metrics for applications or processes as well? Separate from data growth is the growth of your customers, a.k.a. users of the system. As the amount of data and transactions grows, the number of resources will grow at a higher rate and compound over time. Now think again — what is the cost of the bad or inefficient code over the lifetime of the application?

As everyone moves to the cloud and to a utility compute model (charging per consumption), it brings to the forefront the issue of poorly designed processes that use more resources. Why? Because the current goal for application development projects is for the code to meet functional requirements (i.e., solve a request), pass QA and be placed into production. This model doesn’t consider the bigger picture, which is where the greatest inefficiencies lie. It might cost $200 to develop the code offshore and get the job done. But if the code is inefficient, it could cost the company tens of thousands of dollars over the next twenty years. Just like MPG, each application needs a rating to determine its efficiency so we can prioritize refactoring and optimizing inefficient processes that are costing the most money every day.

no room to growHow Data Center Shortages Could Hinder the Future of AI

Developing an Efficiency Standard

As the focus on technology shifts to creating greater efficiencies within systems, we need to create efficiency benchmarks to measure against a target MPG for applications, if you will. Since efficient applications and systems use less power, cooling and system resources, which benefits the environment, we can make a case for a sustainability focus as well (e.g., technology groups earning green certification, just as businesses do).

We’ve been living in a world of abundance when it comes to technology for 20 years, yet we haven’t changed the way we’ve been looking at the health or efficiency of technology systems. There will come a time when we cannot keep adding more resources, as it will be physically challenging and cost-prohibitive to do so. Technology budgets are not infinite, and data centers, cloud or not, are not infinite. 

If you are designing a brand-new application, you should be thinking about its efficiency over time, especially if you are going to be hosting and supporting it. Ask and answer these questions before you build:

Application Questions

• How many users will be on the application in 12 months?
• How much data will be created in 12 months?
• What is the estimated annual growth rate of application users and data?
• How will this affect the resource consumption of the application?

Code/Process Questions

• How many times will the main functionality (code) be called in a day?
• How many resources (CPU, memory, storage and bandwidth) will the code use in a day?
• What is the financial cost of this code for each execution? What about over the next 12 months? Next 10 years?

I can envision one day when we can see the relative financial cost of code before we deploy it to production. Only then can we truly own our own destiny in a utility compute model.

Excerpted and condensed with permission from Chapter 3 of  The End of Abundance in Tech: How IT Leaders Can Find Efficiencies to Drive Business Value, by Ben DeBow, published by ForbesBooks. Copyright 2023 by Ben DeBow.