Open Source

Getting DevOps Right: The Lay of the Land

DevOps means different things to different stakeholders, but the basic components are the same.

During the past year or two, there has been much ado about DevOps in the media. The number of DevOps voices has risen to a cacophony and, in tandem, the level of confusion among listeners is rising, too. The DevOps movement offers the potential for an important bump in both professionalism and productivity in the IT marketplace. But, as with all movements before it, there is the danger that DevOps will be misunderstood and misapplied. This article, and several that follow on, will try to cut through the confusion by providing coherent, no-nonsense advice.

Let's begin with some definitions. First, I use the term "production" throughout this article in two ways. When I use the IT-phrasing "release into production," I also mean to imply "release into the marketplace" when the context deals with a commercial product. When I use the word "production," I mean a combination of both operations and support (sometimes referred to as the "help desk"). Many organizations treat these as two separate concepts, although some combine them. "DevOps" is a portmanteau word for the combination of development and operations. Development in this context includes all activities that occur before a solution is released into production, from formulating the initial concept through project initiation through construction to deployment. Operations in the DevOps context includes all post-deployment activities; that is, the "production stuff," which includes both operation and support of deployed solutions.

Defining the term DevOps is easier said than done because there are several complimentary viewpoints to consider  from each of the major DevOps stakeholders. Depending on whom you talk to, you're going to get a different definition of what DevOps is all about. The DevOps stakeholders, and their viewpoints, are:

Developers, particularly experienced Agile developers, talk about DevOps in terms of a continuous flow of delivery into production, potentially several times a day.

Operations professionals often view DevOps as promoting a more effective relationship with development teams, both throughout the development lifecycle as well as once the solution is in production. Experienced operations people also realize that their internal processes, often based on ITIL or ITSM, need to be streamlined so that they are in a better position to collaborate with development teams.

Support professionals, sometimes called help desk professionals, view DevOps similarly but with a support twist: They want to work with development teams to ensure that their needs are understood and met before a solution is released into production. They also want to ensure that there is an effective escalation process in place to handle change requests (including defects) once the solution is in use.

Senior management views DevOps as an effort to increase the overall efficiency of the IT department by streamlining how everyone works together.

Disciplined DevOps

Now let's look at Disciplined DevOps. Figure 1 depicts a before-and-after picture of what Disciplined DevOps strives to achieve. In many organizations today, the development and operations groups struggle to collaborate effectively, with process and organizational barriers erected between them.

Development teams will deploy irregularly  "fast" teams putting out one or two releases a year with the occasional patch as required to address a production problem.

The operations department, in turn, will push change requests, including defect reports, back to the development organization. The two organizations work together just enough to ensure that these activities are successful, but there is significant room for improvement. Disciplined DevOps introduces those improvements by promoting strategies to increase the collaboration between development, operations, and support staff; introducing continuous delivery practices to development; introducing new organizational structures within IT; and adopting business intelligence technologies and techniques to support both development and operational intelligence, which in turn, supports improved IT governance. The difference between a disciplined approach to DevOps and, if you will, an undisciplined one is that the disciplined approach takes a holistic view that considers the desires of all DevOps stakeholders and doesn't focus on just one viewpoint.

Figure 1: Closing the DevOps gap.

To succeed with Disciplined DevOps, you need to address the 5Ps of improvement: People, Principles, Practices, Products, and Process. These issues are listed in priority order. People and the way that they interact together are the primary determinant of success in any IT endeavor, and Disciplined DevOps clearly requires people to rethink their skillset, how they define their roles, and how they work with others. IT organizations adopting DevOps need to rethink the underlying principles that guide their decision making; for example, adopting a principle of being more reactive to business will motivate them to adopt ways to release into production more often. Organizations will need to adopt practices such as continuous integration, continuous deployment, operational intelligence, collaborative support, and many more that may be new to them if they're going to make a go of DevOps. New products, including development tools, business intelligence tools, and operations monitoring tools, may need to be adopted. Finally, process frameworks such as Disciplined Agile Delivery (DAD), which bake DevOps strategies into the development process, as well as updated versions of ITIL or ITSM, will need to be considered as well.

Misconceptions

There are common ways that organizations seem to be running aground with DevOps. I'm concerned about the mistaken view that "cloud=DevOps," which seems to be growing in popularity. While adopting cloud technologies can make some aspects of DevOps easier, it is only one of the 5Ps (in this case, product). Similarly, the tool-driven messaging from some vendors, and some open-source communities, is also a bit worrisome. New tools are part, but only part, of the DevOps picture. A third problem, mentioned earlier, is being overly focused on one DevOps stakeholder viewpoint. Particularly common is adopting a development focus due to the obvious coolness, and potential for improved productivity, of continuous delivery practices. In this case, the problem is focusing on only the practices portion of the 5Ps.

These misconceptions, the ensuing problems they can cause, and more-detailed advice on rectifying them, will be discussed in future DevOps articles.

Scott Ambler spent 6 years working with IBM Rational, where he helped clients adopt and adapt Agile technologies. He now consults in that area. He is a long-time contributor to Dr. Dobb's.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!