As the market shifts, companies grow more demand for smaller release cycles, improved quality and seamless collaboration throughout the product development lifecycle. In response to this need, DevOps has emerged as the preferred approach as it brings development and operations teams together, allowing for effective continuous delivery.
According to Global Market Insights, DevOps adoption rates are anticipated to grow at a Compound annual growth rate of 17.7% between 2021 and 2026. Atlassian’s 2020 DevOps Trends survey also found that 61% say implementing DevOps helped them produce higher-quality deliverables in 2020
Then how should organizations structure their teams to maximize the value of DevOps? Is it a one-size-fits-all approach, or can it be highly adaptable to the unique needs of each organization? Let’s explore the answer going into the article
Key characteristics of a highly effective DevOps Team
A well-functioning DevOps team typically exhibits several key characteristics:
Continuous improvement: a significant portion of DevOps involves continuously and iteratively improving existing work or replacing components that no longer serve their original purpose effectively.
– Communication and cooperation: while automation is crucial, a truly exceptional DevOps team goes beyond that by fostering effective collaboration and communication among team members.
– Rapid feedback and high empathy: recognize your teammates’ challenges your teammates may face and approach them with mindfulness and respect. Moreover, be prepared to provide and receive feedback promptly for an optimal result and a positive work environment
– Continuous improvement: a significant portion of DevOps involves continuously and iteratively improving existing work or replacing components that no longer serve their original purpose effectively.
Factors to consider when selecting DevOps team structure
Determining the most suitable DevOps team structure or topology for an organization depends on several factors:
– According to Conway’s Law, the smaller the product set, the fewer natural silos there are.
– The strength, extent, efficacy of technical leadership and whether Dev and Ops share a common goal
– The ability and willingness of an organization to transform its IT operations department from tasks such as “racking hardware” and “configuring servers” to align with the value stream closely and to consider operational features seriously by software teams
– The firm’s proficiency in taking the lead on operational concerns
9 Common DevOps team structures
There is no universally applicable formula to determine the ideal team structure for fostering DevOps practices. However, it is valuable to categorize several team models or topologies as some may suit specific organizations better than others.
In the book ”Team Topologies”, Matthew Skelton and Manuel Pais have identified 9 DevOps organizational models that enterprises can adopt as they get going.
By examining the strengths and weaknesses of these team structures, we can determine the most suitable team arrangement that aligns with DevOps principles within your own organizations, while considering the implications of Conway’s Law.
Team Structure 1: Devs and Ops collaboration
The ultimate aspiration in DevOps is achieving seamless collaboration between Development (Dev) and Operations (Ops) teams, where each team specializes in their respective areas while sharing knowledge and responsibilities as needed. Typically, there are multiple separate Dev teams working on different or partially independent product stacks.
Establishing this collaboration model requires significant organizational changes and a high level of competency within the technical management team. Dev and Ops must have a clearly defined shared goal that is effectively demonstrated (such as “Delivering Reliable, Frequent Changes” or a similar objective).
Ops professionals need to feel comfortable pairing with Devs and familiarize themselves with test-driven coding and Git practices. Conversely, Devs must prioritize operational features and actively seek input from Ops personnel for logging implementations and other related tasks. All of these requirements necessitate a cultural shift from the practices of the recent past.
Read more: Comprehensive Guide to Software Testing in DevOps Environments
Team structure 2: Fully shared Ops responsibilities
In a Type 2 team topology, Operations personnel are fully integrated into product development teams, blurring the lines between Dev and Ops. This integration fosters a strong shared purpose among all team members. While this can be seen as a form of Type 1 (Dev and Ops Collaboration), it possesses some distinctive characteristics.
Organizations like Netflix and Facebook, which primarily focus on a single web-based product, have successfully achieved this Type 2 topology. However, it may not be widely applicable beyond a narrow product scope. The budgetary constraints and context-switching inherent in organizations with multiple product streams often lead to a greater separation between Dev and Ops, returning to a Type 1 model. This topology is also referred to as “NoOps,” as it lacks a distinct or visible Operations team. It’s worth noting that the Netflix NoOps model could also fall into Type 3 (Ops as Infrastructure-as-a-Service, IaaS), depending on specific implementations and practices.
Team Structure 3: Ops as Infrastructure-as-a-Service
In organizations where the IT Operations department cannot or is unwilling to undergo rapid transformation, and for those that rely on public cloud platforms like Amazon EC2, Rackspace, Azure, and others, it is beneficial to view Operations as a team responsible for providing elastic infrastructure for deploying and running applications. In this context, the internal Operations team essentially serves as an equivalent to Amazon EC2 or Infrastructure-as-a-Service (IaaS).
A dedicated team within the Development (Dev) department, which may function as a virtual team, is the operational expertise focal point. This team possesses knowledge in areas such as operational features, metrics, monitoring, and server provisioning. They also serve as the primary interface for communication and collaboration with the Infrastructure-as-a-Service (IaaS) team. While this team is still fundamentally a Dev team, they still adhere to standard practices such as Test-Driven Development (TDD), Continuous Integration (CI), iterative development, and providing coaching as part of their role.
The IaaS topology sacrifices direct collaboration with Operations (Ops) personnel in exchange for easier implementation, potentially allowing organizations to derive value more quickly than pursuing a Type 1 Dev and Ops collaboration model. This approach provides an opportunity for rapid implementation, with the possibility of considering Type 1 collaboration at a later stage.
Team Structure 4: DevOps as an external service
Some companies, especially smaller ones, may lack the financial resources, expertise, or workforce to independently handle the operational aspects of the software they develop. In such cases, the Dev team may seek assistance from service providers like KMS Solutions. These service providers can assist in constructing test environments, automating infrastructure and monitoring, as well as providing guidance on the operational features to incorporate throughout the software development cycles.
This team structure can be a valuable and pragmatic approach for small teams to gain knowledge and experience in automation, monitoring, and configuration management. Afterwards, they might gradually transition towards a Type 3 model (Ops as IaaS) or even a Type 1 model (Dev and Ops Collaboration) as they expand their workforce and bring in more personnel with a focus on operational responsibilities.
Team Structure 5: DevOps team with an expiry date
The primary objective of a temporary team is to foster closer collaboration between Development (Dev) and Operations (Ops), preferably towards a Type 1 (Dev and Ops Collaboration) or Type 2 (Fully Shared Ops Responsibilities) model and eventually render itself obsolete.
Members of this team act as intermediaries, bridging the gap between Dev and Ops by introducing innovative practices such as stand-ups and Kanban for Ops teams. They also address operational considerations for Dev teams, including load-balancers, management NICs, and SSL offloading.
If sufficient individuals begin to recognize the benefits of unifying Dev and Ops functions, the temporary team stands a genuine opportunity to accomplish its objective. However, it is crucial to avoid burdening the temporary team with long-term responsibilities related to deployments and production diagnostics. Assigning such duties to the temporary team would risk creating a DevOps Team Silo, undermining the collaborative goals.
Team Structure 6: DevOps advocacy team
In firms with a significant gap between Dev and Ops or a tendency towards such a gap, establishing a “facilitating” DevOps team can be an effective approach. This is a variation of Type 5 (DevOps Team with an Expiry Date), but with the distinction that the DevOps team operates continuously, focusing specifically on fostering collaboration and cooperation between the Dev and Ops teams. Individuals within this team are often referred to as “DevOps Advocates” as they play a crucial role in promoting awareness of DevOps practices.
Team structure 7: SRE Team (Google Model)
While DevOps often suggests that Development (Dev) teams participate in the on-call rotation, it is not mandatory. In fact, some organizations, including Google, adopt a different approach known as Site Reliability Engineering (SRE), which involves an explicit hand-off from Dev to the SRE team responsible for operating the software.
Essentially, the SRE team can decline operationally substandard software and request developers enhance it before it is deployed into Production. Collaboration between the Dev and SRE teams primarily revolves around operational considerations. Once the SRE team approves the code, they assume the responsibility of supporting it in the Production environment, relieving the Dev team from that duty.
Model 8: Container-driven collaboration
Containers eliminate the necessity for certain types of collaboration between Development (Dev) and Operations (Ops) by encapsulating the deployment and runtime prerequisites of an application within a container. By doing so, containers establish a boundary that delineates the responsibilities of both Dev and Ops. The Container-Driven Collaboration model operates effectively when supported by a robust engineering culture. However, if Dev neglects operational considerations, this model can devolve into an adversarial “us and them” dynamic.
Model 9: Dev and DBA collaboration
To overcome the divide between Development (Dev) and Database Administration (DBA) teams, certain organizations have explored a model resembling Type 9. In this model, the DBA team’s database expertise is augmented by a corresponding capability or specialization within the Dev team. This arrangement proves beneficial in bridging the gap between the Dev-centric perspective of databases as mere persistence stores for applications and the DBA-centric viewpoint of databases as intelligent and valuable sources of business insights.
Wrap Up
DevOps is a transformative practice that demands cultural shifts, adopting new management principles and using technology tools. At the core of a successful DevOps transformation lies the selection of an appropriate DevOps team structure, which requires in-depth company analysis and careful consideration.
KMS Solutions’ DevOps services offer everything organizations need to facilitate this change. We provide expert consultation to help determine the optimal team structure that aligns with your specific requirements. Furthermore, our highly skilled DevOps engineers are dedicated to breaking down silos and fostering collaboration, unlocking the full potential of DevOps within your organization.
With our services, teams have the flexibility to create their desired DevOps toolchain by leveraging integrations with leading vendors and marketplace apps. Reach out to us today to drive successful DevOps transformation.
