What is DevOps?

In the past, I've had multiple conversations about what DevOps is. I've read about it and searched for a definitive answer. I can find many definitions for the term, which is part of the problem: the answers to “What is DevOps?” vary substantially.

The term “DevOps” comes from “Development Operations”. I find this vague and confusing at best. I’ve also noticed that people include different tangible parts of software production in “DevOps”. In addition, non-technical people in the IT & Software industry have a varying understanding of the intricacies of software production. Although, I don’t think there is a broad consensus about this, even among software developers. And if there is, it varies between teams and companies.

DevOps is a widely used term; therefore, it needs a more accurate definition. During the last few years, my understanding of the term and why it exists has taken some shape, and in this post, I'll shed some light on what DevOps is and how I perceive its meaning.

Defining DevOps

I identify as a software developer, although I don't make a big difference between being a software developer, a DevOps specialist or a QA engineer. In all these roles, the most crucial and ever-lasting goal is to produce quality software. In my mind, this means I should be able to identify and fix the problems – whether in the software, development processes, design, infrastructure, or operations. 

I think software quality consists of three aspects:

• Value: It has to solve a real problem the user has.

• Extendability: It has to be easily further developed.

• Security: It doesn't compromise the security of its users.

These three aspects are quite abstract and could be explored in their own posts. I may do that someday, but I'll leave it at this for now.

To be a good software developer, QA engineer, operator, security specialist or DevOps specialist, you need to have some understanding of all these areas. This doesn't mean that you need to be an expert in all areas but that you need to be able to look at problems from multiple angles. Even more importantly, people need to have some understanding of each other's work to be able to communicate!

The best solutions are found by looking at things from different angles. That's basically what DevOps stands for. Therefore, I think the task of a DevOps Specialist is to ensure problems are analysed from multiple perspectives.

I've encountered people using the term DevOps for multiple purposes. Here are a few of them:

• DevOps is automation and removal of human error

• DevOps pipelines for testing

• DevOps pipelines for deployments

• DevOps... you get the point.

• DevOps is just a synonym for QA automation

• DevOps is infrastructure building/development

• DevOps is focusing on software development ergonomy

All of these are parts of DevOps, but I've never seen the term used to encompass even half of those in real life.

DevOps is an all-encompassing and overreaching term

For technical people already working close to software development, some of the concepts within DevOps are more or less self-evident. This is not the case for non-technical people: what it takes to build quality software is not self-evident for people working in other domains. The importance of DevOps comes up when communicating about the team's needs and requirements, especially when the communication happens between technical and non-technical people involved in software production.

As DevOps became a "mainstream" term, the different interpretations of it clouded the meaning of the word. It is understandable as the term was never defined as anything else but as the intersection between “Development” and “Operations''. As people have different interpretations of “Development” and “Operations”, defining their intersection is even more challenging. I would argue that DevOps is more about communication and cooperation between the people implementing these software development functions – whatever the functions.

To summarise:

“DevOps” is an all-encompassing term used to describe the scope of software production and to bring attention to the importance of all functions of software production working in alignment.

When talking with people with a “DevOps mindset" or even working with DevOps specialists, these are often the people focusing on the whole scope of software development; cooperation between different functions implementing “software production”. These people usually also have some level of understanding of each of these functions and are capable of doing work across teams.

I argue that DevOps is partly a derivation of Lean. (Another abstract and often misunderstood term, with admittedly a little bit longer and better-documented history.) DevOps, in essence, is achieved by giving teams the freedom to communicate, organise, and cooperate to come up with the best solutions for a given problem. This naturally requires leadership and intent to achieve the goal; no group of people just magically start communicating and understanding each other when told they’re free to do so.

DevOps is best understood as goal-oriented cooperation and communication between people implementing the wholeness called software production. A DevOps Specialist understands the potential of integration and alignment of these teams working towards a common goal on both technical and non-technical fronts.

Valuable lessons learned in practice

I have a small-scale example of DevOps from a job before my current position at Vuono Group. At the time, I was working as a QA lead for a company building a web service. During that time, the QA team was isolated from the development team. Not to a big extent and not intentionally, but the segmentation between these teams existed.

This was mostly because these teams were separate with processes and organisation of their own. After a while, it became clear that the segmentation was counterproductive and built barriers to communication between software developers and QA engineers. Since these teams were separate, each organised their work in near isolation, causing misalignment and misunderstandings. 

After a while, the QA team was integrated into the development team. After only a few months, it was easy to state that the members of the prior QA team were more aligned with the developers and vice versa. For example, this meant that some things didn’t need to be explicitly communicated every time the members of these teams cooperated.

The fact that the team also worked towards a common goal and organised around it independently led to organic communication patterns within the team. This resulted in an overall lighter and more efficient environment to work in for all.

Finally

I don't think that there are silver bullets for anything. Call it DevOps or cooperation; it makes software production easier and more efficient. I think that within an industry working on technology, it is too easy to overlook the importance of communication and cooperation. All software development functions have something to learn from each other.

That's where the value of DevOps lies.