DevOps is the least interesting feature of DevOps.
In case this is the first you’ve run across the term, DevOps is what you get when you add IT Operations to Agile development. This is a Good Thing because when the team needs computing resources a team member can provide them instead of the request waiting in a FIFO queue until it floats to the top.
For the record: I recommended this to a client in 2006. It didn’t seem important enough to name, let alone promote as the Next Big Thing.
But DevOps has become a lot more than just adding Ops to Dev.
First and foremost, it’s about establishing a culture of collaboration that includes all stakeholders in a project and the business change it’s been chartered to engender.
Which makes this yet another opportunity to say I told you so: There is no such thing as an IT project.
You’re welcome.
Second: DevOps is more Agile than Agile: Instead of bundling lots of small changes into a big release that requires extensive testing and change management, DevOps deploys changes so often that each individual change is too small to worry about.
The magic buzzphrase is “continuous testing and integration.” In practical terms this means DevOps makes a wonderful excuse … sorry, change that, business case … for an IT shop to do what it should have done a long time ago, namely, implement automated regression and stress testing.
So … DevOps = Agile + Collaborative business change + Automated regression and stress testing + Continuous implementation of small changes.
Sounds outstanding. But does it pass the so-what test?
Sadly, many of the answers are little more than hand-waving.
For example: “DevOps is a powerful revenue driver. About 34 percent of respondents working at organizations with greater than average profit growth said they had already adopted DevOps while only 17 percent of those with less than average profit growth had done so,” says Andi Mann, vice president, CA Technologies.
I don’t want to pick on Andi Mann. He’s been a Force for Good in this area, providing no shortage of excellent insights.
But as correlation doesn’t prove causation, this isn’t one of them. More likely, the best-run companies — those whose strategy, overall execution and business culture drive exceptional profit growth — are more likely to adopt DevOps than their brethren.
Then there are metrics that are just plain … well, you be the judge. Puppet Labs doesn’t really deserve to be singled out but it is the source of one such metric, namely, that Amazon Web Services claims a mere 0.001% of its deployments cause outages. “0.001%?” I hear the metrically naive exclaim. “Wow! That’s fantastic!”
Uh … no. If you take a release that caused an outage because it contained a defect and break it up into 100,000 micro-releases, one of which contains the same defect, you end up with the exact same number of defects released into deployment, even though only 0.001% of your releases contain them.
To be fair, finding and fixing the bugger would be a lot easier with 100,000 micro-releases.
Then there’s my favorite — DevOps lets you release new features to customers more quickly. It’s a fair claim, so long as the software you’re DevOps-ing is visible to your customers, which it is if it’s part of your eCommerce site but isn’t if it’s something you use for, say, property management.
What’s that? Internal customers? Just a guess: If you change the screens they work with several times a day without warning, they aren’t going to thank you.
Okay, fun’s fun, and fun as it is to debunk hand-waving business cases, providing valid ones is probably more useful. With that in mind, here are three:
- Automated testing: Yes, setting up and maintaining an automated test environment is far from easy. The payoff: Orders of magnitude fewer bugs and system failures make it through to production. DevOps gives you a convenient context for it.
- Integrated business change: There really isn’t any such thing as an IT project. The industry momentum behind DevOps gives you a convenient context for this as well.
- Whether correlation results from causation doesn’t matter: Making DevOps work in a business requires changes in mental habits outside IT that will make the business more agile. And not only more agile, but more focused on whether what it’s doing is something Real Paying Customers will care about.
That is: While the companies that have already implemented DevOps already have other characteristics that make them more successful than their competitors, for those that haven’t, implementing DevOps could help transform them into companies that have these characteristics as well.
It’s a classic case of the fringe benefits outweighing the planned benefits.
It’s classic consultants’ logic: my vast experience tells me that many successful companies do X; do X and you, too, will become a successful company. Whereas successful companies are successful for many reasons, including (generally) a good helping of pure dumb luck.
Now, if instead the consultant had said: my vast experience tells me that many unsuccessful companies do Y; whatever you do, don’t do Y – that might actually be useful.