Evaluating Technical Debt on the ServiceNow Platform

ryan.patrick.pope

19 Jul, 2022

Evaluating Technical Debt on the ServiceNow Platform

When I first started working on the ServiceNow platform, we were told that ServiceNow was meant to be “infinitely customizable.” Back then, that was a huge selling point – customers were encouraged to configure and customize to achieve their organization’s objectives. Since then, ServiceNow, its partners, and entrenched support staff have changed their tune quite a bit. It seemingly never ends; participating in meetings with CIOs, VPs, and platform owners who admit that the implementation and management of the platform in their organization had run rampant with “customization”. As such, the platform became pinned in a corner of being nearly unusable and so difficult to maintain and upgrade that they can barely keep the lights on, let alone keep up with the demand for organizational growth on the platform.

The result: either a reimplementation, or re-assertion to forbid any “customization” moving forward without really understanding what’s meant by “customization”. This isn’t the first (nor will it be the last) write-up by one of those entrenched resources with a perspective and story to share. I thought I’d take an opportunity to add to some of the amazing writeups in the ecosystem (and provide some links to some of these resources at the end of this writeup.

Defining Technical Debt

First things first – what is customization in the context of ServiceNow and what other classifications for changes to the platform are there? I want to provide four definitions here to help set the stage:

  • Customization: Any added functionality via code that alters or overrides ServiceNow’s baseline installation
  • Configuration: Any added functionality that is pre-validated by ServiceNow, typically accomplished with a “no-code” solution, with a few exceptions (like net-new coded logic that utilizes ServiceNow coding best practice and pre-validated APIs). (There’s still a lot of contention on this definition as well, but we’re not going to argue beyond this definition)
  • Data: Any added data to existing tables within the ServiceNow platform
  • Customization Examples
  • Configuration Examples
  • Data Entry Examples

I wrote these definitions to help classify changes to a ServiceNow instance for an organization whose leader was explicit – this reimplementation is intended for a reset. The goal: obtain and maintain an “out-of-box” instance of ServiceNow. While ServiceNow is largely built to meet best practices standards of various frameworks (ITIL, PMBOK, etc.), there are many areas where ServiceNow has left flexibility for implementations unique to the organization, so obviously, completely out-of-the-box will never truly be feasible. However, the leader’s instruction struck fear in the heart of all stakeholders, leading them to fear anything that wasn’t “as built by ServiceNow.” I think the most important definition is the one that was excluded from the list above:

  • Technical Debt: The cost of ownership of ANY change made to the ServiceNow platform, whether it’s customization, configuration, or data.

Asking the Right Questions

It’s incredibly important, both in the context of ServiceNow and likely any application Platform as a Service (aPaaS). These platforms are meant to be extensible and flexible to fit the organization’s needs while still maintaining the integrity of the process frameworks that preside within.

For this organization, before I got to the point of explaining technical debt, every requirement was questioned: “is this customization?” and if it was, it was documented but passed over. That’s the wrong question since customization, configuration, and data all contribute to technical debt, the real metric that should be considered. The question should be: “how much technical debt will this incur?” followed by: “and how much value will be derived from that debt?”

Real World Examples

I’m sure skeptical folks might think, “how are data and configuration classified in the same light as customization?” Here are just a few examples of where data and configuration did a lot more damage than you might expect:

  • Client A doesn’t feel mature enough to utilize ServiceNow’s full potential in the Strategic Portfolio Management suite (SPM, formerly IT Business Management or ITBM) and wants to “start small” with Demand Management. They ask for some form configuration – merely fields being added to the form itself. Well, over 90 new fields later, the form was so large and cumbersome that it exceeded the single row limit for ServiceNow’s underlying database. A record with more than half of those fields populated could not be inserted.
  • Client B wants to leverage automation and discovery tools to ingest CMDB data without establishing limitations around which CI classes are to be collected. Rather than initiate a proper program to establish governance, boundaries, and a “crawl, walk, run” approach, they came out guns blazing. They inserted over 70 million rows of incoherent data, and overloaded the system, especially in any place with a reference field pointed to the CMDB, to the point of inoperability.

Conversely, here’s an example of customization that would have been looked down upon by those fearful of that word, yet in this case, provided tremendous value to the customer:

  • Client C wanted something that’s considered customization – an alteration of an out-of-the-box access control (ACL) – to prevent users from changing certain data elements on their user record, to ensure consistency across the whole organization, by centralizing user data management to a single source of truth. This ensured continuity of the user data being used in SN, as well as prevented unauthorized changes to that data that might then alter perceptions around the data quality within the platform.

Debt Vs. Value Evaluation

With Clients A and B, if the questions “how much technical debt will be incurred?” and “how much value will be derived?” had been raised at the offset of those engagements, I’m fairly certain different approaches to those scenarios would have played out. And conversely, if the question “is this customization?” was all it took to sideline the requirement, the organization as a whole would suffer from the inconsistencies and continue to diminish the value of a centralized “source of truth” for user data.

Going back to Client A – had they explored the SPM suite, extended their execution timeline, and ensured time for proper solutioning and training, they would have realized that extending their scope a little beyond Demand Management yields many tangential tables that house data elements they were seeking. Proper training for these additional tables rather than proceeding with the myopic “we want Demand Management but aren’t ready for anything else” strategy would have yielded the same value at a fraction of the technical debt cost.

Looking at Client B – had they devised an upfront strategy, isolated their discovery tools to observe the quantity and quality of data being collected, and established a data management program to manage a tiered approach to populating their CMDB, they likely would have come to realize that too much data is problematic. With that program, they surely would have come to an understanding of what the appropriate level of granularity should be for their use case to effectively see value derived from their CMDB.

All in all, the primary goal for any change made to the platform is value generation (and secondarily technical debt reduction). For any change being made, is the debt incurred going to yield a value that surpasses the resources required to manage and maintain the platform, its data, and its integrity? Is there a way to approach the change at hand to minimize the debt it would incur while maximizing the value sought after by the change itself?

More Resources For Handling “Customization”: