Go to portal
Audience: ServiceNow consultants; architects; platform owners; administrators
Reading time: 12 minutes
Introduction
ServiceNow instances which have been productive for a few years can easily accumulate unwanted baggage over time. This baggage can take many forms, from customisations which prevent us from leveraging the latest platform functionality, to Catalog Items buried in the depths of an overly complex Catalog category tree, to unneeded fields in forms which were added at one point and never removed even though they are no longer required.
It is useful to refer to all these accumulated inefficiencies as the Technical Debt which is present in our instances. Unfortunately, Technical Debt has the tendency to accumulate slowly, due to the urgency of making changes which have been not been thoroughly designed or analysed. Eventually, excessive Technical Debt can have very significant impact on an instance, from performance degradation to reducing the ROI of the whole platform by giving end users a poor and inefficient user experience, to making upgrades slow and painful as hundreds of skipped records need to be reviewed and accepted just because no one remembers why an out of the box element was modified in the first place.
Once we’re convinced that we need to address or at least control the Technical Debt present in our instances, we have to answer the following questions:
– How do I identify existing Technical Debt?
– What strategy should I use to bring it under control?
In this blog post, we will cover how to identify areas of improvement of our ServiceNow instances and a few tips about how to action it.
Identifying Technical Debt:
In general, Technical Debt in ServiceNow can be grouped in the following categories:
Unneeded customisations
These is the main category when we think about Technical Debt in ServiceNow. The advantages of staying as close to Out of Box as possible are sufficiently preached by ServiceNow to have to be repeated here. You can find a comprehensive list of the Out of the Box modifications in your instance by looking at the accepted skipped records from your last upgrade. However, this will not tell you whether you have modified any additional elements since that upgrade, and if you have, how many new skipped records you will have on your next upgrade. For that, you would need the information provided by the Quality Clouds Upgradeability dashboard.
Poor quality code
Code which has been added to the instance for necessary customisations, but does not follow ServiceNow or JavaScript best practices also contributes significantly to Technical Debt. Doing regular code inspections is a good practice to keep the code under control. With Quality Clouds you can also define your very own coding standards checks.
Unused custom fields and data columns and tables
You have a mature instance of ServiceNow that has accumulated technical debt including unused custom fields that are hampering success. Analyze the fields of any table, what percentage of records have that field populated, and the overall health of your data. Ask us for the Quality Clouds Field Trip application.
Service Catalog
This is an area where clutter, and therefore Technical Debt can really add up over time. The temptation to duplicate code in Catalog Client Scripts, variables across Items, and to create overly complex category hierarchies is great. Surprisingly, we have found a few orphan Catalog Items (items not associated with any catalog) in almost all the instances we scan. You can learn more here.
Reports
Reporting is an area where it is quite common to see reports which have outlived their usefulness remain on the instance simply because no one has bothered to remove them.
UI Scripts
UI scripts are often used to upload third party open source libraries for use in custom Portal Widgets. This in itself may constitute Technical Debt if developers are free to use any framework of their choosing without complying with the organisation’s policies about use of Open Source Software. Even if these policies are used, it is quite common for older versions of these libraries to hang around long after they’ve been replaced by newer versions. You can use the Quality Clouds code monitor dashboard to list all the UI script elements and check the ones that can hold those libraries.
Strategies
Once you have identified the main sources of your technical debt, you can either decide for a full re-implementation of your ServiceNow instance or for an ongoing and regular reduction of the technical debt. In the first case, you should pause the delivery all of the new releases and focus on the new implementation, leveraging the ServiceNow out-of-the-box functionality.
If you can chose for a gradual reduction of the technical debt and keep delivering functionality, a good practice is always to reserve a percentage of each sprint for remediation work, where prioritization is key.
In both cases, regular automated inspections of the code and instances are a must. Start your Quality Clouds trial now and understand your technical debt sources.
Happy Decluttering Season!
