"The CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.