CMDB - Not a DB, not 'definitive master'

Ok - this was a real insight to me. Hope it's not Old News :-)
[25-Jan/15-Feb-2007. This PDF from the "CMDB Federation [BMC, CA, Fujitsu, HP, IBM and Microsoft] supports a similar view - "Federated CMDB's".]

Was talking to a friend today who does config, change & release mgt for a large, secure Government Department.
He's struggling with Data Quality issues - surprise, surprise.

They import equipment details from a logistics system, they do a *lot* of shipping to/from 100+ overseas offices.
It doesn't enforce strict product id's - there could be 20 different versions of a single PC product name.

But talking to him further, it's axiomatic that CMDB's will not and cannot ever be the master or definitive source of all information.

CMDB's are, by definition, a join of existing, disparate databases mastered by other products/applications.
The only thing they can be is an 'intelligent collective repository [just made that up].

It reminds me of comments by Jerry Gregoire

When he was CIO of Dell he said :
"you don't want to use an ERP" - takes away your distinctive business process, costs to get in and out of, and ties you into one monster database. And slows you down - you can't change your business quickly if the ERP vendor doesn't support your new function/process.

Dell used an object broker and connected into existing apps & databases.
They implemented a brand-new Inventory system with *zero* new databases. The place has gone downhill since he's left - I sometimes wonder if that's linked.

Jerry also pens pretty straightforward advice which I heartily agree with.

More...

Summary...