Past Performance Is Not Indicative Of Future Results—Unless It’s The Cost Of Code, Data, And Applications

Among many things, this is the time of year when financial advisors send me emails with a year-end view into my investments. Here is the exact language from one such advisor:

“Your complete financial picture. One secure place…Your dashboard offers a real-time view of your spending, saving, debt, and more with a single login…Plan for all your financial priorities—and get a clear view of your projected net worth.”

Think about that—a complete financial picture that shows a real-time view of spending, saving, debt, and more? Who wouldn’t want to know what their projected net worth is one, five, or even ten years out? Technology leaders should know this information about their technology spend. My approach is based on a simple fact I have learned through decades of implementing mission-critical data platforms for enterprise companies around the world:

Very few enterprises fully know or understand the total cost of their applications—including code and data—over time, much less when they are promoted into production.

Companies that think they know these costs are likely not tracking the actual consumption costs which are impacted by growth and capacity (excess or lacking).

What can we do to measure the Total Cost of Code, thereby saving billions on inefficient processes? We need transparency into the true cost of applications, code, and data to understand the true costs of our systems. This can only occur by forging and strengthening partnerships between technology and the CFO’s office.

When purchasing an application to provide a function for a business, many will compare at least three vendors on the basics such as functionality, pricing, and support. But a more detailed analysis of the Total Cost of Ownership (TCO) of that application over three years based on real costs might be a better approach because if two applications are essentially comparable, the TCO will distinguish the best choice.

One challenge is that the real-world costs are not public. Additionally, many vendors really do not know what the costs are because they only know what their application does, not what infrastructure and costs it will take to run the application for your business for 3 to 5 years.

Another way to look at it is: Which application will cost the least to implement, manage, and maintain over 3 to 5 years based on my business model and growth metrics?

Moving to the era of efficiency in technology, what could it mean to measure efficiency across technology systems? We need to think about efficiency in terms of mindset, action, and measurement.

• How can we change our mindset to put efficiency at the core of everything we do?
• What actions can we take to be more efficient?
• How can we measure efficiency?
• What are the impacts of the actions taken?

The way the industry looks at capacity has not changed in 20 years. We’ve been willing to live with inefficiency as long as there are no outages or issues in production. However, if something is done more efficiently, it’s going to cost less and execute faster, and there is less waste in the system, which means a smaller carbon footprint. If something is done more efficiently, we create more capacity without having to increase it, which only saves more resources, licensing costs, and money.

The design choices we make for data in terms of coding, processes, and data models all have lasting impacts on the bottom line, both from a resource perspective and more importantly on the financials, as most applications are in use for 10 to 20 years. What is the Total Cost of Ownership of that code long-term and how can this be influenced during the design process? If the code is executed five million times a day and costs $20 to run today, what will it cost to run over 5 years, taking into account business growth, cloud costs, and the code becoming more inefficient as it processes additional data?

Benefits beyond code. Scoring efficiency starts within applications, but then must track up to the overall system and someday, to the enterprise, for technology. Looking at the total cost of our systems from as early as when design decisions are made through to the life of the application means looking not just at the financial costs to the overall system but eventually to the greater environment.

One thing I’ve realized in my career: The common link among everything we do, whether it’s performance, financials, or the environment overall—it always comes down to efficiency and really, simplicity, i.e., keep it simple stupid (KISS).

Just as we do with our financial accounts, we need a way to know our technology costs today with more clarity and project out costs within our technology stack that will likely end up skyrocketing if they’re not contained. But unlike your financial accounts, where “past performance is not indicative of future results,” the past performance of your codes can tell you a lot about future performance. The question is, are we willing to listen?