In this excerpt from an interview recorded at the Better Software and Agile Development Practices East conferences, authors Bob Aiello and Jez Humble discuss the challenges and the rewards of instituting configuration management and DevOps practices.

Bob Aiello is co-author (with Leslie Sachs) of Configuration Management Best Practices, and Jez Humble is co-author (with David Farley) of Continuous Delivery, two books concerned with effectively managing change and releasing reliably. In this interview excerpt from a video recorded at this year's Better Software and Agile Development Practices East conferences, Bob speaks with Jez about configuration management and DevOps.

Bob Aiello: We're out there evangelizing configuration management and deployment best practices. What do you think some of the real goals are in the coming year for making this happen?

Jez Humble: For me, I think that the great thing about your book and my book is that what we show is that there are good practices there that have been proven to work, that allow you to achieve more reliable releases and better stability in operations—and these two things are not a zero-sum game. The difficulty is, as you say, trying to convince people to adopt them. The biggest problem from my point of view is the organizational barriers, which is why I'm talking about DevOps. It's just about trying to convince people: Listen, this stuff works. If only you could break down some of these barriers so developers and operations and testers could build up trust and find ways to collaborate more effectively. It's not that the practices aren't there and the tools aren't there. It's that we need to create the time and to adopt them.

Bob Aiello: DevOps is hot, but there's also a lot of confusion about what DevOps is. Maybe you could give us a couple thoughts about what you think best describes the whole DevOps movement.

Jez Humble: There are two main pieces to it. One is a cultural change, which is about developers and operations people just doing simple things like having lunch with each other. Find out, as developers: Why do the DBAs hate you? There's a reason why the DBAs hate you. It's because you forget to add indexes to your tables, and you forget to do query optimization analysis before you put out that new version of your software.

Bob Aiello: Hey, are you in my office?

Jez Humble: It's very common, right? We see this all the time. So, go and have lunch with them. Speak to them. There are very simple things you can do without a "DevOps mandate from the executive people" that can help improve these things.

The second part is the automation part, which fits into the whole configuration management piece—applying some of these techniques, like continuous integration, test-driven development, and refactoring to operations. We have all of these agile techniques for managing code; we can use those for managing infrastructure, as well, in combination with good configuration management practices.

So, I think it's those two things: automation, good configuration management practices; and better collaboration and cultural change.

Bob Aiello: One of the requirements in many of the companies that I work in—and I'm sure many of the companies that you're in—is that there is often a regulatory requirement for separation of controls. That, at face value, seems to go completely opposite to the spirit of DevOps, where you have the same team working with development and QA and operations. So, how do you address those regulatory requirements and still get the benefits of DevOps that you're talking about?

Jez Humble: That's exactly the problem we often face. The operations teams will say, "This sounds very nice, but we have to follow PCI DSS or Sarbanes-Oxley, and they require separation of concerns. How do we do this?" I think that the first thing to point out is that a heavyweight change-management process is actually a poor way to manage risk, because what ends up happening is that people have to fill these documents and they end up short-circuiting the process. I've seen this—heavyweight change-management processes with these huge spreadsheets that the developers fill in and that get sent to another country, and the people who are approving the changes don't know anything about what they're approving. It's a poor way to manage risk.

So, what we say in the book is, if you have a deployment pipeline, and for every change you make to your system it goes through a process of validation to assess the risk of that change, actually that's a better way to manage risk. You can see exactly what the change is. You've got validations in the form of automated tests and manual tests that demonstrate the change is low risk. Then, you can use some of this stuff that's in ITIL v3—like the concept of standard, pre-approved changes, of electronic just-in-time approvals, of not everyone having to approve every change—and you can have a very transparent, auditable system for managing risk that is actually superior to the very heavyweight risk-management processes.