Is dealing with technical debt worth the effort?
This week, Chordia Consulting’s #CautionaryCanadian explores the concept of “technical debt” as introduced in an Enterprisers Project paper: “How To Reduce Technical Debt,” available for you to read here.
Introduction
“Technical debt” is a term that is used to describe what happens to an IT environment over a period of time as acquisitions exceed retirement of hardware and software. It is a pervasive condition that creates substantial challenges and negative consequences for how well IT serves the business. The imperative to enable business growth through IT investments far outstrips the drive or support for a regimen of simplifying or de-cluttering the IT stack. In many client engagements, I witnessed firsthand the technical debt issue and the reluctance to address it. I am always intrigued when I come across an article that attempts to describe the issue and suggests ways to tackle it. This week’s blog features such an article and provides additional insight to support the premise that this is an issue that can - and should - be tackled.
In "How to reduce technical debt: 5 tips” the author describes technical debt as “legacy systems and processes” and the cost of technical debt as “draining, dangerous, and an inhibitor to digital transformation.” She lists the 5 steps to address technical debt are:
Inventory the environment;
Cost out the effort to update systems;
Play the risk card;
Understand opportunity costs;
Have the difficult conversations.
This is advice offered by the veteran CIO interviewed for the article. The author also describes technical debt as a large, off-balance sheet liability that must be accounted for to the business. She suggests CEOs are mostly focused on “shiny new technologies” and that it is difficult to convince business leaders and board members to pay down technical debt when they are more interested in “what’s next?” This is a good introduction to the issue but I believe there is more to it. In the rest of this blog, I’ll focus on the two highlighted topics above and add some additional insights at the end.
Get An Inventory
Take, for example, Step 1 where the suggestion is to inventory the environment. I could not agree more. This requires substantial effort, however, and, unless there is broad support both in IT and the business, it’s a step that might not be fully executed. The principle is to collect all the facts needed to drive better decisions. When you don't have all the necessary data, conclusions can be questioned and will be more difficult to defend. Given that the effort of performing this step is likely to mean someone is not doing something else to support shiny new capabilities, this is a perfectly understandable barrier to the inventory effort. Yet this effort is vital.
Understand Your Costs
A similar need to dive more deeply into the remaining four steps exists. For example, as with the inventory effort, developing a point of view on what it might cost to upgrade systems is another substantial effort that can often meet with resistance. It is not as simple as “upgrading a component or two.” When it comes to technical debt, there are several strategies used to address the issue. For example, Gartner outlines 5 different “Strategic Rs” for application migration to the cloud: Rehost, Refactor, Revise, Rebuild and Replace. (You can read a short article describing Gartner's 5 Rs in more detail here.) A more generic version of Gartner's 5 Rs is: Retire, Replace, Retain/wrap/expand, Rehost and Re-envision. No matter which best practice you subscribe to, the process is quite involved and, therefore, meets with the same resistance.
Additional Insight: Technology Diversity and Brittleness
As a result of my experience on the issue of technical debt, the need for action, and the difficulty of getting commitments, I offer two additional insights not mentioned in the article. They are: 1) the diversity of the IT stack, and: 2) how this drives a degree of brittleness that inhibits change and drives unexpected consequences.
The rate and pace of technology, as described by Moore’s Law, means that advancements in technology in pursuit of lower cost and higher performance and capacity drive a high level of diversity at every layer of the IT stack. The resulting permutations may be measured in the thousands. Sometimes the cost of having two different but similar things is trivial, even when the volume (number of instances) of each permutation in the environment is large. However, there are other times when the cost may be far more substantial for another pair of permutations; costs increase geometrically with volume. Now scale this to a level where there are thousands of these permutations in the environment, each having different volumes and cost considerations; it becomes clear why this can be a tough problem to inventory and cost out.
Many IT shops don’t have a good sense for some of these costs and they lack a way to correlate how these costs drive unintended consequences for IT operations and maintenance. For every permutation, someone needs to understand if it should be handled differently. For legacy permutations, this could mean that fewer and fewer people in the organization have the knowledge necessary to make this determination. One trend we see to address this is the increasing use of automation to perform activities that would otherwise be performed by people. This automation technology, however, still needs to be "taught" how different permutations might drive different algorithmic responses.
What all of this adds up to is the process of changing something in the environment, whether manually or through automation, becomes increasingly difficult to perform without causing breakage or service disruption; the complexity of all these permutations and how they interact causes unforeseen conditions that drive brittleness.
Stuff breaks.
Summary
In a few situations, I saw clients whose leadership had more intestinal fortitude for dealing with technical debt. It wasn’t immediately obvious to these IT shops that their efforts would pay off and there were times when they worried that their executive support would fade. They persevered, however, and in two to three years’ time their efforts led to reduced unintended consequences (better service levels) and increased their agility (more responsive to the business need). Their use of technology made them more competitive than others in their markets. Their investment produced greater returns than they could have imagined.
This is a subject that should get more focus in the press and more success stories are required to help others have the difficult conversations both I and our article’s author have described.
How Chordia Consulting can help address technical debt
At Chordia Consulting we understand the issue, the challenge and the strategies to successfully address technical debt. Our IT Modernization and IT Value Services are specifically designed to address this kind of problem.
Commentaires