Category: Uncategorized

In our previous installment, Jason Bloomberg explored the challenges of delivering innovative AI-based functionality while depending upon legacy architectures. All too often, the design expectations of new and differentiating features are at odds with the massive architectural debt that exists within past systems. 

Any enterprise that is not agile enough to respond to customer needs will eventually fail in the marketplace. At the same time, if the organization moves forward with new plans without resolving architectural and technical debt, that’s a surefire recipe for system failures and security breaches. 

Customers and partners can try to mitigate some of this modernization risk by building service level agreements (SLAs) into their contracts, but such measures are backward-facing and punitive, rather than preventative and forward-looking. This is why both industry organizations and government bodies are adopting better standards and defining policies for IT governance, risk mitigation, and compliance (or GRC, for short).

Ignore governance at your own risk

Never mind the idea that any one institution is ‘too big to fail’ any more, even if they fill a huge niche in an overconsolidated economy. Institutions and companies can and will fail, and governments won’t always be there to backstop them.

Since the 2008 global financial crisis knocked down many once-stalwart financial and insurance firms, additional regulations were put in place to demand better governance and reduce over-leveraged investments, but it seems like some of the old risk patterns such as mortgage-backed securities are creeping back. 

Recent events like the 2023 bank run failure and regulated sale of Silicon Valley Bank (SVB) again put a spotlight on the responsible governance business processes within all financial institutions. Analysts could pin their failure on human overconfidence and bad decisions, because they tied up too much capital in long-term bonds that quickly became illiquid when interest rates started rising sharply in 2022—but there’s a deeper story here.

As the name suggests, SVB grew by catering services to cutting-edge Silicon Valley startups and elite tech firms. Still, they got started themselves back in the 1980s. Therefore, beyond suffering from a lack of diversification, the systems bank executives used to predict interest risk were likely obsolete and poorly architected, and they failed to notice the approaching economic storm until it was upon them.

The changing nature of compliance

We are seeing renewed interest in GRC among IT executives and architects. 

Updates from the Federal Financial Institutions Examination Council (or FFIEC) have now turned their focus on architecture, infrastructure, and operations in their recent “Architecture, Infrastructure, and Operations” booklet of the FFIEC Information Technology Examination Handbook. This booklet provides risk management guidance to examiners on processes that promote sound and controlled execution of architecture and operations information at financial institutions. 

Further, the latest cyber-readiness orders from the White House are encouraging the creation of new mission teams dedicated to software compliance and software bill of materials (SBOMs). Similar initiatives like DevOps Research and Assessment (DORA) are taking hold in the European Union, and around the world.

Companies need to include architecture and operations in GRC assessments

The first compliance programs weren’t software-based at all, they were services engagements. At the behest of C-level executives concerned with risk management, high-dollar consultants would scour a corporation’s offices and data centers to conduct a manual discovery and auditing process.

The result? Usually a nice thick binder outlining the infrastructure as it exists, describing how the company maintains system availability and security protocols, just in case an investor or regulator comes looking to verify the company’s IT risk profile.

That’s not going to be good enough anymore. New guidelines and regulations are sending a warning to get every organization’s GRC house in order and that includes architecture and operations.

Since the advent of distributed service-based software applications, there have always been compliance checking tools, but they are focused mostly on the ongoing operations of the business, rather than the potential architectural debt caused by change. It’s time for that to change.

Where should we look for GRC improvements?

Most compliance regimes are rather general purpose. This is intentional, as a government or trade organization can’t dictate that organizations use specific architecture, only that they avoid risk. NIST and FFIEC guidelines cover all types of infrastructure.

Four unique solution layers have evolved to focus on governance, compliance and risk.

• Code quality. Static and dynamic analysis of code for bugs and vulnerabilities has been around for a long time. Vendors like SonarQube and CAST arose within this category, as well as newer SAST and DAST scanning tools designed for modern platforms.
• Software composition analysis (SCA). By mapping the components of an enterprise architecture, vendors like Snyk, Tanium, Sonatype, Slim AI and other open source tools gather an SBOMb or an as-is topology, in order to help identify vulnerabilities or rogue items within the software supply chain.
• Observability now includes an amazing number of consolidated vendors including New Relic, Splunk, Datadog, Dynatrace and others, with solutions such as APM (application performance monitoring) platforms, as well as advanced processing of real-time events, logs, traces and metrics to provide telemetry into current outages and potential failures.
• Architectural Observability (AO) supports other GRC layers by mapping a software architecture and supporting code into modular, logical domains, in order to highlight where change and system complexity will introduce unexpected risk and costs. vFunction approaches this AO layer from a continuous modernization perspective.

The combined output of GRC efforts should produce effective governance policy, with clearly defined goals and risk thresholds to take much of the work and uncertainty out of compliance.

Who is involved in GRC efforts

Especially in highly regulated industries like financial and healthcare, GRC efforts would create two parallel workstreams: one for modernizing the application architecture with DevOps-style feedback loops, and another for continuously proving that the system under change remains compliant through architectural observability. 

• Architects need to go well beyond the old Visio diagrams and ‘death star’ observability maps to conduct continuous architectural governance to identify and mitigate risk.
• System integrators and cloud service providers will need to lead the way on GRC initiatives for their contributions, or get out of the way.
• Auditing and certification services from leading consultants and vendors will need to move from one-time projects to continuous architectural observability.
• Software delivery teams will need to ‘shift-left’ with architectural observability, so the impact of drift and changes can be understood earlier in the DevOps lifecycle.

The Intellyx Take

Since there will always be novel cyberattacks and unique system failures caused by software interdependence, it’s time we started continuously validating our software architectures, to understand how change and drift can manifest as IT risk for organizations of all sizes. 

Larger companies that fail to govern the architectures of their massive application and data estates will make the headlines if they have a major security breach, or get severely penalized by regulatory bodies. If the problems fester, they may even need to spin off business units or rationalize a merger. 

Smaller organizations are even more risk averse, as a lack of trust can quickly cause them to be replaced by customers, and there’s far less cushion against architectural failures.

Adopting responsible governance policies for continuous compliance, coupled with architectural observability practices can allow everyone in the enterprise to breathe easier when the next major audit or new regulation approaches.

Next up? We’ll cover how AO can help application delivery teams break out of release windows and waterfall development to move forward with modern cloud architectures.

Copyright ©2024 Intellyx BV. At the time of writing, vFunction is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article. Image source: Adobe Image Express

It’s not often that software developers and practitioners get to consume a study that so deeply reflects the cause and solution to significant problems they face. Architectural technical debt is one common area that is not always discussed but is often felt by anyone working in software development. In Building and evaluating a theory of architectural technical debt in software-intensive systems, readers are offered a well-rounded perspective on ATD (Architectural Technical Debt), bridging the gap between academic research and industry practice, making its findings particularly relevant for software engineers and technical leaders who will inevitably deal with some form of ATD in their work.

Introduction to Architectural Technical Debt (ATD)

Understanding and managing Architectural Technical Debt (ATD) is crucial for a software system’s long-term health and effectiveness. Regardless of the technology or organization, the abundance of ATD in the ever-evolving realm of software development is staggering. 

Software engineers, architects, and anyone working within a technical organization have heard the term “technical debt.” In general, this means that software has not been built optimally. This could range from improperly structured code or poor naming conventions to excessive code duplication throughout the codebase. ATD borrows from this well-known concept but is broader in scope. ATD highlights the compromises made during software design and development that affect the system’s core architecture. Fixing these defects requires significantly more work than fixing poor naming or code duplication, as seen in more generalized tech debt. While the choices that lead to this type of technical debt focus on short-term benefits, these compromises can accumulate ‘debt’ that impacts a software’s future maintenance and evolution.

Architects and developers can see ATD in their organization’s codebase in various forms. One common form is quick fixes that patch immediate problems but create deeper issues; another is when design choices made under time constraints limit the future scalability of the system. It’s a common challenge in software engineering, often overlooked in the rush to meet deadlines and deliver features. Architects know that such fixes are necessary to support and evolve the system in the long term, but business and product teams want to use the budget to build something new and shiny.

By the end of this article, readers will have a distilled version of the concepts covered in the study. This includes critical factors in understanding ATD – its symptoms, causes, impacts, and management strategies. Using this study as our guide, our exploration into ATD will cover several critical areas:

• Identifying ATD: how can you recognize ATD in software projects? This includes symptoms like increased complexity, difficulty in adding new features, and a rise in maintenance efforts.
• Origins and Causes: Looking at core factors contributing to ATD, such as time pressure, resource limitations, and short-term planning. Understanding these causes helps in anticipating and mitigating ATD.
• Impacts and Consequences: The long-term effects of ATD are profound. The actual cost appears only by exploring how ATD can lead to higher costs, lower system reliability, and reduced agility in responding to new requirements.
• Strategies for Management and Mitigation: Managing ATD is not just about fixing problems; it requires strategic discovery, planning, and foresight. Strategies include regular code reviews, refactoring, and prioritizing architectural integrity over immediate solutions.
• Implications for Software Development: Lastly, one should see that the study’s findings have far-reaching implications. For practitioners, guidance from the study offers a roadmap to healthier software practices. For researchers, it provides a foundation for further exploration into ATD management.

This knowledge is crucial for software architects and the engineers and developers who work alongside them. This groundwork paves the way to building sustainable, efficient, and adaptable software systems.

Key Findings: Nature and Impact of Architectural Technical Debt

When it comes down to distilling critical findings on the nature and impact of architectural technical debt, there are three key areas to focus on: the symptoms, causes, and consequences. Like any issue technologists deal with, knowledge in these three areas allows architects and technical leaders to identify and remedy potential ATD issues. When organizations fail to address them, they should at least be aware of potential outcomes their lack of action may bring in the present and future. Let’s take a look at all three areas a bit closer.

Symptoms of Architectural Technical Debt. Early Warning Signs.

When identifying ATD, the symptoms can manifest in various ways, potentially making it challenging to detect easily. Increased complexity is a primary symptom, usually appearing as a codebase that is hard to understand and modify. Scalability issues may also arise, limiting the building and integration of new features and causing delays. When these significant warning signs appear, corral the ATD before it begins to balloon out and expand.

Root Causes of Architectural Technical Debt

Before remedying ATD, architects should focus on determining its root causes. Several factors generally contribute to the accumulation of ATD depending on the company size and its ambition (to potentially push out new products and features without maintenance and scalability in mind). As most technologists know, time constraints often lead to suboptimal architectural decisions. Limited resources and expertise exacerbate the issue, leading to short-sighted solutions with sub-par implementations. Evolving business and technology landscapes can also render initial designs inadequate, inadvertently adding to the debt. Like any problem, finding and addressing the root cause is necessary to correct it.

Consequences: The Long-term Impact of Architectural Technical Debt

The impacts of unchecked ATD are significant and tend to only get worse with time. As applications grow in complexity, features, and users, this leads to spiraling maintenance costs and diminished system reliability. Over time, ATD can severely restrict an engineering team’s ability to build new features and scale an application to the needs of the business. As a result of this oversight, the company will find it challenging to align its portfolio of applications with evolving market needs or technological advances. As quickly as technology evolves, this could be disastrous for an organization.

For teams in the depths of software development, understanding the multifaceted nature of ATD is vital for effective management and prevention strategies.

Managing Architectural Technical Debt: Strategies and Best Practices

Effective ATD management requires a strategic approach, such as regular code reviews, refactoring, and prioritizing long-term system health over short-term gains. By applying these practices, teams can begin to mitigate the impact of ATD and maintain the sustainability of the software systems they are building.

Another great option is introducing a tool that explicitly helps manage ATD. vFunction’s architectural observability platform helps teams find, fix, and prevent ATD. By integrating vFunction into your SDLC processes, the vFunction platform helps architects take stock of their current applications and the burden of ATD within them.

vFunction allows architects and their organizations to:

• Manage and remediate architectural technical debt
• Define & visualize domains leveraging dynamic analysis and AI
• See class & resource dependencies and cross-domain pollution
• Find & fix high-debt classes
• Pinpoint dead code and dead flows based on production data
• Observe & detect architectural drift
• And much more.

For a complete overview of the vFunction platform, check out our platform overview.

Conclusion

By understanding the symptoms, causes, and consequences of ATD, software architects and developers can be more aware of how to avoid it. By adopting effective management strategies to avoid ATD, software engineers can significantly improve the quality and longevity of software systems.

To learn more about how you can tackle technical debt, download this complimentary Gartner report on ATD.

Technical debt is a problem at the best of times, but during periods of rapid innovation, it can become overwhelming.

Innovation, after all, is never linear. It comes in fits and starts, with dead ends and sudden turns aplenty. Every twist in this tale of innovation leaves something behind – some tool or experiment that turns out to have been a bad idea in retrospect.

All these deviations can potentially add to technical debt, as they are far easier to deploy than to decommission.

Today, AI – in particular, generative AI (GenAI) – is in such a period of rapid innovation. Enterprises, software vendors, and born-in-the-cloud companies alike are jumping into the GenAI pool with both feet. 

It won’t be long, therefore, until many such organizations run into burgeoning technical debt challenges.

Bob Quillin, Chief Ecosystem Officer at vFunction, discussed this problem in a recent article. In this article, he explains how the rapid accumulation of AI tooling can lead to technical debt as requirements evolve and tool vendors go out of business, leading to unsupported packages and tools.

While the rapid obsolescence of tooling is problematic, there is an even more ominous form of technical debt that the rapid innovation in GenAI exacerbates: architectural technical debt (ATD).

Not only do older architectures fall short of the requirements of GenAI, but even modern architectures suffer from the problem of rapid innovation.

Getting a handle on ATD, therefore, is essential for the successful deployment and operationalization of GenAI-based applications.

Understanding GenAI’s Architectural Technical Debt

As I explained in an article from 2023, architectural debt is a special kind of technical debt that indicates expedient, poorly constructed, or obsolete architecture.

I went on to explain that not all architectural debt is bad. Excessive efforts to limit architectural debt can lead to overdesign, thus counterintuitively raising the debt.

Instead, taking an iterative, ‘just enough, just in time’ approach to architecture can mitigate an organization’s exposure to architectural debt long term.

In the case of GenAI, the ATD challenge divides roughly into two areas: dealing with legacy architectures and iterating modern architectures to support rapid innovation.

GenAI in Legacy Architectures

When I say ‘legacy architecture’ in this context, I mean ‘whatever architecture you had in place before GenAI.’ 

Such architecture might indeed be old, say, a three-tier architecture for supporting websites and web applications. Or it might be relatively recent, typically a cloud-native architecture that leverages Kubernetes to provide dynamic software at scale.

If your architecture falls into the first camp, then it won’t take long until you realize that it’s simply not up to the performance, scale, and specialized hardware requirements of GenAI. In fact, it’s unlikely to support the modeling and data preparation phases of a GenAI project, let alone the operationalization of your GenAI applications.

Even though I’m focusing on the application architecture, part of the problem is with the hardware. GenAI requires graphics processing units (GPUs). GPUs aren’t simply souped-up central processing units (CPUs); they work in new ways to address the unique processing requirements of AI modeling and inferencing. As a result, obsolete application architectures are unlikely to support GPUs – if you can even get such chips to work in a legacy environment in the first place.

Legacy data architectures are also a major source of ATD for GenAI. The belief that you can pour whatever enterprise data you have lying around into your large language model (LLM) of choice and get useful results is a myth.

In reality, discovering, organizing, cleaning, and preparing data for GenAI is essential to the initiative’s success – and in many cases, real-time access to up-to-the-minute data is also essential. Legacy data architectures possess neither the data models nor the real-time characteristics that modern GenAI data architectures require.

Rubber Meet Road: Operationalizing GenAI

Preparing data and tweaking models are important to be sure – but unless you can operationalize your GenAI applications at scale, you’ll never see any business value from them.

Due to their performance, scale, and hardware limitations, any architectures that predate cloud native is simply not up to the task of operationalization and thus form a massive hairball of architectural debt.

Just because you’ve transitioned to a cloud-native architecture, however, doesn’t necessarily mean you’re ready for such operationalization.

Instead, the current best practice is to tweak what is now ‘traditional’ cloud-native architecture to support the operationalization of GenAI. These tweaks should include:

• Supporting the ability to rapidly process massive data sets that include both structured and unstructured data
• Full lifecycle considerations that include ingestion, data preparation, and training as well as deployment, management, and ongoing updates
• The incorporation of AI-based capabilities for the continued management and updates of the GenAI applications themselves.

As organizations require greater power and sophistication from their AI-based applications, the more important it will become to leverage AI to support the ongoing requirements of those applications. This ‘apply AI to AI’ capability is unique to AI and thus represents new architectural requirements that no existing architecture is likely to possess.

The Intellyx Take

The fact that even a fully modern cloud-native architecture may not be up to the task of supporting GenAI operationalization should be a wakeup call for anyone dealing with ATD.

The lesson here isn’t that you simply need to update cloud-native architectures for GenAI. The most important takeaway is that it will be necessary to update your GenAI production architecture on a regular basis as innovation continues and technologies evolve.

ATD, therefore, will accrue on a regular basis. The old saying that today’s new technology is tomorrow’s legacy is especially true with GenAI. 

Developing a proactive architectural observability strategy for dealing with such debt, therefore, is essential for maintaining both a competitive pace of innovation and the ability to operationalize GenAI at scale.

Copyright © Intellyx BV. vFunction is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.

Image by Craiyon

Technical debt has become a catch-all term to explain system failures, extended-release cycles,  and increased maintenance costs. When technical budgets are submitted, reducing technical debt has become a line item. Everyone assumes an understanding of technical debt. Yet, technical debt is more than “smelly” code. Architectural technical debt (ATD) looks at the components of the software to observe how they interface to support workflows and to determine how far the software has deviated from the original design.

When software architects and senior engineers put together a cost for architectural technical debt, executives may wonder why engineering teams still need so much funding to fix old code. They begin to question the ongoing requests. Didn’t they approve a similar line item last year?

Making the Case for Managing Debt

When faced with geopolitical unrest, uncertain financial markets, and ongoing inflation, CEOs find it difficult to approve significant dollars for a standard line item. If architects want help managing technical debt, they must first achieve executive buy-in. They need a business case built from data that establishes a strong return on investment (ROI). Their presentations must be understandable for an audience looking at ways to counter external business challenges that threaten profitability. 

To reach this point, technical debt must be understood—and a plan put in place to manage it. Here are four ways architects can understand and manage technical debt.

1. Begin with Data

Successful business cases rely on numbers. They identify the scope of work, the costs, and timelines. When assessing technical debt, organizations often look at code quality or defect ratios. Some IT departments use AI-based tools to help identify and quantify technical debt.

Code-Level Data

Most of these tools are designed to quantify code-level technical debt. They look for inefficiencies, outdated libraries, or sub-optimal code. They provide teams with data they can use to build a business case to correct source code. Identifying architectural technical debt requires more than static analysis of existing code. Architects need data on how an application was designed and how far it has drifted from that design if they want to build a successful business case. 

Architectural Data

For decades, development teams relied on “code whisperers” to identify a potential problem with software architecture. These developers were the individuals who could look at application output and “know” that the problem was structural. They might even know where to focus in the millions of lines of code.

Related: Technical Debt vs Architectural Technical Debt: What to Know

These code whisperers were engineers who spent hours observing how the application performed. They worked their “magic” to keep monolithic applications functioning. However, magic does not build successful business cases. No CEO is going to authorize large sums of money based on a developer’s gut feeling.

Architects need tools that help them analyze architecture quantitatively. Only when engineering leadership can deliver a business case based on data will they receive the funds they need to manage technical debt.

2. Use Automated Tools

Until recently, software engineering teams had no choice but to employ “code whisperers” to identify architectural technical debt. Today, organizations can use automated tools to analyze their application architectures. Depending on the tool, architects can go beyond analyzing the architecture to establishing baselines, observing architectural drift, and resolving deviations before they become catastrophes.

Establish a Baseline

Automated tools can help establish a baseline for an application’s architecture. They can look at areas of ATD, such as cross-domain contamination or interoperability. With a baseline, architects can identify behaviors and interactions, quantify deviations, and measure drift. They can finally see application complexity, modularity, and risk. 

Monitor Drift

Monitoring drift in a continuous modernization environment is impossible without automated tools. Observability at each iteration is essential to minimizing technical debt. If not monitored, architectural drift can quickly grow into ATD that no one wants to touch.

Software engineers should look for tools that help monitor the following: 

• Service Creep. Architects need the ability to audit service changes that alter an application’s architecture.
• Service Exclusivity. Microservices require service exclusivity, but monolithic structures use tightly coupled modules that share resources and classes. Engineers need a tool that ensures service exclusivity.
• Dead Code. Dead code is unused code that can become active. It may be a feature that was never implemented or functionality that became obsolete. Automated tools should identify dead code to avoid accidental activation.
• Common Classes. Architectural tools should identify common classes that should be moved to shared common libraries for core services. If not shared, duplicate code can increase application size, and dependencies that violate service exclusivity in microservices architectures can develop.

Monitoring ATD enables development teams to resolve issues before they become problems that must be fixed immediately. 

Resolve ATD

Automated tools should allow architects to set notification thresholds for technical debt. As applications grow across an enterprise, architects and engineers face increased complexity that is difficult to monitor if they must resort to logs and traces. By setting thresholds, teams are alerted to potential deviations that could impact operations. They can use observability tools to see what is happening during runtime and develop a path for addressing the anomalies. 

3. Apply Best Practices

Organizations can apply best practices such as identifying and tracking debt, using agile development, setting code standards, and automating testing. Or, they can adopt Gartner’s approach to managing architectural technical debt. 

Gartner’s approach does not replace best practices but extends their reach to include everyone in the software value chain. Product management, software engineering, and enterprise architects all have a role to play in managing ATD. The burden of achieving executive buy-in should not rest solely on an architect’s shoulders. 

Establish an ATD Guidance Team

All levels in an organization contribute to accumulating technical debt. Product managers are pressured to deliver features earlier than planned. Product leaders feel their competitive edge is slipping. Developers feel forced to make suboptimal coding decisions to meet deadlines. Each decision has the potential to add to ATD. 

Gartner recommends creating a cross-functional team that draws from software engineering, enterprise architects, and business leaders. They see this team as a guiding force in developing an ATD remediation strategy that aligns with company goals. This group should be responsible for building awareness and a shared understanding of accumulating ATD.

Quantifying ATD

Before presenting a compelling business case, architects need to quantify the architectural technical debt across the enterprise. Using automated tools, IT teams can establish consistent measurements for determining the scope of work. With help from the ATD guidance team, software engineers can build a business case that aligns with corporate objectives. 

Related: Empowering Your Software Evolution: Continuous Modernization: Unleashing the Potential of Continuous Modernization

Continuous monitoring of architectural drift is a best practice that ensures that ATD does not exceed an established threshold. It allows the guidance team to address the accumulating debt early so a remediation plan can be put in place. It can also help build an awareness of how decisions impact ATD.

Using Continuous Modernization

Correcting architectural drift requires more than changing a few lines of code. It requires careful consideration of the potential impact on the existing and future design. Continuous modernization allows software teams to adjust deviations in increments to ensure that the change is operating as expected. It makes it easier to troubleshoot issues and apply fixes. Trying to find a problem in an annual release with thousands of lines of changed code can take weeks—and it can take months to fix it.

Following the best practice of continuous modernization increases end-user satisfaction as updates are released more frequently. If a problem does arise, the time to resolve it is much shorter, with less disruption to operations. 

4. Ensure Architectural Observability

Building a solid business case to reduce ATD requires data. Only with automated tools that offer architectural observability can software teams acquire the quantifying data needed to achieve executive buy-in. Many executives may see code-level remediation as sufficient without understanding the broader issues that can degrade performance, limit scalability, and jeopardize data integrity.

Architectural observability can help ATD guidance teams understand the consequences of ignoring accumulating ATD. They can use that information to raise awareness across an enterprise. With the right observability tool, architects can provide visuals that underscore the need to make reducing technical debt a priority.

Use Architectural Observability to Understand and Manage Architecture Debt

Agile development and continuous modernization are two best practices that need architectural observability. Each sprint has the potential for architectural drift. Trying to assess drift at each iteration without automated tools is virtually impossible. Architects have little time to review logs, traces, or metrics before the next sprint is complete. 

vFunction’s Architectural Observability Platform allows architects to collect the data needed for executive buy-in for ATD remediation. The AI-driven platform supplies technical teams with a clear picture of architectural anomalies to be addressed proactively. With its AI capabilities, the Architectural Observability Platform can assist cross-functional teams in developing an ATD strategy. Request a demo to learn how architectural observability can help you manage your architectural technical debt.

“Not all debt is bad debt” is a concept typically reserved for financial experts and budgeting gurus. There are, after all, good types of debt: mortgage loans, well-researched business loans, and even credit card debt that is paid off every month without ever charging interest. The issue is bad debt: high-interest car loans, personal loans, and long-standing credit card debt on a high-interest card. The trouble starts not when there’s debt, but when there’s bad debt—or debt that gets out of hand.

These underlying principles of personal debt management readily transfer over to technical management. The answer to the question, ‘Is all technical debt bad?’ is also no—there are both good and bad types—but it’s crucial for today’s businesses to recognize which is which and how to mitigate as much bad technical debt as possible. By knowing what bad technical debt looks like, how to prioritize different types of bad debt, and the right processes for resolving technical debt over time, companies can more safely leverage technical debt in the future.

The Key Difference Between Good and Bad Technical Debt: Intentionality

Very few companies can remain competitive by refusing to take on any technical debt at all. For example, many companies start to incur debt by choosing an expedient solution that allows them to meet a business-critical deadline. They might push out a new feature now and send patches or updates later. 

This is much the same way a business might take out a business loan to cover inventory before a peak sales season; you’re taking on controlled risk and liability to secure the immediate resources necessary to grow. Your team can leverage good technical debt to grow your business, allocate resources to the most important projects, and ensure customer demands are satisfied.

Related: Taking Control of Technical Debt: How Continuous Refactoring Transforms Applications

By refusing to have any technical debt, project costs and timelines can quickly balloon. It can also be an impossible standard to meet, leaving your organization unable to even acknowledge the technical debt that does occur. So it’s better to anticipate it, manage it, and even leverage it. 

This leads to the core difference between good and bad technical debt. In personal finance terms, the interest rate and the purpose of a loan determine whether it’s good or bad. But in software, it’s much more about intentionality.

• Did your team sit down, discuss the risks of the debt, decide it was worth it, and create a plan to address it in the future? If so, it’s good technical debt.
• Did your team take a shortcut without really considering the implications? This is bad technical debt, with unknown ripple effects and no plan in place to resolve it.

When you intentionally choose to take on debt and you understand its primary implications, it’s a measured response to circumstances that can strengthen, rather than jeopardize, your technology.

How All Technical Debt Can Go Bad Over Time

There is one complication here: even good technical debt goes bad. Just like good business loans become a bad liability when they stack too high or you don’t make timely payments, previously good tech debt transforms into a very risky liability. Here’s how:

• The project managers that originally accounted for it lose sight of it or leave the company, which means the debt no longer has an active plan to address it.
• The risks of technical debt have grown over time. Naturally, older code experiences drift, will start to have out-of-date components, and will develop bugs. This compounds the effects of even good debt until it’s a much bigger—and a much less well-perceived—problem.
• Entrenched problems make the cost of resolving the technical debt higher and higher. For example, if your Dev team sticks with a legacy platform for a new product release during peak season, they’re incurring good tech debt because they’ve considered the cost of eventually refactoring the original legacy work and the new product release. But if that same decision-making process happens again and again, the cost of refactoring grows bigger and bigger.

Even good technical debt is debt, and virtually all technical debt turns bad eventually unless you manage it carefully. Even worse, there may be technical debt your organization doesn’t even know about. A fundamental process for resolving technical debt is constantly monitoring your systems to catch technical debt that may have slipped through the cracks so you know what technical debt lingers unanswered.

One form of potentially invisible technical debt that can do the most damage behind the scenes is architectural technical debt. This challenge can creep up on any organization, especially if you have long standing programs. 

Some forms of architectural debt are architectural drift—which happens as code departs further and further away from the original vision until it borders on becoming unrecognizable—high complexity that can make identifying and resolving technical debt much harder, dead code, dependence on third-party libraries and legacy systems, and so on. Architectural technical debt can be so insidious that it’s important to have specific projects and processes created just for countering it.

Why You Need to Care About Technical Debt

Technical debt of all forms has real business implications. Externally, it can lead to performance issues, customer frustration, product failures, and opportunity costs that let your competitors surge ahead. Internally, it can be frustrating for software developers, cause projects to have increasingly long timelines, and result in friction between strategy, product, and IT teams. These potential harms come with both good and bad debt, but there are also unique consequences of both categories.

How Bad Debt Hurts Your Company

• It’s often invisible. While companies can use a variety of static tools to monitor some source code issues, these often don’t account for architectural technical debt.
• Fishing out and resolving technical debt is very complex and takes a lot of time.

How Good Debt Hurts Your Company

• The programs are still changing from your original architectural plans through the workarounds and shortcuts.
• The debt needs to be accounted for in the future, impacting future productivity.
• Eventually, it may reach a critical mass, becoming bad debt, leading to unstable software, unhappy teams, and a poor business reputation.

Ultimately, both forms of debt always have a negative tinge; they add up with liabilities and capital on the opposite side of your corporate balance sheet from positive assets.

Two Important Steps for Handling Technical Debt

Because technical debt is virtually unavoidable, companies need to make efforts to (i) make sure as much of it as possible is good debt and (ii) resolve it as quickly and efficiently as possible. There are two priorities that must be addressed:

Priority #1: Recognize the Technical Debt

This is the first step your organization needs to take to make technical debt more manageable. On current projects, start recognizing the technical debt incurred by different actions and make it part of the project documentation. As you standardize this process and add it to how you manage projects in the future, it will become easier, and you’ll have clearer records of technical debt to-dos. 

Related: Empowering Your Software Evolution: Unleashing the Potential of Continuous Modernization

It’s just as important, if much more difficult, to go through and identify technical debt generated in the past. Modern AI-powered software can comb through the source code and architecture to make in-roads in identifying it. Over time, the software will become more adept at uncovering, identifying, and reporting technical debt, operating efficiently behind the scenes until it needs action from a human developer.

Priority #2: Create a System for Managing and Resolving Technical Debt

As your processes for identifying technical debt are whirring away, it’s time to start methodically addressing it. Just like all aspects of project management, it’s important to create a system that makes action predictable, consistent, and easy to continue over time. Build out your process with these four components:

#1: Create a Priority Schema

Not all technical debt can be addressed at once—nor should it. Work with key stakeholders to decide what types of debt should be the priority to solve in different situations. For example, you can adopt the “snowball method” of addressing personal finance debt: start with the lowest-impact but easiest-to-resolve debt, like source code bugs. 

Alternatively, you can adopt the “snow avalanche method” by tackling the costliest debt first, knowing that the work will be hard but the positive effects will be magnified. You can also prioritize by focusing on architecture simplification, choosing to shore up core product lines first, or other hierarchies.

#2: Choose the Right Resources to Track It

Choose the right stack of tools that can help your company track technical debt. Ideally, your tools will be able to track both source code and architectural technical debt, whether it’s outright bugs, incompatibility that grows over time, or architectural drift as the applications start to move too far away from the original design.

#3: Create Technical Debt Reduction Projects

Once you have a growing list of technical debt, create projects where addressing it is the primary focus. This is different from other forms of projects, in which addressing technical debt is a secondary priority or teams care only about reducing the total amount of new debt they create along the way. These projects focus solely on resolving technical debt, and your leadership team needs to make it their mission to prioritize them, even in the face of tempting new product feature projects.

#4: Make It Part of Your Standard Project Processes

Alongside the direct technical debt projects, make some technical debt recognition and resolution tasks a standard part of all agile projects. You can build elements of technical debt resolution into the software development lifecycle (SDLC) by ensuring new developments do their part to address technical debt. This is much better than ignoring the problem altogether or only addressing technical debt during technical debt projects. By regularly fortifying, updating, and simplifying how new code relates to the whole, you can reduce technical debt as a standard part of doing business.

By managing it on a regular basis, keeping documentation current, and flagging problematic debt that needs to be directly addressed, you can avoid having both good and bad tech debt stack up.

Incurring Debt Is Part of Business—Resolving It Should Be, Too

Technical debt is a constant. But that doesn’t mean it can be ignored—in fact, ignoring it transforms every type of technical debt into an unaudited risk and looming liability. Instead, your company needs to develop a multi-pronged strategy for addressing it. This should include recognizing it, monitoring it, documenting it, and—ultimately—refactoring or rearchitecting your code to eliminate it. 

At vFunction, our suite of technical debt recognition and resolution tools can help with all of these elements. Reach out today to see how automating the identification and problem-solving aspects of technical debt management can help.

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:

1. The weaknesses of the legacy code remain unaddressed. It’s a pending problem that’s continually pushed down the line.
2. The functions for the new product line have the same vulnerabilities—and probably a few extra ones.
3. 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:

1. 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.
2. 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:

1. Analyze: The right tool can continuously analyze application architecture to create a baseline, start marking potential red flags, and maintain a history.
2. 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.
3. 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