"Worms, Roxanne! Worms"

That's the line that kept going through my head after I unscrewed the lid on the semantic can of worms differentiating "DevOps" from "Agile Operations." The movement and concepts behind the terms are still relatively new and with little clear understanding of the differences (if any; some simply consider them to be two terms that describe the same things) I thought it might be a good idea to delineate what I thought each addressed and what I saw as the differences.

Unfortunately, I did a pretty poor job of it and simply sewed confusion in my wake. Fortunately, the more clear-headed and analytical Ernest Mueller took the sorry muddle and created something supremely useful out of it. Ernest's terms and definitions are sufficiently clear and succinct that I plan to adopt them in my own discussions, and I hope others do as well.

My initial contention was that Agile Operations was more focused on, and described from the point of view of, system administrators, while DevOps, while involving both sysadmins and devs, was more described and driven from the development point of view.

Ernest went back to the bible and usefully used it to break the concept down as follows:

• Agile Principles - like "business/users and developers working together." These are the core values that inform agile, like collaboration, people over process, software over documentation, and responding to change over planning.


• Agile Methods - specific process types. Iterations, Lean, XP, Scrum. "As opposed to waterfall."


• Agile Practices - techniques often found in conjunction with agile development, not linked to a given method flavor, like test driven development, continuous integration, etc.

I believe the different parts of Agile Operations that people are talking about map directly to these three levels.

• Agile Operations Principles includes things like dev/ops collaboration (DevOps definition 1 above); things like James Turnbull's 4-part model [Ed. roughly analogous to our Principles] seem to be spot on examples of trying to define this arena.


• Agile Operations Methods includes process you use to conduct operations - iterations, kanban, stuff you'd read in Visible Ops; Agile Operations definition #2 above.


• Agile Operations Practices includes specific techniques like automated build/provisioning, monitoring, anything you'd have a "toolchain" for. This contains DevOps definition #2 and Agile Operations definition #3 above.

In retrospect, I made a number of errors in my first pass. First, I tried to come at it from a 50,000 foot view, where both movements are primarily driven by folks down in the trenches. Just as with agile development before it, DevOps is coming from the ground up (which is good) not the top down. My own practice is focused on strategy, and my efforts are not in evangelizing to grunts (who generally already have the good sense to adopt these things), but to management, who have a different, broader perspective of how all these things fit together. It was probably not productive to try to discuss those with people who do not, and do not need to, share those concerns.

Second, while advancing the observation that DevOps is a primarily development driven movement (which some proponents dispute, though it is not meant as a slight of any sort), I brought up the point that on the whole, most sysadmins never interact with developers, and that from a strategic perspective, it's often wisest to avoid involving one's organization in custom software development in the first place. While I believe these things are true, and that to properly adopt lean or agile techniques at the strategic and operational levels, simplification necessarily calls for an effort to use off-the-shelf (or, these days, over-the-web) solutions first, it's a perspective that almost seems designed to threaten developers, whose livelihoods are called into question by it. While this is not, again, intended as a slight (I often tell sysadmins that it's their job to work themselves out of a job; it's not that I expect it to happen, it's that such a mindset is useful to people building an agile system), it's not going to endear such readers to my considerations.

Finally, I didn't consider the size of the disconnect between the strategic and the tactical perspectives or that my real aim is to address strategic decision-makers. I think that it is something of a historic failing of movements of this sort that they neglect this aspect of changing the paradigm; while IT in general may be unique in that it offers senior technical staff unprecedented influence on their organizations, ultimately they are not the people that are designing or implementing the organizational changes necessary to successfully bring their ideas to fruition. It's a common geek misconception that something that is logical is also straightforward. Anyone who has tried to introduce agile development or the like to staid and non-technical business-people knows otherwise.

So if I apply Ernest's rubric to my own thoughts and goals, DevOps sort of falls away from the discussion. In his vision, it seems to simply be the expression of an overarching principle(s) of Agile Operations, and I will probably get more value, and see less confusion, if I continue to espouse the principle itself without drawing in an appellation that doesn't apply in many environments where the principles would still be useful. Business silos and communications problems are hardly unique to the operations/development interface (which Ernest points out, though still in a development context); agile operations has just as much application to more traditional, and more widespread, issues between IT departments and other business units.

That doesn't mean I won't still be tracking closely with the DevOps crew; I still think a lot of the most practical methods and practices for adopting those principles to operational concerns are coming out of that group. Whether development is involved or not all the principles are aligned and it makes good sense for me to follow their thinking. Little of what I produce will probably be of much use to them, however, and with respect to the folks I am trying to reach on the management side of IT, there's little point in confusing them with DevOps references that don't apply in their environments.