Go to portal
Have you ever been tempted to start fresh with your ServiceNow implementation?”
Reading time: 8 min
Audience: ServiceNow platform owners, software engineers, CTO, CIO
After hundreds of unstructured requirements and mounting pressure to get things done, our instances often lack proper architecture and suffer performance problems. We even consider throwing all the work away and starting with a clean slate.
If only things were so straightforward! Current users relying on implemented functionalities means you can not simply get rid of things overnight. Maintaining two separate instances while you migrate the code is not an easy task either. And hey, what about the data? Data also needs migrating from the old system to the new. There are so many factors that can not be underestimated when considering a re-launch of your ServiceNow instance.
[qodef_blockquote text=”Is it so bad anyway?” title_tag=”h3″ width=”100%”]
How do we even know if our ServiceNow instance is healthy or not worth maintaining anymore? Using the technical debt concept as a base for assessment, we can try to come out with an objective number which drives our analysis as well as helps convince our boss about the right decision.
Technical debt is created mainly by the following:
[qodef_list_ordered]
- Lack of proper architecture
- Duplicated code
- Lengthy scripts
- Code with no comments
- Unused code
- Unused fields or forms
- Lack of use of scoped applications
- Poor usage of naming conventions in elements and variables
- Out-of-the-box elements changed
- Not adhering to coding best practices
[/qodef_list_ordered]
You may ask: “What do I do with these?”
Okay. Let’s consider a scenario.
[qodef_blockquote text=”Technical debt – based on gut feeling?” title_tag=”h3″ width=”100%”]
Listing our “critical” applications in a spreadsheet (first column in the example below) and the technical debt factors (header row), we can assign a number to each cell where:
- 1 means we are very confident that a particular application is free of the issue
and
- 10 means we terrified to even look into the code
All right, with the assessment finished, the TOTAL column gives us an indication of which application needs refactoring most urgently (Catalog team?).
But more interestingly, we’ve got an average score of 4 for our instance! (with 1 being awesome, 10 being not so great, to put it mildly). This tells us that we are closer to refactoring some of our configuration elements than we thought.
[qodef_blockquote text=”But is there something more objective?” title_tag=”h3″ width=”100%”]
Are there tools or approaches that can be used to lead our work?
[qodef_unordered_list style=”circle” animate=”no” font_weight=””]
- Training? Definitely a Yes, it’s always good to invest in our staff and send them to the latest ServiceNow official training. Investing in our people brings their success, and their success is our success. But is there time just now?
- Get external help – There are many excellent services companies out there. Some of them really nice niche boutiques that specialize in apps like HR and migrating into a scoped application.
- Run some queries yourself – If you think that a field in a form is not being used, just look into production for the table and the field and list its content. If you find it empty 95% of the time, it looks like that’s a clear sign that the field is not used.
- Development team tool – It is worth looking into the ServiceNow tools to enable Team Development and streamline your development process.
- ServiceNow ACE report – On-query PDF report with best practices not followed
- ServiceNow Community – Always there to help! https://community.servicenow.com/
- Use external tools like QC for ServiceNow. Yeah, our baby 🙂 QC for ServiceNow will only take minutes for you to populate the table above with objective data straight from your code. It will help you to find duplicated code, out-of-the-box (OOTB) elements changed, bad use of naming conventions, adherence to best practices and many many more
- Free UPDASET scan – Try it here
[/qodef_unordered_list]
With this, we can start assigning actions to our team and the best way to organise this work is, naturally, using the ServiceNow Agile module.
So now that we have a plan to reduce our technical debt and we are already taking action, what’s next?
[qodef_blockquote text=”The maintenance road is long” title_tag=”h3″ width=”100%”]
Once we’ve brought our instance to the level of technical debt we accept, it is time to keep it clean and healthy by monitoring the ongoing work.
The SQALE method (from www.sqale.org) below depicts what we might accept as residual technical debt and what needs to be remediated over time to ensure our ServiceNow instance is on the good track. QC for ServiceNow can help you stay on top of this by doing regular checks on the instance and reacting according to the findings. We will cover the maintenance work on a next post.
[qodef_blockquote text=”Keep on moving and improving” title_tag=”h3″ width=”100%”]
Now that we’re in control and our technical debt is kept in check, we can only strive to make it smaller and smaller by incorporating more technical debt factors into our definition.
[qodef_blockquote text=”Got ideas?” title_tag=”h3″ width=”100%”]
From your experience, what other technical debt factors could be considered to streamline your ServiceNow instance? Share your thoughts in the comment section and let’s discuss.
Set up a demo today to learn more.
