When we want to get an inside peek at the trends within major corporations when it comes to continuous integration, continuous delivery, and DevOps, we turn to Kevin Behr, the chief science officer for the CXO and Board Advisory Practice at Praxisflow, where he consults, mentors, and coaches IT organizations and executives on how to increase their business effectiveness. Behr also is the of seven IT management books, including the bestselling “The Visible Ops Handbook”, which he coauthored with Gene Kim and George Spafford. His most recent book, The Phoenix Project, also coauthored with Kim and Spafford, has helped to spark discussion about DevOps globally.
Today, we sparked a discussion with Behr about how smart enterprises are using DevOps to further differentiate themselves and enterprise excellence.
DevOps.com: There seems to be a lot of misconception out there about what DevOps is – and I’m increasingly hearing it referred to as a software methodology. Are you seeing this?
Behr: Definitely. DevOps is not a software development methodology. I think that is a big misconception out there. It was a big misconception in the in WSJ post, DevOps is great for startups but for enterprises it won’t work yet. The author had that completely wrong: DevOps doesn’t tell us how to develop software. DevOps literally is collaboration between IT operations and development. So DevOps could be about developing software. It could be about fixing bugs. It could be about fixing integration issues. It could be a whole bunch of different things they’re collaborating on. But it doesn’t necessarily denote how you would develop software.
DevOps.com: But there’s no prescriptive connotation to the word at all, is there?
Behr: Exactly. My whole point is that the only prescriptive connotation is “Can’t we all get along?” Can’t we work together to do the work we do? I think sometimes that means we’re not developing software that means sometimes we’re doing a lot of different things. In some cases, software developers are helping sys admins write better scripts, and do better sys admining. And vice-versa: sys admins are helping software guys understand requirements better, and understand the end delivery point, the people that are going to use software or service this, better. That’s not telling us how we must develop.
DevOps is about asking: what can we do to improve, what can we change, and what does this change mean? We’re talking to CIOs like crazy right now about this. We’re trying to figure out how can they leverage DevOps without causing all kinds of organizational trouble. On one hand, we’ve got people in the enterprise that are happy with an ill-defined DevOps. To be honest with you some are saying it’s all kinds of things because that creates a subterfuge where they don’t have to do things to make it work. “If DevOps is confusing, if it’s impossible, or if it’s stupid, maybe we won’t have to actually do it,” they think.
It’s kind of pathetic to watch. We are watching them and wondering: “Wow. Do you really think that doing these in Ice Age speed and style deploys and old school change management that takes 30 people in a room, once a week, to decide what changes are going to get made is okay today?
DevOps.com: That’s just insane to hear and think that it is going on. Outside of IT, how are business people responding to DevOps and continuous delivery.
Behr: I’m telling you, the coolest part about it for me is the business people have reacted to the DevOps message. They’ve done so because we’re talking about changing the business payouts. They’re drastically different now. Organizations that can do these deploys, not just because they’re putting out more software, but because the organization as a whole is focusing on delivering more software to the end user. Even the commercial software companies are way behind what a lot of DevOps companies are doing now when it comes to driving innovation and better outcomes.
When you look at these big software companies that are still releasing software every eight months, they’re really slow and terrible. We’re all suffering from the quality and the slow feedback loops, and the disconnectedness of regular commercial software. These smaller companies, a lot of them are start-ups albeit, but not all of them, and a lot of these banks that have embraced DevOps are drastically changing the old-school cycle time game. They’re getting faster. They’re reducing cycle time, and they’re reducing defects. That adds up when it comes to better applications and producing a lot less waste.
DevOps.com: What does this mean when it comes to impact, can the deficits be measured?
Behr: Yes, because it ends up taking you forever to get anything out. You’re now suffering from that nasty cycle of unplanned work. It’s similar to all of the work that they call failure demand, where the failures in the quality of what you build are creating demand for work. You’ve already got competition for that work, because your company wants to release new value features, but you can’t because you’re cleaning up the old messes. It’s ugly.
Now, and the other thing that’s interesting too, here, is that when you move to SaaS, you’re moving to more release cycles per year. The average SaaS provider is going through four major platform upgrades a year. They’re doing four releases. Think about that change from a traditional model, where you’re adding three more releases a year, essentially.
And every release requires maintenance releases, so now you’re going to have patches. A lot of these companies have been putting SaaS into place, but there’s not a whole lot of SasS that’s profitable from a business perspective right now. There are a lot of companies doing it, but there are not a lot of companies that are in the black. What’s interesting is that they’re spending a lot of labor to maintain the software. It’s expensive, and you have to build it before the customers come. That’s why we see so many people come and go out of that space.
DevOps.com: What does that mean for business then, when it comes to success and IT’s relationship to business success?
Behr: I think what’s interesting is that you’re hearing business people’s expectations change. The business always used to say, “Well, I need that thing tomorrow.” And IT would say, “Well, you’re going to get it when you get it.” Now the business is coming back, saying, “No, I need that tomorrow, because my competitor already has it.” Those rushed cycles used to be crying wolf. But today there is legitimacy to the pressure. They’re actually crying wolf because the wolf is there.
The dinosaurs are going to be in big trouble, because they are competing with organizations that can do 10, 15, 20 or 40 deploys a day.
Some are deploying with feature switches, as dark code, so all of those deploys that they’re doing may not even be active features that people are using. But they’ll turn on a feature, see if it works, and if it doesn’t they will turn it back off. No customer impact. They test it in production. They can also then roll out code that nobody even knows is there, and also be testing it on actual, live infrastructure. What they’re doing is improving so much faster than everybody else this way.
These organizations are going to separate themselves from the pack because of how efficient they are becoming. This is how DevOps is one of those approaches that a lot of organizations are using to make it harder for other people to catch up with them. If they’re a super-predator, in other words if they have a breakthrough idea that nobody else does in some sort of technology, why not spend the dollars and couple that technology with a service approach, or a design from an organizational perspective, so that you can continue to out-improve everybody? DevOps does this.
You’d be insane not to. So now you have a dual threat. You’re not just offering a better product, but you’re a better product that’s actually iterating faster and separating at a rate that’s going to be hard for other people to deal with. This is how the slow moving enterprise is losing right now. It’s content to think that it’s not losing that bad. The thing is, the game is changing so fast in organizations that are able to do this that they’re able to separate so much faster, and outcompete those that can’t.