Cameron Haight, Gartner Research VP, IT Operations, has replaced Jonah Kowall as Gartner's leading Application Performance Management (APM) specialist, since Kowall has taken a VP position at AppDynamics. In Part 1 of this exclusive interview, Cameron Haight discusses his background, and the focus of his research for the last few years: DevOps.

APM: What areas did you work on at Gartner, before your recent move into APM?

CH: I have been a Gartner for almost 15 years. I came to Gartner from BMC Software. My last role at BMC was Director of Research and Development, managing the development of what we then called application management or application service assurance solutions.

When I came to Gartner, I basically focused on the same things, the beginnings of the application management or application monitoring space. I worked on the first Magic Quadrant in this area. We did not call it APM at the time. The report was titled the Java Application Management Magic Quadrant.

Then I transitioned into Service-Oriented Architecture (SOA) management. SOAs were causing some new challenges at the time. And then I started covering more of the infrastructure space, as virtualization and cloud management came online. I saw that we were still being challenged in the enterprise by the fact that even though we had all these shiny new objects to play with – virtualization, cloud, APM style tools – we were not necessarily getting better.

That’s when I came across and started covering the DevOps movement. I wrote the first Gartner note on DevOps in 2010, talking about a new way to approach IT service delivery. I have been covering DevOps since that time. And more recently I have augmented my DevOps coverage with something I call Web-Scale IT, which is rethinking the entire IT value chain, from the application architecture to the data center. Basically trying to capture the patterns and practices of the Amazons, Googles, Facebooks of the world, and helping enterprises identify the parts of their business that might benefit from the same type of approach.

APM: Will you be continuing your work on DevOps, or totally focusing on APM?

CH: Research Director George Spafford is going to take over as the main analyst for DevOps. He is the co-author of The Phoenix Project, a novel about DevOps, with Gene Kim and Kevin Behr.

I will still be looking at the DevOps intersection with APM.

APM: How does Gartner define DevOps?

CH: Gartner defines DevOps as an organic body of knowledge that incorporates agile, lean and other methodologies in a systems-oriented context to improve IT service delivery.

APM: Is DevOps something you recommend for every company with a development team, or is DevOps something that delivers value only in certain scenarios?

CH: We think that the general concepts of Devops are broadly applicable. I work with clients that have very little in-house development, but they can still benefit from rethinking processes, tools and organizational approaches to improve their own time-to-market objectives.

APM: Do you still see political resistance to getting Development and IT Ops teams to collaborate?

CH: It is a learning process. We did not intentionally start out to design a dysfunctional organization. But that is what happened. I don't see enterprise malevolence but I do see enterprise frustration. Sometimes there is a resistance to change. But increasingly the organizations I interact with understand that it is a different era.

I worked with a client that is a large financial services institution, and just as an example of the rethinking that they are doing, they realized as a bank that they were a digital business that had a license to do banking. So IT became the bank. IT and the bank were not separable anymore. That causes organizations to start having interesting discussions about getting faster and more agile.

The businesses I talk to understand the need to change but they're just not sure how to do it. And that shows the good and bad sides of DevOps. There is no DevOps cookbook. There is no organizational body like ITIL to govern. There is no consortium. There is no standards body. DevOps was largely a pattern people in high performing organizations had to learn on the job, i.e., how to do things differently because the conventional wisdom wasn’t working for them.

APM: What types of tools enable DevOps?

CH: In the spotlight these days are automation and provisioning tools. That is where a lot of the organizational friction exists, in the release and deploy process. In some cases, DevOps enters the enterprise as a result of the fact that you may have part of IT doing agile development, so they are cranking out updates all the time, and most IT operational organizations are not designed to support that cadence of rapid release. So a lot of organizations focused their original DevOps efforts on the release and change process and deployment processes. As a consequence of that, you find configuration management tools getting a lot of scrutiny. Now monitoring and APM tools are starting to become more important DevOps tools as part of the all important feedback loop.

APM: How is DevOps implemented today?

CH: In a lot of organizations pursuing DevOps, the Ops teams are becoming engineering teams. We are seeing operations organizations starting to build self-service capabilities so that their customers – developers, QA and other teams – can get their jobs done more easily. Companies like Google have what they call site reliability engineering (SRE) teams, largely focused on building automation, so the software engineering teams can do their jobs more easily.

APM: Do you see movement towards a time when organizations will have a DevOps team instead of separate Dev and Ops teams working together?

CH: That is still not a common pattern, because most organizations are not quite ready for mashing them all up. The pattern is sometimes referred to as an Amazon two-pizza team – because they don't want any team larger than that which two pizzas would feed. So they want small agile teams. In the Amazon context they are multidisciplinary: program management, development, QA, and sometimes production engineering.

I have a banking client that has squads of what they call DevOps teams. They have integrated ops and dev on the same team. It is still a fairly radical approach. But in cases where you need to move fast (because you own a service “end-to-end”)it is one of the approaches that seems to be working in the industry. But again it is not something that I have seen as being pervasive in the enterprise. More commonly, we observe traditional enterprises putting together a “full-stack” team comprised of many roles to help jumpstart a DevOps initiative. They are so-called evangelists that help to communicate, train and even sometimes do the work in conjunction with other groups.

Read Part 2 of the interview, covering the advantages of DevOps.