Many of the DevOps movement’s founders come from the IT Ops world, and are asking the right question: What is important to the Business, and how do we, in IT Ops, align our efforts with what the Business cares about?
The Dev guys already figured this out, quite a while ago. The first principle of the Agile Manifesto, written more than a decado ago, is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
It’s about time Ops figured this out. There’s a reason that in so many companies Ops has a reputation for being the department of “No!” We serve our systems and processes and SLAs. But we have forgotten (or never knew) that our job is actually to serve the Business.
DevOps is largely Ops bridging the gap between who we have been, and who the Devs already are – teams who deliver value to the business.
It’s also about collaboration between the Dev and Ops silos. Teams are building expertise that crosses over between these disciplines. Responsibility for success or failure is being shared between Dev and Ops. (I’ve even heard of Devs carrying pagers and taking their turn in the on call rotation!)
I have heard DevOps proponents tear down best practices methodologies like Problem, Incident and Change Management, for example. Some say these processes are never anything but red tape, getting in the way of delivering meaningful work for the business.
But there’s hard science showing appropriately implemented controls around processes like these increase MTBF and reduce MTTR. I think the operative word there is “appropriately” because I have also seen some of those implementations of “best practices” where the processes do, in fact, get in the way of productivity and effectiveness.
So… throwing the best practices “baby” out with the bathwater is Bad. Folks who can sort best practices out and apply them appropriately are Good.
I have been around a handful of Devs who have used Agile or DevOps to justify being granted the “keys” to the operational “kingdom.” At the same time, they won’t accept the responsibility that comes with that power. These people convince the business that availability problems and release delays are all about Ops and their arcane processes. I read here where the IT Skeptic called this kind of behavior SmashOps. When DevOps is used as a stick to beat up Ops, things get Ugly.
So then… is DevOps really the next Great Thing in IT?
It’s too soon to tell how important DevOps will be. As it has been with ITIL or other best practices, no matter how brilliant a set of principles may be, when applied inappropriately, those principles will hinder productivity and business alignment.
Like any other movement, DevOps should be judged by how well the people following its approach use it to deliver business value. If the movement helps teams be more effective, efficient, and most importantly, strategic and revenue enhancing partners to their businesses, then DevOps may very well become the next Great Thing.