The DevOps Standard Finally Defines DevOps

Hey everyone, welcome back here to techstrong TV. I've been looking forward to this particular interview ever since I first reached out to my friend Mark Kornbeig. I don't know how many of you, of our DevOps audience out here, took note of the new book that was released by the DevOps Institute for the DevOps community on DevOps standards.

But I really wanted to discuss that. I have my views on it, and I want to introduce you to my two guests here, who also have their views on it. And as I was saying in the green room before we started, all three of us are uniquely qualified to comment on this.

So let me introduce you to my two guests for this. First, as I mentioned before, my friend Mark Kornbeig. Mark has a 40-plus year career as a distinguished engineer in testing DevOps software delivery, multi-time author, and one of the lead, I don't know if you want to call it lead authors or lead consultants on the book in question.

But Mark, welcome back to techstrong TV. It's good to see you, my friend. Yeah, it's good to see you again, Alan, too.

All right. And you too. Well, we used to see each other more on the road, but lately- That's true not as much.

Mm-hmm. Joining Mark and I, though, is another friend of mine, Markus Bauss. Markus is the VP product at PeopleCert, but as he will tell you, Markus has a very long involvement in the software development community, ITIL, ITSM.

Probably, I said Mark was in it 40 years, Markus is probably close to that as well. But I'm going to let you both-- Markus, why don't you take the lead, give people a sense of your journey and how you got to be VP product at PeopleCert. Yeah.

Hello. Thank you very much that you have invited me to this interview and to your amazing TV. Yes, I'm working for PeopleCert as the VP product, and my team is the product management team who drives all our frameworks forward, ITIL, Prince2, also all the content in DUI.

PeopleCert has took over DUI some years ago, and our responsibility is to make sure that what we have published that it is up to date and relevant into the market. And personally, yes, these 40 years, we are all with these gray hairs and Mark has covered it under his cap, but he's the same way that I'm in this industry also very long as consultant, as trainer, and for all of these developments, what we have seen the last 20 years. But in the moment- Yeah ...

we are in very special times, which needs a new guidance and this leads us a little bit to what is DUI now doing and also why we have published this book. Absolutely. We are in, so I call it historical.

We're in historical times, historical moment, right? Absolutely. The whole AI thing, it's changing the way software is done.

Mark, I co-opted talking about your background, but feel free to supplement that. Let people know a little bit more about you. Yeah, well, you pretty much summarized it.

Well, I actually would claim I've been doing DevOps, and I wrote an article the other day, DevOps decades before it had a name. Way back at Bell Northern Research, we were doing continuous integration and continuous delivery, not continuous deployments, but we were basically doing all the things that we now call DevOps, at least the delivery aspects of it. And, so yeah, I've been called DevOps the gray, I think largely because of that length of time that I've been doing DevOps and always interested in the way we deliver and build software and systems.

It's been my career for actually more than 50 years, in fact. Really? That's great.

As I mentioned, the three of us all have a deep connection to DevOps Institute. Of course, I was one of the co-founders of DevOps Institute, along with Jane Groh and Lisa Schwartz back in, I want to say 2014 or 2015. 2014.

It was one of those two years, yeah, that we started it. Mark, I think you were one of the first experts that we drafted into helping us when we were looking, because there were no best practices then, right? That was the funny thing about DevOps.

We had no best practices. It was, Jane used to call it emerging practices. Mm-hmm.

And Mark, you really helped bring some structure, some rigor to what was then a very much a wild, wild west. Everybody was calling something DevOps, regardless. Markus, at the time, I remember you were, was it Servint was the company?

You were- It was Spyrid. It was Spyrid at that time. No, no, Mark, you were in Spyrid.

Markus Bauss, though, was running a company in Germany. Oh, yeah. Okay.

Yes, in Germany. Yes. You hear my accents are Yeah, no, but- Yes, my company I was working for was ServU, yes.

ServU. I said Servint. It was ServU.

But you were basically the largest or one of the largest DevOps Institute training providers, certainly in Europe, if not the whole world. Yes. So you were there too, right?

The whole DevOps movement was, if I could use the term, loosey-goosey, right? Yeah. There was no manifesto.

We used to argue over the definition of DevOps, right? You could go pick a fight by trying to define DevOps. Those were like fighting words back then.

And here we are all these years later with the advent of AI and vibe coding and Mark, as you mentioned, continuous delivery and stuff. We've come a long way. Well, let's go back.

What was the genesis? What was the seed of this book now? Now, Markus, I'm going to assume it started with you and the PeopleCert team, that it was time.

Yes. Maybe you reached out to Mark, but if I'm wrong, feel free to fill it in. Mark and my team is working very closely together because, like you said, Mark is one of the most recognized experts in this field, and we are working closely together to work on the content and on all the stuff that we have in our DUI frame.

But the time has changed so dramatically, and we have analyzed the market and see, okay, what's necessary as the next step? And in this AI-driven world, I would say, where technologies are advancing so fast, it's not easy to create out of this real business results. So that is perhaps my role.

I was never been the super-duper deep DUI or DevOps expert. But with my company or the company I was working for, we have always asked for, okay, what is the result out of it? So what is the outcome at the end of the day?

And this was one of the core points of DevOps, always to connect all these steps so together that you, at the end of the day, really getting outcome. And all these technologies right now, which are developing so fast, are not automatically creating this outcome. And AI accelerates development.

But to get all of these developments the right business results, we have to connect testing and all the other stuff which comes later in this, let me say, development and deployment chain, connect also ops in it. And this is also a point when I take a look in the market over the years about DevOps. " But DevOps was always more, how do I get from dev to ops?

And the ops people was never really there. So this was two worlds, and this is what we are trying to bring much more together right now. As you perhaps know, we have launched last year ITIL version five, so the new ITIL version, and have enlarged it in the direction of that it's now product and service management.

And it was never been the goal to replace DevOps with ITIL. This will not work. It's also not necessary.

But let me say, we have built the one side of the bridge to the DevOps world. And with this book, we have started to build the other side to connect these better together. Not to say that this is an ITIL book, it's not at all, but there's much more alignment.

And so we initiate this book to help the readers to connect all these engineering capabilities with leadership, with governance, for better customer outcome. So this was our major motivation out of this, and not with having in mind we're writing a book, we have started with discussion with Mark especially, like what do we have to do? And at the end of the day, we came to the point of all of this idea must manifest somehow, and then the idea of the book was born.

I would like to add something that you said that in the bad old days kind of that people didn't know what DevOps was or how to do it, but I've been recently at a couple of DevOps days events even in the last two months, and I would walk around and ask people at these DevOps events where there are DevOps people, what is DevOps and how do you do DevOps? And even in those events, I get kind of a blank stare and people stumble to try to figure it out, and this is one of the reasons why I think it's time that we kind of settle those questions . And the book is an attempt to settle those questions in a creditable way.

There's a lot of information in the book that helps, I think, settle that and putting DevOps Institute's name behind it gives it credibility more than having, let's say, an ISO standard or an IEEE standard where it sits on the shelf. We want it to be a community book, and the book was not just written by me. There was a lot of input by a lot of reviewers, in fact, multiple rounds of reviewers, of hundreds of people.

And they even scored the draft contents and so on. A lot of agreement that this is needed and the way it is done is something that they can agree to. And I would say the same reaction I got in the DevOps days events, that they think this is a good time to try to at least settle those things.

Of course, DevOps will continue to evolve, but anyhow, that's kind of a motivation. I think that's an important piece of this, right? I mean, look, I've asked this question of no less than Patrick Dubois.

Mm-hmm. Right? The man who coined the term DevOps.

I've asked Andrew Clay Shafer, I've asked John Willis, I've asked Gene Kim. Mm-hmm. I've asked all of them over the years, how come we can't have a written definition?

How come we can't have a manifesto? How come we didn't have this book? And there was always this feeling that, well, it's a moving target, and I think, Mark, you said it, right?

It's a moving target. When we first started, I think was it 2012 or 2011, Patrick, coined the term DevOps. Mm-hmm.

We didn't think about AI vibe coding. Mm-hmm. Right?

We didn't think about agentic AI. We didn't- Or 30,000 integrations a day and things like that . Well, right.

Do you remember, I mean, the all spar 10 X, 10 releases a day was people thought that was crazy. It was revolutionary at its time. But yet, here we are.

Now, my challenge to you, and Markus, I'm going to throw it at you first, is how do we keep it a living, breathing, evolving standard? Because that's the problem is when you put something in a book, it's like freezing at a moment in time without releasing a ... I imagine we'll release new copies or new versions of the book, but how often can you put out a new version, right?

How do you keep this a living, breathing, evolving standard? There. I think that the first step what we have done is we have giving away the book for free, so everybody can download the book for free.

So let me say, our goal behind is adoption. This is what I want to see, is that the people are taking the book, and the book, on the other hand, transports something valuable. So it's not like only a white paper or a digital document or something like this.

There's more, there's substance behind. So the people should download it, read it, like it, or do not like it, justify about it, use it, and share the experiences with that. And this is the most important point of that, and this is what UI is standing for, was always standing for, bringing people together, discussing, sharing ideas, sharing the experiences, and develop it further in the community.

And then we will see what we are doing with that. The book was the first step. It's not connected to any kind of certifications, and this was also by intention.

So of course, at the end of the day, we also want to sell our certificates and so on, but this comes along when the people like what they are seeing and then specialized questions like SRE or something like this comes out of that. First, the book is the initiation point for discussion and adoption. And now we are in this process to distribute it as wide as possible and to collect all of this feedback.

If we are condense this feedback afterwards in a new version of the book or in a more body of knowledge or in something of discussion platforms or something like this, be honest, we are not 100% sure with that. In the moment, we want to start, let me say, this dynamic with that and for that, we thought the book is the best form of it. Yeah, I could add also, it also is a question of how you craft the book.

I mean, the core ideas in the book, I would say, were applicable five decades ago as well as today, and they hopefully will be five decades from now, the core ideas, right? You have to be careful how you craft the statements in the book. It doesn't talk about specific tools because those will come and go.

It doesn't talk about specific practices for specific tools. It talks about practices that are going to stand the test of time. The definition is something that is going to stand the test of time.

I think that's been the difficulty. People will over-specify something, and then the specification becomes obsolete very quickly. So this is a part of the strategy.

That's like scientific method, right? The more specificity that you have on something, the narrower it is, the easier it is to say, okay, well, we've moved past that, right? Because it's evolved and it's moved past that single point.

But here's an interesting thing, and to me, this is the ultimate test of DevOps success and staying power. com before DevOps Institute, right? com in 2013.

And I had met Gene Kim a year or two before. I saw a manuscript of the Phoenix Project. I thought this was going to be fantastic for security and a new way of looking at software.

Did I think back then that in, here we are coming up on 2027, I'd be sitting here with Mark and Markus talking about we finally have a DevOps standard book, right? What is it, 14, 15, 16 years later? Maybe more.

No, I would have thought either we would have had this book a long time ago or there would be no more DevOps. But the fact is, in a world where we had Agile and Scrum, and we had ITSM and ITO, and we've seen the rise of platform engineering and cloud native stacks and SRE, as you mentioned, and all of these, the whole DevSecOps movement, there's been so much tumult is the word I use, right? Like in the eye of a hurricane.

Mm-hmm. But yet DevOps has remained at the core of what it is. You may not have a book.

You may not have a written definition. And Markus, you say you could go to a DevOpsdays and ask 10 people and get 12 opinions on what DevOps is, right? Or no opinions.

But nevertheless, it's proven its mettle. It's proven its staying power by surviving and thriving in all of this, and now AI. So me, I'm bullish.

I'm bullish on where DevOps is going. I'm bullish on how it will survive and thrive and work with. That's the other thing.

It's the ultimate sort of amoeba, right? It just engulfs and joins into anything else you are putting in there, SRE, platform engineering, even AI itself. So I'm bullish on it.

I think the task of keeping this book up to date, though, is a job. It's a job. It's going to take the community.

It's going to take, Markus, your whole People Cert is a organization that is about community, is about certifications, is about these standards. It's going to take a People Cert to keep this book current. And it's not only a statement.

It's a statement that this book is available for free, or is that for the commitment of People Cert of investing in this community, we so deeply believing in the community and DOI and DevOps, and of course it have to evolve, and of course it has to adapt, of course. But with all the developments of AI and what we see right now, we need some kind of orientation. We need some kind of alignment.

We again, need this common language of how do we work together, perhaps more than ever before. So I think DevOps in its fundamental ideas is more necessary as ever it was before right now, and this is the commitment that we are willing to invest in this and support the community for the value of all of us. And I can say this is what motivates me to work for People Cert, to drive this forward and the DevOps Standard book now shows it again.

Yeah, I would add that I think People Cert is the right organization to do this. And this is one of the reasons I bought into it in the first place, this idea of writing a book that eventually we decided would be called the DevOps Standard is, it's a community-oriented practice. DevOps is not just something you can spend three or four years in a standards committee and come out with the answer.

This is going to be evolving. But again, we were very conscious while writing this book that we even discarded a lot of good input that would've been a little too detailed and would've been leaning in the direction of making the book only relevant for a relatively short time. But if you look at the definition, for example, a social technical system that integrates people, process, and technology practices to support efficient, safe, and reliable delivery of software-enabled products and services.

Very broad definition. Will stand the test of time with or without AI, with quantum and all of that. There's nothing in that definition that will crack because of those things.

That's- And there's nothing to stop the People Cert or other organizations for that matter. It is an open community standard. From you want to do supplemental add-ons or stuff that is very time specific, go ahead.

You should. But you need that backbone. Guys, gentlemen, I apologize.

I promised you a 15-minute interview. We're here 24 minutes later. But a good way to end this, hey, Markus, you mentioned a few times the book's free, but how can people get it?

Yes. Going on the DevOps Institute website. There you can download it, and the full book.

Or if you are old school like me and you want to have it in a written form, then give us I think it's a week or two, then you can order it on Amazon, but it will be cheaper. So it's I think around about $30 or something like this, 35, or that covers the printing costs and so on. We want that you read it.

And for me, it was totally cool to write this book together with Mark and all the community and see what's getting out of it. But what is much cooler now is getting all the feedback. I was so happy.

Aaron, I've seen your first reaction on the book as you read it, and this is good and this is perhaps missing and so on. And this is exactly what we want to initiate now. This is so cool to see that these reactions are there in the market.

Excellent. Markus, thank you. Mark, as always, thank you.

It's good to see you, my friend. Looking good. You too.

We'll come back. We'll keep an eye on how this book evolves. You can get it at the DOI website, as Markus mentioned, or on Amazon in just another week or two.

We're going to take a break here on Techstrong TV. We'll be back in a minute.