|
First: I'm glad you are only considering auto-discovery for initial population of the CMDB. there is a popular misconception, promoted by the vendors, that you can keep the CMDB maintained by autodiscovery. this is false. The CMDB is maintained by the Change process. Auto-discovery is useful only to audit the CMDb data against reality, to see what has snuck by Change.
Second: there is no standard for federation of CMDB data. The term has no meaning yet. You need to build your own federation, i.e, software level data synchronisation. There is a first draft of a standard out for public discussion, supported in unknown future versions of vendor products. There is no common data model across proprietary CMDBs, nor any common data semantics.
Third: autodiscovery tools will only populate the lower, physical layers of your CMDB. They will not discover the conceptual or real-world relationships. they won't relate discovered CIs to applications, services, SLAs, business units, business owners, contracts, vendors, UCs, OLAs, warranties.... Nor will they embed business rles: if there is a load-balanced farm of seven web servers, how many need to fail before the web gateway is considered to have failed? AT the end of the day, auto-discovery will only do a certain proportion of your initial seed work.
Fourth: as your question implies, even after autodiscovery has discovered the physical CMDB data, you need to do an extensive manual process to reconcile data from multiple sources, to select the subset of data that is under Change control, and to extend the CIs with undiscovered attributes such as vendor, owner or book value.
Autodiscovery is kinda handy and saves a bit of work but it isn't the magic pixie dust the vendors would have us believe. CMDB is hard manual work that requires good people owning it and paying for it, and good processes maintaining it. There is not a technology solution to CMDB.
|