DevOps is not a culture, a set of tools, processes and procedures, nor an academic theory about operations and development. By trying to define DevOps in these terms, I believe we will miss the big picture of DevOps, because in fact, DevOps is all of these and more.
Your DevOps definition may depend on your level in the organization. This is because different levels have different views on the overall goals of the company. The top management has a field of view of 50,000 feet, the team leader has a field of view of 20,000 feet, and the engineers are in different positions among the weeds. These are the levels of abstraction that these people operate. Therefore,
DevOps means different things to each of them.
Abstraction level
I recently read a great book written by Niklas Modig called "This Is Lean". He details how the exhaustive list of definitions of "lean" can make what "lean" is confusing. Modig decomposes these definitions into what he calls "levels of abstraction." Here, I will do the same with DevOps, and I will use Modig's fruit example to explain the concept.
A piece of fruit
Suppose you are in a coffee shop and ask the barista for a piece of fruit. What do you expect? Sliced or whole? Specific color? A slice of pear is very different from a whole pear, as are red and green apples. This is our lowest level of abstraction, because we are dealing with details that affect individuals, teams, organizations, or companies, but nothing is broader than this.
As far as DevOps is concerned, it will be similar to: "Are we scripting or declarative pipelines in Jenkins?" Processes and procedures, individual and team decisions only affect their teams and even organizations. For example, I can't expect pipelines written for Team A to work if they are picked up and placed in Team B's repository. These teams work very differently, so the pipelines I wrote are very different, and each is different. I may learn knowledge and ideas from one aspect, but different in another.
A kind of fruit
There are different results at the middle level of abstraction. When you ask the barista a piece of fruit, what kind of fruit will you get? Pear or apple, but the color and segmentation of the fruit is not important.
We can also do this in DevOps: "Should we use Jenkins or GitLab CI?" or "Shall we use GitHub or Bitbucket?" or "Should we use cloud solutions or in-house hosting?" These decisions affect the entire company The organization may even affect the entire company (if they decide the business of the overall enterprise tool). Although the pipeline I wrote for Team A cannot be used out of the box for Team B, I am still writing a Jenkins declarative pipeline because at least from now on, my organization makes Jenkins our preferred CI/CD tool.
A basket of fruit
The last level of abstraction is a basket of fruits, or the concept of "fruit is fruit". In our example, when you ask the barista a piece of fruit, she reaches for a black bag and takes out any fruit that her hand touches first. There is no difference between a pear and an apple. They are just fruits.
In DevOps, the definition of "this is a culture" fits perfectly. Organizations may decide to achieve more automation in software delivery, or to break down possible barriers between developers and operations teams. This is a set of concepts that look great on paper, but no one defines the implementation details.
Apply for the Golden Circle
We still need to define for DevOps, I think there is no better way than applying Simon Sinek's Golden Circle model to our fruit layer. In Sinek's model, organizations do things in a certain way ("what') ('how') for a certain purpose ('why'). Sinek proposed that "why" is the most important decisive factor for the company. The golden circle can identify differentiating factors for current and potential customers. Similarly, to define DevOps, we first need to understand the "why" is meaningful.
Why is this so?
Sinek wrote that articulating the "why" is so powerful because it can help other people establish emotional connections with the company, and increase loyalty and inspiration. In DevOps, this is the key role played by cultural definition, but we need more. If our answer to the "why" is that we implemented DevOps to deliver software to customers faster, then we cannot establish an emotional connection.
On the contrary, what if the “why” is “to contact the needs of customers in the entire vertical of the company, so that the most important tasks to the customers are given priority”? This will establish a connection that resonates with customers. They can believe that we value their success, because it means our success. For employees, they now see how their innovation and creativity contribute to our most valued value, customers, and not just our bottom line.
How do we deliver the cause?
When we define "reasons" that do not explain "why" and "what", we are very precise, because the purpose of doing so is to motivate our employees and colleagues to determine our delivery methods and delivery methods. In DevOps, this fits perfectly with the concept of culture, but the "how" defines culture. This can be clearly seen in Sinek's work, which connects the question of "why" to the value and strength of the company. I believe these are the driving factors that characterize the company’s culture.
How do we connect customer needs with the company's vertical industry?
Before development and operation, different organizations/teams/groups in the company generally have different jobs, and for most people, this is all the jobs they know. They have standard operating procedures (SOPs), which define operation methods and operating methods, but it is difficult for individuals to know how they contribute to the whole. DevOps breaks the situation of separate governance, instead of a team composed of vertical industries like ops and dev, but a team composed of horizontal industries. Perhaps these teams are dedicated to specific customers or specific software features. The key is that the team is made up of all the expertise needed to meet the needs of the customer, not just the vouchers in the backlog.
How do we deliver customer needs at the right time?
In today's market, having the largest feature set, the best user experience, and the best customer service is not enough. These are simple value-added. This means that they can add value, but they will not prompt customers to choose us over competitors. They no longer define our industry. Customers can determine the value through the time and applicability of our release. How we meet their needs is to focus on the customer, not the next project that others think will increase profits. The way we deliver at the right time is a combination of the former and automation, which can simplify our delivery and make it repeatable, stable, safe and faster.
At the right time, what do we use to meet demand?
If done correctly, the leadership will define the "why" and "how", but leave the "what" to the organization and the team. "What" consists of tools and defined processes that make sense in a given situation, but may not make sense to the entire organization or even different companies. For example, my team wrote the declarative Jenkins pipeline because we like it with a low barrier to entry, rather than having to learn Groovy to manage the pipeline. Other organizations in the company rely only on scripted pipelines because their teams are more suitable for developing for the Java Virtual Machine (JVM). In any case, the "what" is the detail team used to push the company to meet the "why" requirements.
What is DevOps?
The answer is, it depends.
It depends on your role, the level of abstraction you want to apply, and most importantly, what the company, organization or team you want to define DevOps for. I think that C-level leadership should understand all levels of abstraction and all levels of the golden circle, at least by the way. But be careful, only define the "why" and may play a role in the "how". Inspire other members of the company to come up with detailed information about the "how" and "what". For individual contributors, when developing the "content" that the team/organization/company will use to differentiate themselves from the competition, be bold, creative, break through barriers and think outside the box.
I believe that DevOps is the driving force for breaking down barriers, breaking norms, providing quality, the symbiotic relationship between the company and its customers, continuous improvement and learning—just a professional lifestyle. I hope you have found value in this article and can inspire you to continue your DevOps journey. It is long and never ending, like many precious journeys in life. I hope to see you on the road one day.
