Gartner estimates global IT debt at $500 billion in 2010, potentially doubling to $1 trillion in five years. What does this mean for your business? How can IT decision makers use open source software to help address this “IT debt”?

What is IT debt?
Hardly a week has gone by in the past three years where debt – too much of it, or the risk associated with it – hasn’t played a prominent role in mainstream news headlines. Earlier this week Gartner added to these headlines, but with a twist – IT debt.

Andy Kyte, vice president and Gartner fellow, has written a fascinating research report about global IT debt. Gartner defines IT debt as “the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state.”

IT debt hinders business agility
The reason that companies should be concerned about IT debt is because this form of debt hinders IT’s ability to meet line of business requirements at the rate and pace required by the market. Findings from IBM’s CEO Study, based on over 1500 face-to-face interviews with CEOs of companies of all sizes across 60 countries and 33 industries, continue to highlight the importance of responding to market opportunities and growing complexity faster.

It’s incredibly difficult to respond to market changes or deliver IT systems that support new business designs when underlying IT systems are too brittle to accept change.

Kyte explains how IT debt has built up over time:

Over the last decade, CIOs have frequently seen IT budgets held tight or even reduced. The reaction has been to still deliver quality of service for operational services and to use any potential project spend to deliver new functionality to the rest of the business. The bulk of the budget cut has fallen disproportionately on maintenance activities — the upgrades that keep the application portfolio up-to-date and fully supported. There is little problem if this is done in one year, or even in two years, but year after year of deferred maintenance means that the application portfolio risks getting dangerously out of date.

Why do CEO seeking business agility accept IT debt?
Israel Gat, senior consultant with Cutter Consortium and CEO at The Agile Executive, attempts to uncover why CEOs have been willing to accept alarmingly high levels of IT debt.

Gat draws from “The Big Shift: The Mutual Decoupling of Two Sets of Disruptions – One in Business and One in IT” [PDF] by John Seely Brown. Gat summarizes five key findings from Brown:

  1. The return on assets (ROA) for U.S. firms has steadily fallen to almost one-quarter of 1965 levels.
  2. Similarly, the ROA performance gap between corporate winners and losers has increased over time, with the “winners” barely maintaining previous performance levels while the losers experience rapid performance deterioration.
  3. U.S. competitive intensity has more than doubled during that same time – i.e. the US has become twice as competitive.
  4. Average Lifetime of S&P 500 companies ha declined steadily over this period.
  5. However, in those same 40 years, labor productivity has doubled – largely due to advances in technology and business innovation.

Gat uses Brown’s findings to explain the business agility vs. IT debt paradox:

Put yourself in the shoes of your CFO or your CEO, weighing the five facts highlighted by Brown in the context of Highsmith’s technical debt curve. Unless you are one of the precious few winner companies, the only viable financial strategy you can follow is a margin strategy. You are very competitive (#3 above). You have already ridden the productivity curve (#5 above). However, growth is not demonstrable or not economically feasible given the investment it takes (#1 & #2 above). Needless to say, just thinking about being dropped out of the S&P 500 index sends cold sweat down your spine. The only way left to you to satisfy the quarterly expectations of Wall Street is to cut, cut and cut again anything that does not immediately contribute to your cash flow. You cut on-going refactoring of code even if your CTO and CIO have explained the technical debt curve to you in no uncertain terms. You are not happy to do so but you are willing to pay the price down the road. You are basically following a “survive to fight another day” strategy.

How companies can start to minimize IT debt
To put Gartner’s $500 billion global IT debt estimate in perspective, IDC forecasts the total 2010 global packaged software market, across operating systems, middleware and applications, at just over $280 billion. This $280 billion includes spending on new licenses and ongoing maintenance subscriptions.

At a simplistic level, companies would have to stop new software license and ongoing maintenance renewals for nearly two years just to clear the IT debt backlog – a scenario that few IT decision makers, or their CEOs, would support.

There is no silver bullet for companies to reduce their IT debt. Rather, companies will need to take incremental steps over several years.

First, work to hold the line on IT debt. Gat recommends IT departments combine technical debt measurements with software process change. Gat suggests “…you stop the line and convene an even-driven Agile meeting whenever the technical debt of a certain build exceeds that of the previous build.”

This first step clearly requires buy-in from line of business and C-level executives. Buy-in will require line of business and C-level executives to understand the relationship between IT debt and business agility. The fact that CEO claim business agility is a key corporate requirement, and yet, accept IT debt, suggests that the linkage between IT debt and business agility is not well understood. IT decision makers are encouraged to draw from Gat and Kyte’s research to demonstrate the linkage to C-level executives.

Use Open Source based on technical and business needs
The second step is to reduce the cost of running existing or new applications and redirect the savings to tackle existing IT debt. Open source software can play a role in this step.

Using open source software, with or without a support subscription, often carries a lower cost of acquisition versus closed source alternatives. However, IT decision makers should look beyond initial cost of acquisition, and rather, focus on total cost of ownership.

An IT department could choose to run an open source product in production without acquiring a support subscription. The cost of the software license and support subscription would be zero and zero. However, that’s not entirely true. The cost of supporting and keeping the software current has simply shifted from a yearly subscription payment made to a vendor or support provider, to the salary cost of an employee who undertakes the effort. This employee is thereby unable to do some other work for the department. Don’t ignore the people costs of software selections.

A more typical scenario is using a commercial open source product in place of a higher priced closed source alternative. However, it’s again important to consider the total cost of ownership (TCO) which includes costs such as training, hardware required, administration costs or cost of downtime. Not surprisingly, TCO, is heavily related to the project at hand.

For instance, TCO studies using open source and commercial Application Server products, which I’m most familiar with, reveal that both sets of products can deliver lower TCO than the other, depending on the project’s technical and business requirements.

This doesn’t sound as appealing as blanket statements that suggest: “open source is always cheaper” or “commercial software is always superior”. However, reality is always more nuanced than marketing messages or pundit sound bites would suggest.

IT decision makers are encouraged to analyze technical and business needs, and align them to open source or closed source software using TCO metrics. Consider prioritizing projects where the cost savings from using open source software in place of closed source, or vice versa, can be used to tackle your IT debt.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”