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 had been 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 have focused on providing a solution that the client wanted rather than 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.
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 has 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.
Before we can manage ATD, we must first understand the problem. Desmond Tutu once wisely said, “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 a part of the development process and not a separate event to be completed after development was finished.
Shift-left can be implemented in two different ways in managing ATD:
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 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:
I recently discovered vFunction’s AI-driven architectural observability platform, which is focused on the following deliverables:
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 the implementation of the vFunction platform and an underlying shift-left approach.
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 organizational 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 of considering 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!
This article was originally published by John Vester on HackerNoon.
In the rapidly evolving financial technology landscape, innovative product studios are emerging as powerful catalysts…
In an era defined by rapid technological advancement, Artificial Intelligence (AI) stands as a transformative…
In a historic moment for Indian esports, Wasfi “YoshiKiller” Bilal secured a silver medal at…
The Tech Panda takes a look at recently launched gadgets & apps in the market.…
The Tech Panda takes a look at what’s buzzing in the startup ecosystem. The startup…
With just days until the outcome of the U.S. presidential race, Bitcoin enthusiasts across the…
