DevOps and ITIL
Recently I had a few things to say about DevOps. In a nutshell, DevOps is a niche approach to service design and delivery, which won't have much impact in the near future on traditional Operations of core systems. The concept of better integration between Dev and Ops is good, but the cultural issues and most of all the risks speak against it. And the way some people interpret it is downright dangerous. Now I want to zoom in to look at the relationship between DevOps and ITIL.
My e-quaintance Botchagalupe (well he used to speak to me before these posts) pointed me to two ITIL-specific DevOps links, then our subsequent attempt to debate the content on Twitter (like having a boxing match in a phonebooth) led to this post.
In essence, there is a core of thinkers within the DevOps community who understand what IT management is about and are sensible about the use of ITIL within a DevOps context; and there are others with a looser grasp on reality in general and ITSM in particular. They range from the gentle hippies who just want a nicer ITIL, to rabid cowboys who prance about declaring the end of ITIL because DevOps has apparently rendered it irrelevant or inapplicable or outdated. (I hasten to point out that Botchagalupe - John M Willis to his family - is in the thinking camp; his CALMS model of DevOps is great).
This range in views comes through loud and clear in many DevOps-related links when you look at comments or threads.
Ben Rockwood would have us believe "ITIL is kool again" because DevOps is turning on and tuning in to such rad concepts as change control, and the "new ITIL" is a grass-roots driven people's movement rather than "forced from the top down" by "executives" (read: The Man). Yeah whatever dude. In the walled gardens of DevOps this may be revelation, but in amongst the big iron ITIL never got lost.
Ben is right that DevOps is "is currently mostly affecting SMB and startups which have been, for the last 3-4 years, greatly influenced by the webops shops." That about sums up the home range of DevOps, yup.
Actually I shouldn't hang it on Ben. Gen XYZ may not have discovered the realities of running a business yet, but he clearly identifies that DevOps is a cultural movement, not a bunch of cool tech toys. I'm all for that cultural movement (I've advocated closer cooperation for years via Dead Cat Syndrome) - I just don't think we need an agile revolution, fast change, or automated Chefs and Puppets to achieve it in most IT shops.
So I liked Ben's post even if I didn't buy all of it. I liked the comments even more (down to the spam ones - Ben, do some housework).
Then I wandered into the other thread John sent me, a forum discussion. It starts out well with common sense posts but then starts to go downhill. One person said
If I understand ITIL right it means "no ticket - no service".
Clearly you don't, Marcel.
Reading the thread, watch the developers uncover exciting new concepts like ticketing
using a ticketing system with Scrum or Kanban gives my management and peers a lot more visibility into not only the amount of work I am doing but also the exact amount of time it requires. No more underestimating the time or resource requirements. :) ... Not tracking my work through a ticketing system would be a nightmare!
though others were still having trouble grasping the concept
I believe people shy away from ticketing systems because they are used as a heavy abstraction layer. They don't like to open tickets because the request will get lost in a sea of other work, etc.
Others stumbled across change control
I found that the proper enforcement of change control procedures (all changes go through "development" and staging phases, even our own) actually made my concerns a non-issue. Not only did I have to perform the work multiple times, but I sometimes found flaws in the deployment/change plan.
Oh wow, like amazing. This thread reminded me of teenagers debating whether money is a good thing. The naivety and lack of conception of what ITSM is and why we have it is just amazing. In their sheltered little development workshops, it seems some of these guys have no idea what the real world of service delivery is about. They are blissfully (and often willfully) ignorant of the requirements of Sarbanes Oxley, of managing to a budget, of profit and loss, of reputational damage.
I've seen DevOps folk mention the book Visible Ops several times as if it were some sort of holy grail. This makes sense: Visible Ops is a primer for the dysfunctional, an emergency kit for sites with zero process. (Read the cover: "starting ITIL". Must have been a fertile field in the USA a decade ago). If you don't know jack-shit about ITSM then Visible Ops would seem like a masterwork, and ticketing and change control would seem like road-to-Damascus visions.
Perhaps ITIL is an excuse for bureaucratic assholes to just be obstructive because they enjoy it (in which case shoot the messenger not the message) but when I read
I still feel however that ITIL appeals to a certain kind of corporate bureaucrat. We have had ITIL service management "imposed" and it is seen as the holy grail by our central services managers. I have attempted to bring devops and agile practices into the conversation but the suits are not interested.
I still feel that the attitude problem might be on more than one side. This smacks of a hippy-dippy anarchistic resentment of authority and rules which misses the whole point of organisations: to generate value and to protect it.
ITIL is as flexible as the culture that adopts it. I said in comments after the previous DevOps post, holding up worst-case scenarios of bureaucratic change control as a justification for rejecting processes is as bad as my characterisation of dev techs. Change management without Standard Change is inexcusable - if only ITIL made that explicit. And I'm a huge fan of people actually talking to each other... but so is any good manager. Change management will only ever achieve successful cultural acceptance if it minimises pain and maximises efficiency, which is all about Standard Change and easy CAB and all the "agile change".
It may be in years to come that the anti-ops factions fall away from DevOps, and Agile becomes proven to be safe, and deployment and control can be automated in cost effective and low risk manner. That will be a happy day.
Until then i'll go on promoting standard change, operational readiness (dev/ops collaboration), evolutionary process improvement, and most of all cultural change programmes, all within existing ITSM frameworks such as ITIL.