BizDevOps. DevSecOps. DevTestOps. DevXOps. DevEverythingOps…
Call it whatever you want – the bottom line is that if you hyperfocus on bringing Dev and Ops together, you’re going to overlook a lot of the key elements required to release valuable software faster. Does it delight users? Satisfy business goals? Minimize quality and security risks? And how do you achieve all that without stifling speed and frustrating the original “proprietors” of DevOps: Development and Operations?
That’s what a vaunted panel of experts came together to discuss in the DevEverythingOps roundtable, part of the new DevOps Unbound video/podcast series. With analogies to everything from pizza, to butchering, to soccer, Wolfgang Platz (Tricentis), Caroline Wong (Cobalt), Anders Wallgren (CloudBees), Jayne Groll (DevOps Institute), Mitch Ashley (Accelerated Strategies), and Alan Shimel (DevOps.com) explored topics such as:
- The challenges that arise as DevOps scales and organizations grow
- Whether we’re dumping too much on developers (yes!) and ways to relieve the burden
- Using systems thinking, design thinking, and value stream management to bridge gaps and break bottlenecks
Here’s the complete episode:
We’ll also release it as a podcast soon (check back at SoundCloud or subscribe to “DevOps Chats” on your favorite podcast platform).
Here’s a quick taste of what the discussion involved…
DevEverythingOps: A few analogies
Jayne Groll: I look at DevOps a little differently than other people. Let’s take the analogy of pizza. Your recipe for pizza is probably really different than my recipe for pizza, but we all use certain ingredients – principles, in DevOps. We all need very pervasive testing, security, business involvement, CI/CD pipelines, containers, and so on. But it’s ultimately the proportion of the ingredients that go into that recipe, the quality of the ingredients, and the skill of the person making the recipe that determine the quality of the pizza.
A big tent
Anders Wallgren: To me, it’s the big tent metaphor. It’s being inclusive of all the functions and all the stakeholders that are involved – starting from ideation, all the way through when the value is in the customers’ hands and working properly, safely, securely. We started with this moniker of DevOps, then we’ve been gradually inserting everything in between. And I’m fine with that. If that brings attention to a particular area – short-term or long-term – great. We’re hearing a lot about DevSecOps right now. I think that that’s completely legitimate. It fosters discussion about the roles of the various stakeholders and how we can make these things easier and better. I’m in favor of changing the DevOps phrase so that it embraces these things. I think that’s what DevOps is: it’s talking about all the things that are involved in getting the software out the door.
Building a house
Wolfgang Platz: I want to offer a different analogy here: building a house. You build a house for a certain purpose. Of course you want to ensure that you have the basics covered (there’s a door, working electricity, the walls don’t fall down), but you need to do more to ensure that it’s a success, that people can live a good life in there. You want to make sure that all the different stakeholders are involved. It has to be smartly designed and built to spec. You need to rigorously test it because every house is different and could harbor a unique set of problems. Houses are becoming increasingly complex and you need to know that changing something in the basement doesn’t end up causing a problem in the kitchen. You also want to ensure that people can really live in there, that they look forward to going home, enjoy being there, and want to share it with their friends and family. Moreover, it has to be secure. They need to feel safe while they’re at home, and not be afraid that someone will break in the moment they leave.
Zooming out into the supply chain
Caroline Wong: I really like the term “DevEverythingOps.” I think there’s an acknowledgement, as folks have said, particularly Wolfgang, that it’s not just customers that matter. It’s not just engineers that matter. I’d love to take Jane’s analogy and zoom way out for a moment. Think about the butchers and the dairy farmers and the chefs and all the people who grow and harvest the tomatoes and then get them to your grocery store. I think we’ve seen a shift in software development from waterfall (where you have gates), to agile (where you do it often), and now DevOps (where you do it faster, together, all the time). You’ve got this network of interconnected folks collaborating and working toward a common goal in a continuous iterative manner. So really love Jane’s analogy of the pizza. And I think you can actually zoom out and imagine all of these different processes happening in an ongoing continuous and iterative way.
Would the ‘ultra-orthodox’ DevOps devotees change their tune today?
Alan Shimel: Or, with Wolfgang’s house analogy, it’s the people chopping down the trees in the forest, preparing the lumber, making the nails, and all the other elements of building a house. Let me just play devil’s advocate though – because that’s how I am.
I remember when I started DevOps.com, about seven years ago, the term “DevSecOps” was treated as blasphemy by many in the DevOps community. When I did the first RSA DevSecOps event, there was tremendous pushback from the DevOps community. They said: “It’s DevOps…period. There is no small DevOps, enterprise DevOps, DevTestOps, DevSecOps. It’s just DevOps, and anything else is superfluous.” This was really the ultra-orthodox DevOps view.
Now, fast forward seven years, and here we are having this discussion. If I asked some of those same people to come forward now, I don’t know if they would have changed their minds. Certainly, I think the market has become more encompassing and forgiving. But, you know, at its heart, is it still “just” DevOps? Are we taking core DevOps and watering it down? Or is “DevWhateverOps” the next step in our evolution, ushering in the convergence of all these strategies?