The Rising Cost of Technical Debt in IT Service Management

By: Ron Browning, CEO and Co-Founder Dyna Software

Over the past decade IT service management platforms have emerged as mission-critical tools that power service delivery for IT organizations and beyond. From HR workflows to facilities, security operations center processes and customer-related workflows, organizations are turning to various solutions to simplify business operations. However, when organizations move quickly to meet business needs without proper governance and architectural controls, they can introduce technical debt that makes it more difficult and expensive to innovate on their platform, whether it be ServiceNow, Freshworks, or Ivanti Neurons for ITSM.

There are several factors that contribute to technical debt, and perhaps one of the most important things to understand is that debt can be introduced long before the platform even goes live. Many organizations start an implementation with several years worth of assumptions about workflows and system design. In order to accelerate time to value, some teams attempt to recreate processes exactly as they are currently designed in existing systems. In some cases, this might be appropriate. However, in many cases, it introduces complexity that does not need to exist. Rather than taking the time to critically assess existing workflows and processes, organizations often reimplement old solutions as custom code.

The reason teams take this approach are less about technical challenges and more about organizational pressure. Nobody wants to slow down teams that are being measured on their ability to deliver business value. Governance decisions about what should be migrated versus redesigned or even turned off can be difficult to make, and in many cases are delayed. When decisions about platform configuration and development are not governed, teams often continue working without a clear understanding of what should be introduced into the environment.

Technical debt can also be introduced after a platform goes into production. Although there may be many technical solutions to achieve a goal, not all of those solutions are sustainable over time. The biggest driver tends to be those that elect to build custom applications or scripts when the same functionality could have been achieved through configuration.

---

How Technical Debt Builds Over Time

Developing custom code may feel like a good idea at first as it gets the organization where they need to go. But once it is in play, there will need to be continued investments to ensure operability. For example, every custom script, application, or plugin developed in ServiceNow needs to be maintained. That code should be analyzed, tested, and validated every time the platform is upgraded. As more and more custom code is introduced, it can significantly impact how long upgrades take as well as the platform’s ability to adopt new capabilities. Therefore, if an IT service management platform can be configured rather than built, it probably should be.

Dependency is another factor that complicates technical debt. Numerous modules throughout the application share common dependencies. Features that are added or modified in IT service management can have unintended consequences for HR service delivery or knowledge management, and vice versa. When development is done in siloes without a full understanding of these relationships, quick solutions to immediate problems can ultimately compound technical debt.

This eventually becomes problematic because technical debt tends to proliferate over time. It’s rarely introduced in large chunks that you can see coming. For months, maybe even years, everything works as expected, but at some point, IT teams begin to notice that upgrades are taking longer or new features introduced take more time to evaluate. Part of this challenge is that as more custom code is introduced it takes longer for the platform to be upgraded, but it can also slow the adoption of new capabilities because the organization needs to understand how those capabilities will interact with hundreds, if not thousands of customizations that are already in place.

Eventually, the effort required to maintain the environment will grow exponentially. More time is being spent debugging problems or ensuring that custom code still works with each new release than actually delivering new value to users. In extreme cases, organizations are forced to consider rebuilding or re-platforming their environment because the technical debt has created too much complexity to continue development. This is why technical debt is often compared to financial debt. If you don’t pay a little now, it’s only going to compound into a larger problem later.

---

Artificial Intelligence Meets Technical Debt

Artificial intelligence is the latest development to bring technical debt into the spotlight. AI has the potential to introduce technical debt at scale, but it can also help reduce technical debt if applied correctly. On one hand, AI can drastically increase development speed and simplify many of the tasks associated with configuring an enterprise platform. Developers will be able to work faster than ever before, and many of the tasks that currently take hours can be automated with AI. However, if organizations start quickly throwing AI generated code or configurations onto the platform without proper governance or architectural controls, they may unintentionally introduce complex dependencies or even security issues.

There are guardrails that must be put in place to prevent AI from negatively impacting the platform. Any type of automated development must be validated to ensure it meets platform best practices, and AI should be trained on those standards before getting started. Without these controls AI has the potential to create more problems than it can fix.

As more teams are given the opportunity to develop their own workflows and applications, governance and platform visibility become increasingly important. Organizations must establish architectural standards for development and configure controls to provide appropriate oversight across the environment. Without a clearly defined governance model teams may continue to introduce quick hacks that solve short-term problems but create long-term pain. Focusing on the fundamentals will play an important role in helping organizations avoid technical debt. Software code reviews, architectural governance, and development processes along with following best practices are things that have helped organizations avoid this problem for decades. 

---

ITSM offers organizations a chance to move fast and deliver business value, but as with anything in life, moving too fast can overburden operations and impact performance. Organizations that overcome this and find success realize that technical debt isn’t something you avoid in the short-term. It’s something you continuously manage over time by focusing on governance, system architecture, and adherence to best practices.