CMS Blog

The Configuration Control process guarantees that the content of your Configuration Management System (CMS) / Configuration Management Database (CMDB) remains accurate.

It is always triggered by another process. Usually by the change management process or the request fulfillment process.  As in accounting, you don’t enter accounting records just for fun, you always have a business case such as something has been sold, another thing has been bought, year end closing…

The main result out of the Configuration Control process are

a)  a correct, timely, traceable content of your configuration management system (CMS) (such as updated CIs, updated Relations)

b) a configuration baseline (if you decided to store one)

c) for new CIs (and also new Relations if you treat them alike) an Owner is assigned

There is no process flow example in the ITIL Manuals for this CoM sub-process (unlike for change management), but in my experience the following small workflow expresses the essentials:

1. Configuration Management gets the request to update CMS  (CI / CI Relation / Attribute)
2. Analyse the Configuration Change Request
   1. If CI Type (CI-Class) not yet in the CMS
      –>  trigger “Configuration Identification” and end the process
   2. If Request incomplete return to requester for completion
   3. If Owners not known Identify Owners (and trigger asynchronous confirmation)
   4. If the request is forbidden or not acceptable, end the process
3. Mark Configuration as baseline configuration (if requested or if conditions qualify)
4. Update CMS  (DSL, DHS)
5. Inform stakeholders (of the updates(s) )

One more thing about the triggering of the Configuration Control process. The question is, WHEN is the best time to do it. Is it when the Change (RfC) or Service Request has been approved, or when it has been successfully completed?   I can’t give a standardized answer to this, it depends on the type of CI-Class (logical or physical) but also on what discrepancies you want to detect and also if and how you intend to rollback CMS-changes in case of unsuccessful deployment of a change.

Here you see an example of a configuration control process flow diagram.

Tags: Configuration Control, Process

This entry was posted on Monday, April 26th, 2010 at 21:35 and is filed under CMDB and CMS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.