For CIOs, taking operational shortcuts can often improve the bottom line but rack up unseen long-term costs. Jamming a quick fix into an older platform might be expedient, but if it’s not integrated well into broader IT infrastructure, those inefficiencies will eventually eclipse short-term cost savings—sometimes by a huge margin.
This problem is known as technical debt, and it’s pervasive. A full 70% of C-suite executives say technical debt is hindering their ability to innovate, according to Accenture. In the race to keep up with competitors amid industry disruption, however, a certain level of technical debt can be unavoidable.
Workflow recently sat down with Myles Suer, facilitator of the popular #CIOChat on Twitter and enterprise marketing chief at cloud integration vendor Dell Boomi, for his insights on how IT leaders should deal with the issue.
Why is technical debt a big concern for CIOs?
One focus of CIOs today is driving business agility. In the old days, CIOs worried about having a seat at the table, or making sure their plan was aligned with the business. But technology is how innovation is delivered these days, so the CIO has to be more of a leader. Leadership includes cleaning up things.
What things need the most cleanup?
A lot of CIOs talk about legacy systems and processes like they’re a Jenga tower ready to fall. If I’m part of an older legacy organization, my applications and processes have been customized over time and aren’t connected very well.
If we’re going to create truly digital businesses, the opportunity starts by getting rid of things that prevent you from succeeding, such as patchwork integrations on older systems.
Isn’t some technical debt not just inevitable but desirable when you’re launching large-scale tech initiatives?
You want to cut people loose to innovate, but you don’t want to build up additional technical debt in the process. CIOs worry that if they start creating all these low-code applications that aren’t integrated properly into legacy systems, they’re going to have security issues and other problems down the road. It’s smarter to design so that you don’t create more technical debt in the process.
Disruptors really get this. At an event I ran last year, I got people from disruptive companies to come and talk about how they’re running their IT organizations. These guys said, “We know that if we let technical debt build up, we’ll become just like the people that we’re taking business away from.”
So they’ve created systems to track every time they slam something in that’s not perfect, that doesn’t talk very well to all the stuff around it, and they immediately put in an action plan to fix it.
How can CIOs gauge whether they’re in danger of having too much tech debt?
One of the critical things to do quickly is an audit. Companies often have multiple versions of software and systems. An enterprise architect needs to assess everything and say, “We’re not going to have 100 different versions of servers.” The more variety you have, the less efficient the organization becomes. The solution to that is standardized technology.
Next, you need to start optimizing your core. How does everything connect? Who owns what? How do I get my processes to work more effectively together? The goal is business modularity. That means enabling the enterprise to pull things apart and reassemble them in different ways. You want to make it easy for teams to build more light, low-code apps and fewer monolithic, heavy ones.
How often do you need to do these kinds of audits?
You need to track it all the time. There are companies out there who have no clue about how ugly it is. It’s important that you catalog it, make a plan for attacking it, and explicitly go after it. If you’re mired in technical debt, you’re in trouble.