In the past I've talked with a lot of people about what DevOps is, read about it and searched for it but the answers seemed to vary quite a bit. The term “DevOps” comes from “Development Operations”. I find this is vague and confusing as the meaning of “Development Operations” is non-tangible, sometimes even for developers. Depending on the person I’m talking with it seems to differ which tangible parts of software production are included in the meaning of “DevOps”. How many non-technical people in the IT/Software industry actually understand what software production actually consists of? I don’t think there is any broad consensus about this even between software developers. I don't exactly know how the term got mainstream. Recently it seems the usage of the term has suffered some inflation. Despite this the term is still widely used and no alternatives have surfaced. I have a feeling that there has been a demand for this term resulting in its adoption.
I actually used to hate the term 'DevOps' and I still sort of feel uneasy with it, partly because I'm not exactly sure how people perceive it and what they mean by it: “If I’m working as a ‘DevOps Specialist’ - what expectations am I going to face from my client?” During the last few years my understanding of the term and why it exists has taken some shape and in this post I'll try to shed some light into what DevOps is and how I perceive its meaning.
In this post I refer to “team misalignment” multiple times. By this I mean multiple things; small factors causing the cooperation between the teams in question to be inefficient or lacking completely. The magnitude of this misalignment differs and it can be minimized with proper leadership. Often the misalignment of teams consists of:
Different incentives and motivations
Different measures used for bonus compensation
Different values
Differences in processes and ways of working
Incompatible schedules and cycles of working
Technical lack of understanding
Teams do not understand each others work environments and technical requirements of success
Why DevOps?
I count myself as a software developer. A pretty opinionated one at that. I don't make a big difference between being a software developer or a DevOps specialist as I think that as a software developer my single most important goal and ever-lasting task is to create quality software that actually solves a real problem(s) of its users. In my mind this means that I also should be able to both identify and fix the problems - whether they are 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 user has
- Extendability
- It has to be easily further developed
- Security
- It doesn't compromise the security of its user
Each of the previous aspects is very abstract and could be written about in a post of its own. Perhaps I will someday, but for now, I'll leave it as is. I believe that to be a good software developer, QA engineer, operator, security specialist or DevOps specialist - you need to be able to do any of those jobs to some extent at least. The important thing is for people to have some understanding about each other's work. I believe in the holistic aspect of looking at things from different angles and transparent communication. That's basically what DevOps stands for.
Often DevOps is thought of as automation; continuous deployment and/or delivery, automated software testing, quality assurance and so on. I want to draw distinctions between DevOps, automation or other technical solutions; DevOps is not a technical solution. Some technical solutions such as the increase of automation are often results of DevOps mentality. DevOps is what you want and automation might be a part of what it results into. Whether the result of DevOps is automation or something else, what I’m convinced about is that DevOps will increase the long term throughput of software production if implemented correctly. If we’re talking about DevOps as I perceive it that is. (;
DevOps is all-encompassing term
I think DevOps is nothing more or less but a term communicating what software production consists of; often divided into programming, quality assurance and operations. Depending on the context these functions differ. DevOps puts an emphasis on direct cooperation and communication between teams implementing these functions. DevOps as a term wasn’t initially thought to include quality assurance - or any other functions but development and operations. Now I think that DevOps includes every aspect of software development varying between contexts. At some point another term came up: DevSecOps, where “Sec” stands for “security”. For me it’s all the same and I think DevOps includes security implicitly. I understand security is a technical field of its own, just like operations and quality assurance are. The point is that whatever functions are seen as part of the software production within the organization, they should be included in the meaning of DevOps.
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 and we should work to remember that. As it is not self-evident for me what design and construction of a bridge consists of, it's not self-evident for people working in other domains what it takes to build quality software. Software production consists of ~10% programming and ~90% of other actions. Giving those "other actions” a name makes communication about them easier. A name given to an all-encompassing view on software production and transparency between all parties involved. The importance of this term comes up when communicating about the needs and requirements of the team, especially when the communication happens between technical personnel and non-technical personnel involved in software production.
As DevOps has become a "mainstream" term - the different interpretations of it have muddied the meaning of the word and this post is hopefully a small step towards easing up the problem. This was to be expected as the term was never defined as anything else but as the intersection between “Development” and “Operations”. People have different interpretations of both “Development” and “Operations” so trying to define their intersection is even harder. I would argue that debating about what technical parts software development consists of as a whole is wasted time. The answer to this varies by the context; the organization, the product and people. This is why I argue that DevOps is more about communication and cooperation between the people implementing these functions of software production - whatever they are in your context.
To summarize: “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 development working in alignment. This includes the actual programming, but also other work such as quality assurance, security assurance, data-analytics and operations. Often these functions are handled by separate teams. The transparency and cooperation between these teams is essential for success. If these functions were handled by a single group of people, this would rarely be a problem, but this is often not the case. In cases where there are separate groups of people implementing different functions of software production, DevOps is often used to indicate the direct communication and cooperation between these groups. This is what leads to the results of innovation, quality and automation. When talking about people with “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 think 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 of communicating, organizing and cooperating with each other to come up with the best solutions for a given problem. This naturally requires leadership and intent to achieve the goal; there are no groups of people who 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. DevOps Specialist is someone who understands the potential of integration and alignment of these teams working towards that goal on both technical and non-technical fronts.
Lessons learned
I have a small-scale example of DevOps from a job before my current position at Valuemotive. At the time I was working as a QA lead for a company building a web application. 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 organization of their own. During some period of time it became clear that the segmentation was counterproductive and built barriers of communication between software developers and QA engineers. This didn’t mean that the communication didn’t happen, but the fact that these teams were separated from each other and each team organized their work apart from one another caused misalignment. This also unnecessarily increased the need for communication between these teams.
After a while the QA team was integrated as part of the development team. After a few months it was easy to state that the communication was already working better; since there was only one team, everyone was aware of the team schedules, goals and processes. This meant that these 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 organized around it independently led to organic communication patterns within the team. This resulted in an overall lighter and more efficient environment to work in. This was something developers and QA engineers agreed with.
I think it is important to mention that within the context of bigger teams this kind of integration of teams is not so straightforward. When there are a lot of people working on a project I think it makes more sense to divide the software into technical segments and assign each segment to a multidisciplinary team handling each aspect of development. When in a big project, the task of technical segmentation is an overhead compared to segmentation of the team by discipline. I think this is the reason organizations often decide to implement disciplinary segmentation rather than technical segmentation. I think this is a mistake that is paid for every month in efficiency and quality.
During my short career I’ve seen the implications of this mistake multiple times. I think it’s a natural mistake to make, which is why it is so common. The implication is always the same, independent of the teams we’re talking about: faults in cooperation. For an example: QA team works towards a different goal compared to a development team resulting in an unnecessarily slow feedback loop for the development team. Another example: Development team has conflicts of interest with the operations team leading to unnecessarily release cycle. On a lower level the problems often surface in a way that makes it seem a team (its members) do not understand members of another team. Perhaps sometimes the members of another team seem to act against the interests of your team.
Often the disciplinary segmentation is simply done because other organizations do it also. Or the decision maker has done it before and no one has been able to articulate the implications or the importance of this decision. Whatever the reason is, I hope I’ve managed to articulate this in a manner that is easy to understand. Structuralization and organization of work is mandatory but it should be recognized that there are multiple ways to do it. Also the implications of these decisions should always be mirrored against the communication within the organization. Communication is what drives the efficiency of cooperation either up or down.
Comments