Have you heard the good news?

The 800-pound gorillas have formed an 'alliance' in order to provide interoperability between their respective CMDBs. Of course I thought OASIS~DCML has been working on that, but I admittedly couldn't tell you technical folks squat about OASIS~DCML or what the hell our 800 pound friends are up to...maybe somebody who can translate the geek-speak into a language we can all understand will help us...

as for me, I got some serious deja vu  going on....but perhaps more importantly, if you're implementing --- or want to implement --- IT service management best practice based on ITIL how does this impact your Road Map? Should you shout halleluia and just trust your 800 pound gorilla of choice to provide interoperability someday as promised? (If you do, I have a bridge I'd like to sell you)...

no, there are other (safer) options available to you. You KNOW that you must start with an analysis of your current processes first, so don't even think about tools until you've completed this step. However, if you've analyzed your processes and believe that automation (via a CMDB tool) is in order consider this:

1. 1) The CMDB, like any tool, must automate your processes based on 'Where You Are Today'
2. 2) The CMDB, like any tool, must provide a clear business case
3. 3) The CMDB, like any tool, should create value to the organization QUICKLY

Of course, even if you decide you want a CMDB you'll have to understand and define those nasty relationships between CIs (which really means at least some degree of SLM --- ok, ok so we buy an SLM tool right? NOT )...

and how about the fact that (according to IDC, et al) most of the savings attributed to IT service management seem to be focused on more effective and efficient problem isolation & diagnosis (see Building an ITIL Business Case?...Slow & Steady Wins the Race)

finally, ask yourself: How long will it really take to achieve a CMDB as ITIL defines it? (see some interesting discussion at the ITIL skeptic)

While it's hard to question the staying power of 800 pound gorillas, there are some tenacious little badgers in the forest that can really help focus your Journey on the Right Path without holding you hostage waiting for interoperability nervana. One of these is one you've heard about from me many times, as I'm a former customer and 'true believer'; a small firm called eG Innovations.

This company has spent less time hyping ITIL and CMDB and much more time keeping thier eye on the effective & efficient problem isolation ball...quite simply, the software leverages a patented data flow and dependency based correlation logic that enables them to monitor what is happening at every layer of every component of an end-to-end business service, and automatically identify which layer of which component is the source of a problem. No rules to write, no code, no kidding!

As important, they do this across 75 major applications and platforms out of the box. I mean, out-of-the-box -- up and running in less than a day.

They call this 'service monitoring'. I call it 'A Good Way to Achieving the Paradigm Shift Required for Higher Levels of ITIL Process Maturity While Establishing a Foundation for a True CMDB and Letting the Gorillas Know That a Vision Won't Put Fires Out'. OK, I admit it's not a very catchy marketing slogan, but you get the point don't you?

You can wait for the 800 pound gorillas' Vision to become reality, you can Trust them now (and hope for the best) or you can focus on other areas that bring value (immediately) and gradually build the foundation of knowledge you'll need anyway to populate those beasts.

So get on the Right Road, but keep those headlights on!

(as posted on the n-tiers without the tears blog)

Somebody asked me about "Quality of Experience' (QoE) recently. While those in technical silos may offer a brilliant dissertation on abstract polymorphic interfaces in clients and servers (see Button, Button, Whose Got The Button? Patterns for breaking client/server relationships, by Robert Martin) or even Distributed QoE, my answer is quite a bit simpler.

In my experience users will (usually) let you know if their experience is poor. You don't like the program, you change the channel. You get bad response from a web site, you shop somewhere else. So, of course you want to know what your users are experiencing!

However, different IT tribes will want to measure QoE for different reasons. Many want to be warned of a storm brewing, and be well prepared to explain why thier tribe is not the source of the problem (or fix it before they call). I call this the "it's the other bastards fault" motivator.

QoE is absolutely consistent with best practice. However, when investing in QoE technologies one should be careful of who is defining QoE (i.e., QoE of what services?). It should be the customer (read business process).

Two things worth considering before putting your budget dollars on the line: 1) Defining 'end-to-end' - Citrix access services is NOT a business service. It may be a critical segment of an end-to-end business service, but it is rarely the entire service. So, having 'end-to-end' knowledge of the Citrix servers right to the desktop is great --- but most business service infrastructures have a dizzying array of network devices, web servers, application servers, data base servers and applications.

'End-to-end' means every layer of every component required to support a business process.

2) What are you prepared to do? - So you took the plunge and purchased a QoE tool. Now that you've been warned (pray that your investment will warn you of an impending storm; otherwise your user could have told you --- for free), how will you isolate and diagnose the problem? Nice to know it's not in the Citrix server or the client, but then where is it? This is where analytics come into the picture (see Analytics & IT Service Management on this blog), and things can get really complicated. However, it's good to focus on this objective:

The key to effective business service monitoring is the ability to monitor what is happening at each layer of the infrastructure --- across an array of distributed network, system and application components --- and automatically identify which component layer, in which domain, is the source of a problem.

QoE decisions, like many technology investments, can be tribally driven. This is particularly true if the organization has not invested in the time to understand and define 'what is a service' and performed some due diligence in analyzing processes.

Some IT tribes will display true leadership and go beyond thier comfort zones by incorporating other technical silos into the equation, but I suspect this is going to be difficult for many. Taking an approach driven by best practices (such as ITIL) can help avoid experiencing the angst associated with knowing with absolute certainty where the problem isn't, but not knowing where the problem is.

I wanted a place to rant about ITIL, CobiT and other best practice frameworks and share some experiences with friends, peers and basically anyone who wants to listen and join the fray.

I picked the title of this blog because it makes me smile, for many reasons which I won't go into here, but let's just say I'm a child of the 70's and leave it at that. I also believe that the real road to a quality culture has more to do with people than with process (which may make some ITIL fanatics scream in horror), since in the absence of process it is values that carry the day.

I am in awe of many IT professionals --- many much smarter than I --- who are literally killing themselves keeping the cars on the road as the business keeps its foot firmly on the accelerator (and in some cases on IT's neck). They have my admiration (and sympathy).

For those customers who lack both process and values, it was nice knowing you. The business and IT are simply getting too complex, the world is moving too fast, and big brother's getting much better at watching you for you to last much longer.

For those of you who know the difference between right and wrong, and are struggling to do the right thing (i.e., best practice), then consider this a place to vent, to rant and to share some humor as we continue down what we know is the Right Road.

A savage journey indeed, and what a strange trip it will be.