CMDB and CMS – the industry-created myth

It is pernicious the way the vendors and analysts talk as if CMDB is a given. In fact it is more than a given, it is “the heart and soul of service management” apparently, according to an email about an itSMF Brighttalk. No it isn’t. 95% of sites don’t have a CMDB. Perhaps that explains why service management is so heartless and soulless. And now it is happening with CMS - which by the way doesn't exist. [Updated January 2010]

We only have a need for CMDB because ITIL V2 and the industry around it created a need by banging on about it ad nauseum. It is a nice-to-have geek toy. Almost all the world does without it.

Warning; the term has been debased as always – in fact worse than most. “CMDB” gets slapped on anything that can see anything. So now everybody has something called a CMDB even though it isn't, just like we all have “knowledge management”.

And you know what? It is happening again: the vendor industry (and their parasitic analysts) are creating a new myth: the CMS.

There are just enough attempts at CMDB around the world for the horror stories to start flowing in of wasted money and unrealized expectations. Ah, but CMDB is so last century. Your problem is you need a CMS instead – a federation of CMDBs.

There is one problem with this vendor pitch: there is no such thing as a CMS. I will review the book The CMDB Imperative one of these days, if I ever finish it. It is a good book, for those who have drunk the CMDB KoolAid. Let me share one quote from it for you now. This book is widely referenced as the authorative book on CMDB. Glenn O’Donnell and Carlos Casanova are experts on the subject (and great guys too – I hate to disagree with them over anything). So when they say there is no such thing as a CMS, you should listen. And they do say it. I quote from the book, p189

…federation will be adopted slowly by most vendors… There is no such thing as out-of-the-box integration, at least not yet. This is sometimes even the case across a single vendor’s toolset… No vendor is yet able to deliver the CMS you need” (copyright 2009)

I bet if someone had written a book like this when ITIL V2 came out they would have been saying the same thing about CMDB – it didn’t exist. The industry has spent a decade convincing us we all need a CMDB and the software vendors developed to meet the created demand. Except the reality is showing CMDB is NOT essential and does NOT deliver enough value to compete for funds. Hardly anyone has one - a real one. So now the industry needs a new product drum to bang. Enter CMS.

(As an aside; I thought ITIL was supposed to be documenting generally accepted or good or proven or best practice. Not floating some untested technical wet dream).

We only got hammered with CMDB because service desk tools were becoming a commodity. The industry is incapable of selling real value through services. They have to have a technology product to wedge the customer’s door open. It is all about selling boxes.

So don’t fall for all this endless crap about CMDB and CMS. It is just an industry-created fad to generate easy revenue by selling you something instead of actually helping you do something useful.

And don’t you go along with it. Stop trying to buy a boxed answer to your people problems. Culture and behaviour change takes effort: new tools don’t fix process and new processes don’t fix people. Changing or improving anything in IT is about changing people. Not some quick fix like CMDB or CMS from the snake oil salesmen.

[Updated:]
A new book on the market is Service Management For Dummies (it's in the queue for me to review, behind two others. Sorry can't seem to get time), written by Judith Hurwitz, Robin Bloor, Marcia Kaufman and Fern Halper, some familiar names in the ITSM world.

I refer readers to page 98, 99, 104 and 105:

It would be much better if all [service management ] applications used the same data standards and shared a database that was the single source of of the truth. that idea is a nice one but it belongs in Cloud Cuckoo Land....The only viable solution is a federated one... With the current state of technology [2009] you can't buy any product that constitutes service management integration infrastructure in a box... service management will be better automated and better served when the sharing of service management data can be automated reliably.
...no service management application specifically gathers a comprehensive set of information about all data files...
The processes involved in populating and maintaining a CMDB...to make a comprehensive accurate set of data available to all ...service management applications...and to staff members. With the current state of technology, this process isn't well automated so you can expect to see significant improvements as time passes.

So what is it that the vendors are clamouring to sell us now?

Comments

I like the concept of CMS

It's clear from the comments here that my thinking is off from the groups'.

Since we're all very aware that very few organizations have even the start of a complete CMDB, I never took it as real the CMS as a currently feasible idea - rather I took CMS as a concept.

I've not yet seen a feasibility study that demonstrates that the cost of a fully federated CMS has a payoff. I've always just thought of it as a vendor sales concept that leaked in to ITIL from the dominant vendors that wrote it.

As a concept, CMS seems to work. CMS supports the ideals of Enterprise Architecture. It helps customers to focus on the idea of data from one process supporting other processes.

We use it as a means of reminding customers to gather all the appropriate data to support the other processes when they have a single opportunity. And, to make that data available for others.

For a small example, we recommend that customers gather all the data about a CI - manuals, specs, etc. - when they put the model of that CI in the catalog of CIs that are approved by Enterprise Technology Architecture, available for purchase through the controlled asset management lifecycle. In that way those documents become stored and available for everyones' use. This is a small thing. But, the concept of CMS is useful to help the various silos give consideration to the other silos. Of what other use is the concept?

Cary King
Minerva Enterprises
CEO - Managing Partner
www.MinervaE.com

A Bad Thing

I like the concept too.

The point of my post is that vendors ares selling it as a concrete deliverable that everyone needs, with proven ROI case studies, and they are doing that leveraged off ITIL. That's a bad thing no?

The good old bad old days

Let us not forget that back in v1 days the CMDB could be a reality, at least in the mainframe world. What was not real world was the ability to track every incident, change and cost back to a specific CI.

I'm afraid there was one unfortunate incident where the CMDB was drawn up on a giant whiteboard that a careless IT auditor leant against and walked off with a key part of the diagram transferred on to his shirt. No names, no pack drill.

We know as well that other industries do, and must, maintain something analogous to at least a CMDB if not a CMS. I do not believe the barriers are technological, I believe it is about trying to implement a CMS or CMDB without any reference to context or purpose. We probably cannot realistically implement and manage a database to meet all requirements, but we can, and must implement and manage one that meets the critical requirements.

Who?

James

Was it you, the auditor I mean ;-)

Aale

Mea culpa

It took ages to get the ink out of my shirt. I also had to stand there so they could copy what they could recover from it, which of course was in reverse.

Being a good auditor I lambasted them for not having a back up copy of it on paper at the DR site.

It was a very very long time ago.

James

best platform

We must implement and manage processes and tools to have access to the critical data. That does not necessarily imply a database. Configuration is not solved by technology.

on the other hand I must disagree: many of the barriers to the tech database dream are indeed technological.

The whiteboard is of course the platform on which CMDB and CMS run best.

Hmmmmm

Rob, I would disagree with your comment about whiteboards.

I have seen some amazing CMSs in powerpoint.

Truly seamless integration.

Alex

Old fashioned

Rob,

Configuration isn't solved by technology, but technology can be an enabler or a barrier.

We often forget the role of architectural design - we can purposefully make a configuration easy to manage, at multiple levels.

The issues that make configuration management difficult across technologies and suppliers make the management of other processes difficult as well.

For me my big concern is not fixing the issues with configuration management, it is that having fixed those issue we will still have other critical issues to contend with, and we kid ourselves if a CMS, or a service catalog, is going to solve those other issues.

Back To Basics...

Skep,

I like this thread, as I think it's covered a lot of important ground. However, I still think we can go back even farther. How about to the beginning? Addressing the requirements. I recently gave a presentation on BrightTALK entitled "What Questions Should Your CMDB Answer For You?".

I will not even attempt to summarize almost an hour of slides in two sentences, but I think the whole CMDB conversation has de-evolved over time and it warrants our revisiting what we're out to accomplish. I believe that if you're not clear about the questions you're trying to find answers to, then the value of any CMDB/CMS initiative is sufficiently questionable to warrant deferring until the economy recovers and you have "money to burn".

Until that time, organizations can focus on gaining clarity about and designing/implementing relevant structures to get what they really need. BTW, it doesn't need to be complicated, expensive or packaged as a "product".

kengon

Configuration Management Function

Great point Ken (we missed you)

The only thing I'd change is to ask "What Questions Should Your Configuration Management Function Answer For You?"

(yes it's a function: staff, policy, procedures, tools, metrics...)

The function comes first. Once it has - as you point out - a reason for existence, then a later step is to work out if we need tools and if so what.

If we start with a process activity and get people doing it and we measure it then we will find the points in the process activity where it is not efficient or effective enough (they are too slow to produce the required outputs; they make errors; it requires too many people to manage the data...) and THEN we work out what tools we want, with very specific requirements specified already. that might even mean a CMDB occasionally

What's in a name...

The only thing I'd change is to ask "What Questions Should Your Configuration Management Function Answer For You?"

OK. I can accept that.
The primary reason I went with that title is that it was a "CMDB Summit"
Tried to stay within the lanes for the title and then push the edges with the content! :-)

Good to be back...

kengon

CMDB

I just have to comment on the blog on the CMDB which to my mind is absolute nonsense.

I am the Process and Quality manager with KMD A/S, a Danish IT service provider with ISO 20000 certification .

We have a CMDB based on the ITSM tool called Wendia POB. This CMDB contains 80.000 + CI's and it is absolutely indespensable for our work and our customer care. It supports us with tool support on Incident, Problem, Change, Release and Configuration processes.

Just to mention one function: Based on parent/child relations it is a standard function to press the IMpact button to discover the servoces in which a single CI ts part - very useful for shared CI's.

Thomas Falk Mogensen

sportscar

So you have a McLaren F1 sportscar. in terms of business return on investment and optimal use of organisational resources, what do the cool features have to do with it?

There is only one process that i am aware of that makes use of a CMDB's distinguishing feature - service relationships - and that is the one you mention: impact assessment. Every single other process from Incident, Problem, Change, Release and Configuration processes requires only asset management: a bucket of CIs.

if your trained skilled configuration management people can use reporting tools and a telephone to determine the impact of an incident or change within a useful time period then a CMDB is a redundant waste of money. if they can't after procedure optimisation and practice, you need to consider one. Do the costs of delays in reporting the impact outweigh the TCO of a CMDB? Then it is starting to look like you might have a business case.

CMDB is the last resort not the starting point for configuration management.

Apparently facts aren't universal.

re: There is only one process that i am aware of that makes use of a CMDB's distinguishing feature - service relationships - and that is the one you mention: impact assessment. Every single other process from Incident, Problem, Change, Release and Configuration processes requires only asset management: a bucket of CIs.

How about: Availability, Capacity, Continuity, SLM, Change, Incident, Problem, Event, Request Fulfillment... for openers. Toss in the Service Desk and...

Impact assessment, as Charles noted, isn't a process. it could be a service and / or an activity.

Regarding the "Facts"

CMS Out-of-the-box I agree. Not using... I'll accept the "fact" based on your experience. I cannot make the same statement since I've seen too many organizations that have a CMS (built internally to meet their needs and bear little resemblance to each other except that they're all built on top of a RDBMS.

Most organizations aren't attempting anything close to ITSM, so for them, I suspect the asset database you mention is sufficient. For the ones that are... different story. They did it and maintain it because there is a ROI.

As Carlos noted, vendors cherry pick the ITIL glossary and... We could talk about the ITIL Software Scheme (don't know that last word has a different meaning for me, but I digress ;-)) but I'm on record as thinking it's a process that needs improvement (lots of it). However, that doesn't change the "fact" that there are organizations with functioning CMS. Pervasive as Microsoft Office? No way. Exist? Definitely!

David

amazed

As the quote I used from the CMDB Imperative indicates, when i say CMS doesn't exist I mean as a product you can buy. Every concept on earth "exists" if you are willing to build it yourself and you have enough money. of course if I think the business case for CMDB seldom stacks up imagine what i think of the business case for home-made infrastructure software that involves immensely complex integration and reconciliation across many touch points.

I'm also amazed and impressed that organisations are actually achieving such federation to create virtual service views across multiple CMDBs. it is a technical feat that must have involved near-absurd investments for a single site.

Then we agree :-)

I agree, there isn't an out-of-the-box (OOTB) CMS exactly as described in ITIL or the CMDB Imperative. There could be, if some developer would build the infrastructure to support one and provide a rules engine on top to populate and maintain.

The problem with crafting an OOTB solution is that of the implementations I've seen, the only thing they have in common is the technology starting point (RDBMS) and the outcomes. None of the logic, user interfaces, depth/types of things classified as configuration items, etc., were consistent from 1 to the other.

In every case the crafted CMS provided tremendous ROI because it enabled a consistent approach to service management (from strategy to operation with much better capability to improve). In several cases the organizations started with 3rd party tool while they crafted their own.

No it wasn't a technical tour de force, nor was it as expensive as you've suggested. In most cases, break-even point for the total ITSM effort (including the CMS) was 15 to 18 months (on average -- shortest 11, longest 24).

The 3rd party tools exist, the problem is that they're not nearly as robust, complete or flexible as a "real" CMS is supposed to be. So, in that sense I agree with Carlos, Glenn and you. However, while I appreciate the quotation, the existing tools might be sufficient for some.

David

case studies

I'd dearly love to see some case studies and put the ROI to some scrutiny. I might even be convinced :)

But I doubt it.

ROI compared to what? Chaotic untrained manual impact analysis?

How many staff does the CMS require and could those staff perfoem exactly the same high-value functions manually for a fraction of the cost?

How much of that ROI is in fact from asset management not configuration?

Does the TCO take into account the ongoing maintenance to change the code every time one of the touched systems impacts it? of the core developer resigning?

etc etc

Multiple sources for ROI on top of CMS

ROI compared to the baseline costs in the organization including...

-- Better mapping of demand which lead to optimized spend on capacity.

-- Much easier to determine (and keep current) information needed to optimize spend on availability.

-- Reduced number of change-related incidents because relationships between "this" change and existing CIs / services was visible throughout the change (or new development) lifecycle.

The company has over 100,000 employees, millions of configuration items, and thousands of services! They were spending $100 million annually on an outsourcing contract to have a 3rd party keep track assets, etc. They now spend less than $7 million on this area and it's no longer outsourced. You do the math.

Yes, all costs are included. I can't discuss the "core developer" issue because of NDA. The only thing I can say is that it's not a problem.

David

Even in the USA

that's not exactly your typical organisation :) Even in the USA that's big. I'm talking about the other 95% of the planet

ROI depends on pain points

Even an organization less than a quarter of that size derives benefit.

Currently working with a company with maybe 2,000 employees world wide (actually probably closer to 1,000 with about half in the US), with world wide sales in the 400 to 500 million range. They can already see that if a CMS did nothing more than allow them to reduce change-related incidents by tracking and storing CI / Service relationship information, that by itself would be sufficient to justify costs.

I understand your role as the IT Skeptic. One of the things it might be hard to accept (for all of us with strong views :-)) is that sometimes things actually work, even if we have a predisposition against it.

David

I've never said a CMDB

I've never said a CMDB doesn't work

i do think there are hidden costs

I do think it is a seductively technical solution to a non-technical problem - getting people to write things down and to check

I do think the non-techncial solution works OK often enough

i do think the concept is massively oversold by ITIL, by vendors, by analysts and by consultants

i do think it is not a foregone conclusion that every site needs a CMDB

If you take a loose interpretation of a CMS/CMDB as what Carlos calls a wireframe description of just some core critical relationships and you manually store that in something simple, then I could even become a fan of it :) I always did promote recording the top ten services and their top ten dependencies in the service catalogue - or as a business process view when I was selling Unicenter a decade ago.

But I'll only let up once we get that reasonable message out to the masses that an autodiscovering all-encompassing graphically-exploring hundred-thousand-object federated super-duper-geek-tool is not required - or a good economic decision - for most instances.

Simple seems ok, until you consider complexity

Rob,

There is another issue that I don't know if you're considering. Todays system are too complex for simple manual configuration or asset managment. Even small organizations have hundreds of services and thousands or configuration items that have to be tracked. Software testing requires automation, and that's a very small piece of what is ultimately needed to deliver a service.

Complexity, as I'm sure you're aware, is a non-linear function. As little as a 25% increase in functionality can have anywhere between 100% and 800% increase in complexity. That type of relationship takes the evaluative needs out of the realm of things that can be handled only manually.

Change management requires much more information to avoid change related incidents. The CMS contains information about the relationships between services and CIs that are, in many cases, beyond the capabilities of people to manage. I think we agree that the large 100,000 employee organization I mentioned falls into this category. Smaller business I mentioned is in the same category.

We've spent months taking inventory of their existing services and their relationships to each other. The company would have to add a staff of at least 40 to 45 people people to manually track changes and relationships without a CMS. That's a 10% increase in overhead staff just to keep tabs on configuration items. If you figure burdened overhead at 2.5 to 3.5 cost of salary to support each person, and then make that ongoing year after year... and you think that is cheaper than investing in a CMS...

Let's assume $65,000 per year with an overhead average of 3x, that $195,000 per year per person (that includes taxes, benefits, support staff and other indirect costs, infrastructure, etc.) If they hire 42 people for the effort that means $8,190,000 in just salary related costs per year. We don't know the cost of tools and other factors if they make a mistake, etc. So this figure is a baseline starting point for additional unknown costs.

Development of their CMS is estimated at extreme high end to be between $9 and $11 million. Once completed they'll need a staff of 10 people. This means they'll hit break even in less than 18 months. And these are VERY conservative numbers. Development costs are more likely to be in the $7 million range.

Bottom line, while simple sounds good, I'm not sure it works in reality, given the complexity of the systems of the day.

David

a different world

Perhaps I'm being naïve and provincial but $9M seems like a lot for a CMDB. No it seems like a hell of a lot. Just for development!!! WIth an ongoing TCO in excess of $2M p.a.!!! Holy shit!!! You do live in a different world to me.

I'm really not sure that is an example which is representative of the other 95% of the human race

It's not just crafting the CMS

A lot, yes. For a CMDB, even more so. Excessive... depends. Also remember this is a CMS, scalable CMS.

Consder their increased overheard costs (staffing) if they have to do it manually. You don't think that's an issue? You're not OK with spending $9M on the development of an internal tool -- absent that tool means an annual spend (when EVERYTHING is included) of close nearly the same amount? I don't know about you... One time costs of $9M plus on-going costs of $2M versus $9M on-going costs per year...

Consider the risks of NOT having an automated tool? Which approach is more likely to result in consistent up-to-date information about services and configuration items: purely manual, or combination of automation and manual? Not having the tool means increasing annual overhead (purely non-revenue generating staff) at over $8M and that isn't a concern?

It's easy to say it costs too much, until you consider the cost of NOT having it (costs increased because of the complexity of the tasks).

The cost isn't exclusively for software development. Included is also the cost of the analysis to determine the right level of granularity for the CMS, the tools to deal with automated discovery, populating the CMS, testing, etc. Covers cost of underlying enabling tools, burdened labor costs (either in-house or 3rd party), etc. In other words, don't thing the price is just for the programmers and s/w development.

What do you think it costs to develop a CMS (NOT and CMDB) from scratch? And when the it's deployed, what type of functionality will it provide?

David

do NOT represent the real world

You're missing my point. Sites that need 40 people to run their configuration do NOT represent the real world. they are an elite of the world's businesses, must be less than 1%. What about the hundred thousand (guessing) organisations whose total IT staff number 40? What about the millions (still guessing) of organisations that don't have that many staff in total?

MOST organisations MOST of the time get along OK without centralising config data in a central repository at all. Ever. They can deduce impact on the fly from a handful of unlinked repositories: discovered network topology, change database, procurement assets, discovered desktops, monitored servers. Many use the Real ITSM recommended service monitoring device: the telephone.

Most of the rest would benefit by writing down the top ten CIs for each of the top ten services.

the tiny bit left keep consultants employed

distributed maintenance

A more effective paradigm in my experience is to keep the core team small for *any* enterprise IT process (Change, Config, etc) and train the people doing the day to day IT work to do their own data entry.

Compliance issues? You bet. But a careful combination of carrots and sticks, along with data quality reporting and metrics presented to senior management, can work. Of course, strong executive sponsorship is necessary from the get go.

This is where the discipline of usability engineering really kicks in. IT people know bad interfaces when they see them. Don't let amateurs program your CMS.

Charles T. Betz
http://www.erp4it.com

We started there, but...

We started there, but the problem is getting the compliance without the cultural readiness. Part of the reason for the 40 people (about 28 tasked with managing the CIs the rest with building success teams and working on the cultural, compliance, and organizational issues.

The manual plan was to start with the success teams, first, then add the CI people over time.

Instead, they just going with the success team and an automated system. As the CMS gets up and running, part of the success team responsibility will include audting and verification.

Part of what they discovered, is that the complexity of the configuration items and services. The problem is understanding the relationships between the CIs and services as a part of doing a risk analysis for change management. Very often the people doing the development work don't full appreciate the live environment. What they discovered is that even with the 40 pepple they'd eventually get to a point that they have to develop a CMS, anyway. So the issue was... well if that's the case, then why not start there.

David

Interpretation of automated results

Is part of their responsibility to interpret and translate the automated results into business-meaningful services & components? I've seen a need for that on the software discovery side in particular (ongoing fingerprinting). Also when confronted with an impossibly complex dependency map generated by some tool.

Charles T. Betz
http://www.erp4it.com

Simple answer: yes :-)

They're building a Service Catalog on top of the CMS, so yes. Automated discovery, manual relationships.

David

It IS as real world as it gets!!!

You don't like the fact this org needs 40 people. Fine. The point is still valid. They only have 400 to 450 employees in US and that's where they're have to add the staff. 10% staff increase to manually manage CIs and services! How would you justify this staff increase if you had to write the business case?

Complexity makes the task of managing configuration items and services too difficult for all but the smallest organizations that have a handful of items that have to be tracked, managed, controlled, etc.

Most organizations aren't even close to ITSM, they still think it's about the technology. In that environment they deal with resulting requirement for heros, firefighting, and more. I've worked and consulted for too many of these types of shops.

I've also worked and consulted with organizations that get it. There are more of them than you apparently believe exist. Out of the box solutions, no. CMS, yes. In every case the driver was competitiveness.

Don't misunderstand. I'm not suggesting the use of a CMDB or CMS is the norm, it's not. I AM suggesting it's more than the few percent you're suggesting.

David

Only 450

It is a big IT department. How large is the whole company?

But I agree with Rob that it is not from real world. In the world I live, nobody would try to increase IT staff with 10% and expect to survive!

Aale

Company stats

The company has something between 400 & 500 employees in the US (which is also where all of their IT lives) and another 200ish outside of the US.

The problem isn't the size of the company, it's the number of configuration items they need to track (lumping hardware, software, services, and in some cases people with specific certifications like Cisco in what constitutes a configuration item). Lots of hardware and software (in the 7K area, closer to 8.5K if you include licensed software and over 1100 services). It's the complexity of dealing with reasonable change management, catalog management, portfolio management, identifying relationships, making sure everyone has the information needed.

They're not sure that 40 people will be enough. They have to partition the CI space into what they hope will be manageable chunks -- but this is all the business side would authorize. Basically the biz side was shell shocked at the staffing increase. It took a week of meetings with the Executive Management team and another 3 days with the board. It was the inherent risk in the manual solution that helped justify the expense for the CMS.

David

most of the essential impact analysis most of the time

One client I recall had - i think - 300,000 CIs. They had two configuration people, and tracked only the key relationships and only for the top 12 services. They had all the network/hardware (discovered) and some of the apps and databases and not much else. They did it manually, in CA Unicenter NSM. (the world is awash in tools to relate services to CIs, you don't need to build one). It was enough to do most of the essential impact analysis most of the time. 80/20 rule, business expediency rules. That was a pretty big site, tens of thousands of employees.

How often did they make changes

One of the major problems these folks have is change-related incidents. They currently roll a change package every couple of months with too many problems because they don't have full relationship information regarding the changes and existing services. They can't easily identify the services that flow through a particular CI or all of the CIs used end-to-end to support a given service.

I have no idea the nature of the business of your 300K client or how many changes they put into production. I do know these folks have to get to change packages per month to support dynamic nature of their Web-based business.

Which means... it's not the number of employees, nor the number of CIs. It IS the complexity of the way services are used, updated & changed. This means raw numbers are potentially not a measure of anything, the key is understanding relationships and complexity.

David

simply isn't

I'm sure your client made a valid business decision. The point I want to get out to the other 31999 readers is that not everyone needs one. When i see guys from 20-person IT shops asking which CMDB tool is best I cringe because I know the odds are good they have thought about nothing but technology and they don't need one anyway. the initial message of this thread was not that NOBODY should have a CMDB, it was that the "drummers" talk about it as a given, an essential core, and it simply isn't.

Homemade tools not a good idea

The problem is not the building but the maintenace part. It is not a one time project but a continuous effort to keep the system up and running. In a home-made solution, there is only one customer to pay the development. It will not make sense in the long run.

Aale

GoogleWave

Sorry to be out of topic but I was just reading a comment by David on a public GoogleWave when he started editing it under my eyes. Rather strange experience. I commented that and it had the same effect on David. Soon we were writing a comments together. Here is the discussion. (it is cut from context)

Reply
Edit
6:39 pm
David:

I agree totally. If CSI is the starting point for ITSM initiatives, not ITIL specifically. In other words, not only is/should CSI be part, I could argue its part of the starting point -- gap analysis that starts with understanding how IT and Business can identify and work toward common goals.
Reply
Edit
6:39 pm
me:

Wierd seeing you deleting and type text just as I'm reading it.
Reply
Edit
6:41 pm
David (and me):

Yes it is! :-) But it also is an excellent indication of the type of collaboration possible with Wave.

To borrow a phrase from Spock: Interesting! :-) Yes!!
Reply
Edit
6:44 pm
me (and David):

And yes. Improvement should be the real motive.

This is going to be interesting, we're both editing the same message at the same time... :-) Yes. I did not know it was possible. Think about 3 or more people trying to do this... boggles the mind! :-)) Think about all the possible misunderstandings this can lead to. I' mean nobody knows which of us wrote what!
Reply
Edit
6:45 pm
David:

Do they have to? Is the issue the contribution or the end result? If the issue is the result, then collaboration potentially makes the whole, better. If the issue is contribution then, I agree, confusion reigns! :-)
Reply
Edit
6:47 pm
me:

Right. Have think about the possible applications, this could be quite useful.
Reply
Edit
6:47 pm
David:

VERY!

***********
Really agree with David, this type of collaboration could work well.

Aale

Really was / is amazing

Aale,

That type of dynamic collaboration... actually thrilling in its potential!

We got lucky to both be on line at the same time. Amazing instant education in possibilities! THANK YOU!

David

mutliple users can all babble simultaneously

I'm reminded (as so often) of the HitchHikers Guide: " a race so primitive they still think digital watches are pretty neat"

Am I to understand Google Wave is exciting because multiple users can all babble simultaneously? that's it?

Seems to me it is one more channel i won't be spending all day updating. twitter already takes more time than i have to spare.

Invite available if you want it

Rob,

Tagging on to Aale's comment. I have invites available for Google Wave and will be happy to send one your way, if you'll use it.

David

Yes, there is too much noise on Twitter

Rob
I really do not see what is the point of trying to produce X tweets per month.

Twitter can be useful but it is not collaboration. GoogleWave is different and more interactive. Does it work? I don't know yet but it is definitely worth a try so don't be so Skeptic :-)

Aale

Amazing frame of reference

Why does your comment remind me Robert Kennedy's "There are those that look at things the way they are, and ask, 'Why?' I dream of things that never were, and ask 'Why not?'"

What you call babble, I call new possibilities for collaboration, for learning, for discovery, for creativity, and who knows what else.

re: "Twitter takes more time than I have to spare"

I've come to believe that time management is sort of a myth. What's behind time management, what is really important isn't managing time, it's managing priorities.

David

Great conversation

and a major reason why I don't go to ITSM conferences.

Wow...I missed alot...

Great conversation folks. I was away for a few days ( Cub Scout campout with my 9yr old son ) and amazing discussions were had. Sorry I missed them.

Ian/Charles/David/Rob all are making excellent points. The one I wanted to come back to was a few posts up about the extent to which discovery can be used. There is not a tool out there that could possibly detect some collection of software and hardware and know that it was the "XYZ Service". It is just fundamentally impossible because the 'label' that gets slapped on it HAS TO BE man/woman made. As Charles speaks to, you need to establish what I call the 'wire frame' as a staring point of your structure. The wire frame is just the most critical items that outline the service. From there, then you make continuous assessment/improvements depending on the cost effectiveness OR losses you may be incurring. Remember that losses are not always directly monetary. A loss in confidence by your users could grow into the public perception that you are not capable of delivering a service. Eventually, that will have a directly monetary impact but not necessarily early on.

The CMS / CMDB must be tackled slowly and carefully and most importantly, scaled to the necessity of the organization.

Carlos

Manual and automation required

Carlos,

I agree completely.

What is needed is a combination of manual and automation. One the associations are properly mapped, there also needs to be proper audit and verification, etc. That's one of the reasons one client included the complete service portfolio built on top of the CMS. it took lots of work as part of the initial setup, but maintenance of the relationships is MUCH easier. In fact, what they had was SO complex that it was impossible to do manually.

David

just one more notch

Carlos, if you would wind that back just one more notch to be "Start with a manual configuration process/procedures as a starting point of your structure ...then you make continuous assessment/improvements depending on the cost effectiveness OR losses you may be incurring" then you and I would be on precisely the same page :)

Actually I think we already are because I have in the past suggested storing the crudest service<->CI relationships (especially service<->app/system and maybe service<->server in oldfashioned environments) in the technical service catalogue, so i guess that is a basic CMDB anyway

but coming back again (and again...) to my main point: that doesn't mean everyone has to run out and buy a CMDB tool and it doesn't mean a vendor having an integral CMDB tool in their suite is actually that exciting for many of us and it certainly doesn't mean that a specialised CMDB is a foundation or hub or heart or soul or ....

Change & Problem benefit from impact...

"There is only one process that i am aware of that makes use of a CMDB's distinguishing feature - service relationships - and that is the one you mention: impact assessment. Every single other process from Incident, Problem, Change, Release and Configuration processes requires only asset management: a bucket of CIs."

But impact assessment is not a process. It is a service (in the SOA sense). In the data sense it translates to dependency management, which I have blogged about here. The wasteful expense of re-collecting this data is, in my experience, the *real* business case, with hard ROI, for CMDB.

It is invoked, in a mature environment, as a contribution to Change risk assessment, to prioritize Incident resolution, and to ensure downstream impacts to Releases are fully understood and tested. Dependencies are used for Capacity analysis, IT Financial chargebacks, for Security threat assessment...

And none of this is mere theory...

Charles T. Betz
http://www.erp4it.com

Service Impact is a process

I think Service Impact is a process. You input a CI or set of CIs, it performs repeatable defined analytical and verification procedures, and it outputs the impacted services. Sounds like a process to me in the correct use of the term.

If Impact is a process...

All processes have 4 things in common:

Done on behalf of a customer or some consistency.
Produces specific outcome.
Has specific trigger.
Is measurable.

I can see that it might meet 3 of the criteria, what about the last? What are the specific and repeatable metrics regarding Service Impact?

I can see it as an activity within a process; I can see it as a function. As Charles mentions, it some cases it can be automated. Take the simple case of a failed router or switch. With a CMS that provides view of all services that use that CI, it's possible to very quickly identify what services and potential users that are impacted.

Even without the CMS, but with Event Management, an automated impact analysis might begin to emerge.

So, what am I missing?

David

semantically defeated

Alright alright I am semantically defeated :) Function it is then.

Actually I think it is easily measured: accuracy/reliability, and speed of response.

With a failed router or switch isn't it is easy to figure out what services are impacted with a simple network topology? Why do we need a CMS to do that?

Might seem so, but...

Years ago I worked for a cable TV equipment manufacturer and basically the failed router (or switch or whatever) your describing is very similar to a failed amplifier (or repeater or cable) in a cable network. I was part of a group that worked on a patent application to determine where the "cut cable" or failed device might be. It's expensive to send repair teams to look based upon what could be faulty assumptions derived from a map that out of date. If a network topo map was sufficient, we would not have invested the time or money to work on the patent nor absorbed the expense to file.

While the same thing is true of CMS, some degree of "auto-discovery" is usually part of the requirements, so the CMS is more likely to be up to date. Yes, this assumes regular audits, verification, etc... The CMS provides both a view of all services flowing through a particular CI as well as all CIs needed to support a given service. It also provides a view of both redundancy, and interaction with depending services. Neither view is possible with a network topo map.

One other point. A good CMS includes an interface with the service catalog (one client actually implemented the complete Service Portfolio (including pipeline, catalog and retired services) on top of the CMS, but that's another story). With this capability it's possible to get something CRITICAL to any impact analysis. It's not really a "service impact" it's a business impact that is required. That's the basis for determing priorities for investigation, etc. That type of information is totally concealed by both anything other than a CMS.

In other words, an impact analysis requires input from and knowledge of the business effect or impact.

That's why the CMS provides a rather quick ROI for the clients who implemented it. While there isn't a full OOTB CMS available, today. I have no doubts that we'll see multiple attempts from various sources. The payback is too great.

David

Because "services" are not discoverable

"With a failed router or switch isn't it is easy to figure out what services are impacted with a simple network topology? Why do we need a CMS to do that?"

As Picasso said, computers are useless. They can only give you answers.

Can you *discover* services? Or must they be established by human process? Without a manual component, will you have any more understanding than that the network outage impacted a bunch of OS instances in turn crippling the POJOs in their JVMs?

In preparation for the next edition of my book, I've been refreshing my memory of the logical fundamentals. If your outage resulted in the casual (or stressed out) observation that "SERVICE X IS DOWN!" what does mean?

It means that rigorously, over domain "Service" there does - or does not - exist a Service identified by the name "ServiceX."

But can the existential truth of ServiceX be delegated to the machine? Or must it be established outside of the computing domain? Can the machine can do any more than keep a record and use the concept once established (e.g. app registry, discovery fingerprinting, service mapping, impact analysis, what have you.)

My view is that the core function of the CMDB or CMS is to do that mapping from the human perception of value, to the underlying technology, for operational purposes. (Service Catalog a different question.) It is to map the DEPENDENCY of the human perception of value, upon the underpinning services and assets.

The formal identification of "applications" is the first step on this journey.

Charles T. Betz
http://www.erp4it.com

deduction of the relationship

But Charles you are arguing for a human CMS. You know that i know that services are not discoverable - I've argued that. I said "figure out".

The only difference between your position and mine is that you imply this figuring out is to be done for all relationships, in advance, recorded in some tool and kept current for them all. Whereas I advocate, as a first approximation, to do the deduction of the relationship on demand.

I maintain that in MOST organisations it is more efficient to determine impacted services manually, and it is effective enough - after planning, design, optimisation and rehearsal of the procedure - to still meet the requirements of (sensible) SLAs. the first step should be to try. If a skilled team can't meet required SLAs then condier other tools, such as CMS.

the difference in accuracy between on-demand and a stored CMS will be small. CMS will contain manual entry errrors and out-dated data.

In MOST organisations the difference in efficiency and effectiveness will be acceptable and small enough so as to not justify building a CMS. This must be true else more than a couple of percent of sites would have done it already. the concept has been current - even in the USA - for a decade, predating ITIL. I was selling CA's "business process views" long ago.

CMDB approach & ROI

you imply this figuring out is to be done for all relationships, in advance (emphasis added)

Ah. That is perhaps the basis of our ongoing debate. No, I most certainly don't advocate that. Have I written that anywhere?

I advocate only that the most important structural relationships be documented in advance and I think that the choice of those relationships indeed would vary with the size of the IT organization. I am a firm believer in strongly typed relationships; the application to server dependency IS NOT the same as the application to application dependency. Two completely different processes & performers to maintain.

If one starts CMDB with that basic data discipline, one realizes just how big a task it is and the need for a very measured, incremental and iterative approach.

But there is at least one minimal relationship that needs to be understood, and that is the relationship of application (understood as proto-service, not mere software product) to computing resource (e.g. server). There are various ways of capturing this - in the simplest form of fingerprinting, you can define naming standards for application objects (e.g. a 4 character code prefix for all jobs & programs) and then indeed you can "figure it out on the fly." But absent at least that basic practice I would be nervous. You'll be figuring it out on the fly based on irate user calls to the service desk, a stressful situation for anyone doing impact analysis.

Let's say that
X = size of IT org (measured in budget, capacity, or headcount)
Y = ROI on CMDB

We would both agree that Y = F(X), right?

- My interest is in organizations where X is "large" - perhaps mean(X), which will be skewed considerably by the massive size of the largest shops, or even the top 20% of shops (who perhaps perform 80% of the computing... anyone know any numbers on this?)
- Your interest is in perhaps median(X) across the entire population - or even biased to the 80%, the vast majority in terms of population count.

The questions whose answer would benefit us both are

For what value of X is Y > 0?
For what value of X is Y > (competing use of capital)?

You probably think that X is higher than I do. But I suspect we might not be that far apart.

But we would also need to refine what we mean by CMDB.

CMDB would be just Application >-< Server
CMDB' would include App to App dependencies
CMDB'' would include Database & associated dependencies
CMDB''' would include Switch
CMDB'''' would include Service as an additional abstraction layer
CMDB''''' would decompose Application into Technology Products

and so on. And run the analysis then for each of those... And so on...

Charles T. Betz
http://www.erp4it.com

You are deficient without one

You've articulated exactly my position.

I maintain that X>0.95
After 20+ years of having tools that discover some of the relationships, 15+ years of talking about getting a holistic view, 10+ years of the industry banging on about CMDB... and yet few have CMDB and only the techs are calling for one. There's a message here and it is not - as the pundits suggest - ignorance.

Two more points to ponder.

One: Why do the relationships for service<->app need to be in the same repository as app<->app or app<->server? I have confidence in the ability of professional trained configuration analysts to get the correct answer from multiple sources quickly in real time.

Two: We do on-demand analysis now, and we get it right - in my experience - quite a bit of the time. How much better with a formal, designed, tested, optimised rehearsed procedure executed by trained people with access to all the existing data?

My position is not that the mega-sites don't need CMDB. My message is that CMDB is not a given, an essential. some of this selling of CMDB is a cynical attempt to grow a market at the expense of the buyers, and some of it is a genuine belief that arises from a distorted worldview: those who know CMDB are invited to talk to sites complex enough to be interested in CMDB and they get to feel that their experience is a representative sample. It's not: the simpler sites tend not to be interested in CMDB, or ITSM. The pundits and gurus never get to meet them. if you ask those sites in some dumb survey "Are you considering ITIL?" of course they say yes so as to (a) pretend they know what it is and (b) be one of the cool guys because apparently everybody else is into it. Eventually the peer pressure hysteria reaches a pitch where they actually do look into ITSM and they are told they need one of these CMDB thingies. You are deficient without one. THOSE are the people I am trying to reach with my message.

X > 0.8

And my guess is that we're looking more at the 75th or 80th percentile of X as opposed to the 95th. Now we are getting to some very interesting and specific questions, and the delta is not that great :-)

But bear in mind, there is a big difference between the NUMBER of IT shops (your concern) and the aggregate IT service capacity under management (my concern). My "mere" 20% might well encompass 80% of the world's servers. Data needed. Anyone have?

Re common repository, as a cranky old data bigot i like to have things in a common query space so I can instantly answer questions such as "what technology products are most critical to our highest value IT services" or "what is the business risk of taking this Power Distribution Unit down for service (we'll only have double redundancy, heaven forbid)." SOA is transactional, not analytic.

I am not a believer much in federated data queries; EII approaches add too much overhead and fully transparent Semantic Web interoperability is at least a few months out. Just put all the data into one normalized, related model and let me have at it with my SQL. It is Good Enough. (Including graph query extensions for walking CMDB dependencies.)

On demand is fine as long as it doesn't depend on Joe who is "up at the lake" as we say here in Minnesota. I have seen (not at my current employer) an expensive outage prolonged for at least eight hours longer than necessary because Joe was up at the lake. Some of that risk of course cannot be solved with CMDB; if Joe has exclusive knowledge about system internals finer grained than the CMDB contains (a large domain). But at least the CMDB can get the right people talking to each other sooner, and figuring out that it is Joe who is AWOL and not Sarah.

Bracing debate as always. Too darn bad we're on opposite sides of the planet, or we'd have to hoist some cold ones.

Charles T. Betz
http://www.erp4it.com

do not believe the effort is worth the prize

I think you are guilty of Excessive Technical Fastidiousness (as Real ITSM puts it) wanting all the data in one place. Nice but not worthwhile. Getting all the data in one bucket is hard enough. Keeping it useful is harder. I simply do not believe the effort is worth the prize. Especially since you'll always have to verify with Joe anyway as the data won't be perfect. let the CMDB lead everyone astray disastrously JUST ONCE and they'll ask Joe anyway for ever after.

Something as critical as a CMDB would be on redundant infrastructure right? So if the CMDB is implemented in wetware you have redundancy. Joe and Sue and their understudy Sam. That is all part of properly designing the impact process (ok ok procedure)

having been involved in priority 1/ severity 1 incidents that ran for days I understand the need for this kind of redundancy anyway - people gotta sleep.

(You are free to measure by #servers. I measure by #ITSM engagement instances i.e. conversations about "should we have a CMDB?")

Not guilty

Not rolling over this easily - sorry Rob...

I think you are guilty of Excessive Technical Fastidiousness (as Real ITSM puts it) wanting all the data in one place.
My lawyer and I disagree. I don't want all the data in one place and I think I have been very clear (e.g. here) that it can never *all* be in one place. Much of it belongs in the element (what ITIL incorrectly calls "platform") systems. Federating them is easier than you've been implying; mostly based on DNS registered host names and a solid app registry. (Mainframe a different world.)

I just want the wireframe (as Carlos calls it) in one place. That is not so hard.

Nice but not worthwhile.
Depends on how much it costs, what the value is in maintaining it (e.g. reducing redundant re-collection) and what the risks are of not having it.

Let's leave IT out of it. How big does a manufacturing firm need to be in order to justify an inventory system? One robust enough to handle bill of materials? A midmarket ERP system like Microsoft Dynamics?

$10m? $50m? $200m? (I actually don't have much of a clue, anyone with experience in midmarket ERP?)

Why would we not agree that that is how big an IT shop needs to be to justify a CMDB?

Getting all the data in one bucket is hard enough.
Actually, that is the easy part. IF you have clean data...

Keeping it useful is harder.
The maintenance is the pain. But this is handled through designing good processes, collecting the data as part of process stage gates, and managing data quality. Once you have clean data collected as part of transactions, aggregating it is not hard. Or, the CMDB can be the base platform for the processes, in which case it is consolidated from the start and you just have a reporting/analytics problem.

let the CMDB lead everyone astray disastrously JUST ONCE and they'll ask Joe anyway for ever after.
That is "management by anecdote" and the antithesis of a continuous improvement worldview. How is it different from saying "let the Change process fail JUST ONCE and no-one will folllow it again." You analyze, assess, devise a response, track your execution, and see if it happens again. At least in grown up shops.

Charles T. Betz
http://www.erp4it.com

grown up shops

Ah now I see our disconnect! Grown up shops are like grown up people: rare.

Actually our disconnect is solely a matter of degree I think, quantitative not qualitative

The argument for service impact as function

I think a case can be made it is better as a function (black box). It can be automated to the point where there is no transparency - I tend to reserve the word "process" for a glass box scenario.

The word "process" is notoriously fractal (brushing one's teeth can be termed a "process"), but I try to use it for activities longer lived and with greater fundamental value being delivered and understood by some external stakeholder. Something one level below a value chain.

Impact analysis is a means to an end, purely internal to the IT service organization, as compared even to Incident which is visible to the service consumer.

Charles T. Betz
http://www.erp4it.com

Defining impact is a must have skill...

Charles

Have to agree and disagree I think with regards to your scoping 'impact' - I probably missed something. Impact is a very important concept and term that we need across a service management system to help us link a situational event with a stakeholder interest. As I may have blogged elsewhere, impacts have a positive, negative and even a neutral (unknown or undefined) consequence or effect on a stakeholder. Its an unfortunate mistake to actually associate an impact with a service alone since its what the service is being used for, and the objectives behind that which is most relevant.

An incident has an impact defined for it. So does a change, a problem, and a configuration item event. In every case we use impact management skills and methods to describe the relationship and consequence between an event and a stakeholder's interest. If we put a word on the front, say 'service' then I agree. A service impact is tied to the service, but it should go further and describe the linkage between what happened or is happening and something like provider commitments or consumer expectations.

I'm sure a few will grunt that impacts are associated with infrastructure - true. But the impact comes to life when you can make that further connection to say the customer activity enabled and supported by the infrastructure. The USMBOK has a knowledge area - service impact management, as part of Service Operations Management knowledge domain, where the know-how of translating infrastructure impacts into service and then stakeholder impact is defined.

Unfortunately our industry has a woeful track record in knowing how to define impact.... and given it helps put realism into service management discussions, may be one of the biggest reasons why so many initiatives stumble and fail... or have been exposed by this economic perfect storm.

impact important

I think we would all agree that service impact as a concept is essential to ITSM.

This is more of a debate about semantics - does this concept have a "type," i.e. can it be seen as an instance of a more abstract entity (or meta-entity)? Is that abstract entity something called a Process, a Function, an Activity, a Service? Or ... ?

These questions are quite conflicted and little consensus is to be found. I generally look to Rummler/Brache, Harmon, and Sharpe as the rough center of gravity for these semantics.

more here: http://www.erp4it.com/erp4it/2007/09/a-process-ontol.html

Charles T. Betz
http://www.erp4it.com

Well thought out

My position is that it can be an extremely valuable part of the overall service provided, and if implemented correctly can enable all the other 'processes' to blossom.

however.

The biggest change that needs to happen in an organization is not which software is purchased but rather the cultural shift that makes the CMS the central part of any IT decision: operational, and strategic.

It is my belief that the 'CMS' is oversold, but so is every other part of the IT system.

conclusion: CMS has value when done right, but few organizations are mature enough to be able to do that right and even the ones that are mature enough need to understand the cost before believing the hype.

I have seen large, complex service provider organizations take market share due to lower implementation time directly as a result of a great CMDB (home grown) and also seen companies spend many millions of dollars on a software solution to a people problem.

Maturity

"conclusion: CMS has value when done right, but few organizations are mature enough to be able to do that right"

I would say that few (IT) organizations are mature enough to do much of anything right. Look at the failure rate of IT projects, much less ITIL or CMDB initiatives.

DaveT

Dunning Kruger effect

Unfortunately the Dunning Kruger effect is rife in the ITSM world. IT shops that are poor at ITSM are poor at judging how mature they really are and overate themselves, whilst good IT shops tend to be very hard on themselves. Vendors and consultants aren't immune from this - at one previous employer I was told in no uncertain terms that my maturity assessment was too low because the client wouldn't like the bad news.

If organisations are honest about their maturity then they can develop an approach to improvement that stands a chance of working, but if they adopt an approach that depends upon a solid baseline being in place then they will fail. What will be blamed though will be something other than the real reason.

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

Surveying maturity

Good point James. Never heard the term but I know the effect.

It is amazing that people do not get it. I have seen several ITSM surveys where the respondents are asked to rate their own process maturity. I always think that it is sure sign of complete idiocy when I see that question is a survey, do people really think that a mixed group of respondent could reliably estimate their own maturity on a common scale.

PS I have written a small guide on surveys as a website; The Three Question Survey , see http://3qsm.wordpress.com (Rob, I'm not selling anything, it's free). It explains why it is a good idea to limit the number of questions of any survey to three.

Aale

Popeye view of maturity?

Maturity, capability assessment, all important concepts, but I'm a believer that process maturity is irrelevant unless someone can prove a direct correlation between the improved capability or maturity and the satisfaction of a customer or achievement of desired results. This is perhaps one of the greatest failings of 'process improvement', or 'capability maturity improvement' initiatives, where a named process, such as incident or change management, is reengineered based upon general guidance provided by a framework such as ITIL.

A number of management imperatives (lower cost, risk, cycle times, effort, higher quality, agility, accountability) fueled by today's economic climate have created a 'perfect storm' that exposes these approaches and demands something more targeted.

A few years back I gave a presentation at the itSMF USA Annual Conference on how to assess your service provision capability. The focus discussed mirrored what you might find in Lean approach - customer results, customer satisfaction, and efficient operations through the elimination of wasteful activities. The latest Lean thinking reminds us there are at least two perspectives, the provider and consumer.

So I would propose there are at least two valid views of 'capability' and 'maturity' and that the IT folks are offering a stunted provider side view, and likely missing entirely the consumer perspective. Another thought here is that capability is one element of the 'expectation equation' I discuss in the Guide to USMBOK EXPECTATION = REQUIREMENTS (derived from needs and wants) compared with CAPABILITY (expressed through a catalog of offerings)

Capability maturity antithetical to Lean?

Ian,

Do you think an argument could be made that the entire edifice of CMM is fundamentally antithetical to Lean thinking?

Charles T. Betz
http://www.erp4it.com

I had to look it up!

Hi Charles

By the way - great comments on 'service' earlier in this thread. I wholeheartedly agree that a cannot be discovered automatically (I was a product manager that built a product to attempt that), and requires manual intervention. There are two aspects to the manual intervention, and I I just blogged on capability, they represent the consumer/provider interaction - an interview or two.

Service is more often than not just a bundling of capabilities. Capabilities are closely associated with customer need and wants and the result of sound product management - marketing skills. Back to the expectation equation, and not surprisingly as its product management 101. CMM(I) for Services places a greater emphasis on why processes exist but historically the framework has focused the process. Lean is focused on the customer and activities associated with achieving customer results and satisfaction.

Again I think like yourself (earlier thread?) I feel processes are discussed in our industry at too high a level or two far away from the action. They at best represent the machinery through which something important is put. Take service request management process for example. It 'processes' service requests. The USMBOK speaks to a pathway a service request follows through the organization - or its workflow. Benefit is gained by recognizing the process container and then inspecting the component activities.

This is where frameworks such as ITIL fail. They lack the activity level detail we need to help us discover and target in any continuous improvement effort. Simply implementing a process and maturity it is not enough. And back to my earlier comment I think - what aspect of capability are we measuring - the process architecture and perhaps E+E (effectiveness and efficiency), as seen from a provider view, or the results it helps achieve as seen from a consumer perspective.

Having looked up the word antithetical (its been a while since I used words with 4 syllables), no. lean Thinking does not obviate CMM or similar thinking. Lean just reminds us the more relevant and beneficial approach should include both a consumer and provider view - Lean Consumption and Provision. Having established that view by documenting teh Value Stream in action for a request, you enable process and maturity improvement methods - as additional tools to uncover opportunities for improvement.

What would Jonah do?

The question I am asking myself is, what would Eli Goldratt's alter ego "Jonah" (from The Goal) say if called into consult on a problem of software engineering, or IT service management, and was confronted with process maturity advocates pursuing some externally defined maturity hierarchy?

My conjecture is that he would say "This is at best a terribly indirect approach to identifying your constraints. At worst, it is an actively harmful distraction. Let's throw this stuff out and go figure out what's really wrong."

Aren't you saying the same thing here?

"A number of management imperatives (lower cost, risk, cycle times, effort, higher quality, agility, accountability) fueled by today's economic climate have created a 'perfect storm' that exposes these approaches and demands something more targeted."

At the least, one could write a provocative piece "Capability Maturity Considered Harmful."

Charles T. Betz
http://www.erp4it.com

highly distorted view

Oh good, we're all in agreement then.

Charles says CMDB is for a mature environment when there is a business case for automating the re-collecting of this data

Supportthought says "few organizations are mature enough to be able to do that right" and "need to understand the cost"

We can argue overwhether it is 5% of sites or 15% but no way is CMDB the heart or soul or core or hub or foundation or ...

CMDB is an expensive highly complex technical add-on gadget that pays for itself only in advanced mature complex mission-critical IT shops - who are the only shops that talk to expensive ITSM consultants /vendors/analysts, and thereby give those people a highly distorted view of just how prevalent the idea is.

An understanding of what it is, is key.....

Let's first get some things out of the way that I agree Rob on.
1) Glenn and I are great guys ( LOL )
2) To the best of my knowledge, there are still no technology vendors offering a fully functional CMDB or CMS ( at least not with the functionality and capabilities I want to see in a "real" CMS tool )
3) We in the industry have ALLOWED most software vendors to butcher the ITIL glossary by mapping ITIL terms to their product sheets. Everyone has seen the CMDB and/or CMS "label" placed on just about any tool that has a database that contains data, most of which are really asset repositories with a new label. This is a tragedy because it took an already difficult solution to implement and added layers upon layers of confusion to it. This essentially made the CMDB/CMS solution in many peoples minds so diverse that just about anyone could say they "succeeded" or "failed" simply because the goal was unknown or vague. I have even seen the same implementation claimed as a success AND a failure at the same time. Each party had their own understanding of what the CMDB should be hence the disagreement. Bottom line, without an agreed upon 'end state' / 'goal' how do you know if you succeeded? You don't!

In regards to the remainder of the content, I think it's vitally important that we focus on the purpose and functionality of a CMS rather than a technology. I have a hard time believing that anyone would argue against having a clear view into the services an organization offers and which IT components support those services. Isn't that ultimately what a CMDB and CMS is supposed to deliver? Is that not what every IT shop tries, with limited success, to give their business partners? How can any IT shop maximize its effectiveness without maximizing their efficiency in this area? Can you really execute an change impact assessment without knowing how everything is connected? No you cannot and hence you need the capability of a CMDB/CMS solution. Don't get hung up on a technology, focus on the capability.

The problem is that the capability and functionality is being delivered hap haphazardly with post-it notes and spreadsheets right now. So, let's not throw out the baby with the bath water. The capabilities of a CMS is in fact immensely important to the future of IT organizations however the form that it takes from company to company is what will vary widely.

If you are a small IT shop with only one central office and a minimal amount of people, your CMS may be a simplistic browser interface that lists 5 services from your catalog and pulls information from a MS Access database and MS Excel spreadsheet that collectively contain the information on the twelve servers in your "Data Center" ( likely to be a large coat closet if it's this small ). However, if you are a mulit-national entity with 50,000+ employees in 20+ countries, 10,000+ servers and a Service Catalog of 200+ items, you need something far more sophisticated and dynamic than an MS Access database and Spreadsheet.

All of this, regardless of size needs the governance processes around it for any chance of success. Several years ago I wrote an article that stated "a CMDB without the Change and Configuration Management processes is just another database" and I still believe that today.

So, let's make sure that we focus our aggression in the right direction. Let's work together to push the vendors and force them to address/deliver CMS functionality and capabilities rather than saying the industry doesn't need one. A failure on the part of the vendors to deliver the necessary functionality should not result in anyone believing that we don't need the functionality.

Thanks for listening and feel free to contact me directly for additional clarifications:
Carlos Casanova
Co-author: "The CMDB Imperative"
email: cc@k2sg.com

more pressing issues and more competitive demands on our resourc

Most of us aren't "mulit-national entity with 50,000+ employees in 20+ countries, 10,000+ servers and a Service Catalog of 200+ items". Touting a tech toy to the rest of us is wrong.

There are lots of things that would seem to be necessary to do business. That doesn't mean it is the best use of funds to have them. Ask a fair proportion of those who have tried to implement ERP - which is a good analogy of a technical solution attempting to fix a non-technical problem. Howeever the massively larger scale and scope give ERP a greater chance of success.

Fact: nearly all sites get by today without a CMDB or CMS
Fact: implementing and operating a CMDB/CMS is a massively expensive and complex exercise
Fact: CMDB is not generally accepted or widely proven practice in the industry. CMS doesn't exist at all
Fact: the ROI of CMDB does not scale down below the most complex of sites
Opinion: no CMDB has ever been implemented in a company that has effective project portfolio management - there is always a better use of the money
Opinion: no CMDB has ever delivered ROI that did not actually come mostly from simpler asset management embedded within it

By all means sell CMDBs to the Fortune 500. The rest of us need to focus on more pressing issues and more competitive demands on our resources.

Fork or Spoon? Depends on if you're eating steak or soup.

We can't get caught up in the extremes and claim something is 100% wrong if it does actually apply to at least some portion of the population in the spectrum. I think that people making decisions in companies need to understand their space, what problems they are faced with and determine what solutions will help them resolve those problems. Any individual relying solely on a vendor to decide that for them seems, dare I say it, incompetent or at the very least naive. Any salesperson who is not trying to maximize their sales is also not doing there job. Now, do I like and think it's right for a Ferrari salesperson to push their product on a construction worker who needs a 4x4 Pickup? No, but I would expect the construction worker to understand that he's not going to put to many sheets of plywood in the trunk of a Ferrari, yes. So, who's to blame if he buys the Ferrari instead of the Pickup, the seller or the buyer? The seller may have been sleazy but the buyer was outright dumb!

It sounds like your frustration is more around the fact that the vendors and salespeople are trying to sell a product to as many people/companies as they can convince. Isn't that their job? In order to try and appeal to more people, they (I'll be very polite here and say) 'may enhance the capabilities of the product' in order to make it more attractive to a wider audience. Is it right? No, but again, anyone who reads the tri-fold brochure and buys without a "real" in house proof of concept, is not treating their budget with the care it deserves.

As for the Facts/Opinions:
Fact: nearly all sites get by today without a CMDB or CMS
>>> If you're referring specifically to a vendor provided technology, yes I would agree. If you're referring to the capabilities and functionality that a CMS is intended to deliver, no, I do not agree. Companies are working on making themselves more efficient and trying to get a better grasp of what IT components support which services. Whatever it is they use to do this, whether it be, email, post-it notes, spreadsheets or a $100k system it is a CMDB/CMS in terms of the capability it offers them.

Fact: implementing and operating a CMDB/CMS is a massively expensive and complex exercise
>>> Again, let's focus on appropriate scale and scope. Let's not take a Ferrari to a construction site. If you can meet your needs with an MS Access database, why would you even entertain a major SW vendor and their solutions which are far more than you need to solve your problem. Most of us have heard the saying, "To a hammer everything looks like a nail". Well, the salespeople are hammers and their message changes only the type of nail they are trying to drive in. It's the customers job to realize they have a screw and hence do not need a hammer.

Fact: CMDB is not generally accepted or widely proven practice in the industry. CMS doesn't exist at all
>>> I'd agree that it has not been widely proven. My onion is that in large part the reason why it's not been widely proven is because people lost focus of the problem they were trying to solve and got caught up in the printed words of ITIL. The vendors played a role here by proclaiming their products as the be-all / end-all to all problems ITIL. Had these same people focused on the problems they were trying to resolve and truly understood the core governance principles that ITIL intended when defining the Configuration Management process in V2, far fewer would have failed as they did. In addition, far fewer would have even entertained the vendor solutions before doing their own house-keeping of data and processes. As for a CMS existing, again I agree that from a vendor perspective, I have not seen one. However, isn't a browser interface which pulls data from the Asset Mgt, Change Mgmt, Service Catalog and monitoring repositories into one assembled view a CMS? Assuming of course that those repositories have the necessary controls around them? I've seen this first hand even though it did not come directly in one piece from a vendor. The integration pieces were all home-grown but it does work and is in production today.

Fact: the ROI of CMDB does not scale down below the most complex of sites
>>> Post-it notes, spreadsheets and MS Access databases are pretty inexpensive so I'll have to respectfully disagree. I might actually argue that it's more cost prohibitive to deploy a CMDB/CMS in a large organization because you almost have no choice but to use a major vendor. Regardless though, I think ROI is a bad measure for something of this nature. We need to focus more on Return on Value, Net Present Value and other business measures like Internal Rate of Return. Security programs always run into difficulties justifying programs since many are considered preventative care. Until a major breach occurs that is, then the sky is the limit. I witnessed first hand intrusion detection and virus protection initiatives get shot down repeatedly, until "Nimda" and the "I Love You" viruses came along. Amazingly the initiatives were instantaneously approved and fast tracked after that.

Opinion: no CMDB has ever been implemented in a company that has effective project portfolio management - there is always a better use of the money
>>> Won't go so far as to say "there is always a better use of the money" but I will say that a PPM initiative is vital to the sustainability of a company regardless of what you're doing. The waste that occurs without a strong PPM structure in place is astounding.

Opinion: no CMDB has ever delivered ROI that did not actually come mostly from simpler asset management embedded within it
>>> I'd say that most IT projects, not just CMDB projects, never deliver the ROI initially defined at all. The problem is not necessarily because the projects don't meet their objectives, but most times it's because the ROI target was a bunch of crap to start with. We've all seen the ROI target get massaged in various directions in order to justify or kill a project depending on which side of the table you were sitting on. We in IT are not finance majors so it's not a metric which has lots of credibility in my book when I see it even though it's thrown out there all the time. We're not helping our cause much when we do it and it's a major contributor to the eventual "Punitive Outsourcing" that we see.

In the end, we're responsible for our decisions and if we don't need the solution from a major vendor, then we need to simply ignore them. Once they see that their sales are down, they'll hopefully come around to understanding what we do need, the scale/size of the problems we're trying to resolve and give us the tools that can truly meet the small as well as multi-national firm at price points that are attractive and realistic to both. Not holding my breath on this unfortunately, I expect they'll maximize sales the same way as they always do, so it's on us to not buy the snake oil.

Carlos Casanova
K2 Solutions Group, Inc.
cc@k2sg.com

You're one of the good guys

You're one of the good guys in this Carlos :) i agree with much of what you say, subject to two disagreements

the first is on terminology.

A CMDB is a piece of technology to automate configuration management. i think you are using CMDB in a blurred way that attributes both the practices/activities of configuration management with the CMDB technical software tool that stores and maintains the configuration relationships. people who have an un-integrated set of configuration point solutions, a grab-bag of asset databases, do NOT have a CMDB. They are doing what i advocate; they are doing configuration management practice (I refuse to say "process") supported by pragmatic point asset management tools. They do impact analysis ad-hoc, on demand. they do NOT have a CMDB or a CMS if it is humans and procedures and analysis/reporting tools who work out the service configuration as needed.

the second is on scope: it isn't the software vendors who are overselling CMDB. it is the software vendors, the consulting firms, the analysts, the trainers, the bloggers, the "experts", the customers and the holy bloody ITIL books themselves. it is a Salem witch-hunt: the whole industry has worked itself into a hysteria where CMDB is a given. It is never presented as a high-tech gizmo that a few power-users need. No-one questions the assumption of CMDB's pre-eminent position. if you don't have a CMDB you will some time because you need one. It is the heart and soul, the foundation, the hub, the....

You wait. The next one will be automated user provisioning, a.k.a. online service catalogue. It'll be an essential fundamental must-have foundation hub ....

We have more than in common than not...

I can agree with the assessment that I use the term CMDB more as a conceptual structure than a physical monolithic technology based repository. The way I see it is that by virtue of executing the Configuration Management practice, the 'things' they use to do so are the foundations of, or that persons' incarnation of a CMDB. I've never been a ITIL-topian about the words in the books, I've always focused, very much like you state, on delivering value REGARDLESS of the tool or what the books say. IMHO, if you don't deliver value but did what the book said, you're not doing the right thing no matter the topic.

I can also agree with you that the perpetuation and butchering of the concept does spread wider than just the vendors. I think that no matter what field, there are opportunists that raid the village and are only focused on their own specific short term goals regardless of the long term implications on the masses. I can not however go so far as to say that the conceptual structure of a CMDB/CMS and the Configuration Management practices are not central to delivering long term efficiencies for most companies. I do believe that in some way, shape or form and at some scale, Configuration Management plays a key role.

As for the "Next Big thing" there will always be one of them.... the story is always the same the topic is what gets changed. Any of us who have been around for a few years have seen several iterations of it already.... and will see many more I am sure.

Carlos Casanova
K2 Solutions Group, Inc.
cc@k2sg.com

fully in favour of Configuration Management

I have never ever ever suggested that Configuration Management practices are a bad idea or does not play a key role. Someone has to do it. There you go muddling them up with the tech toy tool again :)

Except...

"Fact: nearly all sites get by today without a CMDB or CMS"

Agreed.

That does not mean that a properly scaled CMDB/CMS is not a valuable tool to get *better* at providing IT services, versus "getting by" with today's standard of service performance. I do not think the discussion should center on "can you get by without one" but rather "is a CMDB/CMS an important tool for improving your IT service performance." Heck, we can "get by" with out a Service Desk. Did for years. But don't you think we do better at supporting our services now by having one?

DavidT

Not often

Yes but you miss my point. A Service Desk makes things much better for not much cost, relative to how much better a CMDB makes for how much cost. A service desk automates repetitive tasks, enhances reporting and monitoring and generally gives a bunch of ROI for what is really just a few tables and forms. A Service Desk tool project usually gets way up the list even in good project portfolio management.

that's why we almost all have one, and almost nobody tries to get by without one

Is a CMDB an important tool? maybe. is it more important - is it a BETTER USE OF FUNDS - than content management or an improved information security infrastructure or automated user provisioning or online catalogue or hierarchal storage management or email archiving or... Not often.

Which one is harder to track manually?

    "Who were the thirteen people who called me this morning and what did they want and what did I do about it"?

    "If I fiddle with this Unix server what services will be impacted?"

Which one is harder or more expensive to implement and maintain?

    A standalone app that people update.

    A spiderweb of software than touches everything from procurement to network discovery, with integration and ETL challenges as yet unsolved except by bespoke code, and a massive data population exercise

Is a CMDB occasionally justified in larger, more complex or more mission-critical organsiations? Sure - that's the 5%. Is a CMDB the "heart and soul" of service management? No. Does everybody need to buy one? No.

CMDB & CMS - myth or reality

You seem to be asserting that software is a waste of time in this arena. Software is all about automating things that people do - doing it faster and in many cases with less error.

Sure CMS and CMDBs are not an out of the box quick fix, but some are quicker than others, and some of them will enable organisations to get a grip on their infrastructure and configuration issues much faster than would be possible without software.

"Change or improving anything in IT" is not JUST about changing people, though of course that is an important part of it. In fact software solutions are very often the catalyst of change. The fact that the software has been justified and then implemented forces beneficial change (usually).

Sure there are a few snake oil salespeople around still, but many of the ones I deal with are not like that.

I think that this article is really rather one-dimensional and does not fully reflect reality, though I imagine that you intended to be provocative to ensure a response.

Mike Paterson
SX Consultancy Limited

a money pit

I'm all for automating tasks where it adds value, especially where it adds more value than the investment in the automation, and especially where it adds more value per investment dollar than any competing projects. that'll be those 2 or 3 percent who have a CMDB.

Automation only pays off for actions that are repeated often and identically, or where errors can be reduced or quality improved by automation. A CMDB is a central piece of software that impacts everything around it in the IT infrastructure. Every time any other tool changes the CMDB has to change. CMDB is immensely complex and technical and appeals to our sense of wanting everything precise and complete. But it's a money pit. Most of the time, humans do it more flexibly, smarter, and much cheaper.

Configuration management is a human activity, which uses processes. if those processes benefit from a tool, great. And if the cheapest most effective tool that works is a CMDB, great. but start with the people, the activity and the proceses. Train, design, rehearse, optimise. End up with the tool. And 95% of the time you'll never get to a CMDB.

Follow the "CMDB" link above or the "Similar" links to the right to get a more complete picture of my views on the topic. I don't think they're one-dimensional.

What's the difference between a used car salesman and a software salesman? the used car salesman knows he's lying. Most software sales people actually believe this stuff. When I sold software, I did. Mostly.

Written by Sting [& Sergei

Written by Sting [& Sergei Prokofiev & Philippe!]

In Europe and America there's a growing feeling of hysteria
Conditioned to respond to all the threats
In the rhetorical speeches of the OGC
Mister Turbitt said, 'We will assess you'
I don't subscribe to this point of view
It'd be such an ignorant thing to do
If the software vendors love their customers too

How can I save my little boy
From Sharon Taylor's deadly toy?
There is no monopoly on common sense
On either side of the IT fence
We share the same biology
Regardless of ideology
Believe me when I say to you
I hope the Software Vendors love their customers too

There is no historical precedent to put
Words in the mouth of the itSMF
There's no such thing as a certified product
It's a lie we don't believe anymore
Mister England says 'We will protect you'
I don't subscribe to this point of view
Believe me when I say to you
I hope the Software Vendors love their customers too
We share the same biology
Regardless of ideology
What might save us, me and you
Is if the Software Vendors love their customers too

Skep, vendor bashing is fun. These are probably the most entertaining articles on your blog.
But when are you going to talk about why so many vendors do so much bullshit : because it works.
Maybe you could start customer bashing.

Written by a software vendor.

Sorry for being slightly off topic.

brilliant

Philippe, I do customer-bash - look at the last paragraph. You're right.

That's brilliant. The best comment on this blog in years

It is really useful

You are mistaken, there is a need for these new solutions. Check today's Dilbert http://www.dilbert.com/strips/comic/2009-11-18/ .Applies to CMS as well as Clouds.

Br Aale

Dilbert.com

CMS-CMDB

Apparently someone agrees with the IT skeptic. Check out the link to Harvard Business Publishing titled Beware of Best Practices.
http://view.ed4.net/v/YC1B/KUAXQ/2UL2ZP/VLC7FZ/
ldiaz

Syndicate content