If you customise a COTS application through configuration what is it?

Gary Fehring's picture
Gary Fehring asked on December 18, 2014 - 7:53pm | Replies (1).

There are a lot of COTS products nowadays that can be customised through configuration and scripting which can significantly change the functionality, so are these still COTS or are they MOTS (Modified-of-the-shelf) or are they something else?

My specific question is about ServiceNow where you can modify the CMDB structure, change and add workflows; create scripts and even change the layout of screens etc. All of this is done through ServiceNow itself and you do not need to develop any 'external' code. Remedy is another tool where this happens.

So do these changes mean that it has been "modified"; is it just a configuration of a COTS, or is it something else?



1 Answer

Drew Benson's picture

I wouldn't get hung up on what you call it/them but make sure you know/understand/manage all the "bits" where they need to be known/understood/managed.

(one of the) first steps in Configuration Management is "Configuration Identification".

ie Defining what "bits" you have and (as important) how you are going to manage them.

This may be spread across a variety of tools etc and wil (almost certainly) have layers of "granularity"/context*

*granularity/context - A sinlge package/tool/COTS/widgit/System may be percieved in very different ways for example

a) Widget1 from a "Production" perspective might be a single entity

b) Widget1 from a "deployment" perspective might be made up of several "components" (all owned by different teams)

c) Widget1 from a "development" perspective  might be 100s or 1000s of individual files (or settings).

So as a simple model for your "COTS" or "MOTS" I normally visualise (at least) 4 contexts.

1) The Vanilla "COTS" - The actual out iof the box unchanged Stuff (at a unitary level ie one entity/CI)
2) The Site/Company specific "config" - The stuff that does what you want it to do (different from vanilla)**
3) The environment specific "config" - The stuff that supports your SDLC eg TEST Server/DBase/WebSite settings differ from the Prod**
4) The delivered "entity" - The thing that the end user knows (possibly the entity in Service Now)

** layers 2&3 may be may config files, pdfs, templates etc that are managed in your Version Control tool or possibly "just" a document that details various settings   

1 may ony be a component of 4 etc etc    




CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.