Technical Debt:

Understanding, Managing and Resolving It

Published:24^thMarch 2023, Updated: 15-Apr-2023

By Ashok Vasa, Galina Stancheva, Reviewed by David Simard, Yuriy Volyanskyy and comments from members of the Enterprise Architecture Forum (Linkedin Group)

‍“It's not a technical debt until it creates a problem, and your assets start to become liabilities”.

This article explains what technical debt is and the problems it can cause for an organization's technology and operations. It provides examples of technical debt and suggests approaches for identifying, classifying, and resolving it. The article also discusses tools and metrics that can be used to manage technical debt effectively. Finally, it discusses the roles and responsibilities involved in addressing technical debt and suggests ways to secure funding for resolving it.

What is Technical Debt

Technical debt is a term used to describe the accumulation of inefficiencies and limitations in an organization's technology landscape due to the deferral of optimal design.

It can be caused by outdated systems, hardware, skills, processes, or practices. The technical debt represents the deviations from established guidelines and targets. These deviations could be intentional or unintentional, present or historic, created by deliberate decision, accidentally discovered, or brought through an audit.No matter how the technical debt is created or found - it has to be managed systematically in order to ensure a healthy balance between creating and removing debt in organizations.

Examples of Technical Debt

Here are a few examples of technical debt that organizations may recognize:

· If an organization prioritizes being cloud-first and deploying to the cloud, projects that do not follow this route are considered to create technical debt.

· If an organization prioritizes maintaining a landscape with the least duplication, projects that create duplicates within a domain or capability create technical debt.

· Customizations made to a 3rd party system to provide a new capability that the product doesn't yet have can become technical debt when this 3rd party system eventually provides the capability out-of-the-box.

· Fetching data from a source (person or a system) that is not the legitimate golden source/data owner of that data creates technical debt, due to the inevitable data discrepancy to be created

Is it Technical Debt, just because is “old”?

Not every older system, hardware technology, architecture, process, or method should be classified as technical debt, solely because newer versions, tools, or approaches exist. If the older technology does not create issues or limitations, it cannot be deemed a debt. Referring to it as obsolete or legacy and advocating for a newer version is useful only if it resolves known issues.

The Problems Caused by Technical Debt

Technical Debt is a problem not only for technology but also for the business. Some of the problems caused by technical debt in a broader context are:

· Increased maintenance costs of a product, system, or infrastructure, as it requires more time and effort to fix issues and maintain functionality. The longer the debt remains unpaid, the more expensive it becomes to fix.

· Reduced efficiency and productivity of a system or process, leading to delays, errors, and inefficiencies. This can result in increased costs, reduced output, and lower quality.

· Decreased reliability and safety of a product, system, or infrastructure, leading to failures, accidents, or malfunctions. This can have severe consequences for the users, stakeholders, and the environment.

· Decreased customer satisfaction as they may experience issues, delays, or reduced quality. This can result in a loss of customers, revenue, and reputation.

· Decreased innovation and competitiveness as it diverts resources from research and development and reduces the capacity to adapt to changing market conditions.

· Increased risks of system failure, security breaches, or environmental damage, leading to legal liability, reputational damage, and financial losses.

Identifying and Classifying Technical Debt

Identifying and classifying technical debt is critical to resolving it effectively. Technical debt can be classified into different types based on its origin, impact, and longevity.

Four common types of technical debt are deliberate, accidental, atrophy, and.

1. Deliberate Technical Debt: incurred intentionally to meet short-term goals or deadlines. Implementation teams may knowingly take shortcuts or adopt suboptimal solutions to deliver functionality quickly, with the intention of fixing them later. This type of debt is sometimes called "prudent debt," as it is a calculated risk taken to meet business needs. However, if not managed properly, deliberate technical debt can accumulate and become unmanageable, leading to long-term costs and risks.

2. Accidental Technical Debt: unintentional debt arises from mistakes, oversights, or lack of knowledge or experience. Implementation teams introduce issues unintentionally or fail to follow best practices, leading to technical debt. Accidental technical debt if not caught early during testing and reviews may become harder to detect and fix than deliberate technical debt.

3. Atrophy Technical Debt: results from neglecting maintenance or upgrades over time. As systems or infrastructure age, they may become outdated, unsupported, or incompatible with newer technologies. Atrophy technical debt can accumulate gradually and lead to increased risks, decreased reliability, and higher maintenance costs.

4. Historic Technical Debt: arises from decisions or actions taken in the past that are no longer relevant or necessary. For example, a feature that was added to the system in the past may no longer be used or needed, but the features to support it may still be present, creating technical debt. Historic technical debt can accumulate over time and become a burden on the system, making it difficult to modify audits and in.

Regular audits and monitoring of the system can help identify technical debt as soon as it arises, allowing organizations to prioritize and resolve it effectively. By categorizing technical debt and identifying the root cause, organizations can take a proactive approach to resolve it and avoid future technical debt issues.

Fostering Safe Environment for Disclosing Technical Debt

Blameless post-mortems are a good technique to foster a culture where technical debt is talked about openly and reported by teams. Even in cases where the debt is deliberate, self-reporting needs to be encouraged. In too many cases, teams may be afraid to "open the kimono" for fear that they will be blamed, or even worse, assuming they will be told to drop everything and address it right away. There needs to be a level of safety for those involved

Assessing the impact of technical debt and metrics to use

Technical debt can be hard to define and measure and its impact is difficult to quantify. Organizations should encourage all groups to report technical debt and document its impacts and costs and prioritize which to address.

Using approaches like the "Four-S" process can help to manage technical debt effectively.

· Smell it

· Size it

· Schedule it

· Solve it

Even though some aspects of technical debt are more tangible than others, making it hard to manage, assessing the impact of technical debt is crucial.

Here are some metrics that can be useful when assessing the impact of technical debt:

· Technical Debt Metrics provide insight into the amount of technical debt present in the System. They can include measures such as deviations from standards, design decisions, customizations to products, and quality of the system (e.g. number of issues, duplications, etc.). Higher values for these metrics can indicate a higher level of technical debt and potential issues with the quality and performance of the system.

· Performance Metrics: provide insight into the performance of the system/technology. They can include measures such as response time, throughput, and resource utilization. Higher values for these metrics can indicate potential issues with the performance of the system due to technical debt.

· Business Metrics: these metrics provide insight into the impact of technical debt on the business. They can include measures such as customer satisfaction, revenue, and market share. Lower values for these metrics can indicate potential issues with the competitiveness and profitability of the business due to technical debt.

The impact of technical debt can be quantified from both a business and technology perspective to convince stakeholders of its value to the organization. Reporting on which business capabilities are impacted along with which Applications, Interfaces, and IT components are impacted is a useful approach to holistically view the impact of debt.

Calculating the Principal and Interest of Technical Debt

Ultimately every technical debt comes at a cost. Measuring technical debt using metrics such as “principal cost to fix the debt” and “interest on the debt” (e.g. extra extended support cost.) “risk of the debt” and “timespan of the debt” can help prioritize which debt to tackle first.

Calculating the principal and interest of technical debt involves estimating the initial cost of taking on the debt, as well as the ongoing costs associated with servicing that debt. Here's a step-by-step guide:

· Step 1: Identify Technical Debt Items

Make a list of technical debt items that need to be addressed. These could include design shortcuts, duplications, outdated technologies, lack of documentation, or other issues that impact the quality, maintainability, and scalability of the system.

· Step 2: Estimate Initial Cost (Principal)

For each technical debt item, estimate the initial cost required to address it. This may involve tasks such as refactoring, rewriting, or re-architecting. Estimate the effort in terms of time, resources, and costs needed to fix the technical debt item and bring it up to an acceptable standard. This estimate represents the initial cost or principal of the technical debt.

· Step 3: Estimate Ongoing Costs (Interest)

Next, estimate the ongoing cost or interest associated with the technical debt. This includes the additional effort and resources required to maintain, support, and operate the system with the existing technical debt in place. This could involve increased development time, higher bug fix rates, decreased system performance, increased downtime, or other operational costs incurred due to technical debt.

· Step 4: Calculate Total Cost

Add the initial cost (principal) and the ongoing cost (interest) together to get the total cost of the technical debt. This represents the overall impact of the technical debt on your project.

· Step 5: Prioritize and Address Technical Debt

Based on the total cost, prioritize the technical debt items and develop a plan to address them. You may need to allocate resources, set timelines, and prioritize based on criticality and business impact.

It's important to note that estimating the principal and interest of technical debt is inherently subjective and can vary depending on the specific context of your project, team capabilities, and business goals.

When should Technical Debt be paid Down?

Technical debt should ideally be paid down as soon as possible to avoid it accumulating and becoming a burden. Here are some key scenarios when technical debt should be prioritized and paid down:

· When Technical Debt Impacts Business Goals: If technical debt starts impacting business goals, such as causing customer dissatisfaction, increased downtime, or decreased productivity, it should be addressed as a priority. This ensures that the system remains aligned with the business objectives and does not become a liability.

· When the Cost of Maintenance Outweighs the Debt: If the ongoing cost of maintaining and operating the system with the existing technical debt becomes higher than the cost of paying down the debt, it's a clear indicator that it's time to prioritize paying down the technical debt. Continuing to ignore technical debt can lead to increased costs and decreased efficiency over time.

Resolving Technical Debt and Securing Funding

Resolving technical debt is a critical process. Here are stages that can help resolve the technical debt.

· Estimating the work needed to fix it: To ensure a successful resolution, organizations should consider all aspects of the solution, including technical solutions, cost, economics, organizationalaspects, and change management.

· Prioritizing : it is essential to prioritize technical debt by considering the impact on business, the potential return on investment, and/or the cost/risks avoided.

· Communicating: organizations should make technical debt visible to ensure it receives the necessary attention and resources to resolve it.

· Portfolio planning: It's a good idea to fix technical debt in small pieces, and link technical debt to business and technology capabilities, and schedule them to be fixed during projects.

Ultimately, resolving technical debt should be viewed as an initiative that's part of a larger portfolio of initiatives that compete for attention and resources, like any other project.

Possible KPIs and Metrics to Track and Measure Technical Debt

Here are a few examples of KPIs to track technical debt trends.

· Technical Debt Backlog - Measures the number of identified technical debt items that are pending resolution

· Technical Debt Age- Measures the age of the existing technical debt

· Implementation Cycle Time - Measures the time taken from implementation to deployment, including time spent on fixing issues or technical debt

· Release Frequency - Measures the frequency of releases, indicating how often new features or issues are fixed are deployed to production

· Team Velocity - Measures team's productivity and ability to deliver features or fix issues within a given time frame

Roles & Responsibilities in Resolving Technical Debt

Roles and responsibilities are crucial in resolving technical debt. Without clear ownership and accountability, technical debt can be pushed back into the pipeline for resolution, causing delays and potential issues in the future.

To ensure that technical debt is addressed, organizations need to make it visible and establish a process for resolution. One way to do this is by assigning responsibility to application managers or asset managers who manage the impacted systems.

Architects can play a guiding role in identifying the impact of technical debt, documenting the assessment, and providing guidance on resolving it. However, once this is done, the responsibility for estimating the work needed to fix the debt and securing funding falls on the application managers.

If the technical debt is related to obsolescence, such as running on legacy languages or obsolete infrastructure, the asset manager is entirely responsible for evaluating the impact and resolving it.

Overall, clear roles and responsibilities are essential in resolving technical debt, and organizations should establish a process that includes making the debt visible, identifying responsible parties, and ensuring accountability for resolution.

Common Templates and Tools Used

A variety of tools ranging from Excel templates, models, and questionnaires to Jira and tools like LeanIX are in use amongst practitioners to understand, manage and resolve technical debt.

Conclusion

Managing and getting rid of old systems can be challenging and replacing them isn't always straightforward.

Technical debt can accumulate and lead to inefficiencies and limitations in an organization's technology infrastructure. Identifying and addressing technical debt is crucial to keep up with new technologies and maintain efficient technology. Measuring and managing technical debt can help prioritize which debt to tackle first and resolve it effectively. Organizations should consider all aspects of solutions, prioritize the debt that provides a better return on investment, and make technical debt visible to secure the necessary attention and resources.

Managing Technical Debt