less than 5% of fortune 2000 have an active CMDB installed ?

Submitted by skeptic on Thu, 2009-06-25 20:47

Share this post with

Can anyone who was at the Gartner conference this week confirm what I saw on Twitter? "Major takeaway from Gartner IOM event is less than 5% of fortune 2000 have an active CMDB installed "

Published in The Skeptical Informer, July 2009, Volume 3, No. 5

Previous story: Fast track to ITIL V3 Expert
Next story: IT in 2011

CMDB

Comments

Submitted by Cary King on Sat, 2009-06-27 15:58.

Reason for vendor focus on CMDB

Only 5% market penetration?

That explains the laser-focus on CMDB by Service Management software vendors. What a great upside cross-sell market.

Of that 5%, how many have implemented a CMS with a scope beyond a central data center or that contains enough information in it to actually do end-to-end management of services? And, how many did an honest study of, and achieved, a reasonable ROI?

It doesn't matter much if the customers will gain much value from it - they surely will be pounded into believing it will.

Vendors obviously think customers are weak minded. Instead of actually demonstrating value by working with customers to achieve real success, vendors seem to be using a lot of false arguments to do their software selling: argumentum ad numerum, circulus in demonstrando, argumentum ad novitatem, and overwhelming repetition - argumentum ad nauseum.

For those organizations that have completed implementation of the necessary predicate process, organization and technology, there may, indeed, be real value to a CMS.

Alas, too many are proceeding as though a CMDB is some sort of magic bullet.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Submitted by skeptic on Sun, 2009-06-28 10:46.

lucrative

I'm still amazed at the hostility with which my CMDB ideas are met. It s a VERY lucrative apple-cart I'm upsetting. The software vendors seem to see me as an amusing sideshow - apparently i don't threaten their sales cycles - it's the consultants who go ballistic

Submitted by Cary King on Sun, 2009-06-28 14:57.

There's a time for all things

At this time it seems to me that CMDB has potential to solve some problems - chiefly being a single clearinghouse for specific data. The value of that seems questionable unless the organization has, or is getting near, orchestrated actions throughout their operations. CMS, or data architecture and understanding of the several data items, seems to be a perfectly useful idea at any point.

CMDB appears, all too often, to be technical fix that is likely to have disappointing business results because the predicate issues are not resolved - many companies do CMDB without having a decent grasp of what items they own and where they are. I suppose, however, that some of the CMDB technology is so intimately tied with application discovery tools that this rush to CMDB will continue so that companies can try to lower their Change/Release costs.

It seems to me that every company IT group I visit is hurting from lack of alignment with their business side. Wouldn't these companies be better off if they concentrated on reorganizing around service delivery? Wouldn't they all be better off if they spent their time defining their services (and sub-services) and understanding the costs; the activity flows for consistent delivery; and started to build evidence (run charts) of the time and variances to delivery so they could get meaningful SLA's defined for their whole portfolio? It seems to me that customers will feel that IT is aligned if IT consistently delivers we say we will, when we say, at the price we say. It seems to me that trust (alignment) is earned.

I guess I don't see that CMDB is a major determinant in that effort. I can certainly see, however, that for some organizations that are ready, CMDB could create value by eliminating data inconsistencies and clutter that are the root cause of poor decision making for Change/Release.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Submitted by skeptic on Mon, 2009-06-29 04:44.

making things nice and tidy

Cary, i agree 100% that there are better use of funds than CMDB, and that the customer facing services are a clasic example of a better place to work. But it's hard icky people stuff, analysing and negotiating a service portfolio. Geeky internal tools are much more fun, more tractible. "CMDB appears, all too often, to be technical fix that is likely to have disappointing business results" Amen!

However I fear you slip back into the same thinking with "CMDB could create value by eliminating data inconsistencies and clutter". How often does making things nice and tidy have a ROI to justify the immense cost of CMDB? As compared to the cost of improving configuration process to get professional configuration data analysts to eliminate data inconsistencies and clutter with a few good reporting, spreadsheet and data scrubbing tools.

Submitted by Cary King on Mon, 2009-06-29 15:34.

Value is in the eye of the beholder...

Skep,

Yes, I do believe that CMDB can create value.

Not to be slippery about it, but that value is up to each company to evaluate - I try not to slide into prejudge the value of any situation.

Big companies with big problems can achieve good ROI even when spending lots. There are scenarios where CMDB would help an organization achieve adequate advancement in capability for a wonderful ROI. I've visited plenty of companies that have multiple help desk software implementations from different vendors (one large auto maker had 27, just in the U.S., another Japanese auto maker has 7, just in the U.S.) plus a high number of disparate discovery tools, management tools generating events and repositories hooked into the these many different implementations. Rather like a company might implement Tibco or Websphere MQ, a CMDB might help clean up the data faster than reimplementing all the service desks into one - the value is in the time to improvement. Getting alignment of all that clutter faster may increase end-to-end dependability. Tough case to make, though, because companies that have this kind of chaos don't normally capture meaningful end-to-end performance management data - just lots of statistics data on specific machines, which provides little information.

Smaller companies, can find trimmed down solutions that achieve a good ROI if they choose wisely. There are, now, service desk software vendors that have included CMDB and many other visualization functions into a package that includes all parts of service desk, asset management, procurement and service catalog with easy integration to application mapping like Tideway and event filtering from a number of different sources. A CMDB does not have to be a separate product from the other tools. Fully Pink verified for all - in one package.

CMDB doesn't HAVE to be that expensive. CMDB doesn't HAVE to be a separate tool that was acquired by the current vendor and never integrated with the other tools.

Neither does CMDB doesn't have to be justified as a separate tool. It can be justified as an integral part of a good Configuration/Change/Release program.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Submitted by skeptic on Mon, 2009-06-29 21:56.

this does not mean that everyone should have a CMDB

We agree:
Configuration data repository should be integral with service desk tool.
A small number of sites can cost justify CMDB because of their complexity and advanced processes (I reckon oh about 5%)
Every company should evaluate the ROI (and I assume you are thinking that evaluation will stem from a good understanding of their configuration management process requirements first)

On this we agree. I hope we also agree that this does not mean that everyone should have a CMDB. But ITIL says so and so too do every vendor. It is the implicit assumption of the ITSM industry right now and that is what I challenge. There are lots of mildly interesting technologies that fit in 5% of sites and they don't generate half the attention that CMDB does.

Submitted by Cary King on Tue, 2009-06-30 14:20.

ITIL is a good practice, not a religion...

Agree? Absolutely.

Every investment decision should be scrutinized for adequate benefit to the organization that is making that investment. ITIL processes and supporting technology are not exceptions. I'm certain that every CIO takes seriously their duty to create value for their organization.

It seems that standardization of execution of processes in alignment with good practices such as ITIL, CobiT, USMBOK, etc. is more likely than not to reduce costs through improved improved quality and denpendability of services, especially as IT becomes increasingly disaggregated through the Cloud and other new opportunities.

It should be increasingly obvious, however, that very discrete service identification and small cost pools for each service will be needed to evaluate cost savings opportunities like Cloud. IT Financial Management throughout operations, more advanced than the blunt-force methods in ITIL, will be required to exploit the new technology cost-savings opportunities.

Activity-Based Budgeting for each service is an important means of understanding service costs and forecasting demand in a way that means true alignement with the customer. If a company is not implementing standardized services with Time-Driven Activity-Based Costing throughout their portfolio they will be poorly armed when the time comes to answer questions like, "should we move to SaaS for this application." As budget season rapidly approaches, company management should look carefully at another year without a good understanding of the IT service portfolio and costs of those services. And, they should consider what it will take to correct the lack of transparency into IT spending.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Submitted by Robert E Stroud (not verified) on Tue, 2009-06-30 22:49.

ITIL is good practice - lets remove the religion!

Cary et all in this tread!

Every day (almost) I visit an organisation no matter where I am that is implementing ITIL - that's no surprise to those of you who know me and regularly I run into what I consider ITIL zealots. Comments such as "V3 is better than V2" or "V2 is the only ITIL" or last week's great comment was that "the CMS was actually the CMBD in version 2". Having been involved for some time and in COBIT, VALIT and to a lesser extent RISKIT which will be released shortly, what they all have in common is that they are frameworks and as frameworks only guidance. What you need to do is use them as samples of good practice.

Cary, your post makes sense. CMDB discussions are not that relevant as you assert we need to focus on financial metrics, especially when almost 2/3 of our CIO's report to the CFO. Now is the COBIT or VALIT or ITIL guidance on Financial Management perscriptive, no, but they are good start and can assist you in developing a good discipline.

Robert E Stroud CGEIT
VP Service Management
Service Management & Governance Evangelist
CA, Inc

Submitted by ianclayton on Wed, 2009-07-01 01:39.

The old 'implementing ITIL' fallacy...?

Rob

Do you mean that all these frameworks are but 'bit players' in a higher service management framework? If so then I could not agree more. As ITIL v3 itself says:

"Frameworks like standards invariably form part of larger complex business systems and as such relating them to each other rigorously requires a systems discipline. Without this you are left with a few cross-references, some guidance notes, and a lot of “tacit knowledge” gluing them together.
Paul McNeillis, head of professional services at the British Standards Institution".

For years we have tried to explain to folks that ITIL is not implementable (stand alone) from a systems or project perspective and anyone starting with just ITIL and especially the CMDB is destined to be the wrong side of an ROI conversation from the get go.

So where is the overall service management 'top to the jigsaw box' framework - a holistic approach to managing services as part of an overall system that includes all the above? Its as yet to be defined in ITIL. COBIT is also lacking such a specification. With the economy threatening all service management initiatives to 'put up or shut up' with respect to real benefits delivered within 30/60/90 days, its time folks realized we need three key leading elements:

1. A service management system definition
2. A service provider organization specification detailing the MINIMUM vital roles to enable an support the system
3. A transformation method that allows all sized organizations to evolve from managing infrastructure to managing customer satisfaction

As for COBIT/VALIT or ITIL guidance on Financial Management - why do we not use what the business enterprise has used for years an continues to use....... why is IT trying to invent an alternate?

Submitted by Cary King on Wed, 2009-07-01 15:04.

Why not use what financial aspects the enterprise uses

Most companies apply only high-level basic standard costing to IT for use of the external financial reporting and basic organizational budgeting. This does not support discrete budgeting and costing of the many services within IT. And, this approach is a root cause of the continued perception of lack of alignment because the business does not have visibility to the costs of services.

No one cost system gives managers all the information they need to promote operational efficiency and produce the highest quality product at the lowest cost. Cost systems must serve three functions--inventory valuation, operational control, and product, in this case service product, cost measurement.

Using Activity-Based Management for products or service products is in no way unique. ABM has been used by many organizations, including government organizations like the USMC, for more than 20 years. The advantage of Time-Driven Activity-Based Costing is that it is easier to implement than regular ABC and can be easily implemented when IT captures time expended by operational work orders. TDABC works particularly well with helping to identify costs within a process so that TQM process improvement efforts such as Lean can be more focused.

Activity-Based Budgeting of discrete services allows for a budget conversation between IT and the business that cannot be achieved in any other way - including Portfolio Management. ABB for services is key to "running IT like a business" because it allows "customers" to "buy" services based upon well-defined costs that are clear to the "customer." And, it allows IT to run each particular service in a way that is conducive to long-run cost effectiveness.

Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com

Submitted by JamesFinister on Sun, 2009-06-28 19:08.

Commitment to a concept

Skeptic has hit on something in saying it is the consultants who get upset not the vendors.The vendors sell what the market asks for, whilst the consultants direct the market. it is the consultants who fifteen or so years ago said "You need a CMDB to leverage the other processes" and more recently have been promoting the value of the service catalogue. It is very very hard to say you were wrong.

15 years ago we promoted CMDB because theoretically it seemed the right answer. 10 years ago the doubts were creeping in. 5 years ago I frankly no longer believed my own statements from 15 years ago because the evidence contradicted it. Today....

.... I like to talk about blended solutions. We can make bits of the ITIL CMDB work for different stakeholders. I hope we are no longer like one client ten years ago who had no idea where 40% of their PCs were. Auto discovery can do great stuff in collecting "as is data" and architects have access to good conceptual models. We have service based models that may or may not be 90% hype. On the other hand for all encompassing CMDB seems as far removed from reality as ever. We don't have a single CMDB, but with some digging and a few mash ups we can achieve the same result.

Ten years ago I would have liked a CMDB which could have said:

" Server Xena is down. That will impact 200 users of the accounts payable service and increase workload for the other email servers. We installed a change to the OS Xena runs on Thursday, and that might be what is responsible for the incident"

Are we any closerto that?

Submitted by Visitor (not verified) on Fri, 2009-06-26 17:27.

CMDB - Why The Failure Rate Is So High

This is beacuse organizations focus on "implementing a CMDB" versus identifying the information they are trying to track, the value of that information and using it to solve specific business problems. The few companies that have focused on outcomes versus over emphasis on getting a tool/database in place have seen, in some cases, significant benefit and hard dollar returns. These were achieved because of the information obtained, not because a tool was installed.

Submitted by Pearson (not verified) on Wed, 2009-07-01 14:59.

CMDB ROI

I have found that determining ROI on a CMDB "implementation" is extreemly difficult, in fact it's preciscely the fact that the organisation dosen't fully understand its services, what they cost and what they make that has usually led them to the vendor discussion in the first place: "what you need is a CMDB!".

I would venture that spending $4m in Capex on a tool/porfessional service contract is easier for most organisations than renting $3M of contractors to really do the grunt work of working out what it is we are supporting in IT, how does it all work togeather, how much it costs, who uses it and how much money is it making...Then we can decide how we should store and use this data. I think a CMS is a good basis for the use of this data (as are others i'm sure) but without real information and a use for it why bother?

Submitted by JamesFinister on Fri, 2009-06-26 19:14.

Good design approach

That comment could in fact apply to the whole of ITIL. Scott Standen at the ECB, who recently won the itSMF project of the Year Award* coined the goonesque expression "Walking backwards to ITIL/ISO" to describe the approach that ISO certification wasn't the endpoint, but just an enabler of doing the things that mattered better. Your approach to accreditation should be driven by what you want to get out of it, not just getting a nice piece of paper.

* I would say they had the benefit of advice from a brilliant service management architect, but modesty forbids.

Submitted by skeptic on Fri, 2009-06-26 20:15.

improving configuration process not tools

...or nearly forbids :)

You guys have hit on my central theme about CMDB now: it is about improving configuration process not tools.

Right now we produce impact reports manually. the first step should be to do those better: a configuration process owner; a dedicated team of two or more who do impact reports; a documented managed improved process for doing it; OLAs for report delivery; specialised tools to help them where they need it. In other words standard ITIL aprroach. ONCE we have a team, once we have a process, once we have rehearsed and optimised, only then might we identify that a CMDB is the only way to fulfill the identified requirements of the OLA. I bet 95% of the time we don't.

We don't start with capacity tools or availability tools or incident tools or problem tools. Why the hell do we start our thinking with configuration tools?

"Walking backwards to CMDB" as it were

Submitted by Alex Honor (not verified) on Mon, 2009-06-29 15:38.

improving configuration process not tools

Yah, it does of course begin by establishing/improving the configuration process. Talking about tools (or how to automate) before understanding the process is definitely the wrong way around.

Submitted by JamesFinister on Fri, 2009-06-26 21:47.

Credit

Well let's be honest, much reviled as consultants are we never get given the credit when we really make a difference, in return for our mistakes being hushed up, not least because every consultancy contract is surrounded by non disclosure clauses. My tame lawyer points out that as an individual there is a big difference between the multiple times I've signed the Official Secrets Act which could still me serving a long jail term and contracts that my ex employers signed up to which are no longer binding on me.

There are a lot of excellent lessons to be learnt from the ECB ITIL implemenation, and I believe they will be speaking at various itSMF conferences. Go along and hear them if you get a chance.

I would argue first step is to stop doing impact assessments based on the CIs impacted, and instead to focus on the impact on services. That thinking then drives decisions about the granularity of the CMDB. My belief is people make it too granular too soon. If you don't know what the persistent, technology agnostic, services are that you deliver to your business then there is no point going down the CMDB route.

James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/

Submitted by pjotrg on Wed, 2009-07-01 14:38.

Let's go even further

I would prefer to go beyond the service levels and look at the business processes themselves.

In larg steps: business processes are supported by services and services are build upon our famous CI's. What the business asks us to enable them to execute the business processes. So we in our turn should garantee them the seemless functioning of their business processes, that is: the part that we can influence.

So why don't we stop speaking about SLA, and start speaking of BLA (Business Level Agreement of the like) instead. In that case the business process will be recorded in our systems (with it's priorities etc). Our high level CMDB connects Business processes with servces and the services with big "building blocks" of infrastructure (HW+SW etc). If we monitor the "big building blocks" we can detect where and how a service and thus the pertaining business processes are impacted. From that moment the "techies" can start researching and remediating the defective elements.