Nondisruptive DevOps: Is it an oxymoron?
Not long ago, I was explaining DevOps to a customer, and after patiently listening to me for 15 minutes he looked at me and said, “The changes entailed by DevOps are far too disruptive for an organization as large as ours. The disruption to our current processes would put our business at risk.” In this blog post I will explore whether implementing DevOps is necessarily disruptive to businesses or if it can be introduced without putting a business at risk.
A commonly encountered situation
In many organizations, entities are seen either as cost centers or revenue centers. Typically, IT operations are considered a cost center that spends money to keep the business going. IT development is more often attached to lines of business, which work toward increasing the revenue of the company. These opposing views are at the heart of the chasm that exists between Dev and Ops. On the Ops side the priority is stability, business continuity and cost reduction over time. On the development side, priority is given to quick changes, new services and innovation.
DevOps aims to bring people from development and operations to work closely together toward a common goal, with common business-oriented success criteria. Bringing people together will always mean some disruption to practices and working habits. But does it necessarily mean that the business is at risk?
A way out of disruption
My experience has taught me that collaborating can be nonintrusive. On a recent project, the operations entity of a large bank had to give developers more insights into their practices so that the developers could design their software with the final architecture in mind and run tests that took into account things like clustering or security.
Letting developers enter the operations working space and shadow administrators or architects was not an acceptable option, as the operations guys were worried that their knowledge was getting out of their hands. Instead of adopting this approach, the operations team exposed their practices through several portal services available to developers, where system topologies and service level agreements were clearly exposed for read, create, update and delete operations.
That way, the developers did not invade the operations space but still had great insight into what the practices were. Furthermore, this enabled developers to work more at their own pace, while enabling the operations team to streamline and standardize around common architectures and topologies.
Applicable to other situations
The context in the previous situation is not the only one that can motivate the adoption of a service portal to provide operations services to developers. Sometimes, geographical barriers may prevent people from getting together. Establishing a clear communication interface will go a long way to ease collaboration between two teams sharing a common objective.
Are you considering adopting DevOps? What approach are you looking at in order to bring people closer together?