The MOF Operations Guide for Configuration Management implies that the tools used to implement Configuration Management can be used to drive the design of the function and CMDB. It is clear that the implementations of solutions such as Service Desk from HP, Red Box or Visionael can lead to quick-wins but problems are often incurred with the determination of the correct granularity of the CMDB.

Some specific Network centric based Operations Organizations sometimes integrate the concept of system management tools into the CMDB. Experience with integration work required to do this in complete IT organization often shows that the implementation can become too complex and only the most automated tools can be used to carry out such work.

Since such automated tools often populate areas of the CMDB extremely well and others poorly, a mismatch between the processes and data on which these processes operate can occur. It might be possible to have a CMDB which contains the entire network configuration using some specific tools and define every change in these items as a change management task but in reality these tasks are better seen as Operational tasks carried out using System management tools. In fact the view of the CMDB as a Service Management tool creates a more consistent view of the operations/change management interface. A more consistent view is to leave referential links to lower level system configuration information not subject to change management.

To this end experience shows that the implementation of these tools requires the scaling back from the implied "complete" granularity of the CMDB and we present here some useful criteria to creating a "selective" CMDB with excellent ROI.

There are diverse drivers to the CIs contained in the CMDB consistent with the fact that the service is accessed by almost all of the SMFs.

Change Management and Version Management both require interaction with the CMDB in order to carry out tasks in the change processes. A good way not to fall into the trap of building a complete CMDB for these functions is to supplement the modification of configuration information with the change log.

Business drivers compel the organization to make CIs available to Service Level Management, Contingency Planning, Financial Management, Capacity Management, and Availability Management with special relevance to business contracts. CIs which are related to SLAs, OLAs and UCs, are, therefore, often selected.

The Service Desk and Incident Management functions will be the drivers for recording information in the CMDB so that incidents can be quickly located and identified. Problem Management will want a large database of incidents to data mine a large amount of background material for reactive and proactive problem discovery and resolution. This can quickly lead to very high granularity in the CMDB.

Lastly are the requirements of the Operations SMFs. Operations by their nature are more related to the system management tools and with configurational information not included in the CMDB. Special care needs to be taken to the overlap which often leads to confusion when considering the Capacity Database which is used to plan future needs.

Considering these needs for the inclusion of CIs, a step by step guide for selecting which CI's to choose for your CMDB might look something like:

-Choose information that relates multiple CI's.

-Choose information that is not recoverable from system management tools in a simple way if the CI is partially or not at all operable.

-Choose information which includes relationships of CIs of disparate types. ( ie. UNIX to a NT via SOAP) 

-Include important SLAs, UCs and OLAs

-Choose the main items in the path from common problems and incidents to End user services.

-Other items which are deemed crucial from a holistic view of Operations Experts with a wealth of experience from the organization.

In summary, a clear understanding of the drivers from the Management Functions CMDB utilization, and a well defined interface between System Management and Service Management providing a boundary between your Operations and Change Management activities is critical to find the best ROI for a your particular CMDB.