DevOps isn’t Automation
DevOps isn’t automation, and it isn’t operations. But it’s also not agile, and it’s not development. So what is it?
It’s all of these things… and more. Perhaps DevOps is greater than Automation would make a better title.
Why isn’t building automation in isolation going to make things better? Gender issues in the statement aside, Deming states it well:
If you don’t understand how to run an efficient operation, new machinery will just give you new problems of operation and maintenance. The sure way to increase productivity is to better administrate man and machine. — W. Edwards Deming
I’ve seen companies who have implemented automation with greater and lesser degrees of success but — without exception — those who have taken a myopic approach which avoids dealing with the fundamental organizational, cultural, and process issues have left huge degrees of efficiency on the table, and usually make things worse for themselves.
So what, actually, is DevOps?
Aside from the cat memes that we love, the Internet is littered with variations on this graphic:
There have been a lot of versions on this theme developed over the last few years, as people have tried to express their own ideals of a perfect approach, as well as vendors who are looking to justify why you should be spending money on their particular tool, because, well, you know, it’s the best. Others have been successful at building a business about a proscribed model of DevOps maturity, calling out specific criteria, like this one from Scaled Agile:
Scaled Agile’s DevOps Health Radar (scaledagile.com)
In the end though, the principle remains the same: this is a loop because we seek continuous improvement, and to do this we have to understand how that last change impacted things. This in itself is nothing special in software: people have been developing iteratively for years.
The interesting thing is that DevOps looks at all of the steps from ideation through to delivery, with the objective of removing the bottlenecks that slow down the delivery of value and doing it in a way that is actually super-efficient.
Okay, fine, but that sounds daunting, because there are a lot of moving pieces, right? Well, yes, but that’s okay: if you’re not sure, or you need to convince your stakeholders, there has been a lot of work done over the years around optimizing process, and we can utilize things like Value Stream Mapping to help work out where those bottlenecks are.
Basically, the DevOps question is simple: what’s slowing us down?
Even without using a particular framework, you should be able to get insights into what to aspire to from the loop graphic or the health radar, but here’s another opinionated view, just in case:
Armory’s Digital Transformation Maturity Model (armory.io)
Whereas you cannot use a production line approach to actually writing software (which is where a proficient team in conjunction with Agile approaches can help if done right), there’s a lot that can be done throughout software development life-cycle where production line principles do apply: drive up velocity and predictability while reducing errors.
Can you say that your organization applies DevOps principles if you have a lot of manual silos, or if you’re in the data-center, or if you do manual deployments, or if you develop in a waterfall fashion, or if you maintain your own custom CI/CD tool-chain? How about if your software is based on a huge monolithic app that was written in COBOL, or if the business is so change-adverse that every production deployment requires five signatures and a sacrificial rubber chicken? How about if product teams aren’t great at prioritizing feature work? Maybe? Probably any one of those things doesn’t negate you getting your DevOps badge, but understand that you are living with a compromise and that compromise has a cost.
It’s not one single thing that makes an organization DevOpsey, it’s the culture around a set of ideas and principles as a whole that help drive the journey of continuous improvement.
This article originally appeared on Medium.