

When implementing a configuration management system you usually start with the following steps:
You don’t have to, but there are some reasons you should consider it:
Reason Nr. 1: because the ITIL Manuals state: What is an Incident? ”An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet affected Service is also an Incident. ” (more…)
This process controls the integration of new CI-Classes / CI-Relationship-Classes into the Configuration Management System (CMS). Its executed the first time after (or parallel to) the Configuration Management and Planning process and everytime you extend your CMS.
The main result of this process is that your CMS System is able to handle the new CI-Class / CI-Relationship in scope of this execution cycle (more…)
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… (more…)
No. I don’t think so.
But the CMS should be the one and only place where the important parts of all this metadata information is consolidated, connected (through relations) and provided to all other ITSM Processes. In addition, I am convinced that the CMS is also the most appropriate place to apply configuration control. (more…)
Federated Configuration Management Database
A CMDB enables organizations to provide their IT objects, relations and attributes in an up-to-date and accurate state. Since organizations often maintain several CMDBs with different contents, there is a need to have an integrated perspective to all the data (now its no longer one single CMDB but a CMS (Configuration Management System), a new term introduced by ITIL V3). That’s where the federated approach comes into place. Federation can either be fulfilled by physically replicate data from one CMDB (master) to another (slave), or by just providing an integrated view to the data from several CMDBs in a visualization layer. A CMDBf concept has to consist of the following considerations:
Define the master source for every type of object. One source has to be the only master whereas other sources (slaves) can consume the objects from the master.
Ensure all participating sources are subject to the data manipulation conditions given by the CMDBf concept to be able to provide consistent data.
Define naming conventions which are binding across the different sources in order to be in a position to relate identical objects to each other.
Work out a unique key concept which allows you to uniquely identify objects across the different sources as well as over time.
The CMDB Federation (CMDBf) working group was founded in April 2006, and today consists of industry leaders BMC Software, CA, Fujitsu Limited, HP, IBM and Microsoft. More information can be found at http://www.cmdbf.org/