The CMDB Tidal Wave? More of a ripple.
Dodgy stats and talk-up-the-market hype mar two otherwise interesting articles on CMDB.
Here are two good articles worth reading on CIO Update from Dennis Drogseth of EMA: Why IT Management is at a Tipping Point and Riding the CMDB Tidal Wave, Part One: Understanding. I've not always been kind to Dennis, but I generally agree with him here and found some new ideas in the articles.
Only one bit made the skeptical radar bleep loudly, a typical piece of analyst's talking-up-the-market: the "CMDB Tidal Wave". The stats are dodgy:
Our data shows that about 30% of our respondents were not interested in CMDBs, and the other 70% divided almost equally between those who had specific plans or deployments in place and those who had interest but no specific plans.
This year’s research has targeted actual adopters and we see a parallel ratio where about 50% are in active planning and 50% are in deployment. Most are in relatively early stages with about 15% showing two-to-three year deployments.
Given the fact that just four years ago the acronym CMDB would have been affiliated only with ITIL with far fewer than 10% in planning or deployment, I would say what we’re seeing is indeed a tidal wave.
Sounds good eh? Now be a critical reader and take that apart. Last time EMA surveyed a wide audience and found 1 in 3 interested and 1 in 3 planning or doing. This time they surveyed only those actually doing. So don't make any comparison between the two sets of numbers.
Of that unknown proportion of the total population who were selected for the latest survey based on the fact that they have actually adopted CMDB, only half had actually got around to doing anything and only 15% (of the total adopters or of the 50% who have roused themselves to action??) have multi-year deployments under their belts.
Last year 33% were planning-or-doing. We don't know how many this year - let's say there is a big wave and we'll guess as much as 50%. So somewhere between 3% and 8% of the industry have "done" CMDB (3% = 15% x 50% x 50%, 8% = 15% x 50%) and 25% (25% = 50% x 50%) are doing (something). Not bad, but a Tidal Wave?
Planning-and-doing has gone from 10% to 33% in four years. An increase indeed, and the term "CMDB" is indeed the leading keyword and search word at the moment, but a Tidal Wave?
"Definitely observable ripples" I would have said. And one wonders how many of those ripples of interest are caused by people (analysts and vendors) calling CMDB things like a tidal wave.
All this ignores the fact that most vendors' and analysts' "research" is methodologically suspect. One wonders how many people "doing" CMDB are in fact putting in an asset database, or license management, or some other user-defined version of CMDB. Or how many are there where "doing" means Fred has been told to come up with something in his spare time with no budget. Or where "doing" means we bought a tool that says CMDB on the brochure but we haven't got past implementing network alerting or incident tickets yet.
The idea of CMDB is making quite a splash but I still don't see too many people swept away.
Made in New Zealand 
Comments
CMDB in the real world
Who knows the truth about CMDB implementations? I'm skeptical about analysts figures (as I believe IT people are less than truthful when questioned about about project success), but what else do we have to go on?
I attended a conference a few days ago where I saw a competitor ( yep i'm a vendor) stand up and preach the latest buzz words about CMDB federation/reconcilation/yawn. Last year it would have been lapped up as the voice of innovation from a market leader. This year the audience bombarded the luckless presenter with good reasons why his concept was flawed (maybe they read itskeptic!) and he left the stage in shame. Poor guy was just presenting the company line.
The point is that people have started to look in more detail as they are actually wanting the benefits promised by the CMDB concept. From our own perspective business is booming as we are spending less time educating and more time implementing solutions. Every "solution" involves a bit of our software and integration with existing service desks, monitoring tools etc. The real world is buying integration, not monolithic all-in-one packages. I wonder how the analysts report that?
It takes a marketing industry to describe a rivulet of real work as a tidal wave - whats new?
DC
Good question regarding how
Good question regarding how many CMDB projects are successful. I hear many organisations claim their implementation was a complete success at events but a few follow-up questions shows they haven't really implemented a CMDB at all but a stand alone inventory database. Let’s face it how many organisations will stand up at an event and admit they wasted loads of cash on a database that doesn’t do anything. We hear so many CMDB projects fail from the analysts but where are all these people??
I too work for a vendor who has a product that fits with this market (not a CMDB solution). As a result I work with projects that interface with many CMDB projects and many deliver way below what I would expect from a CMDB. Unfortunately the vendors providing the CMDB go along with a half cocked plan, as it is a sale. They don’t seem to see in the long term they could be killing their own market.
I do believe in the CMDB as I have seen it work. Several years ago in a former role I implemented a CMDB, it was developed in house as no alternative existed at the time. Most initial benefits were near impossible to measure as it impossible to measure anything in the before (unrecorded) state. But ongoing benefits were easier to measure, Project managers seen the value in removing the need to audit and maintain lists within the project. Management loved the significant one off HW support savings by centralising multiple lists, but any central inventory system could have done that. For me the real value was to service managers who seen the related change process improve which in turn improved their service stability.
I worry the current hype isn’t getting backed up with real success and the whole CMDB concept will loose credibility. Some vendor “out of the box” CMDBs today are quite good but vendors need to show leadership and recommend how to deploy. Simple stuff like, who will own and support this thing when the project ends? How will you verify and audit your data? How will you measure success? How do you expect a standalone CMDB to deliver any value?
The legal side of CMDB
Consider:
1. A company with no HR system of record, named in a wrongful dismissal or compensation dispute in civil litigation.
2. A company with no general ledger, accused of fraud.
I don't think anyone would want to be in such a position, in litigation with no defensible records proving one's position.
Lawyers are smart. Litigation revolving around transactional systems of all kinds is a reality, and practicing litigators I have talked to predict it will only increase - just too much money to be made there. The recent changes to the Federal Rules of Civil Procedure in the United States require opposing counsel in civil litigation to appear at the initial "meet and confer" session prepared to disclose an inventory of all the evidence (paper and electronic) that might be discoverable. If the suit involves IT systems, that means detailed records of their data, its format, location, retention and backup protocols, provenance, supporting ICT specifics, and so forth.
I discussed the matter recently with a consulting expert in the field. A snippet:
Me: "I predict that within ten years not knowing what applications are running on your servers, and where they are, will be construed as professional malpractice or negligence in IT litigation."
Legal IT expert: "You couldn't be more wrong... It's going to happen much quicker than that."
See here and http://edrm.net/. Caveat: 85% of today's discussion around e-discovery revolves around unstructured data and email. The data center is still peripheral.
But not for long, I fear.
Charles T. Betz
http://www.erp4it.com
No dispute with any of that,
No dispute with any of that, but nothing there says it has to be stored in one place, interrelated. So what do legal requirements have to do with CMDB? You can have any number of effective IT information systems and not have a CMDB. Sorry but this strikes me as classic FUD.
Fear, but little uncertainty
Fear, but little uncertainty or doubt. This is merely a report from the front lines, what I am hearing from not only consultants and vendors but fellow practitioners and peer capability owners at comparable large institutions.
Questions:
What do you mean by "interrelated"? If the servers are not related to the applications (and the applications in turn to their business unit consumers) it would be difficult to disclose potentially discoverable data, because litigation starts with the business unit and drills down from there. A list of servers, independent of the list of applications, independent of the list of business units, would seem to be of little value. Dependency management is the Achilles' heel.
Secondly, what are the "effective IT information systems.[yet]..not...a CMDB" that would house this data? I'm very curious if I have somehow missed a major class of ITSM product offerings from the vendors.
Anyone following my work knows that I have been also been a critic of the monolithic CMDB concept, and one of the first authors to propose an integrated picture of distributed ITSM system architecture. What concerns me is speaking at conference after conference, polling room after room, and hearing that most IT organizations have no idea what is running on a given server, in the general case. That is simply not going to be acceptable in years to come. And if the availability, capacity, and security drivers aren't yet sufficient, perhaps the legal pressure will be the tipping point.
Charles T. Betz
http://www.erp4it.com
don't know what is where in service terms
I know you are right Charles that many orgs don't know what is where in service terms. I think they'do if they ask the right people - the info is held inforally ad-hoc. in a legal situation the right people would run the right queries and report and find out. I just don't see legal threat as a good driver for CMDB.
Maybe you are unaware of the class of tools known as systems management :-D these all allow users to map managed objects to services, nd hence store that info quite nicely.
It's not that simple
Skep,
My experience has shown that time and time again, even the people that *thought* they knew where something was and how it was configured really did not. Their procedures for ensuring that their records (intentionally vague about how/where such records would live) were proprely maintained are either non-functional or ineffective. Only by getting all of the reps of the different functional areas in the room does the truth start to come out. Indeed, the value of such a session isn't the diagram and inventory at the end -- it's getting people to communicate with one another (at least that's my opinion on the matter). Automated tools can help matters, but are no nirvana and such help is not guaranteed. I can recall several high profile clients (without much effort) who have lots of shelfware. Nothing integrated with how their people work or what their organziation needs.
kengon
human CMDBs
I agree there is not an automated solution, and OK maybe the legal threat will cost justify the investment but I would want to see the business case in each instance because this IS a big investment.
The way ITIL speaks as if this (CMDB or CMS) is a de facto essential for every site is I believe incorrect. Configuration process: yes, "human CMDBs"responsible for knowing: yes, technology: it depends.
CMDB Required...
I am in violent agreement with you on this. The need for a CMDB is not a universal one. If this were translated on to Maslow's hierarchy, having a CMDB would be more along the line of self-actualization, than it would be safety/physiology.
An integrated business case
Skep,
The legal angle could never back an entire business case. It's hard for any one of the functions or processes dependent on CMDB data to make that case. The only way I've seen it succeed is when several process owners or functional areas recognize that they all can utilize the same shared data store, and commit to this. The numbers become much more favorable then, especially when the costs of the alternatives (silo'd data, redundant databases, and redundant re-surveying) are also factored in.
Enabling this requires not only process architecture, but also careful data architecture, a topic poorly addressed in most CMDB commentary.
Charles T. Betz
http://www.erp4it.com
data models for CMDB
Totally agree about the data architecture Charles. Seen it done well, but not often. I do think it just compounds the complexity and effort of CMDB though. If CMDB is so ^#&^$# important then OGC should have done a standard data model as part of the core. We can dream of seeing one in the complementary guidance.
As I understand it the CMDB Federation have done a data interchange model but not a data model. They ought to come up with a standard one too, but the vendors will never agree because of the amount of re-engineering they'd have to do.
Which finally leaves us with the proprietary models within vendor products. I'm inclined to think we should use a vendor model instead of developing one from scratch. there's the old 80/20 thing happening - it may not be perfect but if it is good enough it looks cheap compared to designing one
thoughts?
The trouble with ad hoc in the US
In the U.S., the trouble with ad-hoc is that it might be too time consuming and error prone given the new FRCP requirements for timely and accurate disclosure of discoverable assets. If an "ad-hoc" effort can be shown to be incomplete (Bill wasn't there when the call came, and so 5 servers with potentially discoverable data were missed), the disclosing company may incur severe court penalties. And when senior legal staff are asking "what is the consequence of the FRCP" the response that "we'll figure it out ad-hoc" inspires no confidence whatsoever. Lawyers are smart, challenging, and don't take things for granted; they start to ask "why on earth don't we have such seemingly important and basic information readily available? Human resource and financial data is no picnic to maintain, either..."
And, as you well know :-), those "systems management" tools themselves are backended by CMDBS... requiring the same level of diligence & investment to create those service maps. It would be curious to say that "CMDB isn't possible, but comprehensive BSM mapping is..." - is that your view? Of course, we only want those dependencies created once; what is utterly unacceptable is a BSM team re-creating dependencies if they are in a separate CMDB; or vice versa. That sort of question is where architects and process analysis actually *can* add value.
The legal angle won't drive anything by itself. Just another interesting piece to the puzzle. Possibly necessary; certainly not sufficient. As we all know, looking for single explanations is a delusion, pace Rosenzweig.
And yes, I should probably stop using the term CMDB since even ITIL abandoned it. It's an integrated CMS.
Charles T. Betz
http://www.erp4it.com
The legal angle is
The legal angle is interesting and a few high profile cases will help quantify the cost of poor service management. But even from a competence perspective it amazes me that IT heads will try and deliver a service blind. Only a fool would takeout a wall in their house without knowing if it is load bearing - in IT changes like this are common. When the bad change takes the service out there is an investigation perhaps some sort of root cause elimination fudge and after some time it all happens again.
The reason CMDBs fail isn't so much because of the technology it is because the required process and discipline doesn't exist to fill it with meaningful data. ADM is a no brainier but it just isn't a sexy as "managing" disasters.
Succeeding with ADM
By ADM I assume you mean application dependency mapping.
In my experience it can succeed if you surface enough of the hidden demand. Beyond Change and Incident/Problem, many supporting IT functions need the basic dependency information: availability, security, IT finance, capacity, continuity planning, architecture, etc (and now legal). The trouble is that these areas too often take a silo approach to harvesting the data, typically through inefficient surveys.
When normalized dependency data is assembled and managed for quality, there is in my experience great demand for it, to the point where the business case for doing it becomes obvious even at the most senior levels.
Now, getting effective and efficient processes for doing so in the general case is where I think the industry as a whole is still lacking maturity. Not an easy question at the practical level, once you get beyond ITIL dogma like "The Change Process should update the CMDB." Rather easier said than done. There may be a need to go through a Deming-like maturation, in which CMDB QA teams are used in a brute force approach to ensure effectiveness, with continuous improvement to embed the dependency capture inherently in the processes in order to get rid of the QA team over time.
Charles T. Betz
http://www.erp4it.com