The IT Skeptic - Comments for "The value of CMDB seldom exceeds the cost of doing it"

redundant data capture

Charles T. Betz — Fri, 25 Feb 2011 14:07:33 +0000

Definitely dependencies - assets often have OK processes even in smaller organizations.

See http://www.erp4it.com/erp4it/2005/12/dependency_mana.html.

CMDB ROI

skeptic — Wed, 23 Feb 2011 05:40:27 +0000

Some interesting ideas on where the value is in CMDB came from today's panel discussion at the Pink Elephant conference in Las Vegas: consolidation of assets and eliminating redundant reporting. Clearly consolidation is a benefit of asset management not CMDB. I also wonder if the redundant reporting was in fact asset information rather than service-relationships. Charles?

desist from name-dropping products

skeptic — Thu, 03 Sep 2009 03:56:19 +0000

Will readers please desist from name-dropping products. If you read any of the other posts on this blog you would know i consider it entirely inappropriate. If you get off on geek toys discuss them somewhere else - technology is the least of our worries.

1) Anyone who thinks they understand a technology based on a vendor demo is delusional

2) All CMDBs are overhyped unnecessary toys for the majority of IT installations

3) Thirty grand is only cheap if it is somebody elses's money. The real cost of the implementation and ongoing TCO will be hundreds of thousands of dollars. You should spend your employer's money as if it were your own

4) Configuration management is a domain (ITIL insists on calling it a process). It has culture and process problems. Technology doesn't fix them.

Alternatives to the big CMDB's

Tim — Wed, 02 Sep 2009 12:49:00 +0000

I have not seen [product deleted] - though the website seems to indicate that they know what they are doing.

I can add another to the list - [product deleted] - I saw this when I had a demo of [product deleted] and I thought it was just going to be a CMDB specific to Business Service Management but it seems to be a complete CMS too. On their website they state that it is available from $30k which seems very cheap.

It is packaged as an appliance and they lead with ease of use and pricepoint so might be a good option for you to look at.

improvement of configuration management

skeptic — Tue, 01 Sep 2009 20:06:43 +0000

The CMDB should answer the question that arises from working on improvement of configuration management domain. if we work on people and process, the bottlenecks and inefficiencies and weaknesses of the configuration management processes will determine the requirements for supporting technology just as all processes should for all cool tools.

Some sites will need six million dollars worth of automated graphical trees, and some will need a box of file cards. Most will need something in between.

the costs and risks of the configuration domain and the other domains it serves will provide the business case.

What questions should a CMDB answer?

ianclayton — Tue, 01 Sep 2009 19:50:31 +0000

I believe in the principle of the CMDB. As someone who has personally designed automation system engines to multi-thread and manage system events, I know how important it is to have an infrastructure GPS capability. Many of today's event management systems have this in-built.

If you add other considerations such as Asset Management, Procurement, Inventory, Governance (we have to control access to stuff in a centralized or aggregated CMDB don't we?), and Purchasing systems, and the little known fact that Ethel's fax out there in the sales department may be a critical component of a business process - we have all the ingredients for turf wars and scope creep.

For years each technical silo has matured and managed what is effectively a State run mini 'CMDB' albeit through their own personalized lens.

Enter the CMDB concept. After more than 20 years of discussion in ITIL, and from what I can see a complete ignoring of the non-IT discussions on Configuration Management, we have a bunch of folks with a keen interest to position a solution before the requirement cart has been put in place.

I dread asking but... exactly what questions should a CMDB answer, and for whom?

Perhaps this way we can begin the process of building a supportable business case for federating the configuration information in support of a service culture.

Skep - what chance this question could be elevated to its own thread on your site?

a loose cannon

skeptic — Thu, 27 Aug 2009 04:00:00 +0000

Jim, those aren't my words, it is a quote. Yes it is an exaggeration. I took it as clearly a rhetorical figure of speech

I've never been called a loose cannon before - I need to go think about whether I mind. Cannons are destructive - I like to think I'm not.

The web is full of hundreds (maybe thousands) of thoughtful ITSM blogs. This blog has quite a following and I believe that is because it provides both entertainment and substantial thought. If my style annoys you, sorry. I'd rather you continued to engage me in serious debate but I won't be changing my style. It works for me. It rattles the cage, it stops us taking IT too seriously, and at the same time it stimulates useful re-think of some of the industry's comfortable assumptions.

Another example

Jim — Wed, 26 Aug 2009 14:28:21 +0000

>>>f) WHAT DO YOU NEED A CMDB FOR? A CMDB needs a service oriented culture that
99,99% of enterprises do not have.

This is another sensationalist example, condemning practitioners around the globe. This is pearl of wisdom? If you stop promulgating this kind of print, many could start taking you seriously and consider your methods as one of a thoughtful person instead of a loose cannon entertainer.

Had you wrote this article instead...

Jim — Wed, 26 Aug 2009 14:22:11 +0000

...it would not have come off as sensationalism. You want me to refute your arguments, but I never set out to do so, read again. I think you are twisting words for readership omitting contrary case studies for fun and profit and damaging the value of IT journalism in the process, though. Why do I think so? Because my experiences tend, much more often than not, to be contrary to your world views and writings, especially on the topic of CMDB. While I am convinced you have a certain common sense that works for folks, I am equally convinced you have not experienced enough ITSM project time in enough environs to ascribe sensational and authoritative terms to your unconventional opinions. The original article has sensationalist niche appeal. Your bullet-ized reply here has value. The words do matter.

cmdb made sense until the product vendors changed the meaning

TimC — Wed, 19 Aug 2009 16:33:45 +0000

I still don't understand why the term CMDB moved from describing the set of data that describes CIs and their relationships, and CIs as being those things that you need to control to manage your IT operations, to a detailed and pointless single view of how everything in your IT estate happens to be set up now (I paraphrase as I don't have any of the books to hand).

Under the current use of the term, I don't think that there is much value in a CMDB, per se. Like any other piece of infrastructure (an asset shared by many to get economies of scale with the aim of reduced unit costs), it's unlikely to achieve much value until it's shared by users with differing intents.

As originally envisioned, I believe, based on some of the people who worked on the project, that the term was deliberately vague and analogous to the set of data that you use to run a business - and no one would envision trying to put a common schema or implementaiton around that.

It's such a shame that IT ops people just keep trying to use tools to make things work. I can build a CMDB to find out what I've got deployed and then use that info to do all sorts of stuff, but it's of no use in itself, and, usually it's not a good idea to encode what you first find as it's probably not what you thought you had and it needs fixing before you set up a system of record for it.

Skeptic's right, certainly for the products that I've seen. We did some work with a client who bought one of the big 'cmdb's and who wanted to use the standard schema. This generated 1M CIs from just the server end of a 1500 server estate. It would have cost more to maintain the data (let alone to build and maintain a more suitable schema), than it was costing to manage the servers to provide a near appropriate service level for the business.

It is possible to get value from a cmdb, even to use one to support ITIL processes, but just not what the product vendors call a cmdb. The simplification needed to bring the data volumes to a tractable level necessarily complicates Skeptic's points about identifying, reconciling, spotting the dependencies between and then tracking assets.

Imposter CMDBs....

ianclayton — Sun, 16 Aug 2009 23:48:17 +0000

Skep - I agree. What I termed a 'Network CMDB' was loose use of how they can sometimes be described and positioned from a Network Analyst perspective. The database(s) are in fact used to manage the network configuration, providing vital intelligence to event and alert management systems. The other examples have similar very personalized uses. All too often, in the absence of a succinct definition of a CMDB, the technical service communities can easily dismiss the need of a centralized capability by saying they already have what they need.

To the untrained eye, a Network Management ("CMDB") Database is where it belongs. The information it contains may be sensitive and copying elsewhere increase the security risk. I have long believed that a CMDB should be designed by an experienced database analyst (DBA) - not an ITIL certified person (unless of course they have designed major information systems). The design should be 'on paper' and driven by stakeholders that can explain what information they need and why, presumably as it relates to their role in fulfilling a a service guarantee.

Another 'best practice' you will find in the USMBOK (@Page 390 - Zero-Cost Operation), a "CMDB" should be self-funding - with sponsors of data elements prepared to rent space in support of their need for the information...

And building a "CMDB" capability - by that I think we both agree we mean the ability to relate any infrastructure item to a service level objective, should be progressed on a case by case, even 'Vital Mission Activity (@USMBOK Page 82 Performance Management Framework Tier 4)' basis.

Don't get me started on the tire tracks the CMDB concept leaves on Service Asset Management...

No service configuration, no CMDB

skeptic — Sun, 16 Aug 2009 21:44:42 +0000

I would have said CMDB serves multiple masters including incident, problem, change and SLM, but it doesn't depend on any of them except Change, to maintain and defend its data.

terminological pedantry: I don't think there is such a thing as "Network CMDBs, Application CMDBs, and even Service Desk CMDBs" - they are configuration data but they aren't CMDBs. the defining attribute of a CMDB is that it "determine what infrastructure elements are involved in providing a service", i.e. it relates to service. No service configuration, no CMDB. And I agree that is daunting. I also agree it is trivialised and oversold by the vendors.

As you said, CMDB requires justification, and that is where the crunch comes. I say in most IT shops it is cheaper and nearly as effective to do service impact analysis on demand by hand.

CMDB needs Problem Management

ianclayton — Sun, 16 Aug 2009 19:25:03 +0000

Skep - as you can probably guess - today was a slow day so I thought I would chip in a comment anywhere across your site just to help fuel some debates.

In my view most organizations already have a CMDB, albeit fragmented, unrelated to the services being delivered, and owned by discrete teams within IT. I see Network CMDBs, Application CMDBs, and even Service Desk CMDBs, all in operational use under differing names and causes.

I'm sympathetic with ITIL's demand for a singular capability to determine what infrastructure elements are involved in providing a service. For some that could be an information querying engine that aggregates the results into a 'service view'. For others its one database that trawls and extracts any and all information sources for input.

ITIL is unclear in the destination and how we get there. Many read its 'guidance' as the need for a logical representation of the service infrastructure and its relationships. Without special tools, even with, its a daunting challenge that will consume a significant investment in resources unless the scope if carefully predetermined. So vendors suggesting and proving it can be done with ease, deserve to charge higher prices! Consultants claiming similar are likely associated with one or more vendor tools.

Anyway, such an investment will require PRIOR justification, especially if it involves software tools. Apart from the need for the organization's embracing of ITSM, governance rules for access rights to what could be very sensitive data, much of the justification is bound to operational issues.

It is problem management's responsibility to define problems and their impact. Problem Management is one of the first practices to implement and get right, providing every other improvement initiative, such as implementing a CMDB, with evidence of the impact of issues its absence causes, and justification for action.

In my humble opinion, a CMDB requires Problem Management...

common sense on CMDB

skeptic — Sat, 15 Aug 2009 20:22:49 +0000

The answers over at the ITIL-Service discussion group on Yahoo are so consistently (and dangerously) ignorant and often stupid - in a word they are awful - that I regularly consider de-subscribing, but every now and then there is a pearl, such as this from Marcus Listas

I already did it a couple of times. I can list some guidelines:

a) Have focus on the process of cfg mgm. You got have it agreed,
documented, communicated and people has to be trained. Without it, any tool
is useless.

b) Keep it simple. Start little, with a group of CIs (the most important
servers, for example). Run away from desktops, unless your business really
asks for them to be in the scope.

c) Make it a project. Define scope, requirements, stakeholders, sponsor,
budget, etc. It is a HUGE investment. It usually takes between 6 to 12
months just to get your process defined and your cmdb modelled. Another year
for getting a tool selected, installed, customized, etc...

d) Don't believe the hype. Vendors (HP, IBM, etc.) will always try to
convince you that their tool is THE answer. But IT IS NOT! As a matter of
fact, their tool is usually the greatest problem you will have.

e) There are 2000 more very important issues; maybe you could tell us your
concerns...

But the most important is:

f) WHAT DO YOU NEED A CMDB FOR? A CMDB needs a service oriented culture that
99,99% of enterprises do not have. If you take out the services vision, the
rest you can get with an asset database and an asset management process. You
can call it a CMDB if you want, but it will not be one...

Do you have already a service catalog? Do you know your services enough to
draw all CI relationships underneath? Do you have a reliable enough asset
database and an asset management process?

These (and others) are all pre-requisites to a CMDB (and a cfg mgm process).

please refute my arguments

skeptic — Wed, 12 Aug 2009 20:10:00 +0000

I'm confused. One minute you agree that it is about configuration mangement process and people, and tools are secondary. then you call it reckless ensationalism. please justify that statement. If I am wrong please refute my arguments, which you haven't done:

Configuration management is about meta-data.
The data exists somewhere in the organisation.
Configuration management assembles it.
The primary activity of configuration management is reporting or at least providing the data to support reporting service impact analysis, for the Incident, Problem, Change, SLM and other processes
It should provide that data to meet an OLA of practical timeliness: it doesn't need to be instant, just within x miunutes or hours, to y accuracy
The only data that distinguishes a CMS from other meta-data stores is that it relates service CIs to other CIs
The data can be assembled in advance and stored in a CMS, or assembled on-demand (which is what we effectively do now in an ad-hoc way)
In the majority of cases - especially those with lower maturity requirements and/or less complex environments - just improving the process of on-demand impact reporting will meet OLAs without a specialised meta-data store
If we store the data it will never be perfect and will need human checking anyway
If we store the data we still need processes around it: the focus is configuration management as a process not CMS as an object - CMS exists only to make the process more efficient and effective
We should start by improving the configuration process, and the culture of those who affect the process
If after/during that improvement we identify that the process cannot meet OLAs without adding tools, then we can consider adding tools.
The cost of adding tools is massively more than the license cost of the tools or even the implementation services cost: maintenance costs and TCO are high for CMS
Most of the benefits ascribed to CMS are actually benefits of much simpler technologies especially asset management
The remaining benefits returned by CMS are usually more about appeasing technical people's craving for accuracy and completeness than they are real business benefits

Competence of practitioners and cost effectiveness of tools

Jim — Wed, 12 Aug 2009 14:25:29 +0000

I don't see anyone saying don't do CMDB/CMS or improve Configuration Management process at your concern. Instead, it is very apparent we're indicting the pratitioners' competence in making it all effective and efficient using prevalent vendor tools.

Unfortunately, no one here is just coming out and saying they support the principles but condemn the cost structures of leading tools, and the education, experience and capbility levels of most pratitioners. It comes through in-between the lines, but not tacitly.

What is glaringly being missed here is that second tier tools, in-house tools, top-tier talent, and pure doggedness is building successful real, honest CMS'es for low costs (including professional services! egads!) in sub-regional and mid-tier concerns, not just the hugest 2% of companies. And yes, using PEOPLE. I would agree that the full-program approach is not appropriate for small companies. But the same meta-data is required to run a business, call it whatever you want.

This article almost crosses the line from "prodding hard thought" to "reckless sensationalism" - devaluing the time I spend reading it, to be honest.

CMDB

Mike Paterson — Wed, 05 Aug 2009 19:39:00 +0000

I am actually interested in what other best of breed solutions are out there.

At SXC we are always looking to find the best technologies. If I had wanted to generate business for SX Consultancy I would have mentiioned the company and given our website address. I tried not to do that, and to add something constructive based on my personal experience, and I have indeed seen it demo'd.

Your initial comments were rather broad brush and surely a one size does not fit all when you are talking about technologies that are vastly different to each other in architecture, design, use and also price and implementation speed.

I do not really see why it matters how the cmdb is federated at the moment (as there is no standard), and I tried to point oiut specifically that it is ease of use and speed of delivery that differs from one solution to the next.

I was actually hoping to find out from others what cmdb or cms's are in fact good at doing this for my own interest and education, though as a good cynic, I am sure that this would not have registered with you :)

Management of configuration, and modelling of change to configuration is a technology problem and can be solved (or at least helped) by the application of appropriate technology.

You ask some pertinent (if oft-raised) questions and most of them have answers of sorts, though my intention was of general interest in the different technologies that can be used to help to alleviate these issues, and not to publicise SXC.

[product deleted] does seem to have a number of uniques, but as you have probably not heard of it, why not ask them these questions directly and see what they say.

Regards
Mike Paterson

Interested in all new technologies in systems management, service level management,BSM, and infrastructure management for my own personal development!

Nice system

supportthought — Wed, 05 Aug 2009 14:12:00 +0000

I wonder if the focus on tools to do CMDB work (when for example we make people do most of the work in Change management) is because of the vendors selling hard, or the fact that Configuration management is considered very boring work.

We would really rather just have someone sell us something to take it all off our hands?

"oh you have a tool that can do all this tedious stuff for me? sweet, how much? (gasp)"

I think we agree too. I just

riCh chestMat — Wed, 05 Aug 2009 07:19:29 +0000

I think we agree too. I just got distracted by the CMMI reply bit without remembering all the other stuff you said elsewhere on the thread.

A system. Sure why not. I

riCh chestMat — Wed, 05 Aug 2009 07:09:29 +0000

A system. Sure why not.
I have a system where every morning I take a dump before showering. Fortunately I don't need a software tool for that. Thank GOD I don't need software for that. Or a consultant.

Having said that when you open up the statement it does actually make more sense:
ITIL v3 Service Transition book 4.3.4.3 Configuration Management System: "Service Asset and Configuration Management requires the use of a supporting system known as the Configuration Management System"
On the other hand it's also a waste of print because all it really says is:
Configuration Management System: [Service Asset and Configuration Management requires Configuration Management]

I've got nothing to say about those later two excerpts because they are, as you say, sensible and often ignored.