DevOps Team Topologies: Anti‑Types, Types, and Choosing the Right Structure

The main goal of DevOps within an organization is to improve the delivery of customer and business value, not merely to cut costs, increase automation, or drive configuration management, which means different organizations may need different team structures for effective Dev and Ops collaboration.

Choosing a suitable DevOps topology depends on factors such as the organization’s product portfolio, the scope and effectiveness of technical leadership, the willingness to align IT operations with the value stream, and the organization’s capacity or interest in investing in operational concerns.

The article lists several anti‑types (bad practices) that hinder DevOps success: A) Dev vs Ops silos, B) DevOps team silo, C) No Ops needed, D) DevOps as a tooling team, E) Renamed SysAdmin, F) Embedded Ops in development teams, and G) Dev vs DBA silos.

It then describes nine positive DevOps topologies: 1) Dev + Ops collaboration, 2) Shared Ops, 3) Ops as IaaS, 4) DevOps‑as‑a‑Service, 5) Temporary DevOps team with an expiry date, 6) DevOps advocacy team, 7) SRE team (Google model), 8) Container‑driven collaboration, and 9) Dev + DBA collaboration. For each type, the article outlines its applicability, potential effectiveness, and typical organizational contexts.

Key take‑aways include that there is no universally correct team topology; each organization must avoid the listed anti‑patterns and select a topology that fits its size, product mix, technical leadership, and maturity level.

Finally, the article promotes an upcoming DevOps hackathon in Beijing (September 7‑8), inviting enterprises to form teams and register for special offers.