Many organizations today treat technical debt like a pariah. They equate it with legacy systems, worry about how subsequent changes will be complex, time consuming, risky, and cost prohibitive, and consider it something that should be avoided in their journey to becoming a digital enterprise.
What they do not realize is that the debt is not bad in and of itself. Indeed, because speed-to-value is critically important in digital businesses, teams may intentionally take planned shortcuts in order to accomplish the task as quickly and responsibly as possible. As long as the teams understand what they are doing and compromising on, and have suitable plans to address it soon, assuming this debt can be a smart move.
Where enterprises err with technical debt is poorly managing it.
In order to manage it suitably and safely in a digital transformation environment, they should classify it into five major buckets.
Planned debt
This is when people knowingly become indebted. It is like buying a house on a bank loan. You know you must repay the loan, and you plan for it accordingly. The defining feature of this type of debt is that the team knows it has the capabilities and resources to “pay” it back. This is a good debt that helps you quickly achieve business objectives.
Blind debt
This is a dangerous debt where system teams do not even know they are building the debt themselves. This is generally the result of poor practices within the team, unplanned and haphazard development, and a fundamentally broken organizational culture. This often also happens during M&As when the acquirer does not know what kind of mess it is getting into.
Acquired debt
This type of debt is unavoidable in business environments. Many systems that were developed in the past with improper technology platforms, tools, coding practices, governance models, and frameworks build technical debt over time. These legacy systems hold valuable information for enterprises aspiring to become digital businesses, and cannot simply be jettisoned. Instead, they need to be made “debt free” in a prioritized manner.
Dead debt
This is probably the worst of all kinds, because, irrespective of corrective measures taken, the systems have degraded so far that they do not support digital initiatives. Therefore, rip and replace becomes the only option. Enterprises need to be careful with identifying this debt as they may confuse it with other types of debt that can be “repaid.” They may end up spending good money after bad, with no way out.
Mirage debt
Not many enterprises think about this one. It appears during system analysis, when architects and others mistakenly believe they have technical debt, when in reality they do not. If there is any, it is in small components, not the system itself.
What should enterprises do to address technical debt?
They should start by understanding that modernization should be of system components, not the systems themselves. Then, they should look at each of their systems and identify the components that can meet future digital demand, and those that could potentially create problems. Once they have catalogued all the components, they need to invest in reducing each one’s technical debt in the most appropriate way. For example, we have seen enterprises successfully build component capabilities outside the main system and exposing APIs for backward integration. This can work across core functionalities as well as user interfaces.
Our research with over 190 application leaders suggests that 75 percent plan to continue to invest and modernize their applications. There is no reason to fear technical debt as long as you understand what you are getting into. For digital businesses, taking on good technical debt can be a strategic choice. Though processes have their value, enterprises that are driven by processes rather than innovation, and are scared of risking short-term technical debt, will struggle in the digital world.
What has been your experience with application modernization? Please share with me at [email protected].
