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.
