The debate over who owns an application in production continues to unfurl. What I’ve found interesting is, after a period of time where writers and bloggers were looking towards IT Operations to be application owners, I’ve started to detect a bit of a backlash.
The arguments for IT Operations owning the application is simple:
- Development should stay focused on creating new applications and adding features, not maintaining what’s already in production
- If you ask a developer, they’ll always say they’d rather spend their time on innovation, rather than production support or bug fixes
- IT Operations generally oversees the production infrastructure (servers, storage, networks etc), so they are the natural caretakers of production applications as well
Analysts often point out that this is easier said that done: what is sometimes called the “required cooperation” between operations and development is often difficult to obtain. I’ve also seen it suggested that putting production applications in the hands of operations is a Utopian dream, leading to performance issues and SLA violations.
If I were to describe my own view of “natural selection” in regards to managing application performance, it would be more along the lines of collaboration. The development team is likely to help support applications as long as IT Operations is able to provide them with the information and data they need to fix root-cause issues quickly. Because much development is now done in agile environments, this sort of teamwork is becoming less of a philosophical choice and more of a business necessity.
If you look through blogs and Twitter, you’ll find some interesting grassroots movements such as #devops and #agileoperations. These are communities forming that acknowledge the need to break down the traditional walls that exist between Dev and Ops, and radically restructure those relationships so that they are focused on shared goals and outcomes.
One devops proponent, James Turnbull at Kartar.net, explains the problem:
“So … why should we merge or bring together the two realms? Well there are lots of reasons but first and foremost because what we’re doing now is broken. Really, really broken. In many shops the relationship between development (or engineering) and operations is dysfunctional to the point of occasional toxicity.”
(I love the phrase “occasional toxicity”…)
He goes on to add:
“DevOps is all about trying to avoid that epic failure and working smarter and more efficiently at the same time. It is a framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups. In a DevOps environment, developers and sysadmins build relationships, processes, and tools that allow them to better interact and ultimately better service the customer.
“DevOps is also more than just software deployment – it’s a whole new way of thinking about cooperation and coordination between the people who make the software and the people who run it. Areas like automation, monitoring, capacity planning & performance, backup & recovery, security, networking and provisioning can all benefit from using a DevOps model to enhance the nature and quality of interactions between development and operations teams.”
I believe that the question that comes naturally out of these conversations is this: does IT operations have the tools they need to facilitate this collaboration with their peers in development? Traditionally, they haven’t. The tools either didn’t provide much deep visibility into the application, or when they did provide deep visibility, they were extremely complicated for IT Operations to be able to understand and use. But creating those tools, and encouraging that collaboration, is one of my own company’s guiding principles.
Applications are becoming more complex and distributed, and development is increasingly taking place in the context of agile release cycles. So really, the question isn’t “who owns the app”–but how best to foster the collaborative process that enables dev and ops to both build out applications and resolve their performance problems, and to do so in record time.
