This article is the first in a four-part series. In part two, we’ll explore the challenges in navigating the cultural change of modernization. Part three will delve into sustaining the resulting transformation. We’ll wrap up in part four, as we discuss evolving toward modern-day technology goals.
At its most basic, technical debt represents some kind of technology mess that someone has to clean up. In many cases, technical debt results from poorly written code, but more often than not, is more a result of evolving requirements that existing technology simply cannot keep up with.
Technical debt can accrue across the technology landscape – and we could even argue, extends beyond technology altogether in other areas of the business, for example, process debt.
Within the technology arena, technical debt breaks down into two basic categories: infrastructure and applications.
Compared to application technical debt, reducing infrastructure technical debt is the more straightforward. Application technical debt, in contrast, is a knottier problem, because there are so many places that technical debt can hide in existing applications.
Simply identifying this debt is challenge enough. Prioritizing its reduction is also difficult. Eliminating the debt once and for all can be a task of Herculean proportions.
Here’s how to start on this journey.
Assessing Your Current State
The first step in an effective assessment of technical debt is to ensure you start with the big picture. Application technical debt may be where the most urgent problems like, but even so, it’s important to place these issues into the proper context.
The first consideration here is the business and its requirements. Where is existing technical debt causing the business or your customers the most pain?
It’s also important to include operational and cost factors in any assessment. In many cases, for example, older applications require older hardware – and thus the plan for infrastructure technical debt and the corresponding application plan are interdependent.
A recent survey by Wakefield Research of enterprise software architects and developers indicated that the most difficult step in application modernization was securing the budget and resources for the project followed by “knowing what to modernize” and “building a business case.” The only way to address these challenges is to accurately calculate the current technical debt in those applications up front with a data-driven plan.
Cost considerations are also important to any consideration of technical debt reduction planning. Some debt reduction projects will inevitably be more expensive than others – but won’t necessarily deliver more value. You’re looking for projects with the most ‘bang for the buck.’
Rationalize Your Applications
Once you’ve assessed the technical debt across your application landscape, it’s time to sort your application portfolio into four main buckets:
Refactoring: Applications in this category are more or less meeting their requirements, but some internal issue with the code is bogging them down. In this situation, refactoring is the best approach – reworking the code in place without necessarily changing the overall functionality of the application.
Deprecating: Sometimes it’s simply not worth the cost and trouble of dealing with particular instances of technical debt. While it may provide value to clean up these situations, your assessment has determined that your time and money are best spent elsewhere.
It’s important, however, to flag such code as something you’ve intentionally decided to leave alone (at least for the time being). Hence the notion of deprecation – an application you can still use, with the understanding that if you have a choice, use an alternative instead.
Replatforming: In some situations, the technical debt has more to do with the platform than the application itself. For example, an application might be running on an older version of .NET or Java EE.
The main goal of replatforming is typically to move an application to the cloud – without changing anything about the application that isn’t necessary to achieve this goal.
While replatforming is occasionally the best approach to dealing with technical debt, many organizations overuse it – putting debt-laden applications in the cloud without resolving that debt.
Rearchitecting: Whenever replatforming falls short (as it often does), then rearchitecting is typically the approach that best resolves application technical debt issues – but also tends to be the most expensive option.
While it’s possible to replatform an application in the cloud without rearchitecting it, such rearchitecture is necessary in order to take advantage of many of the core benefits of the cloud, including scalability, elasticity, and automated provisioning.
When moving to a cloud native platform (typically Kubernetes), rearchitecture is an absolute must.
Rearchitecting to Reduce Technical Risk
While cloud native computing is all the rage today, it’s important to note that taking a cloud native approach may include a variety of architecture and technology options depending upon the business need.
Rearchitecting, therefore, requires a careful consideration of such needs, as well as available resources (human as well as technology), realistic timeframes for modernization, and the overall cost of the initiative.
Rearchitecture also never works within a vacuum. Any rearchitecture project must take into account the existing application and management landscape in order to address issues of security, governance, and whatever integration is necessary to connect the rearchitected applications to other applications and services.
Because rearchitecture initiatives also include replatforming, it’s also essential to plan ahead for any cloud migration requirements as part of the overall effort.
At some point in every rearchitecture effort, of course, it will be necessary to modernize the code as well as the architecture. Fortunately, there are approaches to modernizing code without the onerous responsibility of rewriting it line by line – even in situations where the architecture of the software is changing.
We’ll be covering application modernization in more depth in the rest of this four-part article series. Stay tuned!
The Intellyx Take
In many cases, organizations tackle modernization projects without thinking specifically about resolving technical debt. However, framing such initiatives in terms of such debt is a good way to improve their chances of success.
Today, it’s possible to measure technical debt with a reasonable amount of accuracy using solutions like vFunction Architectural Observability Platform. Such measurements give you a heat map across your application landscape, pointing out those areas that have particularly knotty messes to clean up and can even pinpoint where to start refactoring or rearchitecting in those apps including the top app component contributors to technical debt and the resulting ROI.
Without such a heat map, modernization efforts tend to go off the rails. Therefore, while technical debt is generally a bad thing, it does serve certain purposes – including directing the modernization team to the highest priority projects.
