Technical due diligence is designed to identify the risks and opportunities of technology, including the technology developed and sold by the firm being evaluated, but also the technology being used to run the company.

One of the critical factors which needs to be evaluated in any technical due diligence is the concept of Technology Debt. This report provides insights into technology debt from my perspective as an enterprise CTO turned due diligence professional. These lessons can help companies preparing for a future transaction to better position themselves for optimal outcomes. These lessons can also assist private equity and other investors in thinking through aspects of technology risk and identify areas requiring additional focus prior to a transaction.

What Is Technology Debt?

The simple definition of technology debt is the accumulated costs and effort it would take to fix problems with technology. This includes both the technology developed by and used by the target firm to enable business operations or as components of a solution being sold into the market.

The concept of technical debt first appeared in the software development community as a measure of how untidy or out of date code for a project was. The untidier, the harder the code would be to further develop, secure, and improve. Significant technical debt could cause an entire software project to fail. The metaphor soon became part of the lexicon of software projects.

As an enterprise CTO I saw technology debt in a different light and realized It is not just a term that applies to individual software projects. Large enterprises operate with a mix of very old legacy technology and new capabilities. The legacy IT almost always requires more care and feeding to sustain operations. This systems management overhead is like paying interest on a debt with compounding interest that can never be fully paid off. The more interest you pay on this legacy technology debt, the less time, attention and money you will have to apply to modernizing. You can refactor legacy IT, and that can reduce the technical debt, but that also takes investment over time.

Analogies Between Fiscal Debt and Technical Debt

Technical debt and financial debt are both based on the economics of optimization and are very analogous to each other. In fact, as analogies go, this is one of the better ones. Consider these observations on technical debt:

• Like borrowing money, developers take on software debt because they want something now. For example, developers may cut corners by not documenting their code or not checking for code security vulnerabilities or by incorporating other out of date code libraries and modules. This borrowing to speed the fielding of a solution causes technical debt.
• To pay back the technical debt in software projects, developers must spend time to create the documentation or remedy the shortcuts later which often includes the development of additional code.  In some instances, the code must be completely replaced downstream to reduce growth bottlenecks.
• Enterprises seeking to save money will extend the useful life of their legacy IT systems instead of paying to replace them. This saves the cost of capital that would be required to replace old hardware and software as well as the cost to re-integrate the system into the rest of the enterprise. But it increases technical debt by building up costly requirements to manage outdated systems. In most cases it also includes buildup of significant security issues, and normally also means the workforce cannot benefit from improved functionality in newer product versions.
• The longer an organization waits to pay back the technical debt in code or in legacy IT, the harder it is to do so.

There are differences in technical debt and financial debt of course. Humanity has years of experience in financial debt and over time we have evolved an extensive array of best practices, regulations and laws around fiscal debt. This includes rules by the SEC on evaluating financial debt prior to transactions or regulations that require a certain debt/asset ratio to help manage risk.

There are far fewer rules and regulations applicable to technical debt. Best practices in software development and IT management exist, but they are not always followed. Additionally, if a company does not have formal methods in place to evaluate technical debt, it might not be understood by the company leadership or by firms that are seeking to invest in the company or target it for acquisition.

All this means technology debt is a risk that must be rigorously examined prior to any transaction.

Evaluating and Reporting on Technical Debt

Any firm seeking a technical due diligence assessment should expect to have several key questions answered regarding technical debt.

For example:

• What is the nature of the technical debt in the target company?
• Are there critical “showstopper” issues with technical debt?
• What is the nature of the cybersecurity risk due to technical debt?
• What unplanned costs may arise because of technical debt?
• What would be required to modernize the code base to leverage best practices?
• How long will it take to migrate to a more modern code base (if required)?
• Does the code of the target company need modernization before integrating into the product suite of the acquiring company?
• Will old systems in use in the target company require scrapping? What will be the cost to do so?
• What new IT costs can be expected after acquisition because of technical debt?
• Does the technical debt impact the company’s ability to sell products into the market now or in the future?
• Are there specific cybersecurity deficiencies that introduce an additional layer of technical debt and risk.

Where To Look For Technical Debt?

Hypothetically technical debt can exist anywhere that technology serves the organization. But in practice, the greatest danger of technical debt is in areas associated with critical business operations. Some key examples:

• Proprietary software owned and sold by the company: As mentioned above, the concept of technology debt arose out of the software development community, and it is still, unfortunately, a place where much of the technology debt in an enterprise will be found.
• Custom Software Used For Corporate Processes: Most large companies will use developers to create custom code for serving critical business processes. This may be scripts that run in office environments, or unique interfaces to business systems. But in almost every case, custom software is poorly documented, and the cost of maintaining code like this grows significantly over time.
• Data Architectures: Where and how data is stored, protected, moved and analyzed in large companies needs to be understood to assess risks to the firm. Frequently, shortcuts in data architecture design or cost saving steps have been taken that introduce technical debt.  This is especially true for data that is increasingly under regulatory scrutiny such as PII.
• Legacy Applications: The older an organization is the higher the likelihood that it is running a large number of older applications. The greatest technical debt in these apps will be in the ones that are so obsolete that they are not supported by the vendor and this end-of-life status prevents them from receiving security updates. The dependence on apps like this needs to be understood prior to M&A.
• Datacenters and Servers: Most businesses today still use some internal/on-prem hardware. Many will operate their own datacenters (on-prem or leased). In every case, technical debt here needs to be assessed, since it could involve hard to support hardware or networking equipment or infrastructure that is not able to scale to meet growth expectations. Note: The recent move of more systems to the cloud will help reduce the technical debt for many firms, but still most firms do not use the cloud for core systems.
• Security, Identity Management, Authorization: Well managed technology efforts have very good security and identify management architectures. Conversely, those who have allowed technology debt to build up here may have some significant and urgent issues to address before an M&A.
• Corporate Policies, Standards and Processes: The documentation of processes and guidance in the corporation are also a place that can hold a great deal of technology debt. Expert review can spot the issues here and in most cases provide inputs on ways to mitigate the debt.

Concluding Thoughts

In the context of due diligence assessments prior to M&A activity, the concept of technical debt must be comprehensively evaluated. Technical due diligence should seek to identify and characterize the technology debt of software created by the target firm, as well as the systems used to operate the firm.

In a perfect world, organizations will always use technical debt responsibly, and repay it quickly. But in reality, most firms end up with more technical debt than they should carry. This means technology due diligence should always cover more than just the functionality and security of technology. Technical debt should be understood before any M&A activity as it can drastically impact the long-term value of the target company.  In some instances, poorly structured technical debt should be accounted for in the valuation.

Recommendations

Buy-side due diligence teams should ensure technology due diligence efforts have a special focus on technology debt. Ensure you select technology due diligence partners with the experience required to deliver on this need.

On the sell-side, company leadership should take action designed to smartly pay down technology debt. Doing so will help increase the value of future transactions. External experts can assist by providing non-biased professional assessments and prioritized action plans to reduce technical debt prior to a transaction positioning your enterprise for maximum value in the market.