Increasing Your ServiceNow ROI

IDC projects that 750 million new applications will be built over the next three years. ServiceNow CEO Bill McDermott believes that the low-code capabilities of ServiceNow will play an important role in meeting this demand.  Being able to quickly develop and deliver apps provides value to the business and reduces the total cost of ownership for ServiceNow.  But what if I told you this value comes with a hidden increase in productivity and licensing costs?  In this blog, we will reveal these hidden costs and provide solutions to help you maximize your ServiceNow ROI.

‍

Changes Made in Isolation May Affect your ServiceNow ROI

In the article linked above, two women faced off in a coding challenge to demonstrate how easy it is to build an application on ServiceNow.  That demonstration was powerful, but it also exemplifies a hidden challenge that has to be addressed to maximize your ServiceNow ROI results.  The ease and speed with which you can develop an app on ServiceNow come at the expense of having pre-built functionality and services pre-baked into the platform.  For a single developer, this isn’t a problem but a productivity multiplier.

However, when multiple developers code in parallel and in a non-linear fashion, this interdependency is a concern that must be accounted for.  A code change in one instance may impact the development efforts in another instance because of a shared dependency on the same platform update.  In file-based apps, a git merge can straightforwardly resolve these issues.  In platform-built apps, a git merge, external to ServiceNow, doesn’t necessarily correct the problem.

‍

Misalignment Mayhem May Also Affect ServiceNow ROI

This doesn’t necessarily correct the problem because it assumes all changes will move forward and be reconciled later in a consolidated instance such as a QA or test instance. Later means developers continue to code against a dirty or disconnected instance, unaware of the changes being made in isolation elsewhere in their ServiceNow installation. These isolated changes result in significant merge conflicts that require developers to spend time collaborating to resolve as these deltas either directly or indirectly impact their code. Resolution often requires reworking code that was considered complete. Further complicating these rework reconciliation efforts are the changes made directly in QA or production. These changes bypass the prescribed DevOps progression and lead to the drastic practice of cloning higher-level instances.

Cloning isn’t a bad thing. It is a fully supported capability and is even encouraged by ServiceNow. Cloning gives developers the production data elements they need to write code with the highest chance of working in production. It also enables organizations to meet a ServiceNow best practice of keeping your production-minus-one instance as closely mirrored to production as possible. The challenge is that cloning only solves the underlying problem of instance drift temporarily, and since cloning is an overwrite/reset exercise, it can cause rework and work delays. What if there was a way to reduce the need for cloning, reduce rework, shorten the lead-time to code and almost eliminate instance drift?

‍

On Your Path to Maximize ServiceNow ROI: Back-Sync To The Future

One way to address this problem is with automation mechanics pervasive throughout ServiceNow and triggered upon any changes made to any instance you identify. These automation mechanics will back-sync changes ensuring that every instance is the “standard” instance and reducing the need to clone “gold standard” instances. Back-syncing virtually eliminates all of the manual effort mentioned above which increases developers’ capacity to code more. This increased capacity will drive top line ServiceNow ROI by tripling the number of deployed deliverables each year.

Lastly, back-syncing efficiently and rapidly communicates information back to developers on other instances who need this feedback to produce higher quality code. The information I am speaking of is non-communicated, living actionable data continuously synchronized from your “gold standard” as soon as changes are posted to it.