You wake up and you have a sore throat and nasal congestion. Is it the common cold? Perhaps the flu? Is it bacterial? Viral? Any good physician will tell you that diagnosing disease purely from symptoms is a fool’s errand (or maybe malpractice). A diagnosis identifies disease which leads to prescribing a treatment plan for eliminating or placing in suspension the symptoms. In a similar vein, DevOps is not a diagnosis either. DevOps is merely the symptom(s).
Initially, DevOps was the recognition that development and operations were very often not aligned to a common goal of satisfying the business customer. Over time DevOps became representative of other symptoms of IT dysfunction, such as configuration drift, poor release management controls, lack of testing, high numbers of defects during development, and a culture of finger pointing when systems failed. Again, these are just more symptoms of the same diagnosis, which is application delivery dysfunction.
This realization that DevOps is a symptom has been a long journey for me dating back to July of 2011. At first, I viewed DevOps as the modern day version of the Haymarket Riots. It was a way for the overburdened and under-appreciated efforts of the IT workers responsible for delivering and maintaining today’s systems to take control and bring some stability to their jobs. From there it transformed into the movement focused on dealing with the technical and organizational issues that impact application delivery.
Today, DevOps seems to be a catch-all for so many facets of application delivery that it’s quickly becoming a useless term. When a sales executive calls me and says a client is interested in DevOps, I respond by asking for more details regarding their interest areas, such as continuous integration, release management, continuous testing, etc. To help them understand the comprehensive nature of their request, I put together a checklist of items for them to review with the client.
Perhaps, even more frustrating than the uselessness of the term DevOps in deciphering need, are the conversations with people that say, “we’re doing DevOps,” but refuse to drill down into what they mean. It’s very reminiscent of conversations where businesses state, “we’re doing cloud already.” However, if we look at DevOps as a symptom, and you say you’re doing DevOps, I’d look at you and say, “I bet you are.” After all, many businesses are struggling with application delivery. And as your IT doctor, the real fun of giving you a checkup and identifying the causes of your application delivery dysfunction diagnosis can then begin.
Ultimately, I came to the realization, DevOps doesn’t solve anything (or for some it solves everything, either way its lacking focus) , which led me to the realization that DevOps is the canary in the coal mine highlighting the need for change in the way we build, release and operate applications.
So, if DevOps represents the symptoms and application delivery dysfunction is the diagnosis, what is the treatment plan? Continuous Delivery. Continuous delivery is to the application delivery pipeline what enterprise architecture is to all systems in the business. It’s a holistic approach to enabling the business to leverage its IT assets to operate better and innovate faster. Achieving maturity in continuous delivery doesn’t mean you’ve fixed every issue limiting application delivery, but it does imply that business has taken an honest look at it’s bottlenecks and constraints and are removing them when possible thereby constantly improving.
Interestingly, if you accept this premise, the connection to lean manufacturing often associated with DevOps, and illustrated by The Phoenix Project, makes perfect sense. That is, as we seek to improve the continuous delivery pipeline we can use tools and practices from lean manufacturing, such as value stream mapping and Kanban designed for this type of problem. Following on our analogy, lean tools and practices become the pharmaceuticals supporting our treatment plan (continuous delivery) eliminating our ailment (DevOps).