BrainBlog for vFunction by Jason Bloomberg
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.’
Read the whole BrainBlog here.
