Generic vs Instantiated CMDB
I regularly meet with prospects and customers that are very anxious and nervous about the CMS/CMDB as they see it as a huge work to implement it.
Most of the times, they have been fooled by vendors that explained them that implementing a strong, robust and granular CMDB is key for their business. This is not true. You don’t need such strong CMDB to be successful with your process automation. This argument is only there to justify the costs of dedicated CMDB tools for which most of the customers don’t understand why they have to pay extra for such component that is at the “heart of the processes” as the vendors like to say.
Deploying a CMDB doesn’t need to be a difficult and painful process. For most of the organizations, they can start with a “generic” CMDB in opposition to an “instantiated” CMDB. The idea is that instead of trying to populate the CMDB with every single asset in the infrastructure, to simply start with a generic CI for each class. This is particularly true for customers with low maturity and a need to quickly deploy the Service Operation processes.
Let’s imagine that the customer’s infrastructure looks like:
- 100 HP ProLiant servers (50 with Windows, 50 with Unix)
- 25 Dell PowerEdge servers (all Linux)
- 550 HP Work Stations
- 50 Macbook Pros
Instead of trying to populate the CMDB with every single asset, one approach is to create a generic CI, for example:
- HP ProLiant Windows
- HP ProLiant Unix
- Dell PowerEdge Linux
- End-User HP Work Station
- End-User Macbook Pro
I think you got the idea. This is a straightforward approach that will greatly help with the process deployment (as incident). It will also help in defining the priority for instantiation: perhaps the customer will take care in populating all HP servers in the CMDB as reporting would show that this is the most unstable asset in the CMDB and the need for instantiation is key.