Technical Debt includes the (hard and soft dollar) liabilities, obligations and risks created when suboptimal decisions are made in the architecture or development process. Technical Debt explicitly describes all of the future work generated to restore the consequences of suboptimal decisions to optimal / enterprise outcomes and standards.
According to Gartner, the aggregate level of technical debt at the end of 2015 is approximately $1 trillion and the average level of technical debt for a given Fortune 2000 enterprise is approximately $200 million. With liability levels this high, and increasing annually, we believe that it is becoming essential for organizations to identify, reduce and prevent the incurrence of technical debt.
Identification of technical debt best begins with an understanding of where and how it is formed in a given organization. From our definition of technical debt, we know that it results from suboptimal decisions in the architecture and development processes. From an architecture lens, common suboptimal decisions that drive technical debt include avoiding hardware patches and capacity uplifts, underinvesting in automated workflows, insufficiently documenting the infrastructure, underinvesting in staff development and failing to create and maintain standards and domain blueprints.
Suboptimal decisions in the development arena are often the result of explicit choices and tradeoffs in partnership with the business. For example, time-to-market business priorities may dictate a conscious decision to perform less testing than is customary in order to hit a market-facing delivery date. Quality issues that ensue take the form of technical debt as they must be fixed, or repaid, at some future date. Business-facing risk decisions also result in the creation of technical debt. For example, as applications mature, upgrades may include more complex platform enhancements. These typically carry more risk, and the business may consciously choose to defer the upgrade. The operational risk of running the now outdated application, and the future dollar cost of the pending upgrade, can be thought of as new technical debt.
Given an understanding of these drivers, and recognizing more that may be present in your organization, we can now put forward a systematic approach to identifying technical debt. From an application perspective, organizations can document or inventory all applications running in their environment. From there, they can systematically assess the activities and investments required to bring each application to an appropriate enterprise standard. These are the hard dollar technical debts associated with each application. In addition, the business risks associated with application deviations from enterprise standards can be assessed and captured. These represent the soft dollar technical debts.
From an infrastructure perspective, the approach to identifying technical debt is materially the same. For each asset, it is possible to assess the hard and soft dollar costs required to restore the asset to an enterprise standard level. Restoration can take the form of upgrade or disposition and replacement.
Systematic identification of technical debt includes:
For most organizations, reducing technical debt is more complicated than simply mobilizing a program to bring application and infrastructure portfolios to enterprise standards. There are many reasons for this. Often, there is not funding allocated for technical activities of this nature. Also, the process for securing funding is often heavily weighted to the generation of new revenue and new business capabilities.
Despite these headwinds, there are mechanisms that can be effective in securing the funding and prioritization necessary to mobilize activities aimed at technical debt reduction. For example, technical debt reducing activities can be included as part of large business projects. This is due to the risk reducing aspect of technical debt repayment. Paying down technical debt reduces the risk of unplanned outages and other adverse business outcomes. In the context of larger business initiatives, technical debt repayment often makes sense as part of the overall value proposition. Also, many organizations have become adept at leveraging surplus funds from projects underspending to pay down technical debt. While this may sound like a solution that skirts standard prioritization and governance, the risk reducing benefits of technical debt repayment often provides a welcome use case for suddenly available capital.
The mechanisms to fund and repay technical debt above act within existing enterprise processes. To the extent feasible in your organization, many organizations have set aside a predetermined amount each year to repay technical debt. In practice, these amounts are often small, and address only a small fraction of the technical debt level. These organizations often employ an agreed upon prioritization process to allocate the technical debt reduction budget. Drivers of this prioritization often include the amount of debt repayment required, the level of business risk and the location of the application or infrastructure component in its lifecycle. Drivers for prioritization can be tailored and should fit within the decision making framework in the given organization.
As organizations become more product centric, budgets are increasingly partitioned by product, rather than project. With products come product owners. These individuals, often sitting within the business, prioritize all activities (or stories). Here, the key is to educate the product owners regarding technical debt to enable optimal decision making and technical debt prioritization.
Strategies to reduce technical debt include:
Technical debt avoidance requires attention to assets, processes and communication. From an asset perspective, it is essential to understand which applications and infrastructure components exist in the organizational environment. With this baseline, it is possible to maintain their lifecycle position, hard dollar technical debt level and soft dollar risk level. In addition, the presence of strategic plans and other roadmaps will ensure the ability to identify technical debt that is truly intentional given the business strategy and future needs.
Avoiding technical debt also requires a funding process that explicitly contemplates technical debt in prioritization. Projects that incur additional technical debt should be identifiable, and the cost of that debt should be reflected in the business cases associated with those projects. As funding becomes more product centric, product owners should be keenly aware of technical debt and make backlog decisions in contemplation of the implications of technical debt.
Communication is also a key element to avoiding technical debt. For example, many organizations have found success in publishing application and infrastructure dashboards to highlight technical debt levels. Similarly, traction and culture change has been delivered through the communication of business risk associated with the presence of technical debt.
Strategies to avoid technical debt include:
Whether you’re just beginning to identify your technical debt level, or seeking to optimize your processes to reduce and avoid future debt, Liberty Advisor Group can help accelerate your path. We offer objective guidance, supported by battle-tested experience. Please reach out to us at info@LibertyAdvisorGroup.com. We’d be happy to work with you to measure, prioritize, repay and manage your technical debt levels to enable you to reduce risk and unlock additional business value.
