I read two interesting articles last week. No operations team left behind where John Vincent wants folks to realize that enterprise IT organizations can only take baby steps on their way to adopting DevOps.  He is right, getting any large enterprise to change any of their processes is not for the faint-of-heart.  Most enterprises are using some version of ITIL processes for managing and auditing their infrastructure and applications. This means that enterprises would have to change those processes to adopt a DevOps approach -- which is the reason I thought it was interesting that Jake Sorofman ending his Is DevOps Subversive? commentary by speculating whether ITIL and DevOps thought leaders could collaborate.

In watching the IT management space, it clear to me that every new technology has ultimately required some changes in ITIL-defined processes are implemented in large enterprises.  For example, tiered web applications introduced dependency mapping and real-time SLA (service level agreement) analysis tasks into problem resolution processes.  Virtualization created the need for streamlined, pre-approved configuration and change management processes so production changes can be done in hours or days instead of weeks or months.  So why would cloud computing and the various Platform-as-a-Service (PaaS) options for application development be any different?

IT processes will need changing because enterprises will have to deal with all the new technology and skills that cloud computing and agile development are creating. This got me thinking that perhaps one way to think about the DevOps movement is as a ‘crowd-sourced' way of teaching enterprises how to change their existing IT processes.

Hopefully the result will be enterprise IT processes that are more collaborative, dynamic and able to deliver ‘valuable business outcomes' (or whatever the latest business jargon is for aligning business goals and IT capabilities).  In the best case scenario, these new enterprise IT processes would be supported by management solutions that simplify tasks and enable the auditing for governance and compliance without getting in the way of people completing their tasks.

However, even the best case scenario still involves getting an enterprise to change, and that depends on 1) getting the right people on the bandwagon and 2) having a staged implementation plan.

Doing the first one right, often involves understanding the agenda of key people in the corporate hierarchy. Then the IT changes must be translated into a language they understand, which, in my experience, is a non-trivial effort. Then they must be convinced that the benefits of the IT changes will help them succeed with their agenda. These are seductive tactics rather than a subversive ones, where the goal is to convert stakeholders into advocates.  Most of the case-studies I've worked on seem to follow the same internal political script, where adoption depended on demonstrating the win-win-win to a variety of key people.

Doing the second right, is often a matter of scoping the first stage to demonstrate a quick win for your key advocates.  When web application management was young (circa 2002), I saw that the solution vendors that had early success in enterprises were the ones that scoped their first projects with the owners of a few high-value apps and showed benefits within days or weeks.  My take-away was that giving corporate stakeholders internal bragging rights quickly was the best way to get keep the wheels of corporate change moving.

So it seems to me that the recipe for getting DevOps adopted in large enterprises would involve a mix of process change, politics and initial projects with quick time-to-bragging-rights.