The IT Skeptic - Comments for "The CMDB boundary problem: stop chasing this technological rainbow of a unified CMDB repository"

The fundamental issue remains the effort required to populate

skeptic — Thu, 15 Feb 2007 06:38:15 +0000

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...

CMDB

usedtowander — Thu, 15 Feb 2007 05:32:47 +0000

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 real purpose of the "Holy Grail" sorry CMDB

vaioboyaus — Wed, 14 Feb 2007 10:48:58 +0000

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

skeptic — Tue, 13 Feb 2007 19:14:02 +0000

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).

Watch me

Charles Betz — Tue, 13 Feb 2007 12:32:18 +0000

"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.

-ctb

I agree with everything you said except

skeptic — Tue, 13 Feb 2007 06:15:45 +0000

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.

Beg to differ

Charles Betz — Tue, 13 Feb 2007 01:41:27 +0000

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

http://erp4it.typepad.com/erp4it/2006/09/element_versus_.html

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

http://erp4it.typepad.com/erp4it/2007/01/the_fundamental.html

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

http://erp4it.typepad.com/erp4it/2004/03/erp_for_it_repo.html

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

http://erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html 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.)

-ctb

nobody makes a CMDB yet

skeptic — Mon, 12 Feb 2007 21:49:40 +0000

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

More on CMDB

skeptic — Mon, 12 Feb 2007 21:37:24 +0000

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.