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.