True digital transformation occurs when a business uses modern technology to rewrite how it does business, and sometimes, how the marketplace in which it does business will operate going forward. That requires agility, and one of the enemies of agility is excess technical debt.
Technical debt is a useful metaphor for thinking about the shortcuts, workarounds, and postponed decisions that accumulate in a technology stack. The term was originally coined by Ward Cunningham, a programmer known for his contributions to agile and object-oriented methodologies and for his work on wiki software. He was looking for a way to describe the hacks written into software for short-term gain – like allowing the 1.0 version of a product to ship sooner than it would otherwise – that ought to be tracked and corrected or refactored later.
In a YouTube video, Cunningham cautions against using the concept as an excuse to produce sloppy code. But he also explicitly recognizes that taking on technical debt is not always bad.
Coders often learn to understand a business problem best when they produce an initial version of the software sooner rather than later, even if it’s based on an imperfect understanding of the problem to be solved. (Sounds like DevOps, right?) They can then improve their understanding and their code with subsequent iterations. They may also take shortcuts to allow a product to ship, knowing that they will need to go back later and improve the software.
Beyond programming, the concept can be applied to enterprise architecture. Sticking with a legacy system that you know no longer meets your requirements is taking on a debt, even though it may be what the budget requires.
At any scale, the danger is not necessarily in taking on debt when necessary but in allowing debts to accumulate with no plan for paying them off. As a consumer analogy, taking a zero percent loan to buy the car you really want could be a smart use of debt, and one you need not pay off any sooner than the bank requires. Putting a new car on a credit card that charges 20 percent interest would not be so smart and very likely could become an obstacle to making transformational changes in your life, like getting married or buying a house.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]
When digital transformation meets technical debt: 5 bad moves
Here are some of the tricky ways technical debt gets in the way of digital transformation:
1. Letting technical debt lead to technical bankruptcy
Frank Scavo, president and lead analyst at Computer Economics, estimates that as many as 20 percent of enterprises are either in technical bankruptcy or in the “danger zone” for entering bankruptcy, based on failing to stay current with the progress of technology.
For example, an organization that has been lingering on a version of SAP’s R/3 ERP software from the 1990s is also likely to have accumulated a lot of modifications to that software and workarounds for its shortcomings – all of which becomes technical cruft that inhibits agility.
“If you have accumulated a lot of technical debt around that system, it’s going to be very hard for you to upgrade to S/4,” Scavo says, referring to the current edition that SAP positions for digital transformation work.
Accumulate too many such debts across your technology infrastructure and eventually you will get to the bankruptcy stage, where the organization is carrying such a crippling load of technical debt that regular business operations are impaired and transformational goals are out of reach, says Scavo, whose work includes technical bankruptcy analysis.
As with financial bankruptcy, declaring technical bankruptcy might not be a bad thing if an organization uses it to turn itself around. Given a choice, however, we would rather not go bankrupt.
2. Settling the wrong debts for the wrong reasons
All technical debt is not created equal, particularly when looked at in the context of digital transformation. And as any smart CIO will tell you, a technology upgrade should not be confused for digital transformation.
To be clear, Scavo sees failing to upgrade enterprise systems for more than five years at a time – particularly if that’s true of multiple systems – as a warning sign for technical bankruptcy. Still, some applications for functions like manufacturing planning or accounting may continue to serve an organization’s purposes well into their “legacy” years, Scavo says.
Upgrading your ERP might well be a prerequisite for digital transformation plans if it delivers necessary functional or performance improvements. On the other hand, an aging ERP system might not be an important technical debt – or not the first one you should pay off. Is improving the back-end features it provides relevant to the customer-facing improvements the organization most needs to achieve? That might be better served by investing in a CRM system (unless the organization plans to implement both CRM and ERP from the same vendor).
The point is not to believe the ingredients for digital transformation start with the software. “You really have to start with the digital transformation vision,” Scavo says.
3. Impeding the need for speed
When deciding whether technical debt needs to be addressed, one clue is to look at whether it slows down important business processes. If your e-commerce systems can accept an order within seconds but it takes days to load that order information into logistics and fulfillment systems needed to fulfill the order, that is a technical debt that should not be tolerated in the digital transformation era.
Instant access to information via mobile and cloud systems is the expectation, both in our personal lives and in our increasingly consumerized digital workplace. When instant access is not achieved, instant frustration results. Organizations that consistently frustrate their customers, partners, and employees are likely to fall behind rivals.
Think technical debt is only for “old” companies? Think again:
