Event Management's Moment of Truth

This post is about a recent Keeping IT Real Webinar and a new White Paper titled the same as this post. To those who were kind enough to provide me some feedback on the White Paper, my sincere thanks.

At 30 pages some thought it too long (I kind of agree), and others felt that some areas needed further clarification (I agreed here too). So I'm simply posting it as is --- White Papers don't pay the bills any more than this blog does, and my real motives for writing it will be outlined in this post anyway...

For the past 3-4 years I have evangelized monitoring and (with the release of ITIL Version 3) Event Management automation as a 'better' path to IT Service Management excellence than trying to force process changes and build CMDBs. I believe this more today than I ever did.

In fact, the current frenzy around Service Catalogs is an indication of the general agreement that without defining services (business services) from the 'top down' you will find it tough to reach the paradigm shift that IT Service Management demands. (DUH!) The continued hype around the CMDB, now to include CMDBf, is not really helping matters either...

With service infrastructures continuing to increase in complexity, and now becoming VIRTUAL, the last thing IT needs is more complexity! The big gorillas have deep pockets, a huge portfolio of technologies and marketing savvy but that doesn't equate to a simple, effective solution. 

CMDBs have been built largely bottom-up, have focused on static configuration data, and got organizations focused on processes and workflow. As far as I'm concerned the results have been more Wicked Problems and Death Marches.....So much for changing IT's culture!

There will surely be more techno-babble around Event Management in the future. Some of it will be valuable, but I suspect that much of it will serve vendors more than customers and be shrink-wrapped in complexity and marketing jive.

The Right Road to IT Service Management excellence has service monitoring intelligence and therefore Event Management automation at its core, which is what I continue to rant about 3-4 years later.

It's fundamental value proposition is eerily similar to Event Management's purpose:

The ability to monitor what is happening at every layer of every component across a distributed and increasingly virtual array of compnents --- network, system, and application -- and automatically identify which layer of which component is the source of an anomaly.

However, these kind of projects continue to be Wicked in nature. Not because of a lot of technical complexity but because we are changing social norms --- precisely what we need to do!

I hope you will consider service monitoring intelligence as the guiding force for your CSIP, and stay away from what I've called 'Visions of Nirvana' over the years ---- long term, technical 'evolutions' and incremental 'paths' (like CMDBf) that promise much but at the end of the day (or year) deliver little. 

We have proven the ability to very rapidly instrument end-to-end service infrastructures with all kinds of underlying technologies --- including virtual technologies now --- if customers have committed themselves to defining at least a few business services. This can happen in weeks, not months (or god forbid, years).

My technology preference has always been clear and in the open. But this is not about that, IT Service Management --- and service monitoring intelligence --- may be more about People.

It's about time we got around to that.


Copyright, MyServiceMonitor, LLC

ITIL® is a Registered Trade Mark and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the US Patent and Trademark Office.

PMI is a registered trade mark of the Project Management Institute, Inc. which is registered in the United States of America and other nations.

<site map>