Configuration vs Customization Guidelines

[snyderdb]

Hello -

I have been searching for guidelines and/or definitions for what constitutes a configuration change vs a customization in SvcNow.

I searched the SvcNow web site and found the "Upgrades Best Practices" wiki, I also found a blog titled "CONFIGURATION OR CUSTOMIZATION" on the SERVICENOWELITE.com technical blog and blog titled "Customization guidelines".

Does anyone have any specific definitions/guidelines of configuration vs customization in SvcNow.

I would like to understand the differences between configuration changes vs customization from a technical perspective but have not found anything beyond the resources I mention above.

If anyone has any links to documents that provide information on this topic, or thoughts/guidance that would be tremendously appreciated!

[Paul Ciarfella]

This can be a philosophical discussion!   Maybe a great BOF or drinkup session at K15.  

To me, these terms can be intermixed, intermingled and cause either happiness or consternation with management and program managers:

configuration

customization

development

I suggest the following, based on having dealt with this for over three years:

1. Configuration is applying settings, such as system property values, or adding configuration data, like LDAP servers to enable a function or capability.   Configuration is also modifying forms to add new fields, hide fields or restyle the form layout.   In short, to me, configuration is a non-functional change, meaning that it does not change the out-of-box functionality.

2. Anything that changes the out-of-box functionality is customization.   Customization is where you take an existing application and make it work differently.   For example, taking the Change Request and creating your own change approval workflow.   Or adding new state values to the State field.   Customization may also increase maintenance down the line, as one should always regression test customizations on ServiceNow release upgrades.

3. Development supports or is a synonym for customization   (and 'development' tends to be a very bad word since management takes that as a) lots of effort b) complexity c) specialized skills and d) time and money beyond what was sold to them by SN as configuration.

In my experience, one starts with configuration ... hoping that the out-of-box functionality supports your business needs.   Then, you stroll into the customization realm when you need to change the application to reflect your business processes.

Just some quick observations ... there's more to think about, too, like not changing out-of-box script includes or business rules ....

Paul C

[seanpmcclean]

Totally agree with Paul Ciarfella 's comments about a "tasts great!", "less filling!" kind of discussion here.   That said,   I believe that we have been working to align these two terms to our licensing model (June 2014?).   I believe there are some internal resources about this from Know Your Expert | Chuck Tomasi and the enablement team about this, but not sure if this is easily accessible to everyone - so I don't have a direct source to point you to unfortunately, though if I can I'll follow up with one.

If I understand correctly, Configuration is the process of modifying any included ServiceNow Licensed Application.     So, even more complicated elements, such as field elements, workflows, client, server-side scripting, script includes, etc would be considered Configuration, as long as it's supporting an existing ServiceNow application that is being paid for, it would be considered configuration.  

Though this may appear to contradict what Paul C was saying, if we work with the idea that:

- The system was built to be an easily configured and administered platform

- Even the more complex elements (like script includes or workflows) are very supportable and sustainable

this would still fit into what Paul said in his first point.  

Customizations, in contrast, involve anything that involves the creation of a new Application or Process, or a new Unit of Work (i.e. extension of Task).

This would include things like a new application to track loaner equipment, or a new Application to manage conferences and marketing events.

In all honesty, I tend to be more comfortable thinking along the same lines Paul C described, and I've been doing this long enough (with both ServiceNow and other tools) that I tend to look at things and just intuitively "know" and think like Paul described, but this new model makes sense from a simplicity perspective.

I hope that this helps?

If I can find a publicly accessible link I'll share.