Written by Leonardo Leite, Nelson Lago, Claudia Melo, Fabio Kon, and Paulo Meirelles
on 

The implications of the different ways of organizing development and infrastructure staffs

🇬🇧 🇧🇷

The DevOps movement came up as a cultural shift to break down the silos in large organizations, better integrating development and operations teams through collaboration. However, this collaboration can happen in different ways from an organizational perspective: developers and infrastructure specialists can be part of different departments or can be together in a single team. With advancements in PaaS offers, it is possible even to envision developers themselves taking operations responsibilities.

Our research at IME-USP (University of São Paulo) investigates how software-producing companies organize their development and infrastructure teams. We are taking this endeavor by interviewing software professionals to understand how things are really happening in the real world. With our research, we hope to provide a theory to support organizations in designing their organizational structures toward continuous delivery and handling the consequences of a given structure choice.

Based on the careful analysis of the conducted interviews, we elaborated a theory describing the organizational structures used by industry in the real world regarding how the work of developers and infrastructure engineers can be coordinated in the pursuit of continuous delivery. We describe such structures (segregated departments, collaborating departments, single department, and API-mediated departments) in detail in our digest of organizational structures. Here in this post, we summarize each structure with a figure and its caption.

To better understand such structures, we sought to unfold why different organizations adopt different structures. Moreover, considering the existence of advantages and drawbacks for each structure, we wanted to know about the strategies adopted by companies to overcome the drawbacks of each structure. Thus, through a research process, for each organizational structure, we investigated their conditions, causes, avoidance reasons, consequences, and contingencies, as defined below:

So now we list the conditions, causes, avoidance reasons, consequences, and contingencies associated with each structure. We have just submitted such results to a peer-review process. The complete submitted article is available here. In front of each listed implication, there is a code (e.g., SC01) to refer to in discussions. In our research, we call these implications “strong codes”, so the “SC” letters.

Segregated dev & infra departments

Figure shows an operator and a developer, each one inside a different circle. They have their backs to each other. Communication flows through letters, more from developer to operator than from operator to developer.

Figure 1 - With segregated departments, operators and developers are each one in their own bubbles. They do not interact directly too much, and communication flows slowly by bureaucratic means (ticket systems).

Consequences

Collaborating dev & infra departments

Figure shows an operator and a developer, each one inside a different circle. They are looking to each other and are holding hands (with some difficulty).

Figure 2 - With collaborating departments, operators and developers in different departments seek to work together, even if not easy, by direct contact and close collaboration.

Conditions

Causes

Consequences

Contingencies

Single dev/infra department

Figure shows an operator and a developer, they are inside the same circle.

Figure 4 - A single department takes care of both development and infrastructure.

Conditions

Causes

Avoidance reasons

Consequences

Contingencies

API-mediated dev & infra departments

Figure shows an operator and a developer, each one inside a different circle. The operator provides an interface that is consumed by the developer (UML notation).

Figure 3 - The platform team provides automated services to be used, with little effort, by developers (the platform API mediates the interaction between developers and the platform team). The platform team and developers are open to hear and support each other.

Conditions

Causes

Consequences

Contingencies