Written by
Peter Shand
Chief Technology Officer, Americas

It is often difficult to wade through the plethora of industry buzzwords and catchphrases to get to the actual technology and value associated with the ever-increasing number of terms coined by technologists and industry experts. Let’s explore yet another one; technology debt. The phrase tends to come up alongside topics regarding cloud migration and digital transformation particularly when referencing retiring technology.

Technology debt seeks to quantify the cost for running legacy applications and architectures. The term first appeared when Agile methodologies began to gain ground in development processes and teams. It was referred to as technical debt and was used to quantify how legacy code and techniques negatively affected product development lifecycles to the degree that there were quantifiable financial implications to keeping them. Technology debt expands on technical debt to include architectural, infrastructure and IT organizational debt along with application debt. It is easy to understand the economics of legacy code and architectures relating to higher support and maintenance costs as well as those related to inefficiencies. However, in many businesses, innovation has a direct and quantifiable impact on revenue as well as the cost of doing business. Technology debt has a direct negative effect on the process of innovation as well as the speed of innovation.

Abizer Rangwala and Steven Toomey have further expanded on the subject and break down the effect of technology debt on the balance sheet into 4 key areas:

  • The operational capital required for remediating aging infrastructure, architectures, applications and source code.
  • The incremental costs associated with maintaining the human resources as well as the ongoing costs of attempting to implement new processes on legacy platforms.
  • The costs associated with the inevitable outages, data corruption and increased cyber-risk. Lost revenue and customer satisfaction issues due to inefficiencies and slower applications can also be a significant liability.
  • The opportunity cost associated with the additional time to market for new initiatives that involve interfaces and integrations to legacy applications and infrastructure.

Today’s cybersecurity threat landscape demands that all technology strategy includes consideration on how decisions will affect cyber risk. It could be argued that increasing technology debt results in increased cyber risk as well. In many cases legacy applications, architecture and infrastructure may not support newer and more robust security controls. Cyber risk could be incorporated across the 4 categories of technology debt but its importance and the dire nature of the consequences of unmitigated cyber risk needs to be highlighted. A common but extreme example can be found in environments where there are still deployments of Windows 2003 because there is an application that requires it. Aside from the lack of support from Microsoft, lack of support for later versions Transport Layer Security means that any data traffic emerging from that environment could be highjacked or compromised. Cyber risk management is a competency that is very broad and requires experience that is difficult to find in a single resource and as such some time it may be best to address this risk by outsourcing the operational component of managing security to specialists while internal resources focus on bespoke and industry or organization specific applications. It cannot be emphasized enough that a modern, robust cybersecurity posture has a positive effect on profitability, customer satisfaction and overall company valuation.

This review is in no way a call to action to immediately acquire the latest hardware or to accelerate a hybrid or cloud journey. The main conclusion will entail an analysis of the current state of the applications and their delivery environment based on the following core pressures of technology debt:

  • Application Debt: Is time/money spent on workarounds and waste due to the same data being in multiple applications?
  • Architecture Debt: Is the budget skewed towards supporting and maintaining legacy architecture and are integrations often delayed?
  • Infrastructure Debt: Is provisioning taking weeks as opposed to days and is unexpected downtime becoming common place?
  • IT Organizational Debt: Is it increasingly difficult to find talent to support legacy systems and is slow response to change requests becoming ingrained in the organizational culture?
  • Cyber Risk: Is it getting harder to securely tap into legacy data sources without cutting corners that lead to greater exposure to cyber-risk or extraordinary costs due to the requirement for third party tools to patch legacy security vulnerabilities?

After completing a basic financial analysis of the above technology liabilities, the next steps are to evaluate the following:

  • Evaluate the sources of technology debt based on the amount of financial and other risk it brings to the organization and then prioritize them in order of their critical nature.
  • Evaluate whether some technology debt can be addressed by leveraging pay as you go resources as opposed to large capital expenditure.
  • Evaluate ultimately who is responsible for a particular area of technology debt and attempt to assign ownership.

Overall, the ability to associate aging technology to a financial risk should serve to help technology executives effectively make the case to other C suite executives to retire aging assets. It will also help other non-technology executives to understand the importance of IT resources to the business. That definitely sounds like a “win-win!”