The CMDB boundary problem: stop chasing this technological rainbow of a unified CMDB repository
No matter how much you store in a central CMDB repository, there will always be some data somewhere else. Don't fall for all the vendor vapourware of federation tools. Stop chasing this technological rainbow of a unified CMDB repository. These are not technology problems. Fix the congiguration management process, then apply technology to the process if it helps.
A recent comment on the IT Skeptic blog said "Listening to the podcast allowed me to feel it was OK to have 'CMDB data' in different data sources (as long as there was a solid process). I keep thinking we were somehow doing it wrong. The vendor cool aid was giving brain freeze. Thanks for the thaw!". You're welcome.
Scott is referring to the CMDB boundary problem that I have discussed previously. No matter how much you get in a central repository, there will always be some somewhere else. Telecom connections, manufacturing process control equipment, aircon. As fast as these devices are becoming IP-enabled and discoverable, more and more are being outsourced to other organisations.
And don't fall for all the vendor vapourware of federation tools. It is all just talk right now, and guess how long it will take BMC, CA, HP and IBM (and others) to agree, cooperate and deliver. All have a strategy of closed proprietary systems management suites: once they sell you one tool they want to lock you in to make the on-sell easier.
If you can't get 100% you will need reconciliation (read: manual) processes.
So if you have to deal with more than one repository, what does it matter if the main one holds 95% or 50% or 20%?
Stop chasing this technological rainbow of a unified CMDB repository. Stop chasing technology at all.
Make People the top priority: cultural change. This requires executive commitment, inclusive consultation, cultural fit, communications, training, marketing, fun etc etc
Then put Process second after People: get Configuration Management process (and Chnage Management) right first. Never mind what will it look like or run on: how will it work? Forget the things and look at the actions. Listen in your next workshop: how many people are stuck on nouns and how many are talking in verbs?
Leave Product/Technology/Things to last. Once the process is understood, THEN we can plan the forms, the schema, the cool software... and then we can write the documentation ONCE.
OK if you are NASA or something then you will now proceed to throw buckets of money at technology to try to get your configuration processes to maturity 4 or 5 as discussed in another blog entry, but for most of we lesser mortals, the process fix is a fix and we will manage from here on in without what ITIL defines as a CMDB (also discussed in another blog entry).
Technology starts before Process is finished of course (as Process starts before People has done). Once the technology is selected and implemented, we will see the gaps that need managing through process.
These gaps will include:
1) the boundary problem. Data in one of several possible places. How to find it? How to join the dots to get the service-wide picture? Do you want to replicate to have a broader picture in one place? Note: these are not technology problems. Start by approaching them as a process problem, then apply technology to the process fix if it helps.
2) redundancy. Same data in two places: in the event that they differ, which one is to be taken as the master? ("Never go to sea with two clocks. Take either one or three")
3) the Wild [I am reading the Hobbit to my son]. Some data will be beyond the bounds of the known world. You likely won't have a 100% picture of every service, especially if the internet is involved. What communication process to get the data from someone else? Is it even knowable?
To deal with these we need Process, not more layers of technology (except where tools make the resulting process more efficient):
1) consolidating data and alerts to get a service-wide picture
2) checking and fixing data, and detecting change subversion
3) replicating data between repositories
4) reconciling outputs from multiple systems
5) sanity checking output from tools
You will here it over and over on this blog: People Process Things, in that order. You can't have 100% of data in one place so stop busting a gut to get it. You don't have a CMDB tool problem, you have a configuration (and change) process problem.