Configuration vs. Customization? - wrong question!

#Developer , #Architecture , #Risk

Chuck Tomasi

4 minute read

20190506_104543.jpg

What did you just ask?

Twice this past week I’ve gotten asked to help define configuration vs. customization, so I thought it was time to write this article once and for all. Ask 10 people to define those terms and where the line is between them and you’ll get (at least) 10 different answers.

The short answer - you’re asking the wrong question. When I hear people ask the question about configuration vs. customization I hear several things:

  • Is this safe to change?
  • What is the risk to upgrades, performance, and user experience if I change it?
  • What is the technical debt I claim if I change this?

You can probably see where this is going - more about that in a minute.

Customization isn’t necessarily bad

There, I said/wrote it. Some people think of the word “customization” as “changing something out of the box”. Others think of it as “creating something unique.” Some try to stay away from it entirely based on bad experiences.

ServiceNow is an application development platform. Therefore, you cannot create a custom application without customization. Everything you create, from the tables to the forms to the process flow is all custom - at least within the scope of that application. So please, stop regarding the word “customization” like it’s tantamount to Voldemort’s name.

What are the right questions?

Instead of asking what is customization vs. configuration and getting lost in the quagmire of that argument, ask yourself this instead:

  1. What is the risk/impact of updating this thing?

  2. What is the value of the change?

  3. and, what is the technical debt (how complex is this change)?

In most cases, the value is going to depend on the specific change. Discuss this with whomever is asking for the change to explain WHY a change is needed in business terms. How many people will it impact? How often will they be using this feature/bug fix? How much time/money will it save? Measurable answers are the best!

For risk and debug, we’ll start with some simple pragmatic changes like creating a new report or email notification. I think we’d all agree, risk=low, debt=low. Upgrades are not impacted because this is net new and technical debt is low because even a new System Administrator can understand what’s been done and make updates.

Next scenario, updating the incident form. This is not a trick question, this is actually modifying several baseline (aka out-of-the-box) records and COULD impact your upgrade. But I think we’ll all agree that risk is minimal because ServiceNow doesn’t often make updates to form layouts as part of the standard upgrades. When they do, it’s meant to be a better starting point for new customers. Put a “low” in the technical debt column also.

Let’s do another, updating a change management flow. Starting to feel a little uncomfortable about your answers? That’s right, it carries a little more risk on upgrades; possibly performance, and user experience too. What if ServiceNow comes out with a newer, better flow? You might miss it. Risk is moderate. Because it’s Flow Designer, I’d still give this a “low” debt rating.

Alright, you’re catching on so let’s go for the far end of the spectrum - modifying a baseline script include. To me, this is where customers often give a hard “no”. That’s answer may not always be the right one for your situation. Risk=high, technical debt=high. Script includes are those “libraries” of server side code that we rely upon. Change one and who knows how many processes you’ll impact. You might also miss some critical functionality in the next upgrade - well thank goodness Upgrade Center will flag you on that. The technical debt is also high on this one because… well, scripting.

Yes you can, and should customize (you already are if you have ever modified an ITSM app form layout), and also recognize what the risks are, the value of the change, as well as the technical debt those customizations carry. That’s where YOU can add value when you go back to the business, department, or whomever is making requirements and let them know what they are asking for and the “costs” involved.

For reference, you can find a very useful PDF titled Business Smart Customization on the Customer Success Center to assist you with making customization decisions.

Comments