ITIL product compliance

[updated: it seems salient to revisit this post. To the vendor who proudly declared on this blog that your product is "ITIL aligned" you might like to measure that "alignment" against this list. ("Aligned" is the new slippery-speak now that "compliant" is on the nose)]

The IT Skeptic’s ITIL Compliance Alignment Criteria

OGC and itSMF let an opportunity slip and let down their constituencies when they ignored the whole area of product compliance [Update: OGC have of course reversed their position on this and decreed a standard for ITIL software compliance]. There are some obvious criteria for a reasonable person's definition of “ITIL compliant”. Here are some searching questions to ask your prospective tools vendor, from the IT Skeptic.

ITIL is technology-agnostic. 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”.
The fact is that vendors are full of it when it comes to ITIL. It is far too easy to slap the word "ITIL" on an operations tool. This only serves to debase what ITIL means and to confuse the community. (The IT Skeptic has more to say about the debasement of terminology).

You can sympathise with the vendors (as much as one can sympathise with software vendors… speaking as an ex-vendor myself). They can hardly ignore ITIL, yet OGC and itSMF both let an opportunity slip and let down their constituencies when they ignored the whole area of product compliance. No doubt they had good reasons for standing aloof from the whole sordid business but they have left unregulated an area that cries out for some control.

Today, there is no formal independent certification of ITIL compliance for tools. (Pink Elephant provides “PinkVerify™” commercial licensed certification. The IT Skeptic’s experience is that this is not a good indicator of compliance to some of the following criteria [Note that Pink later objected to my associating "compliance" with PinkVerify which I thought was a semantic dance akin to the aligned/compliant nonsense])

OGC set up individual professional certification early on, and now finally ISO/IEC has given us organisational certification (the 20000 standard). The product vendors have no choice but to make their own claims, and nowhere to go other than Pink to verify them in the event that their claims are in fact correct.

But it seems to the IT Skeptic that there are some obvious criteria for a reasonable person's definition of “ITIL compliant”. So if you adopt ITIL, ask your prospective vendor these questions about their supposedly ITIL-compliant or ITIL-supporting tool (including some PinkVerified ones):

  1. Who says it is compliant or that it supports ITIL? To what maturity and in what capabilities? Just because they think it supports Incident management at maturity level 2 is of little relevance if you need a Service Level Management tool to get you to maturity 4.
  2. How many of their product designers are certified ITIL Masters/Managers? Is the chief product architect? If none, then who are the ITIL masters who consult on design? Ask for a conference call to discuss compliance.
  3. Use of ITIL terminology. Part of the benefit of any standard framework is standard terms, so that new staff, service providers, auditors, trainers and contractors can all quickly understand your organisation and communicate clearly. So it is not OK if an incident is called something other than an incident, especially if an incident is called a problem and a problem is called a fault. Confusion will be endless.
  4. Use of ITIL terminology. Just because it uses ITIL terminology does not mean it supports ITIL. The ITIL processes are clearly defined in the red and blue books. If it doesn’t work to these processes (and a wide range of the variants that arise at implementation) it doesn’t support ITIL. It is too easy to change the words on a few screens and declare compliance.
  5. ITIL is all about Quality Management. How does the tool support this out-of-the-box (OOTB)? For instance, how does it support determining targets? How does it measure and report improvement over time? Does it explicitly implement a Deming Cycle (Plan, Do, Check, Act) in the tool?
  6. Service Management is nothing without Service Level Management. Regardless of whether it is a tool for Availability, Capacity, Service Desk, Configuration, whatever…. ask them how it is SLA-aware and how it contributes to the monitoring and reporting of SLAs.
  7. SLAs are multi-item written contracts. The contract defines who it is with, what period, who are the key people, what the vertical escalation path is. Each item can define support response times, time to repair, percentage availability, performance, resource usage etc. Setting a threshold time in which an Incident should be picked up or closed or whatever is not an SLA. It is one service level objective that might form part of an SLA if it could be defined on a per-customer basis. Do not allow vendors to redefine the term SLA to suit their own purposes.
  8. SLAs relate to a service. This may seem obvious, but SLAs are not related to an asset or anything else: they define the levels for the service. One individual objective within an SLA might relate to a metric for an individual asset. SLAs don’t.
    From the top down: if an incident is raised against a service how to track how long the incident is open as a measure of the outage? How to know when an SLA is in danger of being violated?
    From the bottom up: when a server or network device goes down, how to know what service(s) is impacted? How to roll up / consolidate device outages into a consequent service outage time?
  9. 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? (For example does it support diverging workflows for major or minor change? For requests and incidents?) How does the documentation explain implementing the tool in support of ITIL process? Pretty much every one of the larger players provides services to implement their tool in an ITIL environment, but check what comes OOTB and what is in the manuals. If there is hardly a mention of ITIL then you know their service guys have the tough job of putting lipstick on a pig.
  10. Does the tool consolidate information to a service view? (“service” as defined by ITIL – there’s a grossly-abused term) Tools that cannot measure and communicate in terms of a service are not ITIL tools (though they can provide a foundation of data for ITIL tools). For example: a monitoring tool should show current status of a service; a Service Desk should show current status of a service based on incidents, problems and changes; a Service Desk and/or SLA tool should provide historical reporting of consolidated availability information and cumulative statistics by service.
  11. How many of their field implementation staff or partners have certification beyond ITIL Foundation? Foundation training is known in the IT Skeptic’s part of the world as “sheep dipping”. It is a basic process that everyone in IT operations should undergo. It provides just enough knowledge to be dangerous (the IT Skeptic should know, being a mere Foundation practitioner himself). If your organisation is of any size or complexity, you probably want more highly trained people, although of course you should look at the broader skills and experience of the individuals involved. Nevertheless, their overall level of training is a good measure of their genuine commitment to ITIL. The big vendors generally excel here. The small players often pay lip service. Or worse they have no field support at all beyond one product tech at the local distributor. ITIL is about process not tools: you need process people on the ground to help you implement it.
  12. Specifically for Service Desks:
    1. 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. Changing the type of a record from Incident to Problem is not ITIL.
    2. Do they provide Incident Matching OOTB? Incident Matching does not mean simple keyword searching - it is a clearly defined process [Service Support, p 102].
    3. Do they support Known Error and Workarounds as entities with associated workflow OOTB? Many tools have never heard of these. Some have them as categories of Problem, which is probably OK though strictly they should be another entity spawned from the Problem. Service Desk Level 1 staff need to be able to look for Known Errors and find the Workaround.
    4. Do they assess impact and report it meaningfully? Displaying the CMDB tree in a pretty GUI is not impact assessment. If this device is removed will the service still function? How many servers can be removed from the farm without degrading performance past SLA bounds?
    5. Do they provide Forward Schedule of Change OOTB?
    6. How to support a CAB? E.g. what reports when preparing CAB minutes and briefing papers before meeting? How to help them collaborate without having to physically meet, for minor changes that still need a ruling?

What do you think? Do you have any more to add? How does Version 3 change this list (I think not much, but I'm still reading)?


The 13th ITIL Compliance Criterion

Here's one more:
13. Do the standard manuals talk in ITIL terminology? or just the brochures and one add-on manual...

Here's one more:

Try this one on:

14. How much attention is paid to the integrations? Do they look like they're part of the same approach, or are they all different? It is easy to change and add to them? Are the integrations documented out of the box, or are they unofficial "field" readmes? Beware a solution with crappy integration, it will suck the funding right out of your project and erode your street cred with your users.

By the time you get to anything that can be called a "solution", you're likely to have more than one product. For example, a CMDB that provides service anatomy and impact analysis, and a Service Desk for Incident/Problem/Change management. If anyone has a beef with this particular choice of example, save it for a second - what I'm getting at is, despite the preference for one product that does it all, you're not gonna get that, at least today. So, you're always looking at integration.

The question I'd ask (and I ask this regularly and forcefully of my colleagues) is, how much attention has been paid to the integrations? Is there a methodology, or does your integration plan (hoping you have one) resemble a complex, finely-tuned bowl of pasta? I like linguine, with a nice, fresh tomato sauce...but that's not what he said! He said "truuuue, integraaaaaation..." that is, not a spewing of point-to-point that is added to every time something else is added to the bowl, but having thought about what needs to get integrated from the beginning. Things to make it more manageable, like, all teh integrations follow a common set of structures, terminology, documentation, and how to change and add to it.

Point-to-point integations have a certain smell, and "solutions" built on incrementally-added integrations have that burning, high-TCO smell. It might work, but it creaks under it's own weight, and it's brittle - what happens when Bob's away or leaves, nobody else knows what goes in in between product X and Y. A vendor MUST get the integrations right to answer many of the first 13. Don't let them buy you off with explanations of low-maintenance, without a good look at how that low-maintenance comes about. Is it because the vendor doesn't expect you to have to maintain that integration very much? If so, the vendor is spraying statistical pixie dust on you - overall, the cost is low, but the one time you had to actually extend the integration, it cost a month and five guys and killed yoru other project.

There is no integration kool-aid. Integrations must be consumed without dilution. Get the integrations right. Beware sham integrations.

Now, assuming you DO get the integrations right, your portfolio gets a bit of help. You can as a vendor focus on making your products meet the needs of your market, versus running back to R&D to be in catch-up mode for another year.

Do you agree or am I drunk on my own Kool-Aid? I care deeply about getting IT right, if you agree check out my blog at I am transparent. And apologies to Billy Crystal for the Princess Bride crack.

Fools rush into federation

When I was with Accenture (no, not ashamed, Accenture is like college, you get out of it what you put in to it) one of the things I remember was very explicit guidance saying "always treat integrations as one of the most risky areas on your engagement."

Sound advice and it spurred an interest in EAI for me that I have maintained off & on, career-wise. That interest led me to take David Linthicum's 5-day EAI seminar many years ago, and I've kept up with his excellent writings on the space. Added a bit more rigor years later in my MS in SW Eng, where I had a formal course on distributed systems & the real math behind them, and then of course there was the three year stint in Best Buy's leading edge Integration Competency Center, an ambitious attempt to centralize all development and support of system integrations into one unit.

Having seen the amazing atrocities that constitute system integrations in so many cases, I am bemused by all the chatter about the importance of CMDB federation, and all the purported risks of overly monolithic systems. (They're Too Big! Oooooh, Scary!) I wonder if the people making such statements have studied the inherent challenges of data integrity across heterogeneous systems.

Yes, we have to have integrations, but their risks and costs are sometimes overlooked at the expense of larger, more centralized systems that in fact might be the more manageable alternative.

Charles T. Betz

both tigers, different stripes?

is there a significant difference in cost/difficulty between federating a CMS and providing regular ETL (extract-transform-load) into a monolithic CMDB? Especially since many CMS discussions I've seen propose ETL in some cases anyway? Seems to me they are both integration, and both with the same number of data sources...

Don't move the data at all

I'm not sure what is meant by federating a CMS without moving data at all. It's simply not possible, in the absence of master data management, which requires *some* movement of at least business keys between systems. There's been some pretty fuzzy headed statements about CMDB federation along these lines, inconsistent with basic data management realities.

What I am talking about is consolidating IT systems of record into large transactional systems on one common data model in one large database, supporting multiple modules. You don't need to move the data because it's being mastered in one place.

You know, the approach that has failed so miserably for SAP & Oracle... except, well, wait, it really didn't fail, on balance.... judging by those companies' revenues...

Charles T. Betz


Oh, gotcha. Rip out all our existing IT management tools, and replace everything with a monolithic system like Tivoli or Unicenter so we lock in to one vendor. I used to try to sell that idea.

In a sufficiently large organisation with sufficiently complex business processing, I hear ERP can actually repay the boggling cost of total replacement of staff skills, business processes and technology. The last time I saw one of the world's top 100 banks try it, it nearly broke the company and cost them about 2 billion dollars. Likewise one of the world's biggest resources companies who ran a project for about five years before anything actually paid off.

That was doing ERP for the whole company. I don't see too many organisations where replacing only the IT silo with a monolithic solution is going to be big enough to have a positive ROI in my lifetime.

Plenty of success stories

I'm only talking about the domain of IT. (But there are plenty of enterprise success stories, such as General Mills in our town with their complete cutover to SAP.)

Doesn't have to be an insane, "all-in," rip and replace. You decide on your target platform and move the various modules over one at a time when the respective legacy versions are up for refresh ... the existence of failure anecdotes has to be weighed against the annual revenues of the vendors which are clear evidence of at least some benefit being gained by some firms.

This started off as a discussion of the costs/risks of integration... I think for every failed ERP you can cite, I can cite a failed attempt to build up from smaller, uncoordinated systems via integrations... there are tradeoffs on both sides, and sometime centralizing data *does* work.

Charles T. Betz

The holy grail

One centralised instance of data is certainly the holy grail, and yes there are many instances of success. Even for Tivoli and Unicenter monolithic strategies.

I'm still concerned that a monolithic IT strategy equates to vendor lock-in (as it does for ERP in general)

The Achilles heel of a more sensible longer-term strategy is perhaps expediency. In the meantime we need to do something. let's do some integration/fereration. Oooh look we've "solved" the problem.

What can be done against it?

So if you are not pursuing the holy grail, not believing in monolithic data soultion nor in federation / system integration? So what does work for large enterprises with >1000 IT staff? What is different for smaller IT (e.g. 500, 50 & 5?)?

How do you determine service impact?

Larger enterprises have to do something to manage configuration data and try to get consolidated views of service. Anything is ugly: either you go into integration hell, or you sell your soul to a vendor.

Smaller enterprises should consider on-demand CMDB: fix/improve/rehearse the configuration processes first before thinking about technology, rely on people (plural) as your impact engine, and derive the service configuration on demand instead of trying to keep it recorded all the time.

95% of sites don't have a CMDB. So what are you doing folks? How do you determine service impact? What techniques, tricks and tools do you use? How can we do impact analysis better without CMDB/CMS?

Determine Service impact by starting with Services

The illusive creature "Successful, Ongoing CMDB/CMS" debate...

I would argue that one of the failings of Configuration Management didn't start with anything wrong in the ITIL books. I think people took from it what they wanted, decided that it was an inventory, a repository, a warehouse, etc. - which were all incorrect.

Starting a CMDB bottom up with technology, data models, relationship diagrams, etc is an excellent source of mental masturbation - but it doesn't solve the problem of determining service impact.

Having been involved with many Configuration Management initiatives, I would have to say the one thing lacking was the service perspective, which at the time was considered "an aspect". I think for a CMDB/CMS to have even a chance of being successful (delivering the value intended), services should be "the aspect" and it has to be created and managed;
- Purely from a Services perspective, ergo, you need to understand your services and the value you deliver to customers first
- Actively, with tight integration to Change Management;
- Efficiently, meaning we don't need to manage CI's to the bit level (best guidance I got here; Lowest level of independent change the provides business value); and
- Selectively, meaning based on services, we leverage automated means such as Auto-Discovery to validate CMDB/CMS contents, but our data should represent what is authorized, vs. what is actual. I would also add that the most important data, typically isn't discoverable...

While I always enjoyed the challenges of CMDB/CMS and Configuration Management, from a business value perspective, I have to agree - it's not on the high priority list.

Vendor Lock-in

You make a good point on vendor lock-in. If memory serves, General Mills was one of SAP's largest R/2 installs on the mainframe (Amdahl?), for about a decade. Plenty of time to bake in a monolithic data strategy.

I suspect SAP and R/3 was the only option when they finally decided to modernize. If memory holds, they simply switched to HP Superdomes (9000s?), with another mainframe-like strategy, and performed relatively little business process re-engineering. Not exactly the bold ERP transformation success story touted.

No such animal as "ITIL Compliance"

ITIL is a non-definitive framework - it was that in v2 and is even more so in v3.

Therefore no product should be considered as "ITIL Compliant". A product may be more or less "ITIL Compatible" or "ITIL Enabling", but not Compliant.

You can talk about Cobit or ISO standards compliance of a product, but not ITIL.

the word compliance used deliberately.

yes we've been through that arguement. I was being deliberately provocative by using the word compliance.

i disagree totally. The following remark

So it is quite true that Pinkverify does not claim "compliance". But it certainly does assert assessment, validation, verification, certification, compatibility, comparison against criteria, explicit demonstration of commitment, reassurance, diligence, support for definition and requirements, and guidance met, which does not leave much else in the thesaurus.

applies as much to these discussions around the word "compliant".

Common sense says you can tell whether something is compliant to ITIL. If it looks like a duck, walks like a duck and sounds like a duck....

ISO 20000 compliance

Whilst it applies to other standards I think that claiming ISO 20000 compliance would be somewhat meaningless.

ITIL Compliance

Just add my two cents:
* Agree that ITIL compliance is an inaccurate phrase.
* For my money, PinkVerify is a complete waste of time and money for vendors to pursue other than to placate users who want to 'implement' ITIL and don't want to do the leg work to understand either ITIL or the product itself. Many ITIL implementations were successfully completed with pre-ITIL Remedy, and many unsuccessful implementations have been attempted with verified products so that Verify is not a guarantee of success and neither is the absence of it a consignment to failure.
* I am looking forward to the Pink Verified product that will help me "implement' the new service strategy book. I think that Einstein, Newton and Hawking will need to step up to the plate probably supported by Gödel, Escher and Bach.
* Verify is of course a great commercial business for Pink and good luck to them as long as they can get away with it.
*I think that I disagree with Jimbo - ISO 20000 is a real standard and therefore compliance can be measured as it has "shalls and musts" while ITIL V2 only has one directive comment in the whole library. Compliance with ISO 20000 is both possible and advisable.

Just feeling quite ancy today :-)

It isn't that it isn't possible...


My point wasn't that it isn't possible for a tool to be compliant with ISO 20000, but rather that the compliance would be of limited value, because you could run an ISO 20000 compliant with pen and paper in theory. Conversley, of course, you could implement a "compliant" tool in such a way that it fails to support the requirements of the standard.

Do your ITIL tool due diligence

Excellent topic and list of questions.
As an ex-tool vendor employee myself, it used to concern me the lack of diligence that many orgs (not all!) undertake when looking for a tool, particularly in the area of ITIL 'compliance'.
Also with respect to the Pink verification - the vendor I worked for lied blatantly in the verification submission and never had to fully substantiate the claims or provide a complete demonstration of the tool. Even more worryingly, this behaviour was repeated through certain very high profile analyst tool reviews/reports.
The moral of the story - do your due diligence. And don't believe the ITIL hype.

Disagree on seriousness of verifications

I partially disagree. I personnally conducted a PinkVerify Certification a few years ago, and I must say the Pink Elephant consultant (who was an ITIL specialist) spent several hours verifying the vendor's claims. So, yes, there may be some vendors who lie during the certification process, but not all of them do this, and a Pink verify Logo is something you don't get easily. Pink verification has almost nothing to do with analyst studies, and I agree Analysts never verify the vendor's answers. But there is a difference : Pink consultants are ITIL specialists with real field expertise.

I am not member of Pink Elephant and do not have any relationship with anyone within Pink as of today.

Give Pink their due...

...Pink Verify is the nearest the market place has to an independent verification process, though it worries me that in this case it only took "several hours" to verify the vendors' claims - it usually takes me several weeks before I really get past the hype to discover the substance. However it is certainly true that "Pink consulants are ITIL specialists with real field expertise" (though I have to admit to having worked with Pink many years ago)

I find Pink Verify a useful way of deciding whether a tool set should be on a client's longlist, but that there is still a lot of work I have to do before recommending a package to a specific client.

In the old days it was so much easier, you just asked them how they handled problem records, and when they said something like " Oh you just change the I prefix to a P" you knew it was safest to just walk away...

The "long list" is dead right!

The "long list" is dead right! I like that. And you are right: the only way to know a product's real capabilities is to use it in anger. What Pink and other analysts ought to do is to talk to the real users, not tame one's referred by vendors. The internet makes it easy to get the answers on the forums. Sure you get bitter and twisted characters with an axe to grind - one or two of 'em on here - but if you mix that with the vendor's candy you come up with something approaching reality.

Trademark infringement?

If it was not for the fact Pink once owned the ITIL trademark in North America I would suggest their basing a product on ITIL is real close to trademark infringement. We once requested (officially) from OGC a similar use of the name (Enable-ITIL), it was declined, citing the need for an as yet to be produced 'value-add' license. Anyone out their willing to give their free legal advice on use of a brand name in a product for profit seemingly without permission?

It's called Pink-Verify, not Pink-ITIL

It's called Pink-Verify, not Pink-ITIL

OK I'll add to the comment

OK I'll add to the comment above and say I am a second person who has seen vendor claims made to Pink Verify and found some of them to be a stretch of the product's capabilities.

I realise this is pure hearsay, and we may both be talking about the same product. I have a way of contributing more reliably to this question which I hope will see the light of day before our southern winter is over....

Most software product reviewers are naive at best

Most software product reviews are done "on faith" and reviewers almost never make the effort to actually see and use the tool. This is naive at best.

You can get a review of a mobile phone on the web where the reviewer has used it for days then taken the thing to bits - and the review is free.

You can get a software product review from an analyst and they will have done no more than ask the vendor a few questions then ask the vendor's pet reference site whether they think they made a good decision spending a million bucks of somebody else's money on it ...and the analyst will charge you thousands for it. Or the vendor will give it to you for free.

compliance & interoperability

I wonder if 'ITIL compliant' is what we should be looking for....I'd like a non-technical explanation of how various emerging standards (OASIS, DMTF, etc.) play into the tools world and how they may help with interoperability.

The various standards bodies are as much of an alphabet soup to me as ITIL is sometimes (and I'm a Service Manager). I think if the market embraces ITIL (and ISO 20K) then 'ITIL compliance' will follow soon enough; but that may not equate to interoperability, will it?

I am not big enough, or smart enough, to suggest I have the ideal 'compliant' checklist. In truth I suspect this is not acheivable anyway; every customer's needs are unique ---- even with ITIL and ISO 20K.

Knowing what process elements of ITIL you need in your tool, based on your current postion, suggests that you should do some discovery and process definition first. Problem is, it is very tough to do and make progress at the same time.

(You're a fool with a tool, but you're a fool without one too!) Try SaaS tools early on (where you can) and when you've done your homework, issue an RFP; it might be worth the time & effort.

John M. Worthington
MyServiceMonitor, LLC

Syndicate content