On this episode of the Humans of DevOps Podcast, Eveline Oerhlich moderates a discussion between DevOps Institute CEO, Jayne Groll, and ITIL4 author/editor and Director of EssentialSM, Barclay Rae, on the similarities and differences between ITIL, SRE, and DevOps, and which one best fits your organization.

The lightly edited transcript can be found below.

Intro:
You’re listening to The Humans of DevOps Podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the S-K-I-L framework. Here’s your host, DevOps Institute CEO, Jayne Groll.

Jayne Groll:
Hi everyone. This is Jayne Groll, CEO of the DevOps Institute, and welcome to another episode of The Humans of DevOps Podcast. I’m really excited today to be joined by two of my favorite people, Barclay Rae and Eveline Oerhlich, and we’re going to talk about ITIL, SRE, and DevOps. Eveline’s going to serve as our moderator. So, Eveline, why don’t you kind of take the helm? Let’s let Barclay introduce himself, and I know you’ve got some really good questions for us.

Eveline Oerhlich:
Sounds great. All right, thank you Jayne and Barclay. Why don’t you tell us who you are, and how do you relate to this topic, first off?

Barclay Rae:
All right, thank you very much. Hello everyone. My name is Barclay Rae. I’ve been a consultant for a number of years, really, an author and consultant, but mostly working in service management, particularly around service desk and operations and stuff like that. But a lot of project development work in the past.

And so I’m not particularly wedded to any particular methodology or framework, but I have, in the last four or five years, been working on the ITIL rewrite. Authored other things as well, like service desk standards and so on, but the thing that excites me about the ITIL rewrite was the fact that it was a major rewrite. It was going to be modernized and different, and in the new world, where I think we’ve all been trying to build together those different worlds for some time now, and this is a great opportunity.

Eveline Oerhlich:
Super. Well, let’s just get started right away with that. These different types of frameworks and methodologies is, as Jayne already said, the topic of our podcast today, and we did some research in our 2019 up skilling enterprise DevOps report, or survey, with some really good samples.

And we actually found that ITIL, DevOps and SRE adopted together in many organizations, here, quickly, the details, 47% have adopted ITIL, 66% have adopted DevOps, and 10% have actually adopted SRE, which is, again, quite fantastic. And again, these are ands and not ors. So for enterprises, of course, many, and I see that as well when I travel through events and so on. They do one or two or many, plus Agile and many other things out there. With that, partly, I have a question for you.

So, when you were working on the ITIL before, as you mentioned, you were part of that authorship, what were you thinking? What’s your thinking? What was the team’s thinking around the existence of DevOps, and the rise of SRE? Give us a little bit of that flavor, because I think a lot of people are curious about that.

Barclay Rae:
Okay. Well, one small precursor is that, before we actually started on ITIL4, we had written a book called ITIL Practitioner, about four or five years ago, which was pretty much in all but name a DevOps book. It looked at flow, it looked at all the aspects, the cultural aspects, the organizational change and so on.

But with this version of ITIL, I think there’s a number of things in terms of thinking. The first thing was there was actually still a huge demand, because … We knew that because we were constantly getting requests from the industry, and we actually consulted with around 2,000 people across the industry. We opened it up so that people could make, could say what they wanted.

So before we even started thinking, we had a huge pile of input, knowledge, ideas about what it should be like. And of course, 2,000 different ideas means taking a little bit while to work through. But we came up with some things that we really wanted to fix, and things that we really wanted to change and move forward for the industry.

I think the overriding idea is to bring what has been the traditional operational site of the world and the traditional development and Agile side of the world together as much as possible. We still have to run stuff. There’s loads of great stuff that’s gone on in the last 10, 15 years around Agile and DevOps.

But run is still there, support is still there, and we’ve always been trying to pull them together. We want to make them more of a cycle rather than a one versus the other. I do still find that there are quite a lot those. Some of those kind of tribes still exist, and you still go into organizations and their different tribes.

But that’s what we’re trying to do. We’re trying to take those people who’ve been working in service management for a while on the journey quickly, so that they get up to speed and are part of that new way of working. And we’re also opening up the way that service management works with … I think there’s a lot of great knowledge and experience in service management that can be used by the DevOps community.

I know that from conferences I’d been at, and I’ve heard a lot of the presentations where I thought, “Well, we’ve tackled those issues, so, surely if we worked together more, we can actually improve things.” Couple of quick headlines on some of the thinking going in. Certainly, we wanted to use more common taxonomy. We wanted to definitely evolve, and that’d be considering product life cycles rather than services or operations or systems.

There’s a lot of good practice and things like ITIL that don’t need to be changed, but just needs to be modernized. So there’s a lot of familiar stuff for those that know that. But also, looking at the whole volume streaming to end way of doing things, co-creation of value, all those kind of ideas.

There’s a lot of, not just ideas, but also input that has gone into it. And just finally, we tried to make it as, in the way that we built it, to have guiding principles ourselves on keeping it lean, and keeping it transparent, and flexible, and future-proof, and all those kind of good things.

Eveline Oerhlich:
That’s a good lead into, Jayne, a question I have for you, as you’ve been in also service management, and that’s where we met. I remember way back. And then we met again at DevOps London. My question to you is, where do you see the intersections between ITIL before and DevOps, and then not just intersections, where do you see differences, and are they that different?

Jayne Groll:
So, thank you, and as we all know, we’ve all had a little bit of a heritage in the ITIL, ITSM space, which is how we know each other for a long time. And I think there’s kind of good news, bad news, right? So, as DevOps started to emerge, it merged as almost kind of a next step from Agile Software Development.

So we know that, as organization moved away from waterfall, they moved more to a self-regulating type of approach, smaller, faster, that was born out of Agile Software Development. So the natural byproduct out of that came to DevOps, which was okay, if we’re doing two to four weeks sprints in Agile Software Development, but it’s going to take us two months to get whatever this piece of code or this feature is into production, that’s not working, right?

So then, of course, the next natural evolution was, let’s automate more of continuous delivery, continuous deployment. So Agile kind of has its place in the development space, CICD, continuous integration, continuous development, really has taken hold in the post-scrum-team, pre-production, kind of build and deploy approach to that.

And I think that’s good. I think the intersection of all of this, whether it’s SRE, whether it’s ITIL, whether it’s DevOps, and I’ll even throw in Agile, right? For Agile Software Development, the crossroads really comes at change management. And so I think that there’s some really good things that are carried over from previous versions of ITIL into current versions of ITIL.

I do think that, when we look at change management, and Barclay, as you know, there’s been a lot of debate lately about change management, the accelerate report really took on change management. I worked on breaking the change management barriers with some folks from IT Revolution. And there’s a lot of debate about, okay, which model works for a particular organization?

And so, I think for organizations that are really looking for governance model, ITIL’s fantastic, right? So, ITIL very much has always been more of a governance model. Even there was something yesterday about the move from calling it change control to calling it change enablement.

All right, again, a lot of feedback about, is this more of a focus on governance, or is it a focus on self-regulation? I think SRE is kind of that third piece of the self-regulating puzzle, which is why organizations are starting to trend more and more with SRE. But let’s face facts. At the end of the day, services need to be managed, right?

Service management lives, service management will always live. And I think, depending on an individual organization, we may see more of a trend towards, say, a governance model versus a self-regulating model. And to me, that’s really the fundamental difference between the two.

So I do think ITIL definitely has its place. I think that the authors of ITIL, like Barclay and others that we know, I think that the intellectual property has matured. I’m really interested in seeing what’s coming next. With all due respect, Barclay, I don’t know that I would call the ITIL Practitioner book a DevOps book. But certainly, there’s a lot more to be said about this relationship that’s going to come out in future publications.

So, I’m a little bit in a wait and see. I think that foundation mentioned, Agile and DevOps, there’s not a lot of substance there yet, but I think fundamentally, looking at value streams, looking at cultural differences. ITIL has always had an organizational change management perspective, and I think that carries over, and that spirit is definitely there.

I do think that, I said, I think we’re going to find, I’ll call it a crossroads, or a battleground, depending on which way we would look at, will be a change management. So it’ll be interesting to see kind of how that evolves over time. Particularly, I said, I just saw yesterday, Barclay, maybe you can speak to that, about change enablement.

Barclay Rae:
Yeah. Just to answer a few of your points there, the Practitioner wasn’t called a DevOps book, and it wasn’t explicitly, but a lot of the thinking behind it was, and I think that’s what we’re trying to do. We’re trying not to be, we’re trying not to say, “Oh, this is an Agile book,” or, “This ITIL is now Agile.”

One of the big inputs was about how a lot of things like change management had been, I suppose, over the years, misappropriated. That it was, ITIL was seen as being the author of authoritarian big brother, heavy governance and control. And that was never the intention.

And the content and the words, the way it was written, and the way it was presented, and certainly, the way it was interpreted, sure. Lots of organizations have taken it to the letter, and our big, if you like, jewel in the middle of all this is the guiding principles that we did introduce in ITIL Practitioner, which is … It’s giving people much more guidance about how they can use not just what it is, so that they can be flexible and they can, the old adopt and adapt.

We’ve said adopt and adapt. People tended to adopt, but not, in a way, to adapt. So that’s what’s in those principles, and going forward, it’s not trying to be another Agile, or another DevOps. A different way of doing it is trying to do things in a way that will hopefully blend, that people can see where there are crossovers.

So on the taxonomy side, we have tried to make sure that it doesn’t sound too much like the old control, governance, authoritarian idea. It’s there as a framework for people to … I agree, totally, that it depends on the organization. And I think we had the conversation before that every organization, no sensible organization will implement change without discussing it, or having some kind of process whereby they agree or disagree how and when they’re going to do it.

So whether or not that’s done through an artifact that has a bit of baggage around it, the cab, or no, I don’t really care. I know lots of organizations that have fantastic cabs, and why would they change them, or remove them, when they’re actually providing a lot of value?

So I think a lot of the stuff at the center and a lot of the input to this was to try and loosen it all up, open it all up and make it more of a portfolio that people can use without feeling that they’ve got to adopt all of it, or that they have to do it in a particular way. And that will be more relevant to some organizations than others. I don’t know if that answers your question.

Jayne Groll:
Yeah. But it’s interesting, Barclay, so, again, just kind of stepping down memory lane a little bit, one of the things that I find the most fascinating is that, first of all, the rise of the cab. Even though the cab is really under fire right now, anyone listening has to understand that the rise of the cab came at a time where organizations were being required to produce evidence of their controls.

Right? So, in its time, in its place, it was meant to be an advisory board, right? The original definition of the cab was the change advisory, not the change approval board. And unfortunately, right, as you’re right, people adopted, and their adaptation. We advocated, hey, make this work for whatever makes sense to you. I stood on platform after platform, classroom after classroom, going, “Hey, don’t make …” The only reason process becomes bureaucratic is because you made it that way.

Barclay Rae:
Absolutely. I used to run service desks where you didn’t know, from one day to another, whether it was going to go into meltdown, because people had just stopped.

Jayne Groll:
Right. And so, I think that’s where, when we look at say-

Barclay Rae:
That was part of that history of just getting some order into place. We need to move on and be modern and empowered, and, as you say, self-regulating about those things. But some organizations do need control, governance, whatever you want to call it. But it’s at whatever level is appropriate, not, this is a one size fits all level of governance. Use the level of governance that is appropriate to your organization.

Eveline Oerhlich:
Depending on, yeah, exactly, depending on maturity, depending on situation, depending on vertical, depending on culture, depending on whatever, there’s many dependencies. I would agree to that. I do get a lot of questions traveling in whatever places of the world around, so what should organizations do today moving forward change?

You said, “Let’s just wait and see what’s happening here in the next releases of these different best practices,” or, I think, there were the list of 34 details. On DevOps, there is activity moving forward, organizations are doing and implementing many of them in different shapes, fashion or forms, and maturity. So what is you guys’ advice on, if I am a CIO, if I’m a VP of development, VP of operations, digital officer, you name the role, what should I do? What would you say?

Jayne Groll:
So if you don’t mind, let me jump in on that, because I’m hoping Barclay will appreciate this and be able to add a little bit more color to what I’m saying. So, what people don’t understand about DevOps is that DevOps is nothing more than a recipe.

So if I use an analogy of a cook, right, so you and I are going to make the same dish, but your recipe and my recipe are slightly different, and your ingredients and my ingredients are really maybe slightly different, or the proportion of your ingredients or my ingredients may be very, very different. And the analogy really applies to DevOps, right? If you really look at DevOps on its own, it is a set of principles around which practices have aligned, right?

So SRE is not part, didn’t grow up as part of DevOps. CICD, it didn’t grow up as part of DevOps, right? Jez Humble and Dave Farley wrote their book way before the term DevOps was even coined, right? ITIL wasn’t born because of DevOps. Half the tools out there, DevSecOps, right? All of those are ingredients.

And the value that DevOps brings to the enterprise is a set of principles that allows you, gives you a recipe that says your goal is to go faster, all right, to go more frequently, to go smaller, and to deliver value to your customers in a digital age where disruption is the norm, right?

That’s really DevOps in a nutshell, right? So the recipe of DevOps could have so many parts of Agile Software Development, so many parts of automation, so many parts of testing, of continuous delivery, continuous deployment, so many parts of ITIL, so many parts of SRE. Right?

And I think that, in and of itself, says that again, depending on the needs of the organization, your recipe and my recipe may be very different, but hopefully, we’re both producing the outcomes that our enterprise and our customers need. So I think when we look at it, the original article here was Stop the Argument, I don’t think there’s an argument.

I think that, and again, I’ll go back to some of the controversy that’s arisen, right? IT, we have no shortage of frameworks, right? And there’s new frameworks emerging every single day. And that can be really confusing to a CIO, or to somebody that’s trying to lead a transformation. But the reality is, the ultimate adopt and adapt exists within the DevOps realm.

Because again, you can pick, you can cherry pick which ingredients make the most sense to you, or which part of those ingredients. ITIL tends to span the entire value stream. I know you call it the service value system. SRE really kind of targets an operational perspective and an engineering approach, right, that looks at it from a slightly different perspective, but doesn’t actually go back into the code creation phase, or even the CICD phase, right?

SRE really kind of has a very unique niche, so when we start to look at this, an organization could take parts of ITIL, parts of SRE, parts of Agile, parts of CICD. The recipe could be whatever makes sense. My concern, and Barclay, I would love to hear your perspective on that, my concern is that like we saw with the change advisory board becoming the change approval board, right, that adopt and adapt kind of fits into adopt, right?

It’s one of the reasons I’m really happy that in DevOps, we don’t have a single body of knowledge, right? We have a collective body of knowledge, we call it the CBOK. ITIL is part of that CBOK. SRE book is part of that CBOK. Right? Jean’s Unicorn Project is part of that CBOK, because we want people to internally disrupt. Does that make sense?

Eveline Oerhlich:
Yeah. I like that very much. That’s exactly what I hear from some strategy folks who are not necessarily connected and attached to one, but they’re really thinking, what is the problem we’re trying to solve? Where do I need to advance the business towards in whatever vertical and in whatever function or line of business they’re working with? Absolutely. Barclay, I’m sure you have some comments on that.

Barclay Rae:
Yeah, I totally agree that the world that we live in has probably got too many of these things, and they are potentially confusing, although, for the most part, they’re all genuinely trying to help organizations, help individuals to improve the way they do stuff, to make it more relevant, to make it better.

And there is inevitably overlap, and potential for confusion, or misunderstanding of how these things might actually interact. Just to take a slightly different angle for a second, in terms of what Jayne, you said earlier, you kind of wait and see what’s coming next on the ITIL side.

I can give you a sense of where that’s going, and what’s coming out of this. There’s a number of books just on the cusp of coming out, that are actually out in beta form at the moment. When the highlight is [inaudible 00:23:56], which is trying to really bring a lot of things together for practitioners.

I cross a number of areas, but I suppose the focus of that is bringing in things that maybe weren’t associated with ITIL in the past. Like, how do you manage people, how you develop culture and team building, how you motivate teams and look at structure and all that sort of thing.

There’s a whole pile of stuff that’s coming out there, including Mark Smalley’s High Velocity IT, which is trying to bring as many different ways of thinking together, as a book in itself, and to provide guidance. The big one that’s coming later on digital IT strategy, which is, Dave Kahn and Eric Flora and others.

It really is looking at how all this comes together from the business side. So how, at the C level, or at the organization business level, people can understand what, where the value is in IT and technology, and how they can work better together. So a lot of that is trying to pull those things together from the … Initially, from the CIO level, but then onto the C level, to say, “Look, there are many things, there are elements that we can use. Here’s a whole pile of stuff that you can use.”

There are other bits of information, the bodies of knowledge are available. But this stuff has come from many thousands of manners of time and work and experience. So there’s value in it, and as much as possible, it fits. It does, as you say, ITIL is part of the DevOps landscape, you could argue the other way, that there are many other models out there that people use or terms rather than models, even. Just ways of working, and that needs to come together.

I don’t think there’s a single one, there’s no kind of Swiss army knife framework out there that does everything. And it’s a way in, from where we’ve come on this, and on the ITIL side, it has very much been a way in for people that traditionally knew us, and needs to move forward, but also, really opening up so that we can actually get more collaboration and involvement together with the other worlds that have evolved in the last five or 10 years.

So it’s an exciting time, I think. I agree that there’s no single answer, but I do feel that it’s worth looking at a broad cross section of ideas and thinking and pulling the best bits for your organization. One final point is that many organizations do like to have not single sources, but just when you say that there’s no single body of knowledge, that is challenging, particularly for those that are further down in the maturity chain.

And sometimes, you do need to just say, “Look, here’s stuff that you can do. It works. What we need to make sure is that you’re applying it in the right way.” And I do take your point, Jayne, about the how do we avoid the next cab misunderstanding. We certainly tried very hard to put as much in that would avoid that. But inevitably, these things do happen.

But I guess the ultimate thing is, are there still silos between … I still see them in organizations where there are operation silos and DevOps silos in the same place. And the question is how we can bring those together in a way that doesn’t have one side going, “Well, you guys aren’t any good,” or, “What you’re doing is out of date.” There’s room there, I think, to pull different teams together and make it work in a collaborative way.

Jayne Groll:
So yeah, let me just jump in on that. You’re right, because sometimes I use the analogy, it’s like playing the Game of Thrones, right? So who wants to sit on the Iron Throne? And sometimes the loyalty to a framework sort of supersedes. Let me just jump in on two things, because I know we’re going to run out of time.

First of all, if I had any recommendation, and maybe that’s a little arrogant, but a little recommendation for those that are working on ITIL4s, we need to get those publications out faster. The fact that it’s taking a very linear, almost waterfall approach to release doesn’t really demonstrate agility.

So I’m hoping you take that message back, Barclay, that waiting four to six months between books, I think, is part of the frustration. Because you may be addressing some of the challenges or some of the issues in future publications, but nobody has access to that. Right? And it’s a long, it’s a long period of time between publications.

So we all read the Foundation book and went, “Oh wait, it doesn’t really say anything.” Right? But I’m certain future publications will. So if you wouldn’t mind, take that back to Axelos that getting faster releases would very much reflect on kind of the state of the state. The other thing is-

Barclay Rae:
I think they know that, just to answer that.

Jayne Groll:
[crosstalk 00:29:42] and not be agile, right?

Barclay Rae:
Just to be clear, that it really hasn’t been a waterfall. We have tried to do this in a collaborative, iterative way with doing, effectively, about six books at once. And although it might seem like the end is waterfall, it’s not. We have been trying to do it in a way that’s joined up, so we didn’t have one book and then another book and another book and they didn’t work together. That’s what’s taking the time. And all I can say is that really has helped to try and make the whole thing work together.

Jayne Groll:
Okay. I’ll believe that. The only other thing I’ll say, and again, just to kind of wrap up, going back to single bodies of knowledge versus collective bodies of knowledge, the problem that we’ve seen in the past, and hopefully, we can overcome that. And you and I and Eveline can be evangelists for that, is that we saw, I taught ITIL for a long, long time, right?

I was the preacher at the pulpit, right, where we would sing a hymn before we opened the books, because the books became a little religious. So we don’t want that. Right? We don’t want [crosstalk 00:31:05]. Yeah. And you know what I mean. I’m being a little sarcastic, but you know what I mean.

But that’s what happened. That’s [crosstalk 00:31:13] board became the change approval board. Right? Because it became so kind of singularly focused that it did become religious. Right? And again, I was a preacher, so I understand that.

Barclay Rae:
I really do think that we’ve tried very, very hard to get away from that, not just in terms of the content, but in terms of the way it’s being pushed out and stopping people from making those kinds of interpretations, separating all the practice content.

A whole number of things to say. Look, it’s not to be taken like this. It is much more of take what you want. And the religious stuff is only how it’s been interpreted by organizations and training companies I have to say over the years, where it has become, I suppose, a bit of a … We don’t want that. We really don’t want that.

Jayne Groll:
Oh, I know. Yeah, I know that, because again, I’ve had the privilege of speaking to people like you, and others, that that’s not the intent, but sometimes that’s the interpretation. And just to kind of wrap up, and Eveline, I know we’re running out of time. I think that it’s never an either or. I’m not sure it’s an and yet, is it SRE or ITIL? I’m not 100% sure that there’s an and there yet. Hopefully there will be. I don’t know. Eveline, I know we kind of overtook this.

Eveline Oerhlich:
It’s okay. No, it’s all good conversation. I think at this point, I just want to thank you both being very open. Barclay, thanks for the preview on the coming next of ITIL before, the high velocity book, I look forward to that. It will be on my nightstand, for sure. Jayne, thanks for your openness, and everybody else who was listening in.

If you have any comments or questions, feel free to connect with us. All of us are on LinkedIn. We have emails, and from there, hopefully we’ll have something in the future on the next version of this, because we want to keep this open and we want to make this a conversation.

If you want to join us, feel free. We’re happy to have you. Anybody out there who is an expert, or not, doesn’t have to be an expert. We’d love to hear from you. And with that, thank you to both of you. Have a great rest of the day.

Jayne Groll:
Thanks Eveline. Thanks Barclay.

Outro:
Thanks for listening to this episode of The Humans of DevOps Podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong.