An agile development team is humming along, maturing its practice, releasing regularly scheduled application releases, improving quality, and making business users happy. Then, something happens. Maybe the infrastructure needs an upgrade or needs to scale. Maybe there is a difficult-to-diagnose performance issue. Or maybe the business and development teams are looking to deploy a new enterprise application to support a new capability.

The Development and Operations Clash

When any of these scenarios occur, the question is whether or nor the Operations teams are ready to partner with Dev on the timing, complexity, or scale of the task at hand. When there is a mismatch in culture, values, methodology, timing, skills, or operational practices, a classic Dev Ops clash arises. Finger pointing, bottlenecks, anger, or isolation may form between the IT Development and Operational teams.

It’s not just business or development-driven needs and issues that can drive this rift. Perhaps Dev is pushing changes and breaking operational procedures. Maybe there is a mismatch between an application and a required systems upgrade that’s holding back Ops from maintaining an environment. Or maybe Dev isn’t as good as they think they are in releasing defect-free, secure, high-reliability applications that perform well, and Ops is left holding the bag.

DevOps to the Rescue

In my last post, I covered the What, Why and How of implementing DevOps. The basic technical concept is that as you automate more of the interactions with the infrastructure from building, testing, deploying and monitoring you can remove many operational defects and better align Dev and Ops processes. From a practice point of you, the big questions are what tools and to what degree to invest developing any single DevOps practice area.

Who Implements DevOps

When I’ve discussed DevOps with colleagues, other CIOs, experienced DevOps practitioners, developers, and system engineers, the big divide around it is who “owns” DevOps.

• Does the DevOps starting spark come from Dev encroaching into Ops responsibilities? 
• Is it Ops who standardizes configurations and pushes Dev to align their development and release practices? 
• Or is it better to reorganize into a single DevOps team that collectively owns this practice and its maturity?

I’m not sure if there is a consensus on best practices for this question, but it certainly is one of the more heated topics around DevOps.

While all will acknowledge that DevOps requires a culture change there is some debate on who should take ownership and how to align the IT organization to achieve business and operational benefits.

I feel very strongly on this subject and will provide my perspective over the next 2-3 posts. Sorry for the cliffhanger folks. But here’s a hint. Like all practices, how you go about changing to a DevOps practice depends on the goals, the issues, the opportunities, the availability of talent, and what resources are needed on other business priorities. This transformation has to fit the organization, and I suspect most would benefit by documenting current processes and capturing metrics before jumping into the who and how of DevOps. 

So before I get to some answers, start by collecting some metrics.