The IT Skeptic - Comments for "ITIL product compliance "

Determine Service impact by starting with Services

CyberJMC66 — Tue, 02 Mar 2010 14:49:25 +0000

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.

How do you determine service impact?

skeptic — Tue, 02 Mar 2010 03:53:00 +0000

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?

What can be done against it?

mbuzina — Mon, 01 Mar 2010 20:16:38 +0000

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?)?

Vendor Lock-in

Visitor — Mon, 01 Mar 2010 02:29:43 +0000

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.

The holy grail

skeptic — Sun, 28 Feb 2010 19:44:30 +0000

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.

Plenty of success stories

Charles T. Betz — Sun, 28 Feb 2010 14:15:42 +0000

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
http://www.erp4it.com

monolithic

skeptic — Sun, 28 Feb 2010 08:30:42 +0000

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.

Don't move the data at all

Charles T. Betz — Sun, 28 Feb 2010 03:09:36 +0000

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
http://www.erp4it.com

both tigers, different stripes?

skeptic — Sat, 27 Feb 2010 23:55:30 +0000

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...

Fools rush into federation

Charles T. Betz — Sat, 27 Feb 2010 23:24:06 +0000

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
http://www.erp4it.com

Here's one more:

jody_l_roberts — Sat, 27 Feb 2010 18:39:06 +0000

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 http://www.hp.com/blogs/itsm. I am transparent. And apologies to Billy Crystal for the Princess Bride crack.

The 13th ITIL Compliance Criterion

skeptic — Wed, 08 Aug 2007 09:37:34 +0000

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

the word compliance used deliberately.

skeptic — Fri, 29 Jun 2007 21:38:00 +0000

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....

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

JamesFinister — Fri, 29 Jun 2007 11:47:40 +0000

Alan,

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.

ITIL Compliance

Alan Nance — Fri, 29 Jun 2007 11:13:36 +0000

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 :-)

ISO 20000 compliance

JamesFinister — Fri, 29 Jun 2007 10:34:51 +0000

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

No such animal as "ITIL Compliance"

pshotts — Fri, 29 Jun 2007 09:15:22 +0000

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.

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

skeptic — Wed, 27 Jun 2007 06:11:06 +0000

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

Trademark infringement?

ianclayton — Wed, 27 Jun 2007 05:39:47 +0000

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?

The "long list" is dead right!

skeptic — Mon, 25 Jun 2007 21:49:18 +0000

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.