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.
3 comments:
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.
Regards!
Antonio
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.
The link to the white paper is no longer valid. I presume this is the white paper you're referring to?
Post a Comment