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.



Sure there are CMDBs. There's the new HP UNIVERSAL CMDB. There's CA's CA-MDB. There's BMC's Atrium.

Given the way OGC and ITIL are going, ITIL will redefine the CMDB to be the Universal Data Dictionary and include what's in the ERP and the CRM systems too.

Given Skeptic's very solicitous opinion of HP, I'm surprised that there's any less than glowing opinion of HP's UNIVERSAL, intergallactic CMDB

The fundamental issue remains the effort required to populate

You know, I do think those bits of software are getting close to a CMDB and I possibly shouldn't have disagreed with Charles about BMC's tool. Though I think there are still issues around federation, analysis of impact in a real environment etc...

The fundamental issue remains the effort required to populate and maintain the repository, rather than the repository engine itself.

And I think HP gets flak from me as much as any vendor. Wait until I get onto the topic of itSMF USA...

nobody makes a CMDB yet

Here's another source, Hank Marquis, saying nobody makes a CMDB yet

Beg to differ

Skeptic,the root of your problem is that you are lumping element config together with enterprise config.

BMC makes a CMDB. That's clear to those of us with hands on experience. It is an *enterprise* CMDB. The federation problem comes at the boundary of enterprise versus element configuration management. See

Now, if you are suggesting that no tool will ever handle both enterprise and element config, you are 100% right. To the extent that ITIL and COBIT muddle the two, we have an issues. And process is a weakness. But it can be overcome. I've seen it done.

The key question is, what is the fundamental purpose of the enterprise CMDB? It's quite simple: to facilitate human communication. See

The purpose of element config is, well, to manage elements. Two different problems, sets of stakeholders, processes, points of view.

Re: Hank Marquis... Anyone who thinks that OLAP is an appropriate technology for a CMDB is badly misguided.

OLAP is about denormalization and precalculation for performance in the context of business intelligence (data warehousing). CMDBs have nowhere NEAR the volume requirements needed to justify OLAP. Nor do you use OLAP for a transactional system, which a CMDB most definitely is - data warehousing and BI are generally read-only. CMDB (and its cousin metadata) is about managing complex, insanely normalized data models (metamodels) and handling graph-centric data, which is the antithesis of BI.

OLAP and CMDB in brief occupy opposite ends of the data architecture spectrum. See

and chapter 3 of my book for a detailed discussion of the issues.

Now, we may need an IT data *mart* into which the CMDB, project portfolio, capacity, service desk, IT finance, and many other internal IT systems replicate their data for reporting. But *that* is NOT a CMDB.

(by the way, among other BI experience, I designed a 10-terabyte data warehouse for Target Corporation in 2001, when a terabyte was a huge number - we based it on Oracle's OLAP technology. I also have implemented three metadata repositories and two CMDBs, some built, some bought - I was responsible for the detailed data architecture in all cases.)

I think the problem with CMDB is that the ITIL v2 description was so vague that the scope of the CMDB was unmanageable. The reality of IT internal systems is that there are a multitude, and they do need to federate. Now, you also are implying that federation requires industry standards and will be impossible without them. That's simply not true. All of the major enterprise software packages have APIs which a competent development team can stitch together with middleware. Known problem domain. Can be a tad expensive and risky, but quite do-able.

See for an idea of what the internal IT architecture looks like. This is not idealist - I have seen it largely implemented. Without industry standards beyond middleware protocols (SOA, RPC, FTP, ASCII, etc.)


I agree with everything you said except

Hi Charles

I agree with everything you said except
a) I have a problem :-)
b) element configuration is not part of CMDB (other readers need to check out the blog entry to understand the distinction)
c) CMDB is there to faciltiate communication
d) BMC makes a CMDB

When I talk about CMDB I talk about ITIL-defined CMDB (there isn't any other kind). The purpose of CMDB is to support the ITIL processes. As such there are two key aspects:
1) information about the CI, e.g. current status (meeting service level objectives or not), financial information, contractuals, patch levels and other data to determine whether or not a change will successfully install on it. To this extent I disagree that what you call element configuration is not included in CMDB. There is information about the internal state required to support process. I do however agree there is other detailed info not required by ITIL.
2) relationships between CIs, especially tracking which CIs contribute to which services. Enterprice config if you will.

Maybe ITIL and COBIT do muddle enterprise and element config. The distinction is yours not ITIL's. You can't go unilaterally redefining what a CMDB is. ITIL says some of the element config is included.

While CMDB may sometimes assist communication, it's prime purpose I would have said was as a real-time source of reference for ITIL processes. Data gets put in, data gets looked up. So communication via a CMDB is asynchronous.

I have my doubts that BMC capture enough information about enough CIs to support a business service view end to end for all ITIL processes, but I am not familiar enough with their product set to argue. I am willing to accept that they have a very good repository tool that provides a lot of information about a lot of CIs to provide a fair proportion of the view of a service, particularly in an environment which uses a lot of their tools, but that isn't the same thing as a CMDB.

From there on in we are in agreement.

I too don't see OLAP as a CMDB engine.

A mart is not a CMDB.

The ITIL V 2 definition of CMDB is hopeless [which is precisely why arguements like this one happen all the time. The "proper" definition is unworkable so people define CMDB as something else that is workable. I'm not saying whatever you implement is not implementable, I'm saying it is not a CMDB.]

Federation is possible, just very expensive and requiring extensive effort by the user

Anything, even CMDB, is technically possible given enough money, time and people. The question is whether it is practically possible, i.e. whether there is a business case.

Thoughtful informed robust debate as usual, thankyou.

Watch me

"You can't go unilaterally redefining what a CMDB is. "

Watch me. If what ITIL calls for is technically unfeasible - or more charitably, a logical function independent of implementation - then those of us who have to solve the problem will decompose it as necessary. I've received a lot of feedback that the element versus enterprise config distinction is useful and pretty much the key issue confusing things.


The real purpose of the "Holy Grail" sorry CMDB

Charles, from one of your links "It's not about technology. It's making sure that the right people are talking to each other in IT, especially in the context of Incidents, Problems, and Changes.

How do we make sure the right people are approving the Change? Because we know what is dependent on a given Configuration Item, and who owns it."

CMDB is a supporting process and remember ITIL is about process not tools or technology. CMBD supports all aspects of Service Support and Service Delivery process sets.

If we start at the beginning - "Incident Management" the accepted reason for most Incidents is unplanned/unscheduled change - especially high severity incidents - I know this because I spent many years reviewing root blame analysis reports from around the world for a major services company. How does unplanned/unscheduled change come about?

ITIL tells us that possible problems with the Change Management process is:
- inappropriate for the size of the organisation
- an overly-bureaucratic
- Cultural difficulties, etc (the Blue Book)

I know from personal experience that when the Change Freeze is in effect NOTHING breaks bad.

I don't need the CMDB to tell me this - I need incident data to tell me this. The CMDB when utilised by an effective Change Management process and a functioning Incident Management process will help me to identify all approved changes that have been effected to the system concerned - and remember the system supports one or many business systems.

Ah, we have a business to keep functioning - this means the whole purpose of all this ITIL is to keep a business working - you remember them, the guys and gals who sell the things that write the paycheques to keep IT in a job.

This comes full circle to the Service Catalogue. The Service Catalogue needs to be constructed to support the people and how they deliver service to the Business Clients and could be services such as "Colloboration" being technology like email, MS SharePoint, IM and "Retail Client Services" being technology like Internet Banking, Branch Systems, Call Centre Systems. This Service decomposition should then help deconstructing the Business Service into the enabling processes and supporting technologies. The CMDB is out there and you get it when you envison the IT world from the Business Viewpoint.

When you have that 3:45 AM Hook-up the business is right there with you on that call, that's when the Business get IT. That's when they tell you how they think and you better listen because if they get IT so you better get IT too.

The only opinion that really counts in approving change is the buiness. They are in the end the only right people who approve a change. Keep them involved, keep to KISS and remember automating a bad process won't fix it, and there is no system yet that is foolproof because there is always a fool out there who will break it.

IT is and always has been Business Enablement Services - we just never got it.

We all hope ITIL V 3 has improved the CMDB definition

We all hope ITIL V 3 has improved the CMDB definition into something concrete enough that we can all see it as the same thing and practical enoguh that it can actually be done. With luck the authors were aware of your work.

If everyone, vendors included, start defining CMDB their own way, then we get a Tower of Babel. We also get the situation where lots of people are reporting that CMDB is being done which disguises the fundamental problem (that it isn't).

More on CMDB

See also this recent comment on auto-discovery tools: "When all you have is a hammer, the nail looks like the problem.". And click the "CMDB" link above to get more blog entries on this topic.

Syndicate content