"There is nothing to suggest that devops can’t work in an enterprise. The main challenge will be reevaluating the existing people and processes from a constant collaboration viewpoint, keeping the business goals in mind."

Opening Statement

EMBEDDING DEVOPS IN THE ENTERPRISE

With the term "devops" picking up steam, vendors are now (re)branding their tools as devops tools. Similar to unit-test tools that supported an agile workflow, the current discussion on deployment automation supports the devops ideas. Even though tools have their merits,¹ after reading the August 2011 issue of Cutter IT Journal -- "Devops: A Software Revolution in the Making" -- it should be clear that tools are merely one aspect of devops and must be complemented with other aspects. The nice thing about tools is that they give you something concrete to discuss, as compared to the more intangible notion of "culture." Within large enterprises, tools are probably the easy part. Therefore, in this issue, we would like to focus on the harder aspects, like "people and processes," or as the Agile Manifesto puts it, "Individuals and interactions."

As agile practitioners Ken Howard and Barry Rogers have observed, "If your team has dug itself into a hole, the process ain't gonna pick up the shovel."² It all starts with great people. Getting people to collaborate is pretty easy in small, startup-like organizations, but it's a whole different ball game in an enterprise setting. Ernest Mueller kicks off this issue by looking beyond technical skills and gives sane advice on how to pick individuals and form teams in order to improve devops collaboration. You should not select just the right mix of cross-functional technical skills, but more important, you should screen for people's willingness to collaborate. Managers, you need to support this collaboration beyond the traditional handover point between development and operations. It needs to happen during the entire lifecycle -- from the moment you start thinking about new ideas all the way to running the implemented idea.

Once this team starts picking up steam, it will most certainly hit boundaries in your existing enterprise processes. The agile culture of small and frequent changes seems to be orthogonal to the culture of the Information Technology Infrastructure Library (ITIL). As Cutter Senior Consultant Bill Keyworth correctly points out in the second article, many ITIL implementations have focused on the process for IT operations' sake. This is the point that usually causes the friction, and working with a devops mindset is likely to amplify it. To address this, version 3 of ITIL's set of best practices introduced the concept of the Application Management Lifecycle: acknowledging that interaction between dev and ops needs to be permanent. Instead of dismissing ITIL as a bureaucratic approach, learn about its real intent and how it complements devops collaboration.

On the other side of the traditional dev/ops fence, agile process methodologies like Scrum and Kanban also need to move out of their comfort zones. Seasoned agilist Scott Ambler points out that agile needs to become more enterprise aware and discusses an approach he calls "Disciplined Agile Delivery." Elements such as release and deployment should be integral parts of your agile vision and your daily activities. Keep a focus on the real business requirements not merely by developing software, but by providing a complete solution that can run stably in production. Ambler mirrors Mueller's and Keyworth's thoughts on the importance of addressing both functional and nonfunctional requirements throughout the complete workflow: from inception through construction and transition.

Constant collaboration with good governance is key. To support this, you need metrics and facts. Ambler rightly points out another important aspect besides people, process, and tools: data integration. Large amounts of useful information remain locked up within silos. Think about log files, monitoring information, and configuration. By applying the concept of open data within your company, internal information should be freely available to all people engaged in the complete lifecycle.

Part of the "secret sauce"³ for listening to customer feedback is monitoring and collecting metrics. Alexis Lê-Quôc expresses this need in his article "Metrics-Driven Devops." This is another of the great boundary objects between development and operations. As Lê-Quôc points out, you need to take away the friction of collecting metrics. Having the correct APIs allows you to automate part of the process. Friction discussions -- such as "Why did it crash?" or "How many customers use this feature? -- become less emotional. It puts the engineering back into IT. By identifying the "actionable" metrics -- those between lower-level technical metrics like memory and CPU usage and high-level business metrics like page views and conversion rates -- you create a framework where people from their unique enterprise perspectives can keep relating to the business goals.

The previous advice might sound great, but it might also sound intimidating. Shifting an enterprise into a new direction is like turning an oil tanker -- it takes a while to turn, but once on the right course, it can be very powerful. Concluding this issue, Kief Morris provides a case study that shows us how to go in small steps. Start by introducing the minimum viable approach to get the collaboration flow going between business, development, QA, and operations. This will reduce the cost of change and risks. But please don't stop there: use the feedback channel at the end of the chain to improve your understanding of the process and make improvements accordingly. A powerful positive loop will result, creating a win-win situation for development, operations, QA, and -- not least -- the customer.

To conclude, I would say that there is nothing to suggest that devops can't work in an enterprise. It can coexist with both agile processes and ITIL. But like any other change, it will take time and requires you to take the existing ecosystem of process and people into account. The main challenge will be reevaluating the existing people and processes from a constant collaboration viewpoint, keeping the business goals in mind. If people question collaboration, don't measure collaboration for its own sake -- look at the actual results and facts. And if it doesn't work, learn and improve.

ENDNOTES

¹ Debois, Patrick. "Devops, Tools, Fools, and Other Smart Things." Presented at GOTO Aarhus Conference 2011, Aarhus, Denmark, 10-12 October 2011(www.slideshare.net/jedi4ever/devops-tools-fools-and-other-smart-things).

² Ken Howard and Barry Rogers. "Beyond Process and Tools: People Issues in Agile Software." Interview by Matthew Heusser. informIT, 14 April 2011 (www.informit.com/articles/article.aspx?p=1701933).

³ Allspaw, John, and Jesse Robbins. Web Operations: Keeping the Data on Time. O'Reilly Media, 2010.

ABOUT THE AUTHOR