DevOps and organisational models

The DevOps movement presents itself as a culture involving processes, tools, and organization. While the first two aspects seem to be covered by proven methodological and technical approaches (lean, agility, automation, craft, etc.), the organizational aspect lacks reliable frameworks.

Therefore, before embarking on a transition inspired by the DevOps culture, it becomes essential to identify the organizational model in place and thus target the most suitable pattern for our structure's operating mode in order to reduce resistance to change and achieve a smooth and pragmatic migration.

In the following, we will present some commonly encountered models, evaluate them, and attempt to assess their adaptability in a DevOps transformation approach.

Dedicated DevOps Team

Integration Team

This historical model involves a dedicated team - generally known as the integration team - acting as a liaison between developers and operations. Its role is to understand and master the offerings provided by operations in terms of infrastructure and tools, ensuring the smooth delivery of projects. They must stay up-to-date with new developments.

The integrator thus plays a release manager role, whether dedicated to a project or shared for a functional domain or a set of projects.

• Advantages:
  • Relieves developers and operations from implementing and monitoring deliveries.
• Disadvantages:
  • As functionality/projects for development and infrastructure increase, maintaining the integration team up-to-date becomes challenging.
  • This model encourages the compartmentalization of OPS and DEV teams, contributing to maintaining distinct activity silos.

Classification: DevOps Anti Pattern

Pilot DevOps Team

In this approach, a cross-functional DevOps team is established to address project needs regarding provisioning or delivery issues. The strategic objective is to provide DevOps value without disrupting the existing organization or making fundamental changes.

• Advantages:
  • Rapid establishment of DevOps transformation foundations.
  • Leadership by example and practice.
  • Change management carried out progressively and adapted to the pace and maturity of teams.
• Disadvantages:
  • There is a temptation to perpetuate this organization, leading to the integration team anti-pattern.

Classification: DevOps Compatible

Recommendation: This model is a good trigger to test the organization and provide frameworks for a larger-scale transformation process.

Operational Developers

This pattern involves an organization where developers take on part or all of the provisioning, configuration, and management tasks of technical environments, as well as other tasks typically handled by operations.

This model is also applicable when operations are fully integrated into the development team.

This model can be observed in both small structures (startups) and large IT players like Facebook or Netflix. The common focus is on one (or few) products/services.

• Advantages:
  • Production architecture and tooling adapt to project needs.
  • Good mastery level of the product and software production chain.
• Disadvantages:
  • Operational tasks are often deprioritized compared to development tasks, which are seen as business value-added, leading to deteriorating quality over time.
  • When this approach stems from a poor appreciation of the importance of SysOps expertise, the constraint of maintaining a high level of developer versatility may be underestimated.

Classification: Pattern or Anti Pattern depending on the context.

Recommendation: In a product-oriented approach, this pattern highlights the symbiosis between developers or operations facing the same issues. However, it is better to avoid this pattern if managing multiple products in team models.

Operationals 2.0

This occurs when a traditional OPS team wants to embrace the DevOps trend, hoping to benefit from automation improvements and TTM reduction.

This team - renamed DevOps for the occasion - remains in an organizational silo that does not respect the spirit of cross-functional collaboration and shared responsibilities inherent in the DevOps culture.

• Advantages:
  • Updating OPS methods or tools likely leads to improvements in provisioning, delivery processes, etc.
• Disadvantages:
  • No significant change.Silos are maintained, and the gains obtained are not at the expected level.
  • Adopting this model may generate negative feedback that could constrain or even block future transformation strategies.

Classification: DevOps Anti Pattern

Devops Champions

This model presents a community of motivated individuals who take on the task of evangelizing and promoting the DevOps approach and the accompanying technical and methodological tools.

In general, this can result from collective emulation (spontaneous community) or a strategic decision that identifies evangelists and positions them in the various relevant teams.

• Advantages:
  • Model stemming from a genuine awareness and strong motivation.
  • Transformation "smoothly" through example and practice.
• Disadvantages:
  • The process may be slower than other models and requires a strong investment from DevOps champions and strategic involvement from decision-makers to facilitate their tasks and ensure the approach's long-term sustainability.

Classification: DevOps Compatible

Ops As A Service

Some organizations choose to outsource their operational tasks, either through a service provider or by leveraging public cloud offerings (Amazon EC2, Azure, etc.).

A variant of this model involves relying on an internal OPS team, transversal to the structure, offering its services as infrastructure as a service.

In this case, all or part of the DEV teams must acquire mastery of IAAS offerings to be able to manage their delivery. Support and maintenance tasks are transparently handled by the IAAS offer provider.

• Advantages:
  • DEV teams are directly involved in tasks.
  • This model requires a good level of mastery from OPS teams in their infrastructure and processes, improving the quality and responsiveness of the service provided to development teams.

Classification: DevOps Compatible

Halfway DevOps (Dev + Middleware, Dev + DBA, DBA + Ops)

An organization may already have a process of bringing together teams operating towards the same functional objective without necessarily being part of a strategic transformation strategy.

It is therefore common to see alliances between application developers and support and optimization teams for middleware or DBA.

These teams may be wholly or partially identified in the organization as OPS teams, even though they are often called upon during the development cycle.

Classification: DevOps Compatible