This post is from the XebiaLabs blog and has not been updated since the original publish date.
"Can Devops work in the enterprise?" is the wrong question!
A couple of days ago, venture associate Rachel Shannon-Solomon argued in the WSJ that Devops was great for startups, but not (yet) something that could work in large enterprises. Unsurprisingly, this caused a flurry of responses, among them a Mike Kavis piece in Forbes pointing to a recent survey that catalogs enviable improvements by enterprises adopting Devops. My take? The question of whether "Devops is right for the enterprise" is so dramatically under-specified that it's easy for both to be right in their own way. More importantly: it's the wrong question to be asking in the first place! First off, the fact that some large enterprises have been able to achieve impressive results by adopting a variety of Devops practices in no way "proves" that some of the challenges that Shannon-Solomon highlights - overcoming siloed structures, working with an existing tool infrastructure, changing an ingrained culture - are not real. What we are seeing, though, is that enterprises are indeed aware of these challenges, are looking to take steps to mitigate them, and remain very enthusiastic about Devops. Which brings us to my second point: what does it even mean to say "Devops won't work for enterprises yet", given how broad and vague a term "Devops" has become? That's about as precise as saying "cloud will (or will not) work for the enterprise". Devops as discussed today can seemingly encompass everything from creating end-to-end teams and giving developers pagers, to introducing a bunch of Infrastructure as Code-style automation tools, to building delivery pipelines and working towards implementing Continuous Delivery, or simply hiring a bunch of new sysadmins and calling them "Devops Engineers" without making a single change to organizational practices or culture. Some of these changes are certainly harder to adopt in a large enterprise than others, but to me we can only really have a conversation about the suitability of Devops for the enterprise if we are much more specific about the principles, practices and tooling we're talking about. More importantly, though: why are even talking about "adopting Devops" as if it were a critical goal in its own right - whether for startups or enterprises? The mindset and practices of Devops can definitely have a tremendously beneficial impact (as the Forbes data demonstrates), but they are surely just a means to achieving business goals, not an end in themselves! Let's talk about making our services and applications more scalable and resilient by ensuring Operations has earlier input into the development cycle, or reducing troubleshooting time and effort by making sure administrators understand the services they are maintaining better. Let's try to minimize handover moments and idle time by focusing on the end-to-end service, rather than narrow departmental responsibilities. Let's deliver higher-quality features to our users faster and more regularly (the aim of Continuous Delivery rather than Devops, really), and collect relevant information about how they use our services in order to keep improving them. Let's talk goals and then see how, and with which principles, practices and tools - Devops, Continuous Delivery or otherwise - we can best help realize these within the context of our organization.