You can't automate what you can't standardize, so devops can't address a key developer frustration

Although the devops movement is centered on reducing the friction between developers and operations teams and the ability for developers to deliver applications faster, neither outcome is possible without standardization. But are developers and operations teams ready to agree on standard environments?

Why both developers and operations teams are focused on devops

A recent post from Matt Asay, a longtime open source advocate now at cloud vendor Nodeable, links to an interesting survey of 750 people by Puppet Labs. One surprising finding is that although devops is often considered a developer-led movement, nearly four times as many operations staff and administrators responded to the survey as did developers. Also a surprise, as Asay points out, operations teams appear to see the same potential benefits from devops that developers do.

In the survey, Puppet Labs finds that 55 percent of respondents ranked the automation of configuration and management tasks as the top benefit expected from the devops movement. Another 13 percent ranked it in their top three expected benefits.

You can't automate what you can't standardizeGiven the rise of devops advocacy, I've spent time learning more about the interaction between developers and operations teams. One thing I've come to understand is that these two groups tend to think differently, even if they are using the same words and nodding in agreement.

It's no surprise developers want to adopt tools and processes that allow them to become more efficient in delivering new applications and continuous updates to existing applications. Today, these two tasks are hindered to a degree by the operations teams that are responsible for production environments. As Asay points out in his post, developers seek automation. (As an aside, that's why enterprise developers have been very open to using public clouds.)

Operations and administrations teams, as the Puppet Labs survey shows, are also drawn to the automation of manual tasks they must do today, some of which result in delays for developers as they wait on the operations team to provision new resources or promote applications into production.

Here's the rub: Although both sides of the devops coin value automation, neither is explicitly calling out the fact that you can't automate without standardization. Well, maybe "can't" is too strong a word. In IT, we can do pretty much anything with enough elbow grease.

But ask yourself: Could you automate the provisioning of a development environment or the deployment of a middleware stack without standardizing what exactly is being automated? No, not really. Operations teams understand this; it's why operations teams promote enterprisewide standards. In most cases, these standards -- whether for operating systems, hypervisors, databases, or application servers -- allow for some limited degree of variability. For example, many IT shops support both Linux and Windows, but if you want Solaris, sorry, you're outside the corporate standard.

This is the environment that developers are working in today: You can select among enterprisewide standards, but not go outside them. And yet, this is the exact environment that frustrates developers. Sometimes, the corporate standard doesn't exactly fit the developer's skills or interests or the project's needs. Hearing "tough luck, champ" is what's driving developers toward devops. But developers automating IT stacks that don't fit into the corporate standard won't help bridge the gap between development and operations.

What's needed is a joint agreement between development and operations on the acceptable environments that make up the corporate standard, which are in turn automated.

This isn't a technical issue. It's a cultural issue. Before your teams push forward a devops initiative, get them beyond the buzzwords and into the nitty-gritty around corporate standards, degrees of variability, and how -- or even if -- to allow developers to experiment outside the corporate standard. If you don't, you'll have developers and operations expecting different outcomes while using similar words.

I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.