21 August, 2007

Do not invest too much in building your CMDB now!

Interesting enough a few days ago a new version of the CMDB federation Whitepaper has been posted. The list of participants is impressive as we find every key players in ITSM including Microsoft…CA, IBM, BMC, Fujitsu, HP and Microsoft have worked together to propose a standard for federating data from ITIL compliant CMDB repositories. The intention is to submit their achievement to a standard body sometimes this year. For the time being, this is a draft which is reviewed by the main IT Service Management actors.

In this current version, there are explanations how to push or pull information from/to various CMDBs into a main CMDB. These “other CMDBs” are named: MDR, Management Data Repositories. Exchange mechanisms and technologies used to access these MDRs will be based on the SOA stack (HTTP, SOAP, WSDL, XML).

What does that mean concretely?

· In a few months (years?) vendors could sell Service Management solutions with a different metamodel
· Instead of using autodiscovery tools, vendors could provide these push pull mechanisms for companies which already have in place other platforms such as Asset Management systems, or system management platforms, or other inventory systems
· It becomes maybe un-necessary to build proprietary bridges with systems which contain important information to build a CMDB. This could be postponed.
· Vendors which actually come with tactical scenarios such as HP-Mercury with their UCMDB could change their strategy sooner than expected!
· Companies in a CMDB project may have to “migrate” in the future to another approach, based probably on a hub and spoke architecture
· Taxonomy being a key challenge for such a project may impact existing CMDB implementation

Companies which started to build a CMDB should measure the impact of that initiative in the long term with their vendors as the CMDB landscape could change dramatically in the next months.


Antonio Valle said...

Hi Serge!

I was at the HP Technology Brief last July and saw a demo of Universal CMDB, a federated CMDB based on those concepts.

When I asked the product architect about the cmdbf initiative, he didn't know a word about this whitepaper, so all the development was done in a different way (the same idea, but no compliant implementation).

I think it will take more time than expected to see products running this specification and even more time to see different vendors interconnected.


Lou Springer said...

A lot more attention should be paid to the "glue" (federation) than the CMDB itself.

But the problem isn't the technology.

Many enterprises have various islands of information that together would represent a fairly decent start on a decent CMDB. The issue is that the databases don't talk to each other, much like their masters, or the processes that manage them.

Anonymous said...

The link to the white paper is no longer valid. I presume this is the white paper you're referring to?