Debasement of concepts by IT vendors and analysts
This article has been podcast
The persistent erosion of meaning in IT terminology is a damaging practice endemic across vendors and analysts. When a concept gains some currency and everyone wants it, suddenly all the vendors have got it - often by re-labelling a feature of their existing product. And the analysts keep confusing the definition so no-one can call the vendors out for this obfuscation. I used to really struggle with this. I thought I kept getting the wrong end of the stick with new terminology, until I realised that is was other people moving the stick.
Most of us have been around the industry long enough to remember when "knowledge management" actually meant something. You added value to data to make information, and added value to information to make knowledge. Knowledge management was about gathering information into a knowledgebase, where it could be organised and accessed at a conceptual level, where the IP of the organisation would be captured and shared, and where new concepts and strategic insights would emerge. Now anyone whose tool stores files or lets you type text in has a knowledgebase. By some current vendor definitions, Windows Explorer is a knowledgebase.
Before that it was Executive Information Systems. EIS was about providing the information to support corporate strategic decisions, by distilling out KPIs, preferably in realtime. After a while, any end-user reporting tool apparently supported EIS.
In recent years, it has been ITIL. Suddenly every vendor has ITIL. ITIL is technology-agnostic. Strewth, you can do ITIL with Post-It Notes, and the way things are going it won’t be long before 3M are advertising Post-it Notes as “ITIL compliant”. But it seems to me that there are some clear criteria for a reasonable person's definition of “ITIL compliant”.
Ask your vendor about their supposedly ITIL-compliant or ITIl-supporting tool (including some Pink-Verified ones):
- ITIL is all about Quality Management [Service Support, p2]. How does the tool support this out-of-the-box (OOTB)? For instance, how does it support determining targets? or measure and report improvement over time? Does it explicitly implement a Deming Cycle (Plan, DO, Check, Act)?
- Service Management is nothing without Service Level Management. Regardless of whether it is a tool for Availability, Capacity, Service Desk, CMDB, whatever…. ask them how it is SLA-aware and how it contributes to the monitoring and reporting of SLAs.
- Does the tool support workflow? (Pretty odd if a process-compliant tool doesn’t). Does it come with the “standard” ITIL workflows (clearly flowcharted in the red book and blue book) pre-defined?
- If it monitors the environment, does it consolidate information to a service view? (“service” as defined by ITIL – there’s another grossly-abused term)
- For Service Desks:
- Are Incident and Problem and Change all separate entities? i.e. an Incident does not morph into a Problem: it spawns a Problem. The Incident must continue to exist (and be resolved) as a distinct entity from the problem.
- Do they provide Incident Matching OOTB? RTFM (Read The Manual): Incident Matching does not mean simple keyword searching - it is a clearly defined process [Service Support, p 102].
- Do they support Known Error and workarounds OOTB?
- Do they assess impact and report it meaningfully? Displaying the CMDB is not impact assessment.
- Do they provide Forward Schedule of Change OOTB?
It is far too easy to slap the word "ITIL" on any operations tool (or pay some firm to do it for you). This only serves to debase what ITIL means and to confuse the community.
More recently, the victim has been Service Oriented Architecture or SOA.
our own research shows, that organisations are increasingly confused by the seemingly endemic and varied use of the term SOA in vendor propositions. [Macehiter Ward-Dutton Advisors , May 04, 2005]
And now this, the last straw: from EMA, analysts who should know better.
"The point is the CMDB is not a 'thing', it's a landscape, it's a system," said Dennis Drogseth, VP of EMA. "So, the CMDB is exactly that political-cultural process of getting organizations to define a trusted source of information for a given environment and to share that info in a consistent way with parts of the organization." [ ITSM-Watch August 3, 2006 ]
No it isn’t. Leave it alone. It’s a thing.
Configuration Management requires the use of support tools, which includes a Configuration Management Database (CMDB)… The CMDB is likely to be based upon database technology that provides flexible and powerful interrogation facilities. [Service Support, p124].
CMDB is NOT “a landscape … a system” or a “political-cultural process”. Bullshit. I’m not sure whether this reflects the author’s ignorance of ITIL or blatant lack of respect for the meaning of terms, but either way: stop it!. Invent your own bloody terms and leave CMDB alone.
Made in New Zealand 
Comments
terminological debasement
I thought of another way of describing the remorseless debasement of terminology by vendors:
When all you have is a hammer, call it a drill
concepts and new concepts
I was just surfing the web and then found this interesting new concept:
"Populate the Change Management Database (CMDB) with change information - Provides validation that requested changes match to actual changes so that change managers can quickly reconcile authorized changes."
Wow, a vendor that changes from Configuration Management to Change Management, keeps the same acronym and then changes the entire ITIL concept to suit its product!
:-)
http://www.tripwire.com/products/integrations/openview/service_desk.cfm
Ahh - as an ITIL certified professional...how I agree
I really enjoyed the article you wrote. I took the step to become ITIL certified all the time thinking, this is pretty common sense stuff and btw, it's what I've been doing for years only now it's relabled with a title for which the vultures are charging $5-10K for several weeks of training to get (I got mine through self study of materials off ebay). Take that you over charging educational vendors.
Now, for someone new to the IT industry I can see the benefit of presenting this worthwhile concept yet it is maddening how the vendors will exploit a good, simple concept with a bunch of fluff. Hence, everything 2.0. THere are cars 2.0, libraries 2.0, web 2.0 and in the magzine I received last night, Enterprise 2.0. GADS.
My proposal. Let's stop the labeling hype, get back to the basics of what are we changing and why? Adding a service where you can upload and share files...GREAT, sounds good. Now, piggybacking on it to say and confuse all IT consumers by calling it web 2.0....bad.
Confusion
You've sort of proven the point you were arguing against.
"Adding a service where you can upload and share files..." is not what Web 2.0 is about. Rather than the publish and deploy approach you mention, it is about engagment and collaboration. It is reflected in the means as well as tools. It is not about producing unilateral on-line libraries, but rather mechanisms for participation.
It is easy to knock the label when the whole point is misunderstood.
Stop the 2.0 Spin
I understand the concept. You can't deny though that the the web (not itnernet) in infancy was intended to enhance the experience and sharing (and to that extent participation). It is a natural progression of technology that has been distorted and is confusing many non techies by applying a title. How many people are asking consultants, what can I do to be a 2.0. It's overhyped! Again, I think it's great the ability to share and yes, partipcate, collaborate and more is getting easier by the minute but let's not confuse the IT consumers (meaning businesses, etc) by making them frantic to become 2.0 whatever. Rather, let's help clarify what some of the leading edge technologies MAY apply to their orgnaizations that enhance sharing (perhaps adding a blog where customers can share experiences about their products), etc.
Gartner, as an exmaple, broke Web 2.0 down into manageble, specific technologies which I think it more helpful than a massive, overarching, catch-all title. Talk with an organziation about using a blog versus being all that is 2.0.
Words have power
Labels are words and words have power. Words are the clothing of ideas.
Tools are the enablers, not the idea itself. This is more than open source, social networking, smart mobs, crowd wisdom, or other ideas that touch upon the subject. It is about deep changes in the structure and modus operandi of the corporation, our economy, education and social interactions.
When you dismiss Web 2.0 for your blue-collar tool definitions, you miss the point. Rod McEwan, the CEO of Goldcorp, knew nothing of blogs or Gartner tools when he heard a speaker at MIT tell a Web 2.0 story of how a loose volunteer group of developers had produced linux over the Internet.
McEwen had an epiphany and presented this idea to his head geologist, "I’d like to take all of our geology, all the data we have that goes back to 1948, and put it into a file and share it with the world,” he said. “Then we’ll ask the world to tell us where we’re going to find the next six million ounces of gold.”
His staff were skeptical. This was a violation of how business was done. Geological data is a carefully guarded resource. Not only did the approach yield gold, it transformed his underperforming $100 million company into a $9 billion juggernaut while transforming a backward mining site into one of the most profitable properties in the industry.
Of course, it could be all spin.
The internet changes everything. No really
As usual I'm agreeing with everyone ... subject to semantics.
In the "Look Out" box way down there on the right you'll see one topic I want to address some time is "Web 2.0, hype or just hype?" [though frankly ITIL and OGC are providing such fertile fields right now I can't move away] so I'm as sick of the hysteria as anyone. The vendors still try to play the Y2K trick even though most of us are older and wiser.
On the other hand another topic I have planned is "The internet changes everything. No really". Because it does, in ways we are only just beginning to understand, and probably even more we don't.
Kick 'em in the SaaS
Tools and terminology....interersting thread; but intelligent application of tools hasn't really changed just because we have "ITIL" right?
I’m a strong believer in the ‘On-Demand’ model of software, also called Software-as-a-Service’ (SaaS). When I see articles titled “IT Execs To Vendors: Your Software Stinks”, it only increases my believe that ‘On-Demand’ might be a great way to give your traditional tool vendors a kick in the SaaS and accelerate your implementation of ITSM at the same time.
Everyone knows that tools will help automate processes, but when do you apply them and at what cost? Trying to wait until some process improvement cycles are completed is the best practice approach, but the pressure to automate is unrelenting and the big gorillas only crank up the pressure even more by offering Service Desks, CMDBs and visions of nirvana.
I’ve already spewed on about CMDB madness and the savage journey that can bring (see Avoiding a Savage Journey on the Road to ITSM Excellence) so I won’t continue that here, but trying to 'do it by the book' can be just as bad. The fact is, tools can help significantly!
The sad reality is that automation is one way to help ‘do more with less’, but often customers are simply not ready to make large strategic investments in software early in the journey. Trying to go through process implementation without any tool investment can result in hitting the wall, and making investments before you’re really ready can significantly increase the risk of making a bad investment.
Leveraging SaaS tools is one way to bridge that gap. Traditional software products often result in lengthy implementation cycles -- which is why SaaS may not be an option for these products -- but there are products that have been designed to enable SaaS, which can be used very effectively in ITSM implementations.
Subscribing for a 90 day implementation can quickly provide value for the ITSM implementation, while offering a pilot to measure the value from the tool at the same time:
“One thing we do, which I think every customer should demand, is a pilot. The full implementation of a robust enterprise solution is up and running very quickly, they use it for 90 days, and if they are making money from it, they decide to subscribe for some longer period. If they haven't proven value to themselves before then, why do it?” – SaaS Skepticism is Predictable, IT Business Edge, 9/28/2006
So, don’t be ‘a fool with a tool’, but don’t be a fool without one either. Kick some Saas and get on the Right Road.
(as posted on
Fear & Loathing on the Road to IT Service Management Excellence)
John M. Worthington
MyServiceMonitor, LLC
Challenging the IT Skeptic
(reposted from www.erp4it.com)
OK, let's make one thing clear: I really like the IT Skeptic's site; unlike too much ITIL twaddle, he is making us all think harder. The world needs contrarians.
However, Mr. Skeptic, you've made a number of questionable assertions. My next few posts will be devoted to examining your arguments. Let's start with your critique of Dennis Drogseth:
"No it isn’t. Leave it [CMDB] alone. It’s a thing."
I disagree. The reification of "CMDB" as a thing is in fact one of the biggest problems in the ITIL landscape. As a "thing" it is unmanageable and impossible, a prematurely-defined technical solution to a poorly understood problem - the point of many of your posts! Dennis is exactly right.
In fact, what is needed is an enterprise architecture for IT (http://erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html)
- one in which a specific CMDB may be central, but only as first among equals in an overall ecosystem of tools to manage the IT value chain (http://erp4it.typepad.com/erp4it/2006/02/a_value_chain_a.html).
More later.
-Charlie
Yahoo!!
Thanks Charlie, I've been waiting for some robust debate.
In this case however I think we are in violent agreement - it is just semantics tripping us up again. Configuration Management is much more than a database - it is indeed a system and - most of all - #1 is process, like all of ITIL. Let's stop fixating on CMDB and get back to process. Absolutely. But Dennis isn't talking about Config Mgmt, he's referring to CMDB. And CMDB is a Thing. With the possible exception of a service desk tool, CMDB is the only Thing of any importance in the ITIL books, which otherwise quite properly stick to process. Yes, CMDB is a thing: the quotes I used make that clear. I will defend that semantic distinction to the end :-D Config Mgmt is process and we need to get back to that.
I can't get over how many IT people are technology (read:"thing") fixated. Things don't fix/improve anything, processes do. Processes use technology. The ITIL guys knew that: hence the endless reference back to the People/Process/Technology model (or its variants) ... and in that order.
If there is one thing that I hope shines through this blog it is my contempt for technology for its own sake. I believe you feel the same way Charlie, and I hope with this clarification you'd agree with me: CMDB is the technology, Config Mgmt is the process. On its own CMDB is nothing. It is less than nothing: it is an endlessly complex distraction and money-sink.
Is Configuration Management a process?
Actually, I don't agree that Configuration Management on its own is a process in a strict BPM sense. I can prove this by asking the following simple question: What is a Configuration and how do I know when I am done managing it?
The repeatable processes look more like:
Identify CI
Change CI
Verify CI
Audit CI
But even these aren't fitting well as "processes" in my world - they are too granular, and don't deliver value on ther own. Instead, they are activities that slot into larger, true processes, such as
Fulfill IT Demand Request
Verify SOX Compliance
and so forth.
Configuration Management I believe needs to be built out primarily as neither a system, nor a process, but a capability or a service. As a capability, it provides a distinct set of small-grained, repeatable services/functions that can be re-used across a variety of true value-creating processes. This is essentially an SOA view of configuration management.
"Capability" is not a concept overly familiar to the ITIL discussion, but core to enterprise architecture as I practice it. (Capability contains function contains service in some views).
We've discussed that the ITIL discussion of data has been insufficient; what many do not realize is that the ITIL concept of process is also confused. Search Amazon on Rummler/Brache, Paul Harmon, and Alec Sharpe for the state of art BPM thinking. It will make you view ITIL in a new light.
Charlie
the ten ...or thirteen ..aspects of ITIL, what are they called?
Yup, right on. I'm sloppy in my terminology here, and so is ITIL. Actually the ten ... or thirteen .. aspects of ITIL, what are they called? Domains, processes, disciplines, components, books... The ITIL books are vague and inconsistent. SO too are doc from other providers.
They are often called processes and as you say they are not. Maybe the term can be justified as meaning sets of processes but even that is not strictly correct. I like "capability". Thanks, I'll start using it :-D
10... 13... ... or now 27.... practices
In the series of ITSM Library books we're now producing on all of these 'aspects' we follow a simple guideline:
- we initially label the ITIL 'aspects' with the word "practice". This seems to be closest to what ITIL claims - unlike what many readers seem to read in it... ITIL is nothing but a set of "best practices", or lately "good practices", and the only claim therefore is the word "practice". ITIL doesn't really claim to have processes, they simply have adopted a VERY sloppy way of using that word for what they've actually announced as "practices". If you apply the definition of 'process' to the practices that are described in (any version of) ITIL, you'll easily be able to find the elements that are indeed described in something that looks like the format of a process.
- we then separate all processes from functions, according to the definition of what a process is (as documented in ITIL and ISO9000). This delivers a very simple set of processes and reveals all other 'aspects' as functions.
- we then develop practitioner level guidance on these processes and functions, explaining how these are taken care of in practice, offering guidelines, templates, checklists, examples.
All books will be consistent, since they all are derived from one common factor that explains when something is a process and when a function. They also all use the same holistic structure of explaining each process or function. They provide the answers to all what, who, when, why, how, with, etc. questions, based on views from provider, customer, and user positions.
I often compare ITIL V3 with the result I had when dismantling a motorbike in my early days. When I put the thing together again, I found myself holding a handfull of parts that must have had a position in the bike once... and as you'll understand it never ran again. Looking at ITIL V3, I see a lot of practices (i.e. parts) with names like "processes", "functions", "activities" and "things". And I still can't see how that builds a fast bike - it only confirms that the authors weren't really guided in working within a single architecture. So, in practice, I rebuild the thing, using several of its components, and make my own machine from it - one that I know that works in practice...
So I suggest to use the word "practice", and consider ITIL to be a "reference" for all kinds of overlapping practices, NOT an implementation framework.
Cross-comments
Hi friends!
Just before reading all the comments to this post, I wrote my own post inspired by this discussion.
After reading the comments, I've seen that you arrived to the same conclusion... semantics, formal definitions and best practices collide.
Please, try to translate and read my post. I'll try to trackback yours.
http://gobiernotic.blogspot.com/2006/09/formalizar-o-improvisar.html
Regards!
------------
Antonio Valle
"The safe course leads ever downward into stagnation." -- Frank Herbert
Definition of "CMDB"
Hello Skeptic,
As a vendor that sells IT Operations solutions, I have to say that I love this post.
While going through our phase of trying to understand how to market ourselves, we came across endless permutations of definitions that twist terminology to meet the marketing needs of many different vendors. It became insane to think that you can effectively afford to market yourself a million different ways for one solution.
The reverse is vendors alleging that their solutions fit the definition of a specific term. The example you've effectively brought up, many times, is the definition of a CMDB. Anyone that has an Asset Register/Datbase is calling it a CMDB, these days.
Did you know that all of the following fundamentally perform the same functions?
- Configuration Management Database (CMDB)
- Knowledge Management System (KMS)
- Enterprise Information Management System
- Organizational Memory & Information System (OMIS)
- Informatics System/Platform
- Executive Information System (EIS)
It's just that to different stakeholders in different industries they're labeled to be different things.
Actually, I think that one of the reasons that all of these things become more obscure over time is because technology allows you to do far more with each and every one as the years move forward. It still doesn't excuse vendors from bending things, though. Modern technologies allow things to grow and cross traditional boundaries, hence some of the confusion and cross term pollination.
So, I will share some terms related to Configuration Management that we use with our market. I hope you find them useful.
Configuration:
(We use Merriam-Webster's) A relative arrangement of parts or elements. Something that results from a particular arrangement of parts or components.
Configuration Item:
Any trackable item or entity for which changes must be captured, versioned, and managed.
Configuration Management:
The set of processes put in place to formally manage configurations.
Configuration Management Database (CMDB):
Traditionally a database and, more recently, an application or system that is used for the management of configuration information for any and all entities whose configuration information is important enough to manage for a said enterprise.
I know these definitions are boring... but they're to the point and eliminate the many paragraphs of opinions and prose that many other people append to them.
Where I think vendors take advantage of things is in the "detail" associated with the definitions. For example, the details or specifications of what a real CMDB should do cannot possibly be put into the defintion, since it's a large document. This is where marketing takes its liberties. There is nothing in the definition of a CMDB that talks about managing named and directional relationships between entities. And, there are a huge number of IT resources out there that have never truly been exposed to what a real CMDB should do. Therefore, the only way to keep vendors from taking advantage of prospects is to educate "all" prospects. Unfortunately, this will statistically never happen properly.
BTW, creators of ITIL, while not being vendors, have also bent definitions to meet their needs. For example: Service Management has always been the set of processes put in place to formally manage services. And Release Management has always been the set of processes put in place to manage product releases. Not to ITIL. ITIL has redefined them to meet their own needs. The end result is that ITIL training is misinforming and confusing its students, many of whom come out "quoting" the almight ITIL books.
However, I'm sure that you're aware that ranting and raving about vendors bending definitions and rules isn't going to change anything. In this modern market of "make up your definition as you go", the best option is to learn how to clearly state your position and to learn how to cope.
Thanks for the opportunity to post. I hope this information helps.
Regards,
Frank Guerino
CEO & Founder
TraverseIT
On-Demand ITIL
Frank.Guerino@TraverseIT.com
http://www.TraverseIT.com
Response to Frank
I do not agree that these systems all do the same thing:
- Configuration Management Database (CMDB)
- Knowledge Management System (KMS)
- Executive Information System (EIS)
Knowledge Management systems are typically for unstructured data. Lotus Notes is the pre-eminent example. An EIS is another term for a digital dashboard and is the top layer of a Business Intelligence system. It is a VERY far cry from a CMDB, closer to a Business Performance Management system (not to be confused with a Business Process Management System). One might well see CMDB information underpinning an EIS for the IT senior management, but many EISes would have nothing to do with a CMDB
I have never heard any of the other terms used by any research firms to describe a coherent market segment. One system that IS closely related to a CMDB is a Metadata Management System.
See http://erp4it.typepad.com/erp4it/2003/12/a_story_from_a_.html for more on this.
I also think the formulation "manage configurations" needs clarification. For me, whenever I see terminology like that, I assume that what is being discussed is element configuration management, as opposed to enterprise configuration management. See http://erp4it.typepad.com/erp4it/2006/09/element_versus_.html.
Finally, the term "database" implies a "data model." I'm amazed at how many people pontificate endlessly about CMDBs without reference to any sort of structured description of just what might be in that CMDB. See http://erp4it.typepad.com/erp4it/files/a_data_architecture_for_it_service_management.pdf.
-charlie
Reply to Charles
Hello Charles,
While I agree with you that these systems are not "exactly" the same, my enterprise and me are familiar with them enough to know that they are "fundamentally" the same. If you break them down, you'll realize that they all hold data/information, relationships between data/information, audit and historical data/information, details about nodes and edges, allow for directional browsing/drilling/data mining, etc. If you break down how each and every one works, you'll find that they have far more in common than they do that is different.
BTW, you stated that KM systems "are typically for unstructured data". This is true but not necessarily because they "have to be" about structured data but more because that's the best most vendors have been able to provide. There are both structured and unstructured KM solutions on the market. Only now are true KM platforms being introduced that focus more on structured data/information. Remember "unstructured data" is the mess that people and enterprises have created because they didn't take the time to structure it. There is an entire industry that popped up, which deals specifically with trying to "understand the unstructured mess". This is the unstructured KM solutions industry. Tools like our own, that focus on structured information management, are all about "avoiding the mess" and leveraging the power of cleaning your room before you ever let it get to a state where you have to leverage a bulldozer to get through it all.
I hope this helps.
Regards,
Frank Guerino
CEO & Founder
TraverseIT
On-Demand IT
Frank.Guerino@TraverseIT.com
http://www.TraverseIT.com
Configuration is ALL about relationships
Thanks for an interesting post Frank.
i agree with all except: "There is nothing in the definition of a CMDB that talks about managing named and directional relationships between entities".
The following quotes are from the blue book, Service Support:
I agree with what you say to the extent that I was surprised at how little EXPLICIT definition of relationships is in the book[why am I surprised? the whole data model specification sucks], but certainly there is IMPLICIT definition in the requirement for impact analysis. Good analysis requires pretty sophisticated relationships.