Accounting for Technical Debt

Accounting for Technical Debt

CIOs must do the math and pay down debt before it hobbles business performance.

Wayne Sadin, a veteran CIO and current chief digital officer and CTO for senior living provider Affinitas Life, doesn’t mince words describing the scale of technical debt in most companies:

“It’s a bigger off balance sheet liability than Enron or Worldcom.”

Wayne Sadin

The term ‘technical debt’ was first used in software development in the early 1990s, to describe the costs incurred when an expedient route is chosen instead of a better long-term approach that would take more time and effort.

In recent years, enterprise IT organizations have co-opted the concept to describe the debt incurred as a result of choices such as deferring systems maintenance or upgrades — ‘deferred’ often being a euphemism for ‘never going to happen’.

Over the years, many CIOs have found it difficult to obtain funding for infrastructure and application maintenance. The catch, of course, is that the impact of those decisions could remain hidden for years — until the derelict systems begin failing or otherwise prevent the enterprise from moving forward.

“It’s an off balance sheet liability that’s growing and has not been accounted for as it should be to stakeholders,” said Dion Hinchcliffe, vice president and principal analyst at Constellation Research.

The pressure to digitally transform the organization is shining a spotlight on the issue, revealing a legacy of short-sighted choices is standing in the way of organizations moving toward the future.

Technical debt is an off balance sheet liability that’s growing and has not been accounted for as it should be to stakeholders.

- Dion Hinchcliffe, Constellation Research

In some cases, companies are spending 90 percent of their budgets keeping older IT systems up and running, leaving little for new digital development. What’s more, outdated systems create a fragile foundation upon which to build modern business systems and processes.

“Software is an asset that rusts. Hardware becomes less reliable,” said Sadin. “As the rest of the world evolves, this will continue to be a problem.”

The solution, these experts say, is to fully account for technical debt — locating it, categorizing it, and even calculating the cost of eliminating it.

That process itself is not easy. It requires uncomfortable conversations with business leaders and boards requesting significant budgets for work that, in isolation, seems to offer nothing new to the organization. But there are ways to quantify the costs and potential benefits, and align these investments with business goals — for those forward-looking CIOs willing to do the work.

How Technical Debt Accumulates

So how did we get here? Technical debt is fraught topic for CIOs, in part, because it’s tough to explain to non-IT decision makers.

“In many cases, CIOs have inherited technical debt,” Hinchcliffe said. “And few business leaders really understand how deeply complex and interconnected IT is, and how technical debt can accumulate in ways that aren’t visible.”

Company leaders who would consider it ludicrous not to maintain their multi-million dollar physical assets—a new oil refinery or factory—think it is perfectly reasonable to invest millions in IT hardware and software assets but not earmark budget for their IT maintenance or upgrades or security.

“Boards don’t ask about the five year total cost of ownership. They want the benefit now, and the IT leaders try to figure out a way to pay for the maintenance later,” said Sadin.

“Or the CIO will go in with IT project and the business said ‘do it but cut 10 percent out’.” There goes any further investment in the systems. Later never comes, because from the outside all appears well — until suddenly it doesn’t.

A car that doesn’t get regular tune-ups can keep driving down the road for years, but you don’t want to be in it on the day it doesn’t. “Everyone wants the sizzle and they’ll give you the money for the next new thing,” said Sadin, “but not for that oil change or new hubcaps.”

Dion Hinchcliffe

Enterprise IT debt includes a range of things, said Hinchcliffe: “Upgrades delayed; expedient decisions made in governance or enterprise architecture that solve short-term problems but create bigger long-term issues; underinvesting in security hoping to fly under the radar until you realize that catching up will require an inordinate amount of effort.”

It’s insidious, happening one decision at a time. Unlike other physical assets, the coding, design, and architectural choices in IT are intangible and hard to discern until some change in conditions suddenly makes them apparent.

Put simply, it’s any “unwanted and additional financial and administrative overhead associated with conscious or unconscious decisions associated with IT,” said Mustan Bharmal, head of enterprise architecture for the Royal Mail Group.

“It can be both known and unknown (with respect to both existence and debt value) and also tangible and intangible (with respect to measurement and monitoring as well). This makes it very hard to proactively manage this type of technology risk.”

Don’t Let the Digital Transformation Engine Seize

Enterprise IT debt are a lot like pension obligations, with companies kicking the can down the road until, for one reason or another, that payment becomes due. “At some point, the situation becomes overwhelming and requires C-level and boardroom attention,” said HInchcliffe. For many enterprises, that reason is digital transformation.

“I have clients that are still running mainframes because they haven’t been willing to pay off that technical debt and rewrite systems,” Hinchcliffe said. “It’s literally an albatross around the neck of the IT organization.”

It’s a huge and growing area of unmitigated corporate risk, opening the door to potential failures or security breaches. However, “the more insidious problem is not the risk which knocks you on the head,” Sadin said. “It’s digital disruption and transformation — the reinvention of what you do.” If the business wants real-time mobile functionality bolted on top of 30-year old architecture, it’s not going to work without significant remediation.

Board member and business leaders should be demanding to know how likely the IT environment is to fail or be breached—or how much of a barrier technical debt is to the enterprise’s competitive position. But they’re not. It’s up to CIOs to do the work of uncovering the nature of the debt portfolio they’re holding and explain it to IT’s stakeholders in terms they understand — dollars and cents.

Hard Numbers

IT leaders don’t want to ignore technical debt. Most CIOs aspire to manage and remediate it. In reality, however, “this is rarely done in a consistent, efficient and effective manner,” said Bharmal.

At best, they may have some informal measures or calculations. There are any number of reasons for this–poor and inconsistent understanding across the enterprise of the business risk of enterprise IT debt, lack of supporting processes and behaviors to address it, lack of ability to quantify obvious technical debt or turn unknowns into knowns.

However, it’s clear that organizations that have made the effort to address enterprise IT debt are moving more quickly and effectively today, said Hinchcliffe, noting that digital leader Nordstrom spent five years modernizing their systems in order to create a solid foundation for digital transformation.

CIOs can begin to institute processes to measure technical debt. Although there is not great maturity in this area, said Hinchcliffe, it’s something IT leaders that want to embark on meaningful transformation can — and must — begin to attempt.

Whenever Sadin takes on a new CIO role, the first thing he does is inventory the infrastructure and application stack to understand the technical debt landscape. Some aspects of enterprise IT debt are straightforward: A CIO can calculate the cost of bringing a legacy system up to date. If you have a general ledger suite that is seven releases behind, it can be relatively simple to determine the costs to upgrade, depending upon the amount of customization that was done. Custom-built software can be a bit trickier, but IT staff and auditors can help the CIO quantify the various options.

In some cases, it may make more financial sense to keep the debt on the books, said Bharmal, such as when it is associated with a part of the business that is planned for divestment, or where the costs of remediation clearly outweigh the benefits.

Quantifying risk or opportunity can require more nuance. IT analyst firms offer tools to help CIOs calculate the total cost of ownership and ROI of IT decisions.

“It may be harder to describe what opportunities technical debt is preventing,” said Sadin. “For that you have to be more plugged in to future plans and understand where the company is versus its desired state, and conduct gap analysis.”

If the company wants new augmented reality functionality, for example, the CIO can work with those in architecture to quantify the cost of upgrading the foundational systems to support that move. This works best if the CIO can do a bit of forecasting of future needs, based on trends in the industry or adjacent ones, Sadin said, rather than waiting until someone asks for the system to tell them it will take 18 months and $18 million dollars before it can be done.

Getting There from Where You Are Now

Hinchcliffe and Sadin agree that for most shops, technical debt has become an urgent matter. However, that doesn’t mean it can get resolved all at once. CIOs should expect to turn their math into a long-term remediation plan.

“No new CIO wants to come in and say ‘I did an audit and we’re in big trouble.’ People shoot the messenger,” said Hinchcliffe.

No new CIO wants to come in and say ‘I did an audit and we’re in big trouble.’ People shoot the messenger.

- Dion Hinchcliffe

Instead, CIOs must “take these off balance sheet liabilities and make them more explicit. Then address it — not all at once, but over time. Build credibility as you spend down technical debt,” he said. “CIOs need to band together and educate business side more. Business is going to ask a lot of tough questions.“

But as Sadin also noted, “As an industry, we need to stop pretending that just because something’s running, that means it’s OK.”

Doing the Math: Technical Debt

Mustan Bharmal, head of enterprise architecture for the Royal Mail Group, described two scenarios to illustrate the types of variables and steps involved in addressing technical debt.

Scenario 1
The enterprise did not foresee or consciously calculate that a past decision would generate the technical debt that it has now identified and quantified. Bharmal said this is probably the most common case.

In this case, remediation would involve:

  • Calculating the cost to completely remediate the identified technical debt, and performing a viability assessment of the remediation act itself – asking the question “what will happen if I do not remediate this technical debt?”
  • Using these calculations and risk assessment to secure unplanned funding to address the situation. The success of this approach is tied to the credibility of the risk assessment.

Also preparing for currently unidentified technical debt would involve combining the risk assessment with experience-based knowledge to calculate a ‘contingency remediation budget’.

Scenario 2
The enterprise is already aware of the potential for a current decision to generate technical debt in the future.

Remediation would involve:

  • Calculating in today’s terms what resources (time, people, and money) would be required to totally remediate the technical debt at a specific point in the future.
  • Preparing, within the business case for the instantiation of the IT decision, a budget to cover full and complete future remediation of the technical debt, again in today’s terms.
  • Ensuring (post-decision instantiation) that the technical debt ‘amount’ is regularly reviewed over time, so that the budget can be revised accordingly. Depending upon the rate of technological advancement in the area associated with the technical debt, Bharmal noted, the remediation amount may change drastically from the original forecasted value.

In this scenario, an organization that also wants to prepare for the unknown will add an educated estimate (based for example on analysis of previous technical debt remediations) for a ‘contingency remediation budget’, securing this amount on an index-linked basis in each annual IT budget.

Bharmal said this latter scenario, including the approach to unanticipated future debt, is the one enterprises should aim for.

Did you like this article?


Digital Transformation