Skip to content

September 26, 2018

How DevOps and ITSM Can Compliment Each Other (Expert Panel Discussion)

By IT Revolution
devops and itsm

What were once thought to be irreconcilable movements are now finding common ground, or are they? Alan Shimel of DevOps.com sits down with this great panel of ITSM, ITIL and DevOps experts— Cherry Vu, Rob England, and Jayne Groll to discuss how DevOps and ITSM can compliment each other and what the future holds for both.

This interview was conducted during the DevOps Enterprise Summit in London 2018. Some of the responses have been edited for brevity and clarity. Watch the full interview here.

Alan: Okay. So, the topic today is sort of crossing streams with ITSM and DevOps. You know, there was a time when I first started DevOps.com four and a half years ago, where if you told me we were going to do ITSM and DevOps at a DevOps show I would have said you’re crazy.

ITSM is dying, DevOps is replacing it. That’s the old; out with the old, in with the new. But what we’ve seen, over the last two and a half, three years, is that there is a place where these come together for the good of IT and humanity.

Rob, you’ve kind of led a lot of that charge, right? You also were a skeptic of DevOps.

Rob: I was and then I had a bit of a road to Damascus Conversion. But after that, I mean, I was talking about DevOps Run. You know, I think when the DevOps community talks about Ops, they don’t always mean what we think of when we think of Ops. It’s sort of Ops until it’s live.

You know, and that whole Ops after it’s live still tends to get lost. But, you know, as Cherry puts it, there’s less emphasis that’s talked about. It sort of dies away a bit, doesn’t it?

Alan: You know what? Let me hear what Cherry has to say…
Cherry: I consider DevOps and tools kind of like a happy marriage together because they support each other and they make each other better, so I think it’s a happy marriage if we do it right. And, as Jayne said in her presentation that they need to have better communication between them both and speak the same language, and understand each other just. We are looking forward to the same goal so why should they be separated?
Rob: We kind of went tribal for a while there is how I put it. We went to war for a while.

And the service management people going, “All these free-range cowboys, they’re dangerous,” that was me in the early days.

Jayne: Yeah, but I think there’s a couple of problems there. I think, first of all, when we talk about IT service management, we only talk about ITIL. And so, while ITIL is the most predominant of the frameworks and has given many of us a lot of best practices about IT service management, I think the concern was that ITIL wasn’t current, and ITIL didn’t address DevOps, and it was very much about ITIL. And again, there’s nothing wrong with the ITIL library, but services still need to be managed.

And I think that’s probably what’s trending now, is that there’s a recognition that you still need to manage change, right? You still need to do a lot of what you did. And to address something that Rob just said, you’re right, you know the original DevOps approach was, you press the button, it goes into production, and then you start again. And it was like, what happens life after deployment? And that’s I think trending a little bit now as well.

Alan: It’s more than trending a little bit. I will tell you what I’ve seen at DOES this year, is a recognition that as DevOps is maturing, we’re seeing where it ends, begins, meet-ups with other things, right? And so I’ve done a number of panels on whether you want to call it Next Gen Ops, or New Ops, what have you.

But certainly, a recognition that part of the maturation of DevOps is understanding ‘okay, look, we’ve got this CICD thing, not down perfect, but I think we’ve got our heads wrapped around it, right? We need to wrap our heads around what happens post-deployment.’ And to wrap our heads around post-deployment to just discount twenty years of ITIL and ITSM, and to throw the baby out with the bathwater is a little bit ridiculous.

Right? And I think that’s part of the maturity. That’s a mature way of saying, “Oh, they’re not mutually exclusive. Leverage, learn, learn how they go together.” And I think that’s why, frankly, all three of you presented here at DOES to standing room only.

Rob: Yeah, it was interesting to see the response, you were saying that beforehand Jayne, that a lot of people came.
Jayne: Yeah, that was a huge surprise considering I know during my session I had some pretty good competition in other breakout session happening at the same time, and it was standing room only, and I know at your session [Rob and Cherry] it was the same thing, so there is a lot of curiosity about how do we make this work?
Alan: Is it just curiosity?
Rob: Well, it’s beyond that now, isn’t it? It’s pressured. Dr. Richard Cook put it in an interesting way. And these aren’t his exact words, but he was framing it as if, we’re building a new kind of technical debt, sort of, because we’re now so good at pumping stuff out into production, and not so good at what happens after production, that we’re actually piling, you know, the issue has now moved beyond the ability to produce into the ability to run.

We can produce really well now.

Cherry: I think, yeah. Yeah, I do agree. DevOps tend to be very good and very focused on ‘making a baby’, actually. And they’re having babies, but who’s looking after it? So, ITIL, I think, that’s the theory, ITIL is much better in taking care of a baby.
Jayne: That’s a great analogy.
Alan: Yeah. You know, that all being said, let me just play skeptic.

ITIL numbers are down. People taking ITIL exams, I think we’d all agree. You know, we’ll probably see a spike with the next version of ITIL but a lot of that will be a sort of a momentary spike of people moving up. So, unfortunately, DevOps is appreciating ITIL just as ITIL seems to be coming down.

But will this kind of rapprochement between DevOps and ITIL see a renaissance perhaps of ITIL and ITSM as it blends in.

Rob: Well that depends very on how they do ITIL 4 doesn’t it?

So, you’ve got adaptive labs and, you’ve got the snafu catchers, you’ve got SRE coming out of Google, you’ve got these amazing new ways, new lenses on the same reality. But they’re deconstructing serious management and reinventing it through, almost a naïve way, they’re almost coming with no prior eye and then saying, “What does it look like?” Applying DevOps agile principles. If that gets absorbed well into ITIL, and if they’re good at learning from those things incorporating it, then there could really be a rebirth of ITIL. But if ITIL just sort of, refreshes version 3, then it’s not going to work.

So it’s how agile they make ITIL, really.

Cherry: I say if you look at the nine principles of ITIL’s now, who is to say that how much is different to DevOps?
Rob: The idle practitioner, yeah.
Cherry: It’s exactly what we are looking at, focus on the value or start from the small square where we are now, or whatever ITIL says, just ITIL practitioner.
Rob: They did a good job, didn’t they? And the ITIL practitioner book, what I call ITIL 3.5, they…
Cherry: They transformed themselves.
Rob: Yeah, they’re in the process of reinventing themselves already.
Jayne: But, you know, and I’ll be a little bit of devil’s advocate myself, so, unfortunately, when we start to look at nine principles versus three ways, versus partridge in a pear tree kind of thing, then we’re still at the same place. We’re still trying to recreate decorum, we’re not doing it together. And I think that of all the disconnects that we’ve seen, we’re not collaborating, we’re not one IT that the loyalty of, between one framework or another is still very much there.

I think though that when you start, you mentioned SRE, and I think what’s interesting about SRE, think about why DevOps became interesting. It was something new, it was something innovative, it was a different approach for a modern age, right? Really not that different. It’s about release, it’s really about build, test, deploy, something that comes out of scrum and takes it into go faster, shift left, all of that.

But it was new and it was cool, and it’s a very, very different, very modern approach. I think one of the reasons that we’re seeing an increased interest in Ops is largely because of SRE, that we’re starting to see surface level objectives, you know, everybody’s talking about surface level objectives where in ITIL we’ve been talking about surface level agreements and operational agreements for a long time.

You know, you’re talking about error budgets, you’re talking about incident commanders, you know, you’re looking at a lot of kind of saying the same thing but in a newer and modern way. And that’s resonating very much with the DevOps community.

Hopefully, we’ll start to resonate with the ITIL community. And again, nothing wrong with ITIL, nothing with ITIL 4, nothing wrong with ITIL 3, but it’s taking all of that and mirroring it into IT. And that’s our big problem is, we like to label things.

Alan: So I think you’re focusing on technology.
Jayne: No, not really, because it’s practiced, it’s really about processing practices.
Alan: For what made DevOps cool was the cultural element, the idea of Dev and Ops working together.
Rob: The humanity of it!
Alan: Seriously, it was that human element and when we look at Ops and you know, I had someone over here in another session, and we were talking about Ops and the fact of the matter is there’s a reason why Ops people are not happy. It’s because they do repetitive tasks. Boom, boom, boom, boom, you know? And there’s a reason, and so, one of the cool factors of DevOps for them was the chance to get out of that rut. To get involved in the Dev.
Rob: The cool things, creative things.
Alan: To the cool things, right? So how do we make Ops cool? Because right now the average Ops guy, they’re so unmotivated that they’ll hop to the next thing like fleas to the next dog, for a 3% increase in pay. Right? If you give me a hundred dollars more a week, I’m out of here.
Jayne: Well, see that’s what I like about SRE, and as I said it, SRE doesn’t replace ITIL and it doesn’t replace AGILE. But there are a few things that come out of SRE. First of all, there’s a role, right? There’s a role, there’s a job that people can be hired for, that is fairly exciting.

Second of all, there is automation. It’s an engineering approach, which we haven’t taken before.

But most importantly, I think this is missed, if you look at the guidance for SRE, 50% of your time is spent reducing your toil, right? Your manual effort, whatever. The other 50% is you’re supposed to be learning something new. You’re supposed to be thinking about the future. You’re supposed to be spending and if it works, then your job now becomes innovative, because you’re now charged with doing something cool and you’re given the time, again in a perfect environment, you’re given time to be able to do that.

Now again, let’s bring in ITIL. Take SRE, marry ITIL, in a much more AGILE way, all of the good stuff is in there.

Alan: I don’t know if ‘marry’ is the right word. I think ITIL needs to figure out how to graft this to somehow bottle this excitement, this new-age OPS or new whatever you want to call it, new Ops.
Rob: And that’s a cultural change for the people writing ITIL.
Alan: Absolutely. And which is why I say that’s what drove DevOps’ coolness and that’s what needs to drive Ops’ coolness. If ITIL isn’t going to embrace that cultural change, it’s done.
Rob: You know they build those hospitals and they haven’t got enough money to open them and you have these huge empty clinical buildings. The ITIL books always felt to me like those sort of hospitals. It was always sort of like, where are the people? You know, they felt like we built the wards, and we built the beds, and we built the machines, and we’re done.

You know? And it didn’t have that humanity to it in the books. I know, I mean the authors will be right on me on that one, and say, “Oh, well there’s this bit about particle change in here and there’s this bit about teaming in here.” And it did address it at times, but they just had a very clinical feel to them as a book.

Alan: Yeah, it was sterile.
Rob: There was nothing folksy about them.
Jayne: It’s religious, too. And that wasn’t the intent, I mean we’ve all been in the ITSM space for a long enough time, certainly have a long history at ITIL. And I don’t think the intent was that they had to sing a hymn before you opened up the book. And the book said, “Do it this way,” and if you didn’t you felt you had to go to confession.
Rob: All the authors will say that wasn’t. But that’s how it was taken up, wasn’t it? “I think you’ll find that section 3.2.3 says…”
Alan: Yeah, and so that’s exactly the antithesis I think of what we need. I think today, and you can talk about millennials, I don’t really care what you want to call it, but today people want to feel the ability to evolve, to grow, to improvise, to be excited.
Rob: Improvise is an important word, you know, people, they want to feel some freedom in these things. They don’t want to feel bound into a system.
Alan: I had a great conversation with Jon Smart, from the Barclays, and his crew yesterday. And you know, their philosophy is, they have a team of people, they give them a goal, they give them the tools, and say, “Have it.” There are no rules beyond that. Well, there are, but, you know, within reason.
Rob: Yeah, you have to have a very clear policy, actually, if you’re going to let people loose in a paddock, you got to tell them where the fences are.
So the one thing you want is a clear policy, but nothing about the how.
Alan: Yeah, I think people today don’t want to feel that they need to follow the cookbook.
Jayne: Well, but that’s a cultural change because if you set people loose, even though you have the fence, it’s a very, very uncomfortable feeling because many don’t know if they’re going to do it right. Right? Am I going to do it right? Now maybe that’s generational?
Alan: But that’s DevOps. If you don’t do it right, that’s okay. But learn from your mistakes, and improve.
Rob: But that’s cultural, that’s your point.
Jayne: But they’re not culturally trained to be able to do that.
Rob: If you kept animals in a cage for years, and then you let them loose in a paddock, they’re not running around leaping and gambling, they sit there and blink in the light.
Jayne: And looking for the cage, because it’s comfortable, it’s familiar. I understand the boundaries, and I also understand how I’ll be successful so I can pay my mortgage, support my family, you know?
Rob: And in some organization, it’s, “Are you going to hit me again?” Alright? You know.
Alan: Well, that’s a whole other thing. But, yeah, you have, “Beatings will continue until morale improves.”
Cherry: There’s someone say that in this culture in our organizations I wouldn’t be shoot down if I even about to stand up. So that’s really common saying in many organizations
Alan: But those I think are cultures in IT, those are not the high-performing IT orgs like we read about it in the state of DevOps report.

And I think that those are the people that, you know, I mean there’ll always be some of them, but by and large they fall by the wayside.

Jayne: But probably more in Ops than in Devs. So Dev has always been encouraged to be creative because that’s the nature of the beast. You’re building or creating something, and Ops as you said, very, very repetitive.

I like what Cherry said about, if we really look at, you know, having a baby versus raising a baby and supporting a baby, that’s a really great analogy because it shows you that during that period of gestation, right, there is a very creative aspect to it. Afterward, you’re like, “Okay, how do I feed them?”

There’s a lot of neuroses, where you’re afraid to do it wrong, and I think it’s probably more systemic in Ops than it is in Dev.

Alan: But I will put forth the proposition that Dev went through a similar thing when they went from being creative to being pure coders. And now they’ve come back to being creative again, right? And I think we’ll see that with Ops as well.

But guys, believe it or not, our half hour went so quickly. But, it’s a conversation we’ll continue, right? As we continue to eagerly await this ITIL 4. We’ll see how ITSM continues to integrate in here, and we’ll see, I think they continue maturation with their Ops.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Mitigating Unbundling’s Biggest Risk
    By Stephen Fishman , Matt McLarty

    If you haven’t already read Unbundling the Enterprise: APIs, Optionality, and the Science of…

    Navigating Cloud Decisions: Debunking Myths and Mitigating Risks
    By Summary by IT Revolution

    Organizations face critical decisions when selecting cloud service providers (CSPs). A recent paper titled…

    The Phoenix Project Comes to Life: Graphic Novel Adaptation Now Available!
    By IT Revolution

    We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…

    Embracing Uncertainty: GenAI and Unbundling the Enterprise
    By Matt McLarty , Stephen Fishman

    The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and…