CMDB Federated Model

[gcronin]

From all that I've read to date re: CMDB, the accepted wisdom seems to be that taking a federated approach to implementing your CMDB is the best approach.

However, the piece I'm still missing is what do you do if the existing data sources you are federating from do not have any support for tracking changes and maintaining a historic record of previous states.

Obviously, first choice would be to convince the data source owners of the important of tracking changes to their data and have the data source itself store historical records. But, this will not always be feasible for any number of reasons (technical and/or political)

Seems to me that if you are confronted with this scenario the only other alternative in order to support change history within your CMDB is to do some from of data grab from these data sources and store the date insitu within your CMDB - but then doesn't that contradict the whole concept of Federation in the first place?

Should the CMDB therefore be turned into some form of datawarehouse or is it best practice to create a seperate DW implementation that the CMDB federates in order to get the historical data.

As you can see, this is confusing me - any guidance would be greatly appreciated

[gcronin]

any takers?...please :-)

[The Skeptic]

if you are going to go the whole hog, then I vote data warehouse. As I said in another post there is no standard for federation and you have to build all the integration yourself. Might as well extract, transform and load so you are technology independant.

But there are easier options:

Buy a service support tool (usually mis-named a "Service Desk" by the vendors) that properly integrates service desk, incident, problem, change, asset and config (and hopefully service level reporting) in one tool with one set of data (not all of them do). Now you have 90% of your CMDB in one place. if your network and systems management data is somewhere else, big deal. You'll cope. You can never get 100% of data in one place anyway. So what if it is 90% or 70% or 30%: you'll still need the same processes to cope with the fact that it is not 100%. I call this the CMDB boundary problem.

Then have two people who are your walking CMDB for impact analysis. They understand the data, or they know where to look, to work out what it means when a component fails or a RFC wants to change a CI. The vendors will sell you automated impact analysis tools, but these tools can be notoriously stupid in their deductions. They only have to get it spectacularly wrong once and everyone will go validate each automated impact deduction with the "human CMDB" anyway.

(But don't buy any tool until you have your processes sufficiently designed to know what you need,and you have enough Change process implemented to protect the data. Without adequate Change in place your data is crap minutes, hours or days after you load it.)