Auto-Discovery & CMDB

[gcronin]

So, you have a new CMDB implementation installed and you're now ready to seed (populate) it with CI information for the first time. You are adopting a federated approach and thereby have identified a number of pre-existing data sources that you are going to federate from.

what I'm unclear about is whether you should

1.) install your own set of auto-discovery tools and use those to seed your CMDB and, only after that, start linking these CI's to other data sources for federation purposes OR

2.) do you use the existing set of data sources as the basis for seeding your CMDB; in which case you're not actually installing & using your own set of discovery tools but 'trusting' the accuracy of these other data soucres for the identification of your CI's

I guess if these other data sources have their own discovery tools why the need for installing another, distinct set of discovery tools/technologies

Can onyone shed any light on what they did/would do

p.s. I do appreciate it may come down to how much confidence you have in the accuracy of these other data sources and pre-existing discovery tools

[gcronin]

any takers?

[The Skeptic]

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.

[lou]

speaking here from experience...

The questions raised and discussed are real life and i (and my organization) have struggled mightly with them.

ITIL has nice theories, but what is reality... that's the 50,000 dollar question

I agree with "the Skeptic" and would add that if you already own tools which maybe manage your environments like SMS or SCCM for Windows, yes you can get some relationship information from those tools, however only hardware to software and they are limited to strictly that relationship. They cannot map at an application level and have no hardware to hardware relationships.

Use the true CMDB autodiscovery tools to get the hardware to hardware relationships, do application mapping, and hopefully your CMDB discovery tool can integrate into your ticketing tool and push your application CI to hardware relationships for your Change, Incident, Problem management teams.