For several years, analyst told us that you must have Discovery in order to do a CMDB project. Sure… I’ll buy that concept, but it doesn’t mean I have to start with it. I think discovery does wonders for a CMDB, as long as your CMDB has a good way to drink from the firehose 🙂
One obvious starting point that is typically omitted is leveraging existing tools that do different types of discovery. Connecting into the existing management tools to get inventory types of data about the devices is powerful. Several of the tools are able to determine the type of hardware, OS installed and a slew of other tidbits. Integrating with other tools such as Help Desk, Change Management and Asset Management systems can provide even more information such as the applications or services being used, potentially a list of the end customers/users in order to provide a impact mapping.
The typical difference between a management system that has discovery capabilities and a full fledge Discovery product is that the Discovery product also does relationship/dependency mapping while the management tool understands different levels of health and availability. Both are useful, both are potentially good starting points.
A good starting point to feed the CMDB might be to connect into existing management tools, bring in the CI’s it knows about, the attributes it understands and then expand from there. There are several silo’s of data to pull from. Discovery tools typically work on schedules and sweep the network, integrating with the existing management tools provides a more up-to-date, closer to real-time update to the CMDB…. oh wait, that assumes the CMDB is able to consume it in that manner, the list of vendors just got real small.