Cloud center of excellence (CCOE)

The CCoE is a team of cloud engineers and architects who help the company achieve stable and manageable cloud solutions in a short period of time. It is a focal point of knowledge and expertise, a balance between speed and stability, but more importantly, a helping hand. In addition to designing and building the application, the developers will deploy and support the customer themselves. No interference from IT department with ITIL processes and tickets.

The CCoE will provide the cloud platform, and then the developer is in-control. They will also become responsible for security and service management themselves. The CCoE will provide support in these areas, but not be the man-in-the-middle they should be waiting for. The CCoE will shift the focus from a heavy reliance on the IT department, to more autonomy with the DevOps teams.

Usually, a CCoE starts out as a single-cloud provider (for example, on Azure, AWS or GCP), but may well grow into a multi-cloud provider over time.

Sometimes the term Cloud Based Service Provider (CBSP) is used for a similar construct to the CCoE.

A CCoE begins with a vision. This will vary by CCoE, but will boil down to:
Maximize autonomy and agility for DevOps teams.

The CCoE helps DevOps teams by providing a reliable cloud platform so they can build cloud applications quickly and reliably, minimizing risk. They don’t do this like a traditional IT department, but more like a service provider. The DevOps teams are self-managing their cloud environment.

Basically, you are going to build your own team within your organization, which is likely to be a combination of internal employees supplemented by external specialists.

Microsoft (for the Azure cloud) can help in this with guidelines (link) and resources (cloud engineers and architects). But there are also other partners and cloud providers that can help you with this.

Not every CCoE is the same. Just as you can apply Scrum to your own liking, the same is true of CCoE. There are general guidelines, once devised by Stephen Orban, but feel free to deviate from them as you see fit. Here is a setup as set up at my client, and also advised by Microsoft.

• Customer team
  Consists of a few cloud solution architects who conduct an intake with the customer, create a solution design, provide advice, align responsibilities, and help build their product through a POC or MVP.
• Product team
  Consists of some cloud engineers who create standard/certified products that can be used by the customer team and the customer. Think VM images, Kubernetes clusters, SQL servers and storage accounts compliant with security and service management.
• Platform team
  Consists of a few cloud engineers who provide connectivity, IAM (Identity and Access Management), monitoring and management (operations).
• Cloud Architecture
  Consists of a few enterprise and security architects, who together with delegations from the other teams draft the reference architecture (policies) of the CCoE.
• Service Management
  Consists of one to two cloud architects who establish guidelines for managing the cloud platform, such as patch management, cost management, ownership, cloud limit management, knowledge transfer, and setup of operations.
• Security and risk management
  Consists of one to two security architects who establish guidelines for security, such as Identity and Access Management, data classification, and network security.

We call the various DevOps teams with their cloud requirements, or “the customer,” a workload. When a new workload presents itself (via email, walkway, ticket system), it is onboarded, and the process of Intake > Design > Build > Run begins.

When a DevOps team knocks on the door because they have a cloud requirement, the CCoE’s Product Owner will first roughly inventory what the requirements are, test whether their cloud requirement is feasible and plausible, and prioritize.

A cloud solution architect further picks up the workload, meets with the customer to discuss further details, creates a cloud solution design, recognizes reusable products and calculates costs. The output is discussed with the client. This is also where the platform for the client is often prepared (deployed), such as a resource group or AKS cluster.

During the construction phase, it is the client’s turn. He should build the application, if it is not already built. The solution architect often helps with the CI/CD pipeline for Infrastructure-as-Code. Sometimes a Proof of Concept (PoC) is created, but often we quickly move on to the Minimum Viable Product (MVP). Once reusable products are recognized, the product team will now build them.

The product (MVP) was built and tested in a test environment. After the customer agrees to the RACI (matrix of responsibilities) and a security officer approves the solution, it can be put into production. From here, the commitment of the customer team stops, and business-as-usual (management) begins.

An important term is demarcation: who takes care of what.Sometimes DevOps teams think the CCoE is going to build their cloud needs. Or that the CCoE is going to patch their VMs. Here the demarcation should be clearly stated, and you can see the stark difference between an IT department and CCoE. You get the agility (agility) in your own hands, but you also have to do the management yourself. For example, if you request a Kubernetes cluster, you can get it as early as this afternoon, but you have to do the upgrades yourself. This is made clear with a RACI (see Wikipedia) that clarifies who has what responsibilities.