Digital transformation requires paying off that technical debt, studies show

Back in the Y2K days of yore, some IT shops got around the impending millennial date expansion challenge with some interesting workarounds -- such as resetting their system clocks back to 1972 (which aligned with the Year 2000 calendar-wise), and installing bridge utilities to convert dates back and forth by 28 years. This is an example of incurring "technical debt," in which quick fixes, usually under fire-fighting conditions, solve a problem at hand, but will mean major, expensive overhauls at some future date -- a way of borrowing time or resources, but often at a very high interest rate.

There are countless examples of expedient, quicker fixes installed in today's enterprise systems, necessitated by tight budgets, tight timeframes, and uptight department heads. The patchworks add up and take their toll, bogging things down as organizations seek to evolve into fast-moving, real-time digital powerhouses. In a recent survey from Accenture, 70% of 1,000 C-level executives say technical debt is significantly inhibiting their ability to innovate from a technology standpoint, while 72% blame technical debt for difficulties in assimilating new technologies.

Similarly, a survey by IDG and Insight Enterprises finds 64% of executives cite legacy infrastructure and processes as a barrier to IT and digital transformation, along with data security, technology silos, budget and competing priorities. As a result, 51% at enterprises undertaking IT transformation initiatives have "stalled or abandoned select projects" while grappling with IT modernization and process issues.

Unfortunately, it takes time to unravel technical debt, as explained by Adam Burden, global lead at Accenture and his team of co-authors in a recent analysis of their survey in MIT Sloan Management Review. "Indecision abounds," they write. "Some 67% of executives we surveyed said they would like to replace all of their core legacy systems. But 70% would like to keep their existing core systems as long as possible -- and 50% wish they could have the best of both worlds. In other words, what leaders really want most is to enjoy all the benefits of new information technologies, such as being able to adapt quickly to new situations, while keeping their legacy systems humming."

Burden and his colleagues do provide a strategy to keep moving while unraveling technical debt, which they call "decoupling." Here is some of what they have to say about that, and you can be forgiven if it sounds a lot like the goals of microservice/service oriented architecture many have been working to accomplish over the past decade and a half:

Decouple data from legacy systems. Move data to data lakes, which store data in its raw format, to be transformed as needed for current and future applications.

Decouple applications from the legacy infrastructure. Abstraction is the key. "Running applications on your legacy infrastructure can be inefficient because bundled applications incur high computing costs -- it's like having to turn on all the lights in your house when you really only need one. Decoupling applications from your legacy infrastructure gives you the flexibility to scale offerings and accommodate different application workloads."

Decouple the business process systems from one another. The authors take a page from the service/microservice oriented architecture playbook -- break down the monoliths and keep essential systems and services in separate, loosely coupled domains. "The days of building software as one large, unified system -- where everything runs on one machine -- are over."

Decouple IT talent and budgets from traditional silos. "For instance, a team that includes both customer-facing experts and data scientists can improve e-commerce sales by making more sophisticated use of customer data." In addition, "instead of focusing on individual projects, budgets should go toward continuous maintenance, upgrades, and improvements of IT systems -- but with the caveat that business value be the driver of spending. This not only makes spending more predictable, it also prevents new technical debt from accumulating."

Again, there isn't necessarily anything new or revolutionary about the above approaches. But they still resonate, and are needed more than ever, at a time in which organizations base their success -- their very existence -- on their ability to capitalize on information technology. We know what it takes to modernize or move away from debt-laden systems, it just takes organizational will -- or pressure from outside disruptors.