Have you ever been tempted to start fresh with your ServiceNow implementation?
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.
Is it so bad anyway?
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 in software development is created mainly by the following:
- 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
You may ask: "What do I do with these?"
Okay. Let's consider a scenario.
Technical debt - based on gut feeling?
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.
But is there something more objective?
Are there tools or approaches that can be used to lead our work?
- 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 provided by ServiceNow PS team with a list of best practices not followed in a particular instance.
- ServiceNow Community - Always there to help! https://community.servicenow.com/
- Use external tools that analize ServiceNow code and help in the governance of our development. Free scan updatesets here
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?
The maintenance road is long
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. Regular health checks can help you stay on top of the tech debt.
Keep on moving and improving
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.
Got ideas?
From your experience, what other technical debt factors could be considered to streamline your ServiceNow instance?
