How Enterprises Solve Technical and Data Debt

The great thing about ServiceNow is that it’s a powerful and easy-to-use application platform. The not-so-great thing about ServiceNow is that it’s a powerful and easy to use application platform.

And as with any such platform that is easy to develop on, citizen developers build onto it. The more time passes, the more they add into the applications. This custom development is often delivered quickly, and without traditional development discipline, creating technical debt, which raises the risk for loss of work. At some point, an upgrade, a migration, or some other change will cause loss of that custom development.

Easy and powerful applications like ServiceNow lead to not only technical debt but also data debt. As a company increases their use of the platform, they amass more and more data. This data growth can strain storage capacities and cause performance impacts on the application. Data debt is a sign of past success, but it also leads to present and future bottlenecks.

During a recent webinar, attendees answered several questions about technical and data debt.

Technical and Data Debt is Pervasive

We asked attendees, “Are you experiencing either technical or data debt with ServiceNow?”

The vast majority (92%) said that they are experiencing both technical and data debt.

A company starting out with ServiceNow can plan for how they are going to grow their ServiceNow usage. They can project how they will accumulate data and technical changes in their system. 

To prevent technical and data debt, an organization can take several steps. They can establish an Integration Competency Center, enforce data-driven customizations, embrace automation, and enable frequent data backups and archiving.

But what can a company do if they have already accumulated too much technical and data debt? They can migrate their data to reset to the default applications. Such a step would remove customizations and may require the manipulation of data already collected. They can also move  data no longer needed off the platform, thereby reducing storage and increasing performance. They can also identify and reduce activities that make extensive use of SQL and web services.

Most Are Considering Migrating to Out-of-box

One approach to reducing technical debt is to abandon that custom-built application in favor of a packaged application from ServiceNow. In the early days of ServiceNow, the packaged applications were little more than templates, and so it was very common for organizations to use those as a starting point for their own custom built applications – apps which grew in functionality over the years. But as time went on, ServiceNow applications matured, and became much more functional to the point where, today they are extremely capable, full-featured products.  

We asked attendees whether they are considering migrating back to out-of-box applications.

Most (58%) said that they are considering it, a quarter (25%) said that they are not, and 17% said that they already use out-of-box apps.

Often, those who face the prospect of migrating end up deciding not to do so for various reasons. Some feel that doing so is just too difficult. Others made very mindful customizations that avoided the temptation to create short-term fixes, and so they do not have as much technical debt. Still others create custom development that is still not available in the out-of-box application.

On the other hand, migrating to out-of-box improves performance. It means working with a new, clean engine. The company can keep their historical and foundational data. But when they migrate to out-of-box, they can bring their data, putting it into a new box with better applications, better workflows, better engines. And they have reduced or eliminated technical debt. It’s like having a new car – even as the driver is still the same person. 

Going back to out-of-box also lets the company press reset on their strategy for building mindful customizations, without creating technical debt, so that upgrades can work properly.

An Almost Even Split on Hesitation to Upgrade ServiceNow

Upgrading ServiceNow can be scary. After all, how can you be sure that all your custom apps are going to keep functioning the way to expect them to? And what about those integrations that you have built over the years – will they still work, or did they make use of functionality that has been deprecated or changed in this latest release? The fear is real, and so we asked, “Have you ever been hesitant to move to a new version of ServiceNow?”

While a little more than half (54%) said they have not experienced that hesitancy, the remaining 46% have – with 31% declaring “occasionally” and 15% declaring “yes.”

Upgrading ServiceNow introduces new data-driven applications. It also lets a company remove historical customizations that are no longer needed, thereby reducing or eliminating technical debt.

But companies encounter the challenge of possibly losing data when they upgrade. They can meet this challenge by implementing a continuous backup strategy during the upgrade so that they can rollback successfully without losing work. Here’s how that works.

Before starting an upgrade, ServiceNow performs a full backup of the instance so that the upgrade can be reverted if needed. But what happens to records that are created between when this backup is initiated, and when the production instance is reverted?

Before commencing the upgrade, a company can set up a dynamic share to “publish” records to the message broker service – effectively using the service to store all the records as they were created. 

Doing so creates a live backup of every record that is created or updated since the upgrade commences. If the upgrade is unsuccessful, the company can revert to their ServiceNow instance backup, taken prior to the upgrade window. The company would then be able to “subscribe” to the records pushed to the message broker service and recover all the data their users created during the failed upgrade window.

Attachments – Replace with Links?

Attachments are necessary because they are the best way to describe unstructured data. They support business process. During a troubleshooting session for an incident, for example, you need log files and screenshots to be attached. 

But attachments also make up most of the data growth in the ServiceNow platform. They are difficult to search and are often duplicated. In our webinar, we asked, “Would you consider replacing attachments with links?”

The clear majority (73%) said that they would consider replacing attachments with links.

If a company already has many attachments in their database, they can offload those into cloud storage. They can use automation to create links in the records so that they are not saving those attachments with their data in a ServiceNow database. They effectively replace attachments with URLs.

Extending Custom Apps from the Task Table

When a company starts building apps, they extend the Task table because it is easy and financially beneficial. The Task table already contains all of the meaningful CMDB fields. But as the use of ServiceNow increases, the number of tables extended from Task grows dramatically. This growth happens especially when there is no Integration Competency Center or other relevant governance.

We asked our webinar attendees, “Are all of your custom apps extended from the Task table?”

One third (33%) said that most of them are extended from the Task table, 44% said some of them are, and 22% said that none of them are.

When custom apps are all extended from the task table, your queries will start to slow down. Every incident query (for example) will probably touch a bunch of extended task tables that are not that important – slowing your query and the overall performance of your instance..

To address this problem, a company can review the reasons for extending the Task table. They can de-normalize existing extended tables through migration back into their own ServiceNow instance.

Getting Some Help with Technical and Data Debt

These polling questions show that technical and data debt is pervasive – but that enterprises are open to taking meaningful steps to address these risky and performance-impacting problems.

For all of the above methods of addressing technical and data debt, Perspectium can assist. We can help you migrate data to another ServiceNow instance, upgrade ServiceNow with confidence in data integrity, and move your attachments to a database. If you’d like to learn more about backup and restore, check out DataSync Snapshot. Or if you’re ready to chat, let’s get in touch.

For more on eliminating technical and data debt, check out the Perspectium webinar Five Ways to Avoid Data Debt in ServiceNow … For Good!