Defining DevOps

One of the biggest misperceptions about the term DevOps is that it is a set of technologies and tools that developers and operators use to automate “all the things”. DevOps is much more than tools and technologies and it takes more than just developers and operators to successfully embrace DevOps in any enterprise. Many people will shrug off this debate as nothing more than semantics but understanding DevOps is critical for an organization so that they can put together a good strategy to drive towards their desired outcomes. If all that DevOps is to an organization is automation of CI/CD pipelines, they will likely leave out many important steps required to deliver in the cloud at scale.

There is no official definition of DevOps. The definition Mike came up in an article back in 2014 is “DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better-quality software more quickly with more reliability.” I went on to add “DevOps is the progression of the software development lifecycle (SDLC) from Waterfall to Agile to Lean and focuses on removing waste from the SDLC”.

But don’t take our word for it; look at the work of the leading DevOps authors, thought leaders, and evangelists. Gene Kim, co-author of popular DevOps books such as The Phoenix Project, DevOps Handbook, and the Unicorn Project, in his keynote presentation at the DevOps Enterprise summit in 2017, stated:

“This is my personal definition. I would define DevOps by the outcomes. In my mind, DevOps is those set of cultural norms and technology practices that enable the fast flow of planned work into operations while preserving world class reliability, operation and security.

DevOps is not about what you do, but what your outcomes are. So many things that we associate with DevOps fits underneath this very broad umbrella of beliefs and practices--which of course communication and culture are a part of them.”

In the book “The IT Manager’s Guide to DevOps” the authors Buntel and Shroud define DevOps as “... a set of cultural philosophies, processes, practices, and tools that radically removes waste from your software production process”.

The DevOps Handbook opens with “Imagine where the product owners, Development, QA, IT Operations, and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds”.

And finally, the popular and influential book, Accelerate, by Forsgren, Humble, and

Kim, describe the basis of their research:

“We wanted to investigate the new ways, methods, and paradigms that organizations were using to develop software, with a focus on Agile and Lean processes that extended downstream from development and prioritized a culture of trust and information flow, with small cross functional teams creating software. At the beginning of the project in 2014, this development and delivery methodology was widely known as “DevOps”, and so this was the term we used”.

As you read through these definitions, what are some of the key terms you see?

• Culture
• Cross functional teams
• Processes
• Remove waste
• Reliable
• Quality
• Trust
• Sharing
• Collaboration
• Outcomes
• Flow

If DevOps embraces all of these terms, one has to wonder why some many organizations create a new silo called DevOps and focus on writing automation scripts without collaborating with the product owners and developers. We see many companies take their existing operations teams, adopt a few new tools, and call it DevOps. While these steps are not bad, and can even be viewed as progress, a non-holistic approach to DevOps will not deliver its promise. DevOps silos often lead to even more waste in the SDLC because the focus is usually exclusively on the tools and scripting, and not on trust, culture, collaboration, removing waste, outcomes, etc.

What about DevSecOps? NoOps? AutoOps? AIOps? Aren’t those things all better than DevOps? Should I be adopting those instead? Well the answer to those questions all get back to having an outcome focused definition of DevOps that have tools and techniques as enablers of the culture and process, not as the goal. To most mature DevOps practitioners, DevOps is all of those things. When we are focused on outcomes, you use the techniques that best help you deliver those outcomes. These new terms get created to focus on some aspect of the system that a proponent feels is under-represented (security, Automation, AI, etc). It helps professionals and consultants feel more leading edge, and their clients/organization feel current. But make no mistake there is little truly new in these next generation buzzwords from this old fashioned (circa 2009) term of DevOps. So at the end of the day, you should follow the principles we discuss in this chapter. Then call it whatever you want.

To understand DevOps, it is critical that we understand its roots. Its evolution started back in 2008. At the Agile 2008 Toronto conference, Patrick Debois, a data center consultant and Andrew Shafer, an agile developer, met shortly after Debois was the only attendee for Shaffer’s session entitled “Agile Infrastructure”. The two discussed how to use agile infrastructure to resolve the bottlenecks and conflicts between development and operations. They created a group called the Agile Systems Administration Group to try to improve life in IT. In 2009 at the O’Reilly Velocity Conference a presentation given by John Allspaw, Head of Operations at Flickr and Paul Hammond, head of Engineering at Flickr titled “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, got the IT community buzzing, including Debois. Deploying multiple times a day back in 2008 was almost unheard of. Inspired by the presentation, Debois set up a meeting in Belgium where he lived and invited his network on Twitter. He named the conference DevOpsDays and used the hashtag #DevOps when promoting it on Twitter. Were it not for Twitter’s 140 character limit, we would likely have had a less succinct movement in the industry.

From this history, it is easy to see why many people think that DevOps is just about developers and operators working together. However, the DevOps net has since been cast much more broadly than during its founding days and touches all areas of the business. Many companies start their DevOps journey looking only at automating the infrastructure or the application build process, but high performing companies that have been on their DevOps journey for several years are redesigning their organizations and process both inside and outside of IT.

Typical Maturity Progression

Many companies that are enjoying success in their DevOps journey share these common beliefs:

• Changing the culture and mindset is a critical success factor
• Removing waste/bottlenecks from the SDLC helps drive business value
• Shifting from reactive to proactive operations improves reliability
• Start somewhere and then continuously learn and improve
• DevOps and Cloud requires a new operating model (Organization change)

These companies look very different 3 to 4 years into their journey as they continue to embrace change and continuous learning. Table 2-1 shows a typical order in which companies address bottlenecks to improve delivery and business outcomes. Usually as they make strides removing one bottleneck (for example inconsistent environments), they then progress to resolve their next biggest bottleneck (for example security).

Pattern	Bottleneck/Pain Point	Solution
1	Non repeatable, error prone build process	Continuous Integration (CI)
2	Slow and inconsistent environment provisioning	Continuous Delivery (CD)
3	Inefficient testing processes/handoffs	Shift testing left/test automation
4	Resistance from Security team, long and painful approval processes	Shift security left, DevSecOps
5	Painful handoff to operations teams, forced to use legacy tools/processes, poor MTTR	Shift ops left, new operating models (platform teams, SRE, etc)
6	Slow SLAs from Tier 1-3 support	Shift support left, new operating models
7	Slow and painful approval processes for GRC (governance, risk, and compliance)	Shift GRC left, Stand up cloud GRC body

Table 2-1. Bottlenecks and pain points

This is just a subset of the types of problems and the corresponding changes that are often implemented to remove the bottlenecks. There are also large initiatives for reskilling the workforce and rethinking the future of work. The way we incent workers must change to achieve the desired outcomes. Procurement processes must change as we shift from licensing and maintenance to pay-as-you-go models. Basically every part of the organization is impacted.

A New Operating Model

As you can see from the list, there are a lot of changes that fundamentally challenge how IT has operated for years.. This transformation is bigger than CI/CD pipelines or Terraform templates. The organizational change, culture change, thinking and acting differently, and modernizing how work gets done while leveraging new tools and technologies is indeed the heart and soul of DevOps.. Sure there are teams within large organizations that are having great success focusing mostly on the technology but to scale DevOps across an organization, a new operating model is required. A fundamental reengineering of IT is now happening in many large companies. There is great irony that technology and IT were often significant contributors to the waves of re-engineering we’ve seen in the enterprise over the last several decades, while IT themselves were largely running the same processes and structure despite major changes in the underpinning technology. Even fairly large advances in methods in IT, most notably agile, only changed processes in parts of silos, rather than holistically looking at the IT function.

Now that we have framed DevOps is the context of people, process, and technology across the entire SDLC, the next three chapters will go into detail for each.