Considering a Cloud Center of Enablement (CCoE)

Implementing and deploying Cloud technology presents challenges in many organizations. Besides the transformation of legacy applications to Native Cloud technology, this also concerns the integration of various Architectures and/or the need to deploy new innovative technologies as efficiently and compliantly as possible. Setting up a team of experts under the name Cloud Competence Center (CCC) or a Cloud Center of Excellence (CCoE) is then often a logical approach. Personally, I prefer the term Cloud Center of Enablement (CCoE) to the other examples. In my opinion, the term ‘enablement’ expresses that this team facilitates the other teams to build up knowledge and skills themselves as soon as possible

Motivation for a CCoE.

Accelerating the development and adoption of new knowledge and expertise and promoting standardization are common reasons for establishing a CCoE (or CCC). In practice, there appear to be many more underlying reasons. Some examples are:

• The interaction between the (DevOps) teams and the support roles from Architecture, Risk management, Compliance management etc. does not run optimally.
• There is no or insufficient interaction aimed at recognizing and realizing reusable components, code and templates
• Re-use of components, code and templates is difficult to start up
• There is much uncertainty about the application of Guiding Principles (Reference Architecture).
• There are complaints about Guiding Principles, but hardly any proposals for improvement.
• The recognition and adoption of new innovations is slow
• The efficiency and quality of the team that manages the Cloud Foundation, respectively the Cloud Infrastructure, is disrupted because many ad hoc knowledge and expertise questions are also fired at them.
• There is a (still growing) diversity of redundant tooling.

Scope and Focus of a CCoE.

The initial motivation behind the CCoE is to develop and adopt new knowledge and expertise and contribute to standardization. Preferably, this team does not fulfill a primary role in the daily operation. In other words, without a CCoE, no operational process falls silent, only they are less likely to be renewed, potentially less compliant and efficient.

So, the CCoE helps the organization to innovate, accelerate, be compliant and secure. In practice, this proves to be a broad playing field. The proposed/submitted new innovations should be relevant, and as focused as possible. It is important that teams and team members are then assisted in learning to apply them in practice. Thus, the CCoE expert is skilled and familiar with the technology.

Periphery

An important consideration is whether the CCoE focuses only on the agile/DevOps teams (software production and management), or also on other roles/functions within the organization. The answer to this question is unequivocal; the CCoE focuses on everyone who is or will be involved in further digitalization where Cloud technology plays a role. So also, the managers, lawyers, buyers, risk managers, architects and for example IT service managers.

Added Value/Output CCoE

A more concrete picture of the tasks and role of the CCoE emerges if we pay attention to the added value this team brings to many organizations. In addition to the direct substantive added value, there is also the efficiency benefit and speed gain that the CCoE can contribute. Appealing and common examples focus areas of the CCoE are:

• Bringing in relevant new technology

Actively recognizing innovations in the market and presenting them internally. Often focused on potential application within the organization, but sufficiently open and transparent to promote creativity of those involved.

• Training, coaching and mentoring

Besides new expertise, the onboarding of new colleagues also requires the necessary attention and care. In terms of content, the CCoE contributes to this and coordinates the maintenance of an accurate onboarding kit. As a result, new colleagues can be productive more quickly, in line with the working methods and strategy of the organization.

• Innovation sparring partner and hands-on assistance

Implementing new technology often goes faster if you can talk about it with an expert. The CCoE provides this, as much as possible by providing the expertise itself, but also by making expertise from elsewhere (temporarily) available.

• Quality and compliance sparring partner

The CCoE should not have a formal role in validating and checking compliance and security. This would jeopardize the independent position of the CCoE. However, the CCoE should preferably be involved in the critical challenge of, for example, Designs, Templates, Pipelines and controls or tollgates.

• Bottlenecks in Guiding Principles

Bottlenecks in Guiding Principles or the absence of Guiding Principles often have a disruptive effect on the compliance and productivity of a Team. The completeness and applicability of these Guiding Principles is structurally monitored and analyzed by the CCoE. Where relevant, consultation with the owner and guardian of the Guiding Principles (e.g., the Design Authority) takes place by proposing additions and refinements.

• InnerSource Library

To share code, templates, components or experiences internally between the teams, so-called InnerSource Libraries are used (i.e., not accessible outside the organization). The CCoE plays a central role in maintaining such InnerSource Libraries. There can be several of these. This means that it oversees the libraries, and coordinates the processes, the tool(s) used and the core teams that perform the validation.

CCoE expertise

A frequent misconception concerns the staffing of the CCoE. The required expertise should include the infrastructure, but that should not be the focus. The focus should be more on Architecture and the application of software development. A helicopter view and the ability to oversee potential implications across multiple focus areas is extremely valuable. In other words, the CCoE expert has affinity with security, compliance, maintainability, or even better, has affinity with virtually all quality characteristics that are important in modern digital development.

Conditional

The CCoE expertise should be very accessible. Besides the tools used for sharing knowledge and components, the Experts must be visible and accessible without barriers. Avoid the Ivory-Tower syndrome and let the experts act on the floor(s) where all the DevOps-teams are working. Participating in the daily discussions and chats, will support adoption of sharing knowledge and interaction between DevOps teams and will grow the added value of the CCoE.