In this article we discuss some of the misunderstandings surrounding DevOps and provide an introduction to a process that can bring the cultural shift that DevOps is all about.
In a post entitled “No, You Are Not a DevOps Engineer”, Mike Kavis, VP/Principal Architect for Cloud Technology Partners, has addressed some of the misconceptions surrounding DevOps. For example, he mentions how some teams are misusing the term DevOps:
Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.”
Some engineers advertise themselves as DevOps, but they are not, according to Kavis, because “DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one.” If DevOps is not a role, a qualification, a title, then what is it? Kavis’ definition 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.
He then details:
DevOps is the progression of the software development lifecycle (SDLC) from Waterfall to Agile to Lean. DevOps goes beyond Agile and focuses on removing waste from the SDLC. Often, the waste or bottlenecks are found in the forms of inconsistent environments, manual build and deployment processes, poor quality and testing practices, lack of communication and understanding between IT silos, frequent outages and failing SLAs, and whole suite of issues that require precious IT resources to spend significant time and money keeping the systems running. …
Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.
If DevOps is a cultural change meant to bring better communication and collaboration between various teams involved in creating a product, the next question that comes to mind is how do we get there, how do we bring this change into our company?
Damon Edwards, co-founder of DTO Solutions, keynoted on “How to initiate a DevOps Transformation” during DevOps Days Mountain View 2013, presenting a three-steps process he is recommending to introduce the DevOps culture into an organization:
1. Build the “Why?”
According to Edwards, it is important to start by having a clear understanding of why the members of an organization are there, what they are trying to accomplish, what is their purpose. To find out that reason, one could simply socialize with people in the organization and ask them why they are there. The main purpose of the organization is the only reason for implementing a DevOps culture, and there is no other.
Edwards considers that DevOps is just a means to reach an end, and not an end in itself: “DevOps is not your why, not your co-workers’ why, certainly not your business’ why.” He even suggests forgetting the DevOps term, noting the he’s using service delivery instead because “we are in the business of making a service.”
2. Building Organizational Alignment
The next step in Edwards’ process is to align the entire organization so everyone would work “towards a common goal under a shared set of assumptions and rules.” An organization is correctly aligned when giving the same goal to multiple people, they choose the same way to achieve the respective purpose; they have the same answers for the same problem. That would be the “ultimate dream of the organizational alignment.”
To achieve this alignment, one needs to develop a DevOps Vision within the organization. That is not obtained by teaching a process, because people will simply try to mechanically follow some steps. What is needed is to teach a way of thinking. According to Edwards, this can be achieved by following the next steps:
- Teach the basic concepts, such as “single piece flow, working in batches, limit work in progress, pull vs. push, continuous delivery”, the tools that can be used, etc., concepts that make up a common vocabulary to be shared by the organization.
- Getting everyone on the same page through
a. Value Stream Mapping – a Lean concept detailing the flow of information and artifacts going on inside an organization, leading to value creation.
b. Timeline Analysis – attempts to discover where time is spent, where are the bottlenecks.
c. Waste Analysis – determining all sorts of waste that are produced by an organization in order to eliminate them as much as possible - Developing metrics chains, which are meant to measure the activity across the value delivery chain and how one’s activity impacts others’.
- Identify projects/experiments against baseline. Identify which projects or activities deviate from the baseline and take corrective measures.
- Repeat steps 2-4. This constitutes a Continuous Improvement process.
In order to implement these ideas, Edwards proposes a 3-days program:
- Day 1 – Teach the principles, present a case study, patterns and anti-patterns
- Day 2 – Analyze the current status of the organization providing problem identification techniques and improvement metrics
- Day 3 – Discussing solutions and tool-chain automation principles, building a roadmap
3. Continuous Improvement Loops
These loops are meant to continually improve the process by Making Plans, Implementing Plans, Measuring Outcomes, and Deciding on How to Continue.
Edwards has recently presented these principles during his QCon London 2014 session called "Dev ‘Programming’ Ops For DevOps Success", session that will be later made available on InfoQ.
