ITILigent Service Management

[#1]

What is the difference between a Configuration Management System (CMS) and a Configuration Management Database (CMDB)? This is a question that came up several times in meetings that I had with several different HP customers in multiple industries over the last couple of months. Let me address this post to answering this question.

Let's first take a look at the ITIL V3 glossary definitions:

CMDB - (Service Transition) A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

CMS - (Service Transition) A set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes.

There are a couple of points to take away from these definitions:

1. CMDB is a database only, while the CMS also includes tools
2. CMS maintains one or more CMDBs
3. CMS is used by all IT Service Management processes 

So the quick answer to my question above is that the CMS concept builds on top of the CMDB concept.

Let's also take a look at the sample CMS (figure 4.8) in the Service Transition book. This sample shows a CMS that consists of 4 layers: data & information layer, information integration layer, knowledge processing layer and a presentation layer. As you can see in this figure there are CMDBs (and other data sources) within the data & information layer, as well as an integrated federated CMDB within the information integration layer.

Now this means that the CMS concept recognizes the fact that no single physical CMDB can hold all (service asset) data for a service provider.

On the other hand the CMS concept does however indicate that there needs to be a single integrated CMDB that holds configuration items about the available data and how these configuration items are interrelated. By using federation this integrated CMDB can pull through the data from the sources at the data & information layer and make it look at the presentation layer as if the CMS is one logical database.

There is a lot more to say about the CMS, however as I am writing this close to midnight I will stop here and save some thoughts for another post.

Please let me know your thoughts and experience on this topic. Thanks.

Regards,
Jeroen Bronkhorst

[#2]

Thank you for sharing near mid night.
Do you think a CMS could consists of:
a) An in-house developed Domino application containing Service Assets and their attributes and relationship
b) A Microsoft SMS database collecting network PC asset information for comparison with the information contained in the Domino application.
c) A set of visio files showing network architecture diagrams
d) A set of visio files showing the infrastructure diagram
e) A set of application data diagrams

Thanks & Best Regards

[#3]

Yes, sure. A CMS can be implemented with many different technologies and products, although I have a (slight) preference for HP software of course ;-).

There might be a challenge with the components that you mentioned in how to make it look at the presentation layer as if the CMS is one logical database. In other words, how is the integrated federated CMDB being addressed.

Hope this helps.

Regards,
Jeroen Bronkhorst