As DevOps adoption continues to accelerate, many leaders are looking to set up their DevOps center of excellence (CoE). The CoE’s role is to ensure that the wider company sees the valuable benefits of DevOps: innovation, efficiency, and reduced risk.
With the ongoing trends toward hybrid and remote working, knowledge-sharing between colleagues is less likely to happen organically and developers will default to their preferred processes. Assembling a CoE can help combat these challenges and facilitate DevOps adoption, but you should avoid these five common pitfalls.
1. The mission isn’t clearly defined
The CoE’s mission must be defined at the outset. Without a shared understanding of its purpose, the CoE will struggle to identify objectives and find themselves needing to justify their work.
It’s important to define scope and structure. In terms of scope, consider these questions: Will the CoE simply establish effective methods, or is an overhaul of DevOps tooling across the enterprise in view? Are there specific targets for the CoE, or will it drive innovation more generally?
As for structure, some enterprises dedicate a full-time CoE team while others gather experts from various teams who collaborate on improving DevOps processes. The latter approach is similar to Communities of Practice (CoP), which more strongly correlates with DevOps success than traditional CoE setups, according to the DORA report on the State of DevOps. For this reason, I recommend that your CoE takes as much as possible from the CoP model.
2. The CoE becomes detached
Breaking down silos between DevOps teams is a key objective for CoEs. Ironically, some CoEs become an additional silo and risk becoming detached from the rest of the company. While building a CoE guarantees having a team dedicated to the ongoing improvement of DevOps processes, finding a way to keep the CoE integrated with parallel teams can be difficult.
Your CoE might become a bottleneck for innovation, slowing down other teams by advocating an idealistic process that’s difficult to implement. Avoid this scenario by keeping the CoE working on real-world projects so they stay attuned to the nuances of the actual DevOps processes used by teams across the company.
3. No two-way communication
The center of excellence model is all about peer-to-peer knowledge-sharing. A CoE can lend structure and decisiveness to that model, but open communication channels need to be available for other teams to pass their insights and feedback to the CoE.
The CoE should create formal structures for proactively obtaining insight. At some of the enterprises my company advises, the CoE audits other teams across the business regularly. The audit establishes the following:
- Which tools and processes teams are using
- Who the stakeholders are for environments maintained by each team
- How the team is performing in terms of DevOps KPIs (e.g. release cadence and lead times)
This data helps the CoE identify best practices across the organization, not just from the CoE itself. By combining the best bits of each team’s process, and forming a coherent approach, the CoE arrives at a process it can share across the enterprise and justify with data-driven analysis.
The expertise needed for a high-performing CoE often exists in large enterprises, dispersed across different teams. Bringing that expertise together and tasking the team with finding innovative DevOps solutions can be valuable if you avoid the pitfalls that cause CoEs to underperform.
Disclaimer: The original blog was published on https://www.informationweek.com/
BDCC
Latest posts by BDCC (see all)
- Top Security Practices for DevOps Teams in 2025 - December 19, 2024
- Jenkins vs. GitLab vs. CircleCI: The Battle of CI/CD Tools - December 16, 2024
- Beyond the Pipeline: Redefining CI/CD Workflows for Modern Teams - December 13, 2024