At least one area of IT where we do not have to deal with that idiocy.
For crying out loud since when is the UK government entitled to teach any of us in the private sector on how to do IT. Did they suddenly deliver an IT project on schedule and on budget? Are they the golden standard of customer service? And so on.
Dunno about the rest of el reg readership, but I for once am happy that there is an area of IT which they (or their servitor abbreviation generating muppets) are yet to fail to screw.
Thing about government IT projects is that the successful implementations are transparent to the end user. So, yes, government has just put a system live early and under budget delivering payments on a scale that would scare the crap out of you.
And, no, its not an exception. The IT supporting Universal Credit is one of the most innovative and challenging IT projects that any one could ever work on.
I've been i both private sector and public and when you trot out the old line about public sector IT you sound like a complete twat. Is that what you want?
When you've delivered £200million of IT changes into a vast legacy infrastructure with multiple stakeholders, deadlines set by election dates rather than the critical path activities ministers and news crews looking for a screw-up and no ability to sweep the mess under a carpet of commercial confidentialty the you can talk.
Until then, how about a bit of professional respect eh? .
ITIL Is Not a Cure-All!
I've done admin and systems design work in a few "ITIL shops". The reason that's in quotes is because, in my experience, being an ITIL shop involves paying 7 figures to an enterprise software vendor for service desk/change management software. The software is then deployed with zero customization, and every single ITIL process, including the ones that don't make sense for that particular org, are put in place.
This is the kind of environment where requesting a change involves the *entire* ITIL procedure, including filling out generic change management forms in the software with 150+ mandatory fields, the change management meeting, backout plan approvals, scheduled maintenance windows, post-change reports, etc.
Unfortunately, I wish there was a better way to do what ITIL sets out to do. It seems like you either have a situation where it takes 21 days and the CIO's personal approval to provision a network port, or mad cowboy admins from the local tech degree mill wreaking havoc on live systems 24/7.
The sad thing is, because of these cowboy idiots, those of us who take the time to properly learn the sysadmin trade are reduced to form-fillers and button-pushers. I'm all for planning a change properly and not getting yourself into a situation where you can't recover, but when it gets crazy, that's no fun either. (Example I've heard -- RAID 1 drive fails, change management process prohibits replacing the mirror drive without a million approvals, and the other drive in the mirror dies before the change can be approved! A zero-downtime change becomes a multi-hour outage...)
Ironically, VM technology makes things much more flexible, giving the cowboys even more power if you don't control it. I'm guessing the changes in ITIL for the virtual world are going to involve even further separation of duties (you'll have a "VM provisioner", a network guy, a storage guy, and a security guy all involved with any server build or change, etc.) ITIL is sold to CIOs and corporate boards as a complete cure-all for IT ills -- just have your staff follow this entire set of guidance and you will never have downtime. Reality is (a) the cowboy admins will find a way around it, (b) the processes are so paperwork-intensive that the environment stagnates because no one wants to go through the hassle to fix something, and (c) the better IT staffers will leave to work somewhere that gives them just enough freedom to keep things running.
Sounds like piss poor implementations then
The company where I work, a failed service gets fixed (lets use your failed drive example) as soon as possible, the change requests can be submitted after the fact. Even in more complex cases ITIL does recommend you have an emergency CAB who can evaluate and decide - rather than 10 dept heads you can have the change mgr, the incident mgr and a couple of techies to tell you whats what.
You can also define pre-approved changes to accomodate network patching, account creation & alteration and the million other admin tasks a IT dept undertakes. As long as you record the change and you don't stray too far then it works. Obv if some clown decides to repatch the server room without telling anyone then you have a problem, but by and large, if you have a demonstrably repeatable task then it makes sense to setup a pre-approved change template for it.
tl;dr don't blame ITIL for piss poor management
A couple of points on your great article:
I don't think ITIL is struggling per se. In my experience most 'ITIL Implementations' fail (note the carefully placed quotes) because companies use ITIL as the end/objective, not as what it should be: the means to an end and an enabler of IT as it delivers the services the business needs. A lot of companies go into 'IT Process Management' mode instead of 'IT Service Management' mode. Hence, the appearance of bureaucracy and bottlenecks. It is called IT Service Management because you're delivering Services, not Processes. ITIL processes will help you deliver the services, cloud or otherwise, based on proven, repeatable activities; Implementing ITIL processes (or the tools used to support ITIL, for that matter) by themselves does not provide any intrinsic value to the organization, in my opinion.
Also. when considering IT Service Management frameworks, ITIL should not be considered in isolation. There are others that need to be taken into consideration, specially by management, to make sure IT Services delivers the value that the company's looking for. And this is crucial: if management wants to just 'do ITIL' that would be the first sign of trouble.
I don't necessarily believe that ITIL, or other similar frameworks, will become irrelevant by the Cloud. I do believe that the next version of ITIL will take into account Cloud Service and other things, but I don't think Cloud Services by themselves will render ITIL irrelevant. Organizations need to look at managing the Cloud as they look at managing other services: delivering services at agreed costs, service levels and with the value required by the business.
One of the few Certainties in Computing
ITIL Never Work!
Well HSNT Yet!
Best Practice evolves, it can't be dictated.
So really what you're saying is "no change"
Properly defined to fit the business needs, ITIL is a Good Practise framework that will drive an efficient IT service.
Poorly defined or implemented and it is just a millstone around the neck of the business.
When we went on our ITIL v2 course as far as I could see it all boiled down to common sense. Most (not everyone got it) of us just had to learn the new labels for what we were already doing, i.e. service management.
I have my ITIL v3 cert, but still haven't
been employed in a shop that implements ITIL. What I learned looks like a good framework for organizing IT processes. What also seemed obvious to me is that implementing ITIL will magnify management: Good management will get better, bad management will get worse.
The one place where management still seems to get hung up is on Change Management. I've come to believe there are three types of Changes: Standard Changes, Semi-Standard Changes, Full Changes. Standard Changes are things like activating an internal network port. You do them routinely, the risks are well defined, the recovery process is well defined, and as long as you stay within your provisioning margins not a problem on that front either. Semi-Standard Changes are things like applying monthly MS patches - mostly routine but a little bit different each time, requires a bit more thought on risks, usually requires some testing both pre- and post- install. Full Changes are things like standing up a new SAN. Full risk analysis is required, as well as a extensive testing. Standard Changes should be implementable without the requirement for prior approval although they still need to go in the CMDB, Semi-standard require a light to medium review, and Full Changes require the full blown CMB review and at least a 14 day lead and an expectation that the process will require a month or more depending on the actual extent of the change.