What in the world is DevOps? I think this is a question everyone new to DevOps asks early in their journey.
If you ask 10 people this question, you will most likely get 10 different answers. This speaks positively to the pervasive, open nature of DevOps but also to the lack of a clear definition or implementation. This is not necessarily a bad thing, but it can make it difficult for DevOps journeymen and journeywomen.
Some people will answer your question, "it's a culture because it breaks down barriers" or "it's Jenkins pipelines because they help you deliver software faster." These are not horrible answers but, and I mean this in the nicest way possible, they are far from complete answers. For that reason, they are simply wrong.
DevOps is not a culture, a set of tools, processes, and procedures, or academic theories about operations and development. By trying to define DevOps in those terms, I believe we miss the larger picture of DevOps because, in reality, DevOps is all of those things and more.
Your DevOps definition probably depends on your level in the organization. This is because different levels have different perspectives on a company's overall goals. C-suite leaders have a 50,000-foot view, team leaders have a 20,000-foot view, and engineers are at different levels in the weeds. These are the levels of abstraction where these individuals operate; therefore DevOps means different things to each of them.
Levels of abstraction
I recently read a great book called This is Lean by Niklas Modig. He went into detail about how the exhaustive list of definitions for "lean" caused a confusing picture of what "lean" is. Modig broke these definitions into what he referred to as "levels of abstraction." Here, I'll do the same thing with DevOps, and I'll use Modig's example of fruit to explain this concept.
A piece of fruit
Say you are at a café and you ask the barista for a piece of fruit. What do you expect to get? A slice or a whole? A specific color? A slice of pear and a whole pear are very different, as are red and green apples. This is our lowest level of abstraction because we are dealing with specifics that affect an individual, a team, an organization, or a company, but nothing broader than that.
In terms of DevOps, this will be something like: "Do we write scripted or declarative pipelines in Jenkins?" It is the processes and procedures, the decisions of the individuals and teams that affect only their team and maybe their organization. For example, I can't expect that the pipelines I write for team A will work if they are just picked up and plopped in a repository for team B. The things those teams work on are very different, so the pipeline I write is very different for each. I might gain knowledge and ideas from one, but I apply it differently in the other.
A type of fruit
In the middle level of abstraction are different fruits. When you ask the barista for a piece of fruit, what kind of fruit will you get? A pear or maybe an apple, but the color and segmentation of the fruit are not important.
We can do this in DevOps too: "Do we use Jenkins or GitLab CI?" or "Do we use GitHub or Bitbucket?" or "Do we use cloud solutions or host internally?" These are decisions that affect entire organizations within a company, and maybe even the entire company (if they are in the business of dictating holistic enterprise tooling). While the pipeline I write for team A will not work out of the box for team B, I am still writing a Jenkins declarative pipeline because my organization has made Jenkins our go-to CI/CD tool, at least for now.
A basket of fruit
The last level of abstraction is the basket of fruit, or the idea that "fruit is fruit." In our example, when you ask the barista for a piece of fruit, she reaches into a black bag and pulls out whatever fruit her hand touches first. There is no difference between a pear and an apple; they are just fruit.
With DevOps, this is where that "it's a culture" definition fits perfectly. An organization might decide it wants more automation in software delivery or to break down the wall that probably exists between the developer and operations teams. It's a set of concepts that look great on paper, but no one defines implementation specifics.
Apply the Golden Circle
We still need a definition for DevOps, and I can think of no better way than to apply Simon Sinek's Golden Circle model to our layers of fruit. In Sinek's model, organizations do something (the "what") in some way (the "how") for some purpose (the "why"). Sinek proposes that the "why" is the most import and defining factor for companies. The Golden Circle can pinpoint a differentiating factor for current and potential customers. Similarly, to define DevOps, we need to understand "why" it makes sense in the first place.
Why indeed?
Sinek wrote that articulating the "why" is so powerful because it helps others connect emotionally with the company and drives loyalty and inspiration. In DevOps, this is where the culture definition plays a key role, but we need more. If our answer to "why" is that we implement DevOps to deliver software to our customers faster, we have failed to make an emotional connection.
Instead, what if the "why" is "to connect our customers' needs across all the company verticals to prioritize the work that makes the most value for our customers when it matters the most to our customers"? This creates a connection that resonates with our customers. They can trust that we value their success because it means our success. For employees, they now see how their innovation and creativity contribute value to what we value most, the customers, and not just our bottom line.
How do we deliver on the why?
We are very precise when we define the "why" that we do not dictate the "how" and the "what" because the point is to inspire our employees and coworkers to determine how we deliver and with what. In DevOps, that fits the idea of culture perfectly, but the "how" defines that culture. This can be seen clearly in Sinek's writings, where he connects the question of "why" to a company's value and strengths. I believe these are driving factors in characterizing a company's culture.
How do we connect customer needs with company verticals?
Before DevOps, it was pervasive for different organizations/teams/groups within a company to have different jobs and, for the majority, that job was all they knew. They had standard operating procedures (SOPs) that defined how and on what they operated, but it was hard for individuals to know how they contributed to the whole. DevOps breaks down the silos and, instead of teams consisting of verticals like ops and dev, teams consist of horizontals. Maybe those teams are keyed to specific customers or specific software features. The point is the team consists of all the expertise needed to operate on customer needs instead of just tickets in a backlog.
How do we deliver on customer needs at the right time?
In today's market, it's simply not enough to have the biggest set of features, the best user experience, and the most amazing customer service. These are all simply value-adds. Meaning that they add value, but they do not drive a customer to choose us over a competitor. They no longer define our industry. Defining value is perceived by customers through the timing and applicability of our releases. How we deliver on their needs is by putting our focus on the customer instead of the next project someone believes will increase profitability. How we deliver at the right time is a combination of the former coupled with automation that can simplify our deliveries, making them repeatable, stable, secure, and faster.
What do we use to deliver on the need at the right time?
If it is done correctly, leadership has defined the "why" and the "how" but left the "what" to the organizations and teams. The "what" consists of tools and defined processes that make sense in a given situation but maybe not to the whole organization or even to different companies. For example, my team writes declarative Jenkins pipelines because we like the lower barrier to entry it provides over having to learn Groovy just to manage a pipeline. Other organizations in the company rely solely on scripted pipelines because their teams are more tuned to developing for the Java virtual machine (JVM). Regardless, the "what" are the specifics team use to drive the company to meeting the "why."
What is DevOps?
The answer is, it depends.
It depends on your role, what level of abstraction you are applying, and most importantly, what company, organization, or team you are defining DevOps for. I would argue that C-level leadership should be aware of all the levels of abstraction and the layers of the Golden Circle, at least in passing. But be careful to define only the "why" and maybe play a role in the "how." Inspire the rest of the company to come up with the details of the "how" and the "what." For individual contributors, be bold, be creative, break barriers, and think outside the box when you are developing the "what" your team/organization/company will use to set itself apart from its competition.
I believe DevOps is the breaking down of barriers, the crushing of norms, the delivering of quality, the symbiotic connection of company and customers, the drive to constantly improve and learn—simply a way of professionally living. I hope you have found value in this article and it inspires you to continue the journey of DevOps. It is long and never-ending, like so many valuable journeys in life. I hope to see you on the path some day.
2 Comments