“What is DevOps?”
Taken at face value, the question may seem a bit rhetorical, but allow me to explain.
There is no single definition of “DevOps”. If you ask five people “What is DevOps?”, you’ll likely get five different answers.
Need some examples?
Here’s how Gartner has defined DevOps: “A change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”
Take a look at “The DevOps Handbook” by Gene Kim and others. It states that DevOps is “…the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others…the result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and InfoSec.”
One of my favorite definitions is from Rob England (aka “The IT Skeptic”). Rob describes DevOps as follows : “Agile is the approach of working with complex systems anywhere. Lean is the approach of optimizing the flow of work anywhere. DevOps is the application of Agile and Lean to the acceleration of value work through IT.”
Perhaps the best definition of DevOps is credited to Jez Humble, one of the co-authors of “The DevOps Handbook” who coined the term “CALMS”. CALMS is a conceptual framework for integrating development and operational (DevOps) teams within an organization. CALMS is an acronym for:
- Culture – A culture of shared responsibility
- Automation – Automate as many tasks as possible
- Lean – Visualization of work-in-progress; limit batch sizes; eliminate waste; continuous improvement, focus on customer value
- Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
- Sharing – There are user-friendly channels for facilitating on-going communications
In most DevOps thinking and reading, CALMS seems to be a common theme. But I also encounter a lot of DevOps “anti-thinking” as well.
What DevOps is not
Here are a few examples of DevOps “anti-thinking” that I’ve encountered. DevOps is not:
- A standard – There is no documented “DevOps” standard.
- A tool – There are literally hundreds of tools (I’m not sure if this is a good or bad thing) that claim to be “DevOps” tools. The point is buying a tool does not make your organization a “DevOps” organization.
- A best practice – There is no defined “body of knowledge” or designated reference for DevOps. In fact, there are literally hundreds of books about DevOps, and some (highly visible) examples of organizations that have successfully adopted DevOps thinking. But there is no designated DevOps “best practice”.
- Just automation – While automation is perhaps one of the most visible aspects of DevOps, automation alone is not “DevOps”.
- A silver bullet for IT issues – Just saying that you’re “doing” DevOps is not the same as addressing communication issues, collaboration challenges, wasteful processes, poor measurement practices, eliminating technical debt, and other organizational problems.
What is DevOps?
So, what is DevOps? At its core, DevOps is a mindset; a way of working together. DevOps is:
- About building trust and teamwork, sharing knowledge, taking accountability – Teams build trust when members can rely upon one another. Trust is built when team members openly and willingly share their knowledge and contribute to the success of the team. When mistakes happen, the member making the mistake acknowledges the error; but more than that, there is no blame; the team works together to resolve the error.
- About tearing down the walls that exist between working groups within IT – DevOps can only be successful when all parts of the IT team are part of the success.
- About creating a culture of experimentation and learning – Too many organizations work in fear of failure. Much about DevOps is about empowering and learning.
- About improving the productivity of the overall organization – Sometimes that means searching out and eliminating waste or streamlining the process. If it’s taking too long to get code to trunk and then tested, what can be done to improve that? If standing up a new development environment requires manual intervention, what could be done to standardize that work so that manual intervention is no longer required?
Avoiding DevOps “Ditches”
Knowing what DevOps is and is not will help you get on the road to success. Here are five ditches to avoid to achieve success with DevOps.
- Purchasing and implementing tools before anything else – DevOps adoptions taking this approach usually fall into the old “hammer and nail” syndrome (“when all you have is a hammer, every problem looks like a nail”). Well, just because you own a hammer and can swing it doesn’t make you a carpenter. One of the most common mistakes with DevOps adoption is too much focus on tool implementation and automation of (often poorly or even undefined) processes. When all you have done is implement a tool without designing processes or developing teams, you’ve not “DevOps”- you’re just using a tool – and likely not getting the full benefit of that tool.
- Getting hung up on semantics – Developers and operations both have developed their own specific languages for what each group does – and this often causes confusion. Take the time to define and agree on a shared terminology.
- Developers running over everyone else in the organization under the flag of “we’re doing DevOps” – Once, while at a client site, I heard a “DevOps engineer” (seriously) tell a sysadmin that “I’m about to automate you out of a job.” Not a very collaborative, teamwork attitude, huh? DevOps is about building teams whose members trust and rely on each other- not trying to dominate or control.
- Arbitrarily throwing out existing process and procedures – Although a process may not be performing as effectively and efficiently as desired, don’t overlook the fact that there was a good reason why that process was defined and implemented in the first place. In my experience, process design and implementations have been treated as “one time” activities and rarely revisited to identify improvements or needed changes. Before getting rid of an existing process, first understand the reason for the process, and if that reason still exists today. Then look for ways to improve that existing process, rather than just throwing it away.
- Ignoring the need for organizational change – DevOps adoption represents a significant change in the way IT does its work. Without good communication, appropriate training, and a shift to a “thinking / experimentation / learning” mindset, DevOps adoption will fail.
Keep CALMS and DevOps on
Knowing what DevOps is and is not is key for success in adopting DevOps. Following the CALMS model ensures that you’re addressing the complete extent of DevOps adoption, and not just being fixated on a single aspect.
Need help answering the question “What is DevOps?” Want to build a fundamental understanding of DevOps? Tedder Consulting offers the DASA-accredited DevOps Fundamentals class. Visit our training page to register for an upcoming class!
For more pragmatic advice and service management insight, click here to subscribe to my newsletter!
Picture Credit: Pixabay
 Kim, Gene, et al. “The DevOps Handbook”. IT Revolution Press, LLC. 2016. Portland, OR
 http://www.itskeptic.org/content/laymans-definition-devops, retrieved 8/11/2018.