Why DevOps?

Key Takeaways

• DevOps exists as a way to accelerate innovation through collaboration and frequent releases.
• Shorter release cycles give customers value more frequently and allow for experimentation.
• Bringing Development and Operations together streamlines the product release process to keep your organization focused on the goal of delivering value to customers.
• Statistically, high performing DevOps teams are far more successful than teams that do not have a DevOps process.

Introduction

In our first article in the DevOps track, What is DevOps?, our goal was to dispel some of the misconceptions around DevOps (for example, it isn’t just a team or set of tools) and arrive at a definition of DevOps rooted in principles and a shift in cultural mindset:

“DevOps is a discipline rooted in collaboration and communication, made possible by removing perceived barriers between teams and building trust in a culture of learning and continuous improvement, and drawing from proven technical and management practices that work toward a common goal of shortening software delivery cycles and improving the stability of deployments.”

It’s a bit of a mouthful, but the definition touches on all of the key points of DevOps. Without all of its constituent parts—the People, Processes, Tools, Principles, and Culture—you’re really just dabbling in DevOps, instead of truly embracing its mission.

To provide some background on why these different elements are so important to an organization’s DevOps strategy, in this article we’ll discuss a brief history of DevOps, including what problems DevOps attempts to solve, as well as the business case for fully embracing DevOps in your organization based on the latest research.

A Short History of DevOps: What Problems Does DevOps Try to Solve?

This year, DevOps has been around for a decade. DevOps is the culmination of many events, from the Agile and Lean movements, to practitioners and thought leaders trying to solve the recurring problem of painful software deployments, all while development teams became increasingly tasked with accelerating innovation through more frequent releases.

The term “DevOps” was coined by Patrick Debois, an IT consultant and one of the authors of The DevOps Handbook, in 2009.

In The Origin of DevOps: What in a Name? Steve Mezak describes this “perfect storm of events” that led to its inception, including a frustrating project where Debois was tasked with straddling the line between application development and IT operations to accomplish certification/readiness testing.

Those influences and experiences, coupled with inspiration from John Allspaw and Paul Hammond’s now-famous Velocity conference talk 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (which he wasn’t able to attend in person), led Debois to create the DevOps Days conference in Ghent later in 2009.

Thus, “DevOps” was born.

The Lessons of Lean: Optimizing the Value Stream

As mentioned earlier, the Lean and Agile movements were some of the key influencers of DevOps. Although different sources vary on when Lean Manufacturing truly began, the principles of the Lean movement gained traction in the early 1990s, after the publication of The Machine that Changed the World.

Lean grew out of the need to deliver value to customers faster by identifying and removing waste from a manufacturing process, or (put another way) by reducing lead times through optimization of the value stream.

In terms of manufacturing, where the flow of work is visible, The DevOps Handbook describes a value stream as the following:

“In manufacturing operations, the value stream is often easy to see and observe: it starts when a customer order is received and the raw materials are released onto the plant floor.”

Although it can be more difficult to identify the flow of work in the software delivery value stream because it isn’t observable from a bird’s-eye view, these same techniques have been adopted by many organizations to carry them through a comparable technology value stream, summarized by The DevOps Handbook as “the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer.”

The challenge of adapting Lean principles to IT Operations is illustrated in The Phoenix Project, where Bill, Director of IT Operations, finds himself overlooking the manufacturing plant floor at his own company one day. He’s just met with Erik, a potential Board member candidate, and after they’d briefly discussed the recurring issues plaguing the IT team, Erik urges Bill to follow him to the plant floor to observe the flow of work, though Bill is befuddled as to why.

Over time, Erik continues to take Bill under his wing, introducing him to The Three Ways—Flow, Feedback, and Continuous Learning and Experimentation—in the context of a manufacturing environment. He then waits, sometimes impatiently, for Bill to start connecting the dots between the principles and how they can be applied to his own flailing team’s issues.

Whether it’s being applied to processes on the manufacturing floor or from the workstations of IT and Development folk, the principles of lean are much the same (The DevOps Handbook):

“To enable fast and predictable lead times in any value stream, there is usually a relentless focus on creating a smooth and even flow of work, using techniques such as small batch sizes, reducing work in process (WIP), preventing rework to ensure we don’t pass defects to downstream work centers, and constantly optimizing our system toward our global goals.”

The Advent of Agile: Accelerating Software Releases

The advent of agile software development processes in the early 2000s was necessitated by software teams’ inability to continue to deliver software at the speed consumers demanded as PC computing proliferated in the 1990s.

In the TechBeacon article To Agility and Beyond: The History—and Legacy—of Agile Development, author Peter Varhol explains that organizations in the 1990s using traditional waterfall software development methodology had typical development cycles spanning 3 years, with certain industries (e.g., aerospace, government) having even longer cycles. He continues:

“The problem was, businesses moved faster than that, even 25 years ago. Within the space of three years, requirements, systems, and even entire businesses were likely to change. That meant that many projects ended up being cancelled partway through, and many of those that were completed didn’t meet all the business’s current needs, even if the project’s original objectives were met.”

Software development thought leaders understood the need for “lightweight” principles to replace process-heavy waterfall development methodologies in order to release usable software to customers more frequently.

Movements such as extreme programming, rapid application development (RAD), and iterative software development were all precursors to Agile that shared many of the same goals: getting working software into the hands of users more quickly, getting rapid feedback, and continuing to iterate to meet changing business requirements and user needs.

In 2001, the Agile Manifesto was solidified, including 12 principles that focus on customer satisfaction, effective collaboration, and continuous delivery.

The Business Case for DevOps

In our current “software is eating the world” climate where much of the innovation across industries is software-driven, Nicole Forsgren, et al., in Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations assert that how well an organization is able to deliver software to their customers is integral to how well an organization performs in “profitability, productivity, and market share.”

Accelerate authors present their research on 24 key capabilities (both technical and management) found to contribute to improved software delivery performance, and, in turn, overall organizational performance. (We’ll discuss these capabilities more in the next article.)

In fact, the Accelerate authors seemed almost surprised by the demonstrable value they surfaced:

“The findings from our research program show clearly that the value of adopting DevOps is even larger than we had initially thought, and the gap between high and low performers continues to grow.”

Their research found that high-performing DevOps teams when compared to low performers, have:

• 46 times more frequent code deployments
• 440 times faster lead times from committing to deploy
• 170 times faster mean time to recover from downtime
• 5 times lower change failure rate (⅕ as likely for a system change to fail)

These four key metrics span the entire DevOps pipeline, revealing that both accelerated development and operations stability are integral measures in improved software delivery performance—and are not at odds with one another.

The Accelerate authors explain further:

“Astonishingly, these results demonstrate that there is no trade-off between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures. This is precisely what the Agile and Lean movements predict, but much dogma in our industry still rests on the false assumption that moving faster means trading off against other performance goals, rather than enabling and reinforcing them.”

With the trade-off assumption busted, and the gap between high and low performers in DevOps ever-widening, the case for DevOps adoption has never been stronger.

Up Next: In the next article, Principle-based DevOps Frameworks, we’ll take a deeper dive into The Three Ways from The DevOps Handbook, mature capabilities in technical and management practices from Accelerate, the CALMS framework, and what each of them has in common.

Sources

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, and Gene Kim

Manifesto for Agile Software Development

The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations by Gene Kim, Jez Humble, Patrick DeBois, & John Willis

The Origin of DevOps: What’s in a Name? by Steve Mezak

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, & George Spafford

To Agility and Beyond: The History—and Legacy—of Agile Development by Peter Varhol

Talk to Us

Have more questions or comments? Learn more at help.sonatype.com, join us in the Sonatype Community, and view our course catalog at learn.sonatype.com.

And visit my.sonatype.com for all things Sonatype.