Article

The True Cost of Technical Debt

Two teammates evaluating the technical debt cost of their company

Patterns of Technical Debt

In the last year, our company has encountered numerous clients that have been facing issues caused by technical debt and certain patterns have emerged. 

 One of my favorite people in the academic community on the topics of architecture and software development maturity is Rick Kazman, who has researched and written extensively on the topic of technical debt. I strongly recommend his little book Technical Debt in Practice: How to Find It and Fix It (with Neil Erns and Julien Delange).  

What is Technical Debt?

Technical debt, much like financial debt, is a choice to bear a certain set of costs for some real or perceived benefit.  The most common form of this is holding on to legacy applications and infrastructure because the perceived benefit to changing does not justify the financial cost of the change.  When you swap out a legacy mainframe application to a modern ERP system, you may spend millions of dollars with no uptick in revenue and only incremental improvements in process or productivity. 

But the error of this thinking is looking at legacy technical debt from an exclusively financial perspective.  Running old systems may indeed be the cheapest way to support the transactions of the enterprise.  But the cost will be borne in other ways, including: 

Episode 59: Optimization vs. Modernization

Episode 59: Optimization vs. Modernization

Prepare for take off as we explore topics to help you move from aspiration to accomplishment at a perspective-changing height.

Listen to the podcast

Pace of change and adaptability

Legacy systems are difficult to adapt, may not be scalable or extensible, data fields are repurposed, and shadow processes develop around the deficiencies of the system.  Scalable change and innovation cannot be introduced and quality initiatives stall because of process or system inflexibility.  People are fearful of changing the system or making an upgrade, because the last time it was done, something broke revealing the brittleness of the underlying systems. Systems of record become less trustworthy due to workarounds. 

People risk

We had one enterprise client replace a legacy system because they were down to two people that could maintain the application and platform it was running on.  Since the technology was obsolete, there was no vendor training, and the colleges no longer taught people this language.  Retirement or health issues could have made a business-critical process fundamentally unsupportable.  It was a program that exceeded $2M, but it was necessary to mitigate the people and knowledge risk to the company.  One of our clients retained someone post-retirement part-time because the business process knowledge tied to the legacy system was needed for the conversion to a new system and only one person had the extant knowledge. 

Security risk

Cybersecurity is clearly a topic on the top of mind for every enterprise risk committee.  Cyber threats oftentimes have an entry point in systems that have been undermaintained or are past the point of support from the vendor, with security updates no longer available.  Firewalls and Identity management only go so far when security risks are publicized widely by both the global security community and the bad actors.  Security by obscurity used to be the watchword for some teams, viewing older marginalized systems as being too small to worry about.  IoT products and internet-facing application services are special places of concern.  But now the cost of technical debt is paid by taking on risk to the organization, often without consensus or awareness across the leadership team.

Employee and consumer experiences

Employees struggle with the workarounds and human process shims that are used to fill the gaps between systems caused by incompatibility or absence of modern interfaces.  In one case, a client’s major digital initiative was fundamentally compromised because the legacy back-end system could not deliver real-time information assumed to be available by consumers using the mobile application.  Batch systems assumed nightly or periodic updates, and when that information was not presented in real-time to consumers, it had a negative impact.  But digital products expose the weaknesses in the enterprise backbone, and customer experiences are then dialed back into what is possible from the legacy systems. 

Reliability and quality of service

Manufacturing lines that go down because of MES failures, product not shipped because of WMS downtime, revenue losses from front-end systems being unavailable, emergency departments redirecting patients because of a storage failure – these are all examples of the organization bearing the cost of the reliability failures caused by technical debt.  This situation requires the CIO to demonstrate the risk of downtime to the business in real terms to justify the investment needed to update the systems.  The benefit is to the enterprise, the cost is borne by IT. IT leaders that optimize for their cost center can put the enterprise at risk in reliability and quality of service. 

All of these risks are from not paying down the debt that already exists. 

When Technical Debt is Overwhelming

Imagine that your family bought a six-bedroom home on the lake for $1M, and then complained when the maintenance and tax payments are due.  Sometimes we incur debt because we have overbuilt for our needs, and we need to simplify our environment and perform the equivalent of downsizing our home so that we can manage the ongoing maintenance.  Overbuilt IT infrastructures and applications are a risk when the business restraint is not placed on the technologists that want to implement certain cool features, or the cost of that capability to build and maintain is not communicated to the business.  We must think about lifecycle costs for the technology that we build and not just the acquisition costs. 

What do we call it when financial debt becomes overwhelming?  Bankruptcy.  I have had this conversation with several clients at the end of the tech debt cycle.  They have entered into technical bankruptcy.  They can’t change to meet the needs of the business, they don’t have people to maintain the systems in a way that serves the business, security scans reveal longstanding deficiencies or ransomware has hit, digital innovations stall, core business processes become unreliable, and these problems heap up upon one another.  At this point the Board or CEO declares bankruptcy through an outsourcing arrangement, making a strategic acquisition of a company with a core tech capability, or firing the CIO and IT leadership and starting over.  

Vervint is launching a new offering helping clients understand and quantify the technical debt they face in a way that puts people and experiences at the center of the evaluation, not simply the cost of running an IT infrastructure.  We look forward to helping you overcome your challenges and face the future without the burden of technical debt. 

Manage technical debt and prepare for a successful future with infrastructure modernization.

Manage Technical Debt & Empower Your Organization

Get a comprehensive assessment of your technical debt and a prioritized roadmap that aligns infrastructure modernization with business strategy. 

Learn More

Embrace Innovation with Vervint

We meet people and organizations where they’re at to take them where they want to be. Get in touch, and we’ll help move you toward a more innovative future.

About the Author

mm

Jim VanderMey

Author Title

Jim VanderMey is the Chief Innovation Officer for Vervint. Jim has provided technical leadership and product strategic planning for the organization since the very beginning. Jim is a technology visionary who sets the long and short-term direction for Vervint. As our company has gained an international reputation, Jim has taught and spoken at conferences on a wide variety of topics in Europe, Japan, and throughout North America.