In a global survey of 500 IT leaders in 2021, 69% of respondents identified technical debt as a major limiting factor for their organizations.1 In 2022, CIOs also reported that issues due to technical debt comprised 10-20% of their new technology budgets.2 Additional surveys on legacy systems found that 73% of respondents had initiatives to reduce technical debt associated with legacy systems.3
This article explores the concept of technical debt, examines its implications, and offers strategies for reducing it.
Although legacy systems can take many forms from hardware to software, this article uses the accounting and job cost system (or enterprise resource planning (ERP) system) as a case study. While ERPs are a common legacy system, this is not to suggest that all ERP systems are. The examples, approaches, and techniques outlined in this article can be applied to other systems and technologies.
What Is Technical Debt?
Technical debt refers to the cost of additional work and/or technological investments caused by choosing an easy short-term technical solution to a problem instead of a better longer-term approach. It can take many forms, from choices made by contractors in software, hardware, or services to the decisions made by vendors about the products and services they deliver.
As technical debt reduces organizational efficiency and increases operational risk, its impact can be far reaching.
Typically, contractors acquire technical debt in one of three primary ways: deliberate, accidental, or technical obsolescence.
Deliberate Technical Debt
Deliberate technical debt occurs when software is selected to meet a deadline due to initial budgetary constraints or other external factors — and only sometimes does it come with a plan to address any issues “later.”
During the height of the COVID-19 pandemic, many contractors had to scramble to provide computers for office-based employees so they could work from home. Due to supply chain issues, only some of the computers were consumer grade and/or they weren’t from consistent vendors. Because of this, warranty management became an issue, and for some IT departments, this added significant support demand. However, with no other options, some IT departments elected to pursue this approach knowing it would have long-term implications.
Accidental Technical Debt
Accidental technical debt arises from unforeseen problems such as unanticipated complexity of a system, not fully vetting the system before selection, or getting too far behind with updates and upgrades.
There are countless examples of software that have been either heavily customized or not kept up to date and now cannot be upgraded to the current version. Additionally, plenty of contractors have technical debt from old databases, complex Microsoft Excel files, or outdated Microsoft SharePoint sites.
Technical Obsolescence
As systems evolve and grow, they naturally accumulate complexities and inefficiencies, leading to increased technical debt.
Many systems were originally designed as client-server applications for in-house use only. Over time, they had to be delivered remotely, however, the software was never designed for such a deployment approach. This created all kinds of technological challenges for IT including poor memory management, driver conflicts, and session management issues.
Compounding Technical Debt
The four drivers of technical debt are:
- Strategy: failure to properly align and define business and technological strategies
- Architecture: failure to maintain and update hosting environments or insufficient uses of standards-based infrastructure deployments
- Talent: resource availability issues or a misalignment of resource needs
- Process: poor project backlog prioritization, development controls, and IT operations that are more reactive than proactive4
Even in today’s world of cloud applications, many file-based desktop and client-server applications are being used (and purchased) by contractors. Typically, these fall into one of the five main categories: design, estimating, accounting and job cost, scheduling, and shop floor systems.
To illustrate the challenges that a legacy system can generate and provide an example of how technical debt compounds, let’s consider a client-server ERP built on an older development platform and running on a common database.
Layers of a Legacy System
It can be helpful to think about technical debt like a ripple effect — each of the ripples represents a different layer of technical debt — as shown in Exhibit 1.
Vendor Layer
The vendor layer refers to any existing technical debt in how the vendor architected and developed its product. In the context of Exhibit 1, if a vendor didn’t design its software from the outset with the capability to upgrade or update parts such as the database, data layers, business logic, security protocols, workflows, and the user interface, then it may end up having to overhaul its entire application to stay relevant.
Utilizing outdated programming technology could require the vendor to employ developers that are familiar with older coding practices, which restricts their ability to embrace new technological advancements.
Often, developers incorporate third-party components like grids or drop-down menus into the user interface for added functionality. If these components haven’t been updated or secured over time, then there may be constraints when trying to modernize the code due to obsolete elements.
Such considerations represent the technical debt that a contractor assumes when choosing to work with a particular vendor’s product.
Application Layer
The application layer refers to how the application is implemented and used.
In many cases, either initially or overtime, the contractor may have elected to customize the application to support specific internal functionality rather than change an internal process to match the capabilities of the new software. These customizations can often limit the ability to upgrade the existing software, creating long-term technical debt.
In the ERP example, it is sometimes necessary to augment the capabilities of the ERP by leveraging third-party applications such as time capture, payroll systems, internally built applications, or even an Excel spreadsheet.
In some instances, contractors have to deploy third-party financial reporting tools to replace the reporting capabilities provided within the ERP itself. For every new application that gets deployed, contractors are compounding their technical debt.