What is relevant information in CMDB?

It seems like many of CMDB designs and implementation fails to define the purpose for the content. This often leads to that everything that is accessible and available is stored in the CMDB. Every CI will be populated with attributes usually collected from various discovery products etc. What is the purpose of this? Well in the short term this can be useful. If the information was stored and accessible in different sources the short term gain could be that it is now accessible from one source. But is this really the purpose of the CMDB?

Well I think no, and here is why in my mind.

Imagine a CMDB with CI's and only one attribute per CI, the name. that means that any CI you create in the CMDB only gets a name and nothing more. Could this be used in a valuable way? yes very so, but it requires you to do more than just create CI's from discovery. You need to create services and service functions and you will probably not find them with a discovery tool.

lets make an easy service example and choose the ticket handling service that a ServiceDesk is using. The IT department is the supplier of the ticket handling service and the ServiceDesk is IT's service customer and consumer. Then i guess we have a service called ticket handling but what does it deliver? To define the content of a service i use service functions. One service function that the service desk is using is registration for sure. So lets line up some of the more obvious service functions that the Service Desk might consume.
- Manual registration of tickets based of phone call
- Automatic registration based on e-mail
- e-mail (communication outside the ticket handling application)
- incident Dashboard
- Self service (enduser knowledge, request and ticket registration)
there are more but lets keep to these five obvious service function just to prove the point of using few attributes in the CMDB.

So now we have the following.

We have one service with five service functions which actually tells the provider what the service desk is doing. This means that if we now connect the application CI's that provide this functionality directly to these service functions we get a pretty good view over how the provider is delivering the functionality to the service desk. Just to illustrate it i have entered som applications and server to the structure and we get the following.

This solution is very simplified but I have added three applications and three servers. the ticket application is critical for all functions and therefor have relationships to all functions but there are the e-mail application and the www application that actually does not affect all functions that the Service Desk is consuming. This means that if IT understand the availability demands from the service desk for the service functions IT can use this information when performing changes and handling incidents, problems etc. All this intelligence is still achieved with very few attributes on the CI's. It is the combination of CI's in a context that creates the magic. not the number of attributes you can squeeze into a CI. At this point the service and service function is quite static and the information is manageable even if performed manually by the service responsible.

If we add monitoring to the concept we can calculate the priority very easy when a incident occurs. we do not have application to application relationships and almost no attributes but we have the most important information available. How does this affect our customer! There are of course a lot of information that could be valuable that could be added but this basically covers the basics for a slim CMDB still with a customer centric structure.