Who Owns DevOps???

An agile development team is humming along, maturing its practice, putting out 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, DevOps experienced practitioners, developers and with 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 best practice on 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.

1 comment:

  1. I think that it needs to be a collaboration between dev and ops. Ops needs to own the ops environments, but if they want dev's help in supporting those apps, then they need to work with dev to plan a deploy and release process - one that is rapid and robust. Much of devops today is the opposite of robust: automated does not equate to reliable.

    I also think that complexity kills, and today's deployment processes are becoming too complex: too many flaky tools - tools that become obsolete in two years. Teams need to keep it simple, and rely mostly on mature tools that have stood the test of time (e.g., bash) - not the myriad ones created by "some guy". The key is to create deployment processes the way you create your important apps: use sound software engineering, and use experienced developers. Don't hack it out: use encapsulation, comment the code, use ATDD, identify failure modes.

    ReplyDelete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share