The IT Infrastructure Library has come a long way from its humble beginnings in the 90's. DevOps has shot to the top of the hype curve in the last two years, however some questions still remain. Is ITIL still relevant? Is DevOps the update to ITIL that it so surely needs? Does ITIL need to change at all?
Not resting on its laurels, ITIL has been updated, but I get the distinct impression that ITIL and the physical IT world go together like hardware and software. However, I think the nub of the problem is this – how can ITIL be relevant in a virtual and cloud services world without throwing the best practice "babies" out with the bath water?
Does ITIL even need to be relevant in the virtual IT world? I suggest that it does not and for the main reason that it is one of the best references for managing the physical IT domain. DevOps conversely is a set of practices for the virtual IT domain. I believe that it is not "ITIL vs DevOps", but is about demarcation and identifying where each is best suited.
Firstly let’s get a feel for both ITIL and DevOps…
ITIL – slow but steady
ITIL is process driven, process heavy, and some would even say bureaucratic. However when done well (adopting and adapting) there is no denying that ITIL can improve the lot of IT and their customers. The virtual IT world is defined by speed while ITIL processes are... well... not. To be fair ITIL processes are measured in terms of efficiency and effectiveness, but pure speed to market is not part of its DNA. And again this is my point, ITIL does not need to be relevant in the virtual world and therefore not concerned about speed, instead deferring that to DevOps.
Speed to market has become the defining measure for the effectiveness of internal IT organisations. Take your eye off this ball at your peril as there are plenty of service providers who will promise the speed your customers are demanding. ITIL has had a fling with speed, spawning methodologies such as "Lean ITIL" and "Agile ITIL", but have they really improved the way IT works? Have they really improved the customer experience? It reeks of trying to fit a square peg in a round hole. But does that mean that DevOps is a better fit?
DevOps - the IT renaissance
DevOps is a collection of practices combined with a culture focused on the customer experience. Remarkable customer experiences are baked into the DevOps feedback loop. In his musings on DevOps blog, Rob England believes that DevOps is part of an IT renaissance, and when asked what the enlightenment consists of Rob says that "DevOps is a new way of doing IT". This new way includes terminology (a bit like ITIL in that respect) and practices rather than processes. DevOps is about doing IT via automation. In contrast ITIL has the burden of process design, that can and does bog things down. Indeed the DevOps purists say "if you define it, you will kill it" (referring of course to application development rather than processes, but you get my point).
The new way of doing IT is based on three core practices:
- Infrastructure as code
- Automation (especially automated testing)
- Continuous integration
At its heart DevOps is about coding and deploying interconnected software environments that contain both the infrastructure and application code. Environments are deployed to ensure applications are resilient and can be managed using DevOps practices as they are used and changed. Software tools such as Docker, Chef, Puppet, SaltStack and Jenkins are just a sample of the tools used to make DevOps work. In yet another contrast, ITIL has not and would never tell us a process that runs better on Remedy, Heat, ServiceNow or Cherwell, and that is because it does not have to. DevOps only happens with software tools. Just like without documented process you are not doing ITIL, then you are not doing DevOps without automatically spinning up and testing application environments.
Rob continues to define the IT renaissance by adding to the “new way of doing IT” with new ideas, a new IT culture and a new beginning. New ideas come in the form of agile and resilient development. An example of resilient apps is the oft quoted Netflix 'Chaos Monkey' - code that is deliberately loaded to wreak havoc with production environments to ensure they are resilient. Yes you read that right. We are talking self-inflicted 'incidents' that are designed to prove or disprove that your application is indeed resilient.
How does ITIL handle that? Imagine this incident review:
Incident Manager "the Chaos Monkey is the root cause of the incident so let's log a problem to permanently remove it"
Application Developer "We can't, it’s part of our application deployment"
Incident Manager - "!" (stunned silence).
Given that Netflix survived an AWS storage outage where others did not, I’m pretty sure the Chaos Monkey is not going anywhere soon. So in answer to my own question, ITIL processes do not handle those incidents. Instead the DevOps teams respond to and fix these incidents, embodying the very definition of “you made your bed, you lie in it!”
A new IT culture includes teamwork and respect. Putting people over process and dropping the cynicism that can befall any IT organisation. This is not so much needed to make DevOps work but is actually a consequence of DevOps. With developers and operations people working closely together for customer outcomes then cultural change is inevitable. Gene Kim offers the example of issuing developers with pagers. Being woken up at 2am to fix a production bug does help change behaviour and has an enormous impact on code quality! As one of the Fathers of DevOps, Gene is worth following, and seeing his presentation on high performing IT organisations is a good starting point.
A new beginning is the hardest of all. Starting with new technology and a new mind-set may seem like it would make it easier to adopt DevOps practices. But what about all those legacy systems? What about all of those integration points and customisations that make upgrades nearly impossible, let alone rolling out incremental improvement?
The answer is to ignore all of that and really, yes I mean really, start with new. This is best summed up by Tom Goodwin in his 3 Big Trends for 2016. "In 2016 ALL legacy companies should seek to retool for the future. They shouldn't upgrade systems, it's like building a 3rd runway at Heathrow, they should build in parallel a new system for the future, to replace everything. To open in one new go. It's not new signals on an old train line, it's a brand new high speed line built alongside, which is faster and always ends up cheaper and boosts capacity."