incident

Calling all you ITIL theorists, philosophers, pontificators and pundits. Marty is back: our follower from the real world, trying to make sense of ITIL on its home grounds, the operations of big iron batch computing. Marty asks what happens after a service is restored? What does ITIL call the function of undoing the damage done while a service was unavailable? I have a view - of course - but I'm going to stay quiet - for a while- and hear what everyone else thinks. So have at it.

Could it be that the personality and skillset of the Major Incident Manager is more important than what role they have in the organisation? I think so. Too often we get hung up on theory and lose sight of what matters in a crisis - people.

Long ago we used to follow the one true Codd, and data normalisation mattered. Now middleware, messaging, MapReduce and Twitter seem to have blown that idea away. Charles Betz may not agree but it seems to me data modelling is in retreat. Certainly it amazes me that a framework like ITIL can gain such ascendancy without even a token effort at a data model. (Personally i think that is just pandering to the vendors with existing products who would all end up with a non-complaint model). As a result I think some obvious entities are missed out, and one of those is the Interruption.

Complex systems are by definition broken. They will always break and sometimes they will break when everybody did what they are supposed to. Fixing the problem won't necessarily reduce the risk of another incident.

A BOKKED post three months ago drew a lot of attention. It was about the disconnect between Incident and Problem Management in ITIL V3 Service Operation. [See also the ITIL Wizard stirring the pot about Major Incidents] I've just discovered a response to that post which has popped my brain with its simplicity and clarity

A hundred users call up and say they can't get emails. One incident or 100?

Fundamental and simple question. Go check ITIL for the answer. I'll wait.

The more I think about it the more convinced I become that the way ITIL and COBIT and ISO20000 structure incident and request fails the basic test of being customer-focused or business-aligned.

This BOKKE (body of knowledge known error) has been posted for a day or so, hundreds of views. I was sure someone would say "no you idiot, service impact analysis is right here" but not one. It seems to be true.

Unemployed skeptics have too much time to ponder things. As I lay sprawled on the footpath outside the labour exchange in the sun, it occured to me that although we are stuck with the word "incident" for historical reasons, there must be a better word for it.