4 Most Popular Questions When Starting A DevOps Initiative
Are there any standards or averages (metrics, other) that a company can follow or adopt while making the transition to Continuous Delivery?
Kurt: The distribution of costs and benefits are so wide across so many organizations that it really matters where you are instead of where the industry average is, because you’ll have different production stability, different security risks, different governance costs and different reliability goals. So, all of these things are going to drive a different set of business case numbers. The data I quoted and some of the articles that I’ve linked to in the presentation will give you some idea of average industry cost production incidents. I would say you can use some standard data, but by all means convert it to your own experience because the industry data has a lot of variability.
Who would be leading this CD/DevOps initiative in the first place? Who should be building the case for CD?
Kurt: I’ve seen a couple of different ways that it works out. Generally speaking it’s driven by a critical business need to go faster, so a product that’s been threatened by competitors, or a business opportunity to go faster to reach new markets to new customers, and so in that kind of scenario the business case doesn’t have to be terribly detailed.
In other organizations where the DevOps initiative is driven by Ops, then it tends to focus on reducing production incidents, reducing security incursions, and things of that nature. In the cases where it’s been driven by an application development leader then typically it’s getting to build faster, and getting testing faster and more reliable.
We are still soloed in many organizations, so it depends on who’s driving it and what the scope of the initiative is. Depending on who’s driving and what the scope is, you’re going to focus on different factors in the business case.
How does one quantify the benefit of a DevOps culture? Can you?
Kurt: I would say that if you’re not seeing the benefits of the business case, you’re probably not looking under some of the rocks that we’ve talked about.
Look at production incident numbers, most organizations have sufficient data on that and sufficient problems to solve. It ends up being really compelling. Once you show the numbers, generally management just says do it, if that solves the problem just do it. Though you might have to prove that the approach you’re proposing, in other words putting the environments under better control and getting better control on the application releases. You can do that through proof of concept, but I would say that the hard dollar costs are generally there in almost every organization and that if you’re not coming up with them, keep turning over rocks. Look for various sources of waste in a delivery pipeline process, look for errors, look for other things that you can catch earlier in the cycle and I think you’ll find really compelling numbers.
What is the biggest obstacle to ensuring quality doesn’t get lost in this acceleration initiative?
Kurt: I think both of those questions reflect a perspective that there’s somehow a tradeoff between going faster and achieving higher levels of quality, higher levels of security. What the important thing to realize is that by having higher levels of automated testing as part of the delivery process, control of the environments so you end up with having fewer production incidents, which is also a measure of quality, and also incorporating security testing and other things like static code analysis into the delivery pipeline, you can achieve very high levels of quality and achieve high rates of speed. So the view that there’s a trade opportunity between speed and quality is usually based on the perspective that quality insurance and security reviews are largely manual, but those can be automated and the quality that results of that process is a much higher level of quality and a much higher level of security.
My colleague, fellow analyst Rick Holland and I did a report last quarter that talked about how security practices are actually improved by DevOps and what some of the cultural changes on the security teams are and similarly we talked a lot about the advantages of automating testing and automating quality assurance as part of the continuous delivery pipeline process. It’s really coming to the realization that applied correctly, these Continuous Delivery practices actually improve quality and improved security not the other way round.