Customization, Advanced Configuration, and Technical Debt are just some of terms used to describe modifications within a ServiceNow environment, each with varying definitions. Despite the differing terminology, it is rare to encounter a truly out-of-the-box ServiceNow environment devoid of any of these elements. Personally, I prefer to avoid the term technical debt and instead use customization or advanced configuration, depending on how the changes have been implemented.
Regardless of the terminology or definitions, this post focuses on why it is essential to track these modifications in a register and provides a recommendation on how to do so effectively, ensuring that the process adds value rather than simply ticking off a task.
For the sake of simplicity, I will use the term customization throughout this post. Many articles have already explored which terms to use and how to define them, so I will not revisit that discussion here.
Why should you register your customisations?
Customizations are purposeful development activities carried out within your ServiceNow Environment to achieve specific business outcomes and provide value. To maintain their efficacy and continue delivering the intended results, these customizations must be managed throughout their lifecycle, which includes regular reviews typically conducted during platform upgrades.
When reviewing a customization, the following types of questions should be asked:
- Does it still deliver the intended outcome and value?
- Has ServiceNow introduced this capability as an Out-of-the-Box feature?
- Does the customization require updates to:
- Align with changes in the supported business processes?
- Utilize new ServiceNow features?
- Eliminate the use of deprecated ServiceNow functionalities?
Maintaining a record of the customizations in your system facilitates an effective lifecycle review process.
Where should you register your customisations?
So now we understand why having a register of your ServiceNow customisations is valuable, the question is Where do they get registered?
There are several options that I have either seen or heard of being used to answer this question:
- Using a spreadsheet or a SharePoint list
- Using the Demand record in SPM that tracked the customisations initial implementation
- Using the User Story or Epic the customisation was developed against
Now while these options do allow for the registration of your customisations, there are some immediate downsides:
- Use of an external system
- Relying on products that the customer may not be entitled to or be using
- No easy way to distinguish between customisation records and other records
So, what is my preferred method of registering ServiceNow customisation records, using a custom Configuration Item (CI) Class.
Establishing a new CI Class to serve as the register for your ServiceNow Customisations provides an easy and effective way to ensure you get the intend value out of your Customisation Register and are not just ticking a box in a process.
A ServiceNow Customisation Register built in the CMDB provides a range of benefits that are not available through other options:
- The CMDB is available to all ServiceNow customers
- There are no additional licensing costs to add a new CI class
- The CI Class can be quickly configured to capture the attributes needed to track and manage the record of customisation
- The Customisation CI can be linked to Knowledge, providing reference to design or support information
- A Customisation CI can be referenced in process records. For example:
- On the Change used to implement the customisation
- On an Incident or Problem record if an issue arises
- On the Change used to finally retire the customisation at the end of its life
- The Customisation CI can be related to the rest of the CMDB and CSDM model, showing how the customisation is implemented, leveraged, supported, and consumed.
In my experience the establishment of the ServiceNow Customisation Register as a CI Class provides a simple, effective and easy to manage way to track your customisations throughout their lifecycle.
These images show some of the Customisation and Configuration Register that I have built and implemented.
