When I think about technical debt, I still remember the first application I created that made me realize the consequences of an unsuitable architecture. It happened back in the late 1990s, when I was first getting started as a consultant.
The client had requested use of the Lotus Notes platform to build a procurement system for their customers. Using the Lotus Notes client and a custom application, end-users could make requests that would be tracked by the application and fulfilled by the product owner’s team. In theory, it was a really cool idea – especially since web-developed applications were not prevalent and everyone used Lotus Notes on a daily basis.
The core problem is that the data was very relational in design – and Lotus Notes was not a relational database. The solution’s design required schema management within every Lotus Notes document and leaned on a series of multi-value fields to simulate the relationships between data attributes. It was a mess.
A great deal of logic in the Lotus Notes application would not have been required if a better platform was recommended. The source code was complicated to support. Enhancements to the data structure resulted in major refactoring of the underlying code – not to mention running server-based jobs to convert the existing data. Don’t get me started on the effort behind report creation.
Since I was early in my career I was focused on providing a solution that the client wanted over trying to offer a better solution. This was certainly a lesson I learned early in my career, but in the years since that project I’ve come to realize that the consequence of architectural technical debt is an unfortunate reality we all face.
Let’s explore the concept of architecture tech debt a little more at a macro level.
Architectural Tech Debt (ATD)
The Architectural Technical Debt (ATD) Library at Carnegie Mellon University provides the following definition.) of ATD:
Architectural technical debt is a design or construction approach that's expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now (including increased cost over time).
In the “Quick Answer: How to Manage Architecture Technical Debt” (published 09/22/2023), Gartner Group defines ATD as follows:
Architecture technical debt is that type of technical debt that is caused by architectural drift, suboptimal architectural decisions, violations of defined target product architecture and established industry architectural best practices, and architecture trade-offs made for faster software delivery.
In both cases, benefits that often yield short-term celebrations can be met with long-term challenges. This is similar to my Lotus Notes example mentioned in the introduction.
To further complicate matters, tooling to help identify and manage tech debt for software architecture have been missing in comparison to the other aspects of software development:
For code quality, observability and SCA, proven tooling exists with products like Sonarqube, Datadog, New Relic, GitHub and Snyk. However, the software architecture segment has lagged behind without any proven solutions.
This is unfortunate, given the fact that ATD is consistently the largest – and most damaging – type of technical debt as found in the “Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt” 2015 study published by Carnegie Mellon.
The following illustration summarizes Figure 4 from that report, concluding that bad architecture choices were the clear leader in sources of technical debt.
If not managed, ATD can continue to grow over time at an increasing rate as demonstrated in this simple illustration:
Without mitigation, architecture debt will eventually reach a breaking point for the underlying solution being measured.
Managing ATD
Before we can manage ATD, we must first understand the problem. Desmond Tutu once wisely said that “there is only one way to eat an elephant: a bite at a time.”
The shift-left approach embraces the concept of moving a given aspect closer to the beginning than at the end of a lifecycle. This concept gained popularity with shift-left for testing, where the test phase was moved to part of the development process and not a separate event to be completed after development was finished.
Shift-left can be implemented two different ways in managing ATD:
Shift-left for resiliency — identifying sources which have an impact on resiliency, and then fixing them before they manifest in performance.
Shift-left for security — detect and mitigate security issues during the development lifecycle.
Just like shift-left for testing, a prioritized focus on resilience and security during the development phase will reduce the potential for unexpected incidents.
Architectural observability
Architectural observability gives engineering teams the ability to incrementally address architectural drift within their services at a macro level. In fact, the Wall Street Journal reported the cost to fix technical debt at $1.52 trillion earlier this year in “The Invisible $1.52 Trillion Problem: Clunky Old Software,” article.
To be successful, engineering leadership must be in full alignment with the following organizational objectives:
Resiliency — to recover swiftly from unexpected incidents.
Scalability — to scale appropriately with customer demand.
Velocity — to deliver features and enhancements inline with product expectations.
Cloud Suitability — transforming legacy solutions into efficient cloud-native service offerings.
I recently discovered vFunction’s AI-driven architectural observability platform, which is focused on the following deliverables:
Discover the real architecture of solutions via static and dynamic analysis.
Prevent architecture drift via real-time views of how services are evolving.
Increase resiliency of applications via the elimination of unnecessary dependencies and improvements between application domains and their associated resources.
Manage and remediate tech debt via AI-driven observability.
Additionally, the vFunction platform provides the side-benefit of providing a migration path to transform from monoliths to cloud-native solutions. Once teams have modernized their platforms, they can continuously observe them for ongoing drift. If companies already have microservices, they can use vFunction to detect complexity in distributed applications and address dependencies that impact resiliency and scalability. In either case, once implemented, engineering teams can mitigate ATD well before reaching the breaking point.
In the illustration above, engineering teams are able to mitigate technical debt as a part of each release, due to implementation of the vFunction platform and an underlying shift-left approach.
Conclusion
My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional:
“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”
- J. Vester
The vFunction platform adheres to my mission statement by helping engineering teams employ a shift-left approach to the resiliency and security of their services at a macro level. This is an important distinction, because without such tooling teams are likely to mitigate at a micro level resolving tech debt that doesn’t really matter from an organization perspective.
When I think back to that application that made me realize the challenges with tech debt, I can’t help but think about how that solution yielded more issues than it did benefits with each feature that was introduced. Certainly, the use of shift-left for resiliency alone would have helped surface issues with the underlying architecture at a point where the cost to consider alternatives would be feasible.
If you are interested in learning more about the vFunction solution, you can read more about them here.
Have a really great day!
Top comments (0)