|By Anders Wallgren
|February 22, 2017 02:54 PM EST
In our recent Continuous Discussions (#c9d9) video podcast, DevOps and ITIL experts discussed how ITIL and DevOps can work together.
Our expert panel included: Kaimar Karu, head of product strategy and development at AXELOS; Robert Stroud, principal analyst at Forrester; Mike Kavis, VP and principal architect at CloudTP; and, our very own Chris Fulton, Anders Wallgren and Sam Fell.
During the episode, the panelists discussed ITIL’s relevance in a DevOps world, and how DevOps practices can be incorporated within an ITIL framework for key use cases, such as change management, incident management and more. Continue reading for their expert insights.
Is ITIL Still Relevant in a DevOps World?
Stroud continues to see more and more organizations throw their hands up over ITIL: “To quote a discussion I had yesterday with a Fortune 100 company, the CIO said to me, ‘We’ve actually terminated our total investment in ITIL. There will be no more ITIL courses approved in this company. If somebody mentions the word ITIL, they’re looking for a job.’ So fundamentally, there’s a rapid change going on, and we can go through our data which shows that people who are doing DevOps have this misnomer or this proposition that traditional ITIL doesn’t work with DevOps. Let’s think about this traditional change that’s happening – we’ve got a change that’s going to production, and as it goes into production, we’ve got 32 approvals, and development developed the code in a week, and it takes me 12 weeks to go through the change management approval cycle. This is a real use case. And this is what’s annoying the living daylights out of people right now, it’s that ITIL’s just not relevant.”
ITIL can be frustrating when the level of output increases from dev, but that doesn’t mean it’s bad, says Wallgren: “I use this video in my presentations, it’s from the ‘I Love Lucy Show’ when she’s in the chocolate factory, and her job is to package the chocolates that are coming down the conveyor belt. And the conveyor belt is moving too fast for her to be able to do it, so she’s got to start eating them and stuffing them in her clothes, and all that sort of stuff. I think that’s the way lot of ops teams feel. Now that dev has cranked up the conveyor belt a little bit faster, ops has to figure out how to adopt or how to accept that. There is an impedance mismatch there between the output and the input, and there’s pain there. That doesn’t mean ITIL is completely wrong, it just means you have to figure how to make these things work more smoothly together.”
ITIL does not have to be as long and laborious of a process as some assume, states Karu: “Making people to go through 30 plus hoops getting a change approved, that is not actually ITIL. That is nothing like ITIL. One of the answers I sometimes give to this question is, show me where it tells you in the ITIL publications that this is the way you should decide the process. When we talk about development and operations, development has been able to push out codes quickly for a very long time. So that capability has been there but it has been a slightly different capability.”
When development and operations teams harmonize, good things are bound to happen according to Fulton: “I think a lot of the pain with DevOps for me is truly putting dev and ops on the same team. Because in the past I’ve seen the finger-pointing, ‘Oh, it’s development’s fault because they gave us crap,’ or, ‘Oh, it’s operation’s fault because they can’t get us stuff installed fast enough.’ It’s truly about putting those two on the same team and having them work together. It’s good to have an operations person realize the issues of a developer, and it’s good for a developer to realize that the operations person may put these processes in place, because if the website goes down, they lose a million dollars.”
It’s not ITIL that’s gone wrong, it’s the implementation of ITIL, says Kavis: “A lot of times people poorly implement ITIL, and they had poorly implemented waterfall, so they go to Agile and they poorly implement that, and then they expect DevOps to fix it. Well you’re going to poorly implement DevOps, right? It comes to culture again. You have to build a culture of full-stack teams, where you talk about DevOps with your security guys. There’s all kinds of actors, so whether they report in silos or not, how do you form a full-stack team around this product or service you’re trying to build, and everyone’s accountable for the customer satisfaction, the reliability? Everyone’s accountable.”
For more on change management, audit compliance and more, read the full post here.