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.
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.