Discover our blogs

According to Gartner, every enterprise needs one.  According to conversations with our customers, every enterprise wants one.  But what exactly is a Cloud Center of Excellence (CCoE)?  In 2016, Stephen Orban, at that time Global Head of Enterprise Strategy at AWS, started using the term CCoE in a blog series around the “Enterprise Cloud Journey“.  His vision for a CCoE at that time was similar to what today would be a vision for a DevOps team with a little more focus on change management. 

That original vision is sometimes still causing confusion: “is a CCoE not another name for DevOps?”.  The short answer is that the original vision is still relevant: you should have a team responsible for developing a framework for cloud operations, the governance around it and for building out best practices throughout the business.  However, just like the cloud have evolved a lot since 2016, the definition of a CCoE has moved on as well.  DevOps still is one of the capabilities a CCoE will focus on, but there is much more.  Already in 2017 AWS had expanded the original definition:

“A Cloud Center of Excellence is a cross-functional team of people responsible for developing and managing the cloud strategy, governance, and best practices that the rest of the organization can leverage to transform the business using the cloud.” 

AWS, Cloud Management Report 2017

How we see it at 45 Degrees:

A CCoE is a centralised program with the goal to optimise the cloud-enabled IT transformation with focus on 6 key capabilities: Strategy, People, Governance, Platform, Security and Operations.

Enough of definitions.  Everybody will have their own definition.  Let us go into what it really is.

It is a program.

When you bring people together in a cross-functional way it is a good idea to put a program structure behind it.  Hence, we do not start from “it is a group of people”, but rather, “it is a program”.  The program needs a program charter, which defines what the program is all about.  Building this program charter is best done in an iterative way.  Just like adopting cloud technology, a big bang approach will not work.  Start simple, version 1 of the program charter.  Work in an agile way even with your program definition.  Which does not mean it changes every day but work in defined iterations.  Expand the scope as the maturity grows.  Calling it a program and running it as a program will also establish trust with senior leadership.  It will help to get buy-in.

There are people in the program.

Of course, the program is staffed by people.  But how many and what roles?  And where do they come from?

First things first: outsourcing a CCoE is not the way to go.  The CCoE is a program you must own and run yourself.  You can add staffing of external experts.  To start of you might even need to find the new skills you need to start a CCoE.  Our pragmatic recommendation is to staff iteration one of your CCoE with at least 2 own resources: a CCoE Lead and a CCoE Architect. 

The CCoE lead takes control of the CCoE program and of the non-technical capabilities.  The CCoE architect takes control of the technical capabilities.  By keeping the core team small, they must bring other people into their workstreams.  That is critical for the success of a CCoE.  As the maturity grows you can add more people to the CCoE.  Always keeping in mind to be lean and mean. 

A question we often get is: but I do not have people with these skills in house?  Which obviously makes sense.  We see 2 ways of dealing with that scenario.  Or you appoint 2 people with a keen interest and with the potential to learn to operate in a cloud world and you put external consultants next to them and let them work as a tandem.  Or you hire them externally.  The second scenario is not without risks. 

Finding this type of people is one challenge.  But more difficult is onboarding them.  One of the key skillsets of people in the CCoE is that they can bring people from different skillsets and organisations together to work on a common goal.  For new people it takes time to understand the organisation.  The second scenario mainly has a timing challenge.

It is centralised.

The CCoE is a centralised function at the crossroad of central IT, business IT and cloud service consumers in the business.  A successful CCoE serves as a broker or a business partner.  In the traditional view of IT, the IT division is often an operations unit or an abstraction layer between the business and IT assets.  With a well running CCoE the focus is on delegated responsibility.  We like to call it “freedom within the frame”.  Microsoft has a nice analogy image showing the difference between the 2 approaches:

A misunderstanding we often hear is that customers assumed a CCoE will “run all of the cloud”.  Whatever it means exactly, the CCoE is not there:

• To run all the cloud (migration) projects within the CCoE.  These projects will be done in project teams, which will use various best practices established by the CCoE workstreams.
• To run all the cloud operations.  The CCoE will define best practices for topics related to operations.  But the CCoE is not the team that will do the operations.

People in these project/operations teams will participate in workstreams owned by the CCoE.  That is critical for the success of the CCoE and as such of the cloud transformation.

It is to optimise.

Cloud computing is marketed as “easy to adopt”.  Start with a proof of concept or a pilot, the investment cost is very low.  Fail fast, learn fast.  It took Thomas Edison over 9000 attempts to invent the light bulb.  His advantage was that he was not stressed by time…  Reality is that cloud adoption is complex, and the adoption time is not unlimited, quite the opposite.  A CCoE is there to optimise the cloud enabled transformation.  Optimising has a lot of faces. An interesting example is “cost optimisation”.  Recently we got a lot of questions around “the cost of the cloud”.  Let us be a bit provocative:

• If you do a simple lift and shift of your on-premises datacenter to the cloud, it will most likely be more expensive.
• If you just put a proof-of-concept workload in production as is, consumption costs might be very high.
• If every development team can pick and choose what cloud services they will use, your cloud services will trigger a big bill each month.

The topic of optimising cost in a cloud world is one of the many topics where a CCoE plays a key role.  The list of topics is long.  As such it requires a framework to give you a checklist of capabilities required to optimise your cloud transformation.

It has a broad scope: the 6 main capabilities.

And that brings us to these capabilities.  At 45 Degrees we have structured our CCoE framework around 6 capabilities.  Within each of these 6 capabilities there is a defined set of sub-capabilities which give a good overview of what it takes to run an optimised cloud transformation.  Looking at the scope of such a framework, the need to work in an iterative way becomes clear.  That triggers another interesting question, which is covered in another blog: “How do you start building a CCoE?”.