Technical debt is a broad topic that’s getting a lot of attention—and for good reason. The industry has a growing number of horror stories about outright infrastructural failures, and every company that’s older than a couple of years can almost feel the shadow of unresolved technical debt through slowdowns in release cycles, glitchy performance, and dead code in the system.
Surveyed CIOs admitted that technical debt in their organizations was probably equivalent to 20-40% of their technology estate. In fact, Gartner reports that, “by 2026, 80% of technical debt will be architectural technical debt.” There’s also a lot of acknowledgment that unresolved technical debt leads to failed modernization and high turnover.
The fact that there is a conversation about how to deal with technical debt in many companies is great news for making technical debt resolution a bigger—and more standardized—part of agile projects and business objectives. But that conversation is still incomplete because it doesn’t focus on architectural technical debt. Architectural technical debt conversations start with an awareness of what leads to technical debt and the consequences it has—and it should end with a plan for ongoing monitoring and resolution.
Architectural Technical Debt Isn’t Part of the Technical Debt Conversation
Before we take a closer look at what architectural debt is, let’s look at what it isn’t. Read through these three more commonly addressed types of technical debt, and try to categorize your most pressing problems into these categories. You may be surprised by how many simply don’t fit into them because they’re part of that missing piece instead.
- Code Quality: These issues are due to problems in the source code. They are bugs, previously functional bits of code that broke over time, and just general quality issues like inefficiencies. “Bug smells,” or source code issues that let developers sniff bigger issues. While not always easy to resolve, there are lots of tools developers can use to aid in the process, like static application security testing (SAST), dynamic application security testing (DAST), and vulnerability analysis tools.
- Performance Issues: All systems have some risk of faltering performance. But teams can stay on top of faults and outright outages by using application performance monitoring (APM) and observability tools. When things dip into yellow or red, staff can respond to supplement the system or identify the underlying causes and mitigate downtime.
- Software Composition Problems: Software is multi-layered, and its interactions are, too. Components may stop mapping properly (especially when something new is added to the system or something old is taken away), third-party vulnerabilities become your vulnerabilities, and open-source components stop functioning properly. Software composition analysis (SCA) tools can help teams identify these problems and resolve them.
So, what’s left to resolve?
Architectural Debt: The Fourth Piece of the Puzzle
Architectural technical debt is similar to other types of technical debt, but it’s more built into the software construction. It comprises trade-offs made for immediate short-term benefits, architectural drift, intentional violation of best practices or target architecture, and using unstable shortcuts to get to the product delivery finish line—while there are real costs and drawbacks, it’s in service of bigger priorities.
Architectural debt happens when architects decide the ‘principle’ (or the immediate costs of fixing the problem in the moment) is too high or impossible to immediately pay. Instead, they accept that the principle plus interest (the long-term consequences of not making the change now) will be paid over time.
Related: Architectural Technical Debt and Its Role in the Enterprise
This debt may have increased operational costs, increased risks and inefficiencies, and less potential to be modified or enhanced in the future. For example, if a company needs to modify a legacy program to include functionalities that support a new product line, they have two broad options:
1. Build the new functionalities into the existing structure.
The legacy program remains a legacy program, and the team builds the new product line on top of that shaky foundation. They might have to add a few workarounds, and custom exceptions will need a lot of attention, but the core functionalities are up and running. There are key upsides to this approach: it’s faster, so deadlines are easier to meet, and it addresses the primary project need—without adding extra work, expenses, or complications.
However, there are some hefty downsides, all of which have to do with architectural debt:
- The weaknesses of the legacy code remain unaddressed. It’s a pending problem that’s continually pushed down the line.
- The functions for the new product line have the same vulnerabilities—and probably a few extra ones.
- If something takes down the system, it breaks everything, and the dev teams are going to suddenly be faced with solving the architectural technical debt whether it’s a good time or not.
2. Use the opportunity to rearchitect things.
Legacy software is, in many ways, a ticking time bomb. It has to be reworked eventually, and everyone agrees that the best time to do it is now. So the legacy program is assessed, broken down, and remade. Maybe it’s now fully cloud-compatible, or maybe it’s built through more standardized processes so it can integrate with other tools or by a modular microservice.
Then, once everything is back in working order to the new standards, those functions for the new product line are incorporated. It may not be the fastest or cheapest option, but it can reset the clock on architectural technical debt.
However, there are significant risks to this approach. It may be too ham-fisted for the project because it requires you to devote a lot of time, money, and staff resources to it. Rearchitecture projects can take years, and that takes away from your team’s ability to focus on new projects, software upgrades, and profitable opportunities.
3. Address architectural technical debt by prioritizing observability
The biggest challenge businesses face with architectural debt is that it’s invisible—and, even when it’s visible, it’s hard to untangle and trace to a core cause. However, that doesn’t mean companies have to consider struggling under the invisible weight of sub-par logic. Instead, companies should adopt these two strategies:
- Add architectural observability tools to the list of programs used to spot and resolve problems. Just like all three of the other types of tech debt (source code quality, performance problems, and compatibility issues) have their own triage tools, architectural debt needs its own, too.
- Make architectural debt a priority by focusing on architectural simplification—or actively searching out complex systems to rearchitect and fully standardize. Using architectural observability tools that can comb through software architectures can remove obscurity and make it much easier to implement actionable workflows. Whether you have a coalition focused on architectural debt or you want the issue to be the focus of more projects, continual monitoring offers the best first step.
Why Architectural Debt Falls By the Wayside
Unfortunately, architectural debt has historically been hard to identify, let alone resolve. This is because it’s more abstract than source code issues. Some common types of architectural debt are tightly coupled components (especially when combined with lack of documentation), relying on third-party and outdated libraries, and having an architecture that was built before operations on the cloud became universal. Companies often don’t have the tools to see architectural debt.
While source code bugs may be immediately visible, captured by tools, or even hinted at through code smells, there may be no direct sign of sub-optimal architectural design. Things just simply won’t work as well as they should, and speed, frustration, and failure build.
Along with its lack of visibility, architectural debt is often unintentional. In the example above, the dev team may have sat down and intentionally decided to forego rearchitecting in favor of the faster option, tabling the massive liability for a later date. But in many situations, that’s not the case for architectural tech debt. This is a severe problem, as the only ‘good’ tech debt is intentional tech debt.
Reveal Architectural Technical Debt Through Architectural Observability
Architectural observability tools specifically review and analyze software architecture to search out sub-optimal elements, including complex class entanglements, zombie dead code, and log dependency chains across resources, classes, database tables, and more. Past generations of software were not able to manage this because it’s highly conceptual work. But smarter systems, powered by AI and the ability to sift through increasingly large piles of data, can recognize what static analysis tools couldn’t.
Related: Getting a Handle on Architectural Debt
Today’s engineering teams can use architectural observability to monitor tech debt that develops over time in applications. Architectural observability is both the capability and the ongoing process of using quantifiable data produced by a system to assess the health and performance of that system.
AO tools can gather measurements about transactions, application functions, and events and compare that performance to baseline metrics or changes in performance over time. With this insight, the tools can monitor changes to make sure they remain within acceptable levels, alert teams when bigger problems start to emerge and—with particularly advanced tools—make recommendations regarding prioritization and potential solutions.
How to Use Architectural Observability Tools
Businesses and development teams can implement architectural observability tools to monitor existing systems and uncover suboptimal processes or architectural debt. There are three key phases these tools can enact:
- Analyze: The right tool can continuously analyze application architecture to create a baseline, start marking potential red flags, and maintain a history.
- Pinpoint: Once it gains familiarity with your system, it can identify definite and potential architectural issues for your team to dig into. AO tools can flag anomalies, dead code, and developing problems.
- Observe architectural drift: Most architectural debt doesn’t start as suboptimal. It becomes suboptimal over time as other software advances and leaves your architecture vulnerable or simply comparatively worse.
From these phases, teams can use insights and recommendations to:
- Prioritize the most significant or the easiest to fix forms of technical debt. Much like the debt snowball or debt avalanche methods of resolving personal debt, companies are in a better position to pick a strategy.
- Address the high-priority items. The development team can do this on their own or employ tools to handle part or all of the project.
- Continuously observe the system.
- Whittle down architectural technical debt to manageable levels.
Reveal and Resolve Lingering Architectural Debt
More and more organizations are recognizing the real dangers of technical debt. But because there’s so much of it, many companies are either swamped with source code debt or are focusing on the low-hanging fruit of technical debt.
Addressing only performance issues, code smells, or faulty service connections during fixed periods in delivery cycles may give leaders a false sense of progress and fails to address technical debt accumulating in the architecture. It’s in the resolving of architectural technical debt that companies see the most relief from performance issues and expensive tech liabilities. At vFunction, we’ve developed a platform for identifying, monitoring, and resolving architectural debt. Reach out today to see how our AI-powered Architectural Observability Platform can do the heavy lifting in optimizing your software architecture, enabling scale and ongoing engineering velocity
