In today’s fast-changing technological and business environments, modernizing mission-critical apps is a high priority for companies that want to improve or even just maintain their competitive position. Yet modernization efforts often fall short of yielding the hoped-for benefits.
A recent McKinsey report highlights a major reason for such failures: “as companies modernize their IT, a hidden peril is emerging that could undermine their efforts: tech debt.” The sad reality is that, despite being firmly committed to modernizing their legacy apps, 58% of companies have no process in place to help them address tech debt in their application portfolio.
Why Companies Must Address Tech Debt
The Journal of Systems and Software defines technical debt as “sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term.”
A good example of tech debt are many of the Java and .NET apps that companies actively depend on for their most business-critical processes. Such apps are typically monolithic in structure, meaning that the code is organized as a single unit with functions and dependencies interwoven throughout.
Because the architecture of that kind of codebase (often characterized as a “big ball of mud”) is inherently difficult to understand, a change to any function can potentially cause unanticipated effects elsewhere in the code that can cause the app to fail. And that makes updating such apps to meet changing requirements a risky, time-consuming, and costly undertaking.
Let’s look at some specific ways unaddressed technical debt can hinder businesses.
- Slows Engineering and Business Velocity: As an app’s codebase becomes increasingly outdated and mismatched with its operational environment, the cost in terms of time and engineering resources of updating the code to meet new business requirements grows even faster. As Ward Cunningham, who coined the term “technical debt” says, “Entire engineering organizations can be brought to a stand-still under the debt load.”
- Stifles Innovation: The McKinsey report on the perils of technical debt declares that 10% to 20% of companies’ technology budgets are “diverted” from developing new products to resolving technical debt-related issues. In fact, 70% of organizations name technical debt as a major obstacle to innovation.
- Lengthens Test Cycles: Technical debt often makes a codebase hard to understand. Because of the potential for developers to overlook obscure process flows and hidden dependencies as they update the code, more extensive testing is required to mitigate the increased risk.
- Hamstrings Onboarding Engineers: The difficulty new engineers typically have in understanding out-of-date code inevitably lengthens the time it takes them to get up to speed.
- Diminishes Team Morale and Job Satisfaction: A recent survey report declares categorically that “Technical debt is destroying developer morale.” In the survey, 52% of engineers said that technical debt negatively impacts the morale of their teams. Many are discouraged by spending, on average, a third of their time dealing with technical debt rather than working on innovative products that help them sharpen their skills.
- Impacts Customer Experience: According to a 2019 Gartner report, the key to customer loyalty is giving them an “effortless experience.” But when technical debt results in bugs, glitches, performance issues, and delayed functional updates, it’s difficult to provide the high level of excellence in the user experience that today’s sophisticated customers demand.
- Elevates Costs: As technical debt accumulates over time, apps become increasingly difficult to maintain and update. The result is that organizations waste 25% to 45% of their development budgets dealing with tech debt.
- Increases Security Vulnerabilities: Outdated libraries and hastily implemented patches can increase an app’s vulnerability to cyberattacks.
The Impact of Architectural Technical Debt
In common usage, “technical debt” refers to deficiencies in an app’s code or “code smells.” However, source code technical debt is neither the most common nor the most important form of technical debt. Architectural technical debt, which according to Gartner will constitute 80% of all technical debt by 2026, is an even more critical issue.
Related: Don’t Let Technical Debt Stymie Your Java EE Modernization
In an IEEE (Institute of Electrical and Electronics Engineers) conference paper, researchers define architectural technical debt as, “sub-optimal architectural design and implementation choices that bring short-term benefits [at] the cost of the long-term gradual deterioration of the quality of software.”
In other words, architectural debt is technical debt that’s built into the very structure of the codebase—it may already be present before the first line of code is written. Over time, as the technological environment and design standards advance, that structure becomes increasingly out of date, making the app more and more difficult to maintain and update.
Architectural technical debt may also arise due to “architectural drift,” which occurs as ad hoc (and usually inadequately documented) patches are made that cause the current codebase implementation to deviate over time from the original architectural plan.
Architectural debt is normally hard to find and even harder to fix. Finding it requires what’s called “architectural observability,” which is the ability to see, or observe, the internal structure and operational profile of an app and compare them to a desired or ideal architectural baseline. Fixing architectural technical debt is difficult because it normally requires more than just making discrete coding changes—rather, the codebase must be entirely restructured.
The McKinsey technical debt report sums up the impact of architectural technical debt this way:
“Poor management of tech debt hamstrings companies’ ability to compete… Challenges hidden in the architecture can spring surprises that make projects run over budget and miss deadlines.”
When Should a Team Address Tech Debt?
Technical debt doesn’t just affect legacy apps that were written long ago. Rather, because the surrounding technological ecosystem is constantly changing, new technical debt begins to accumulate in apps from the moment they are implemented.
For example, even applications written over the last 10 years using a cloud-native microservices architecture can develop significant technical debt as the cloud ecosystem around them has evolved, causing the libraries, interfaces, and architectural frameworks the apps use to become outdated over time.
So, when should a team address tech debt? Continuously!
The worst thing an engineering team can do is continue to defer dealing with technical debt until the accumulation of architectural and coding issues reaches a critical mass that causes some type of operational disruption. Instead, teams should proactively look for opportunities to reduce an app’s technical debt from the very beginning of the software development lifecycle (SDLC) until the app is retired.
In particular, teams should leverage architectural observability to identify any technical debt-related user stories that need to be addressed during each Agile sprint release throughout the app development and modernization processes. Ensuring that any architectural drift issues are immediately identified and corrected (rather than being deferred until the end of the process) should be a top priority. You should make addressing technical debt an integral part of your sprint planning rather than treating it as a separate (and optional) issue.
How to Balance Addressing Tech Debt vs. Project Delivery
Proactively addressing technical debt and delivering the project as quickly as possible may seem to be incompatible goals. In reality, both are imperatives: teams don’t have the option of speeding delivery by deferring technical debt reduction indefinitely; nor can they choose to address tech debt at the cost of significantly delaying delivery.
So, how can you reach a productive balance that accommodates both necessities? It can be done by effectively leveraging architectural observability.
The key to proactively eliminating technical debt without introducing inordinate delays into a project’s release schedule is to quickly identify each instance of technical debt in an app, pinpoint what parts of the codebase that debt is affecting, and characterize its impact on both technical and business objectives.
Related: How Continuous Modernization Can Address Architectural Drift
That’s exactly the benefit of architectural observability. It enables you, at each stage of the development and modernization cycles, to accurately identify specific work items that are aligned with a business or domain function instead of just fixing every problem regardless of its true importance. It gives you the ability to assess the potential lifetime costs of each technical debt issue and balance the expense in time and engineering resources of fixing it against the potential long-term costs of not doing so.
How to Effectively Address Tech Debt
To effectively address technical debt in your organization, start by inventorying your existing app portfolio to understand the architecture of each app, how it behaves in its production environment, and the degree to which it has drifted from your reference architecture. This allows you to identify the most urgent technical debt issues associated with each app, and determine if and when each issue should be addressed.
But how can you gain such comprehensive insights into a portfolio that may consist of hundreds or thousands of apps with millions of lines of code? What’s needed is an automated, AI-enabled architectural observability tool that can perform the static and dynamic analyses required for obtaining the needed metrics.
The vFunction Architectural Observability Manager is just such a tool. It enables you to track architectural technical debt across your application estate, identifying and quantitatively measuring instances and amounts of architectural drift and other sources of technical debt. With those metrics in hand, software architects can use vFunction Architectural Observability Manager to generate a detailed modernization to-do list to prioritize,remediate, and eventually refactor appropriate domains without trying to mount a “big bang” effort that attempts to modernize everything at once.
If you’d like to see first-hand how an advanced observability tool can help you unravel architectural complexity and minimize technical debt, contact us to schedule a demo.
