As CIOs face growing pressure to increase agility and responsiveness, it’s no surprise that DevOps is becoming a frequent topic of conversation. While DevOps originally gained traction with startups, it has started to make inroads into larger enterprises as adoption of public and hybrid cloud platforms has spread.
DevOps is a software development concept that seeks to break down the traditional silos between developers and IT operations. The goal? To enable a continuous software release model that allows business requirements, not IT needs, to drive the pace of change. Automation driven by infrastructure-as-code and supporting tool chains is a big part of story, but DevOps is essentially more about creating a collaborative, cross-functional culture that accelerates the software delivery cycle.
As with virtually any new technology or IT model, there are voices that discount the applicability of DevOps in larger organizations. In fact a recent Wall Street Journal article even went so far as to boldly state that DevOps won’t work in the enterprise.
CIOs and application owners rightfully have questions about a new software development approach that challenges many of the assumptions of traditional models. But in many cases these concerns turn out to be unfounded. Here are some misconceptions and objections to DevOps that I’ve heard recently:
- “Our current models are too entrenched” – one common reaction is that existing organizational structures and SDLC processes are too deeply entrenched to change, particularly for large enterprises with thousands of applications. In many cases, development, QA / testing and operations have become independent silos that have been optimized for scale and cost efficiency (often through outsourcing). But this ignores the fact that DevOps can be piloted in parallel to existing processes. Just as many CIOs have discovered with cloud, incubating DevOps with a small, focused team and supporting automation tools can provide a the opportunity to define new models and processes while minimizing risk.
- “DevOps isn’t a fit with our application portfolio” – will DevOps be applicable to every type of application in the enterprise portfolio? Of course not. Stable, mature legacy applications will likely not benefit from a new continuous delivery model that enables daily releases. But to discount DevOps just because it’s not universally applicable is throwing the baby out with the bathwater. A natural focal point for new DevOps efforts is often around new market-facing “systems of engagement” that benefit from more rapid release cycles.
- “DevOps conflicts with ITIL” – organizations that have adopted ITSM and ITIL sometimes express concern around how DevOps automation impacts controls in areas like release and change management. But at the end of the day, ITIL is a best practices framework, not a prescriptive set of methods. The way that ITIL processes will be implemented in DevOps will necessarily look different than in existing models, but there is nothing inherent in ITIL that precludes adoption of DevOps practices. It’s adherence to the principles, not the implementation approach that matters.
Just as we’ve seen with cloud adoption, CIOs may not, in fact, have a choice as to whether to go down the DevOps path. Business users will likely demand the agility and market responsiveness that DevOps enables. For CIOs driving ITaaS and cloud transformation programs, finding a way to incorporate the DevOps model may not just be prudent, but necessary.