We have experience with an insurance company that wanted to take its first steps in a digital transformation. With a goal of improved customer experience square in its sites, the new initiative would overhaul the company’s website and establish a true handheld mobile device presence for the first time. Management was onboard and ready to write the check to drive the transformation over the next few years. The Marketing, Sales, and Finance teams stood ready to provide support. Information Technology was energized.
Then, the chief architect and CIO broke the news: since existing systems were so old and poorly maintained (due to historically insufficient attention to capital improvement), a significant amount of backend modernization would need to be completed before the customer experience work could begin.
The next two years were spent re-coding websites, modernizing integration points with legacy systems, and addressing security concerns. This work was required to lay the foundation for improving the customer experience, that would eventually drive new revenue. Little movement was made on “transformation” during those two years. Technical debt got in the way and made IT hard.
As part of our ongoing series on why IT is so hard, we continue the discussion with the introduction of technology debt. Tech debt is the implied cost incurred when organizations do not fix problems that will affect them in the future. There are several types of tech debt.
Constructed Debt: building customizations to packaged software that complicate updates/replacements; or constructing “temporary” solutions without fully understanding the environment or technology. (For example: Customizing a vendor software solution. When new versions are released, the update cannot simply be applied.)
Aging Debt: as systems age they become inefficient, incompatible with newer linked systems, and they should be replaced. When systems are not replaced, they can become debt. (For example, a CFO said that the financial ERP was not broken yet so we could wait a few more years without vendor support before migrating to a current and supported version from this decade). As systems age, they are often more complicated and expensive to replace.
Knowledge debt: in 2002, Sheila was a master coder. She solved all the organization’s problems on the AS/400. In 2021, Shelia retired. She left no documentation; and her code lacked comments, was not structured in design, and could not be reverse-engineered without great effort.
Technical debt examples are everywhere:
- Highway improvements cannot be made due to the debt of crumbling bridges
- Highspeed rail cannot be implemented because of insufficient tracks that have not been upgraded for decades
- An ERP replacement impacted by the debt of legacy software and hardware that have not be sufficiently well modernized, documented, or supported
The ACME company acquired a new business with the intent to integrate operations and systems. Due diligence teams completed their assessment; however, information technology was not involved. Management decided that while not simple, the merger appeared straight forward. When eventually brought to the table, IT’s assessment was that systems integration would not be done so easily:
- The acquired systems, while still functional since being built in 2003, were written in a language that few understand in 2023
- The on-premises hardware of an acquired company has not been updated with the latest system releases and patches (and after the acquisition, the non-IT leadership fired the one woman who understood the hardware)
- There was no documentation of the data repository, making opportunities for combining data into the corporate data lake significantly complex
Why Technical Debt Matters…
Like financial debt, technical debt needs to be paid down. Having too much can suffocate organizations’ opportunities for future investment. Organizations pay interest on technical debt in the form of resources committed to maintaining systems which are outdated but which are nonetheless critical to operations. Eventually, the principal must also be paid in the form of a major upgrade or investment in completely new solutions. This is a hard pill to swallow because the best outcome is generally just staying even. Fixing outdated legacy systems is table stakes. It is like paying off the credit card balance: writing a big check but receiving nothing in return, other than literally zero (as in a zero balance).
The effort to pay down the interest and principal can consume a staggering proportion of an organization’s budget and brainpower. This can be a challenge for any organization. Remediation initiatives become Information Technology’s top priority. Other work is de-prioritized, including revenue-driving initiatives advocated by business leaders with P&L responsibility. Understandably, business leaders become unhappy.
As illustrated by the case of the aging ERP noted above, leaders like return on investment. Upgrading or replacing an ERP ahead of the last possible moment does not increase revenue. Nor do new PC operating systems, refreshed servers, faster networks, or better help desk ticketing (IT Service Management) systems. In short, winning business cases tend to be revenue drivers. Good CEOs understand that cost-centers, like IT, require investment to stay current. But they don’t necessarily know what those investments need to be. That is why they hire CIOs.
…and What Organizations Can do about it
In terms of managing technical debt, a critical skill for a CIO is the ability to communicate, sell, and build consensus. A CIO must be able to convince an operational leader, the senior leadership teams, and/or the board to make major investments that have a zero-revenue return. The CIO and the IT organization are responsible for doing what it takes to keep the technology up to date. Part of what it takes to fix technical debt is to make a persuasive case. Systems need to be upgraded. Aging systems must be replaced before they become “bad loans” and begin to incur unwanted debt. In our experience, strong leadership within IT is a must for avoiding a technical debt crisis.
While fostering strong leadership who advocate for investment in modern platforms is key, there are no magic bullets. To a large extent, avoiding technical debt comes down to good habits and good decisions. Homeowners, over time, replace windows, roofs, and old pipes. Nothing magical about that. It’s just anticipating needs and putting aside money. Admittedly, this simple formula becomes complicated in large organizations with divergent needs from competing stakeholders. Nonetheless, to build good habits, organizations can try the following:
- Educate leadership in information technology through regular briefings
- Carve out capital to begin remediating debt before it is essential to do so
- Adopt principles of no customization and instead rely on configuration to meet operational needs
- Document, document, document
- Keep service level agreements current, software patched and up-to-date
The term Technical Debt was originally coined by software developer Ward Cunningham, one of 17 authors of the Agile Manifesto. Once a modest challenge to prevailing wisdom, Agile methodology is mainstream in the 21st century. Now it’s time for Technical Debt management to step fully into the mainstream before it becomes a crippling albatross around the necks of companies, universities, and non-profits.
If your organizations is beginning to feel the pressures of Technical Debt (or you want to avoid it altogether), TSI can help you with that. A Technology Assessment is one of the first steps in understanding your debt position.
