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.
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.
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.
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.
About Johan Flikweert
Thanks to multiple years of experiences in discussing and implementing Digital innovations in multiple Branches, the role of sparring-partner on Digital acceleration suits me as a leather jacket. Once I started with guiding and managing the implementation and roll out of National Wide online information network in the Agricultural sector, where users neither as the providers had any experiences with this topic. With in between steps where I was enabled by a team of technical and data-experts to define, create and implement a vegetable supply forecasting system for a a merged company (out of 10 auctions), I made the step to Sogeti. After multiple roles as consultant, project lead and program manager I have been in the position of dealmaker for the Cloud-Journey of PostNL. Since 2012 I have been focusing on Cloud and specially the strategy an Enterprise should develop to realize a successful Cloud journey. The last years I work as a SME in close harmony with Cloud Solution Architects and Cloud Engineers to improve our approach and bring our Best Practices to Clients.
More on Johan Flikweert.
Well written Johan.