In Part 2 of this exclusive interview, Cameron Haight, Gartner Research VP, IT Operations, discusses the focus of his research for the last few years: DevOps.

Start with Part 1 of the interview

APM: What are the main advantages of DevOps that a company can gain?

CH: DevOps is ultimately about improving the business. It is not just about making IT in alignment with the business, but in the context of DevOps, IT is the business. IT cannot be looked at as a cost center. Not just to drive down costs. IT needs to look at how they can provide more value added capabilities that the business needs.

Mobile channels and digital channels are becoming quite critical. The expectations are very different when you interact with a smartphone device than if you are sitting at your desktop. So to enable new capabilities; to do A/B testing; to be more like a lean startup; to learn about customer desires, wants and needs – DevOps is an approach to help enable that.

APM: When DevOps is embraced by organization, if they do it right, will they have less problems on the production end?

CH: I would not say less problems, but the problems will change. You're always going to have problems. In the DevOps world you are always experimenting, you are going to find things that do not work. You are going to continuously iterate to improve. We try this, that didn't work, so we try something else.

Automation, hopefully, tries to remove some of the manual problems that crop up. One of the benefits of automation is consistency. We do this thing over and over again automatically, and we can now know what the results are because the human error part is largely removed from the equation. But we have to be careful that we don't blindly adopt it, because automation has gone awry in other domains. We have to be careful how we design these systems to ensure that we’re not just doing the wrong thing even faster.

But in a larger context, we have to be careful that we don't fall into the hammer and nail syndrome where we assume that the solution to every problem is a tool. The Amazons and Googles and Facebooks of the world are systems thinkers. So they try to look at: how can we improve this? And sometimes the answer is to re-architect it and therefore reduce the complexity. And maybe build manageability “in” at the beginning. And perhaps that means we need less of these tools like APM on the back end of that process because we built it right the first time. That may be an outcome.

At the end of the day DevOps is about proving the business outcomes by changing your culture and how you look at IT and how you perform IT. We are always going to have problems, but the question is how do we address (and learn from) them? How do we solve them? The goal is to recognize those problems and fix them as quickly as possible and in the process recognize that the problem is the problem and not get into a “blame game” mode of behavior. Agile and DevOps help us iterate towards getting it right quicker.

APM: What is the best way to help development teams to ensure top application performance before an app goes into production?

CH: Be a part of the discussion early in the lifecycle. One of my ambitions in life has been to get rid of the term “nonfunctional requirements”. Nonfunctional requirements are those which are not business logic related such as availability, maintainability, usability, things like that. Oftentimes, in the classic development organizations, those nonfunctional requirements have low priorities and are seemingly optional because the requirement is to get the code out the door, not to build manageability. So Operations needs to be part of those planning sessions where they discuss the backlog and what needs to be developed in the next interval. Operational concerns need to be put in the backlog as user stories, or perhaps operational stories, demanding the same level of attention of those development teams as the business-related needs.

In addition, I see development as increasingly owning deploy, so guess who gets the problem calls when it doesn't work. It won't be the Operations team, it will be the Development team. So it is in their own best interest to think about “nonfunctional requirements”.

APM: How is that accomplished, by having more conversations?

CH: At the end of the day, DevOps is about changing the culture. Start building a culture of trust and openness and collaboration. And so, formally it is in those sessions. But it has to take place all the time. I see some organizations put people together physically. Not just having the Ops side of the floor and the Dev side of the floor, but actually mixing desks, to build that relationship. It is about knowing what the other person has to go through.

Read Part 3 of the interview, covering Application Performance Management (APM).