This post was originally published on Goat Can.
“You are not special. You’re not a beautiful and unique snowflake. You’re the same decaying Enterprise IT Org as everyone else. We’re all part of the same compost heap. We’re all singing, all dancing crap of IT.” — Apologies to Chuck Palahniuk
I’ve seen a few exchanges from “Enterprise IT” vendors on twitter about the need for “a different kind of DevOps” for Enterprise IT. This culminated with a blog post from Andi Mann from CA on “Big Enterprises Need Big DevOps“. I’ll avoid the proverbial piss taking that could take place on the title alone and instead focus on the content.
First, let me say that Andi is spot on in the problems he mentions with Enterprise IT. Andi highlights that code cannot be “streamed into production” because of change controls. Audit and Compliance is critical for many large IT organizations. Enterprise IT can’t go buy cloud services with a credit card, and so on. In the end, Andi proposes that a new form of DevOps, Big DevOps, is needed to handle the unique nature of Enterprise IT.
But like a first year med student that is trying to impress the professor with an intelligent response, Andi is focusing on the symptoms of the problem, rather than the causes of the problem. Giving a patient a prescription for pain killers because he has a headache will do nothing if the cause of the headache is the patient constantly banging his head against his desk. The only people who benefit from that scenario is the doctor who gets to pay for his boat with the extra office visits, and the prescription drug salesperson that is making their quota (and taking the doctor to steak dinners).
The problem with many Enterprise IT shops is that they think they are a special and unique snowflake. They won’t stop talking long enough to understand how they might actually be their own worst enemy in creating all this process that is not “small DevOps Compliant”. Instead of understanding how the tenets of DevOps can achieve the same goal as many of their legacy processes, they are immediately dismissive.
Take for instance the issues around audit, compliance and change control. Many legacy change controls were put in place because changes to the environment were impossible to track across one or hundred systems. But the ideas of automation and Infrastructure as Code have evolved to help alleviate this problem. Wrapping things like Source Control Management, and Test Driven Development around your automation allows you to 1) have tested infrastructure code, 2) audit what is changing in your environment , 3) have an audit trail of who changed things, and 4) know exactly when it changed. Compare that to legacy change control processes if you will.
If you want to be successful with any large scale organizational change, you need to assume that everything you are currently doing is wrong and be open to change. Attempting to conform the organizational change to the organization just leaves you with the same organization you had in the first place.
Which brings me around to this post from ZeroTurnaround on “Why your organization hates DevOps and won’t implement it this year (again)“. They make excellent points that echoes and reinforces the points made in this post. Enterprise IT won’t do anything about DevOps or Cloud or anything else this year. They are too happy with the status quo. They want the change to conform to them and their processes. But change doesn’t work like that. Change is often hard, but if you dislike change, you’ll dislike irrelevance even more*.
*Props to @jonisick for that great quote.