Building a Cloud Centre of Excellence in 2020: 13 Pitfalls and Practical Steps
As more and more organisations look to scale their cloud journeys, many will choose to establish a Cloud Centre of Excellence (CCoE) to take care of the initial embedding and ramp-up of cloud adoption within the business.
What Is a Cloud Centre of Excellence?
A Cloud Centre of Excellence is a multidisciplinary function, bringing together expertise from a range of disciplines across the business, to champion the cloud and drive forward a secure and compliant path for cloud consumption. It is effectively a miniature, internal representation of how the organisation as a whole should work with regards to cloud.
Whilst the concept of a CCoE is nothing new, its role in enterprise organisations has evolved over the years as the industry’s approach to cloud adoption has matured. Traditionally, a CCoE has been thought of as a singular central control function or “tower” that sits independently from the “data tower” and the “hosting tower”. But here are two things I believe to be true today:
- A CCoE should NOT be a central function of ownership
- A CCoE should NOT be the central function of expertise
Instead, I prefer to think of a CCoE as an enablement function. On the one hand, a CCoE is there to provide a product (i.e. the cloud) but on the other hand it exists to enable consumers (i.e. the product and development teams) to consume this product. It does this by providing a set of repeatable standards, governance frameworks and best practices for the rest of the business to follow during the cloud migration.
Done well, this enablement function will achieve the following outcomes:
- Accelerate cloud adoption across the business
- Encourage innovation
- Optimise costs (based on FinOps practices)
- Minimise the risks involved (based on Continuous Compliance and Compliance as Code practices)
Done badly however, a CCoE can actually end up acting as a barrier to consuming cloud within the organisation.
In this blog post, I’ll share how to avoid six of the common traps that organisations fall into as well as give practical steps for how to overcome seven key challenges businesses face so you can establish a successful CCoE!
6 Common Traps to AVOID When Establishing a Cloud Centre of Excellence
1. Getting hung up on the term ‘centre’
One of the biggest traps that we see at Contino is organisations getting stuck on the principle of a centre of excellence. This is dangerous territory since a centre indicates a singular, central, isolated function and this can lead to the misconception that the CCoE is the only place the cloud can be consumed within an organisation.
The key here is to shift the focus away from the term centre to the term enabler.
As we’ve seen, an enablement function advocates shared responsibility and empowered product teams. This is a much healthier and more sustainable approach to consuming cloud at scale.
In reference to Team Topologies, which provides mature naming standards across the industry, the CCoE would be an Enabling Team with the potential need to provide a Cloud Landing Zone, and the team looking after it would have a Platform Team Topology.
2. Controlling consumption of cloud services and blocking innovation opportunities
We often see CCoEs make the mistake of taking sole responsibility for operating the cloud across the entire organisation, rather than federating operations out to product teams. They tend to fall back on traditional governance approaches which dictate what cloud services can and can’t be used by consuming teams. This can result in a massive bottleneck for innovation and progress will inevitably be much slower than the business had anticipated.
As a centre of enablement, it shouldn’t be up to the CCoE how other teams consume cloud.
Yes, they should be asking the right questions and making the right governance decisions to protect the organisation but they should not be doing so at the expense of innovation.
3. Ignoring developer experience
A big part of the CCoE’s role involves using the cloud as an enabler to help product teams and dev teams to move at speed. To make sure they’re on the right track, a key metric that CCoEs must take into account is developer experience: How are you doing with regards to your internal customers (i.e. your engineering teams)? How good is their experience when they use your product (e.g. a landing zone, developer tools, compliance frameworks, multi-tenanted platforms)?
One of the biggest mistakes organisations make is failing to listen to their own dev teams when they are building out platforms.
Instead, they get hung up on standardising tools and frameworks and try to establish a common centralised architecture. And this ends up delivering little to no value to developers, let alone to the organisation's customer.
Imagine, as a developer, that your organisation won’t let you push anything into production until a central team has given the go ahead. The central team might not have any idea or context about what changes you have made but they have final say. This is not good for developer experience! And this, in turn, is not good for business.
4. Applying traditional architecture standards and processes
Another trap that is all too common is the tendency of CoEs to stick to traditional architecture standards and processes associated with on-prem, which dictate what dev teams can and cannot use.
The problem here is that a lot of these architecture functions are just paper-based governance or product-selection functions. They lack the technical skills to advise engineering teams on what to do.
5. Confusing guardrails with blockers
A lot of organisations confuse guardrails with blockers.
They forget that guardrails aren’t meant to be set in stone; they are often there to guide you towards doing the right thing but they’re not meant to be blockers.
They should form part of a continuous feedback loop, tracking progress throughout the entire lifecycle, to ensure you’re doing the right things.
In the same vein, the CoE should not have end-to-end accountability of what each product team is doing by blocking their decisions. If the organisational structure is set up well, product functions should have the final say with regards to what they are about to push into production and the potential customer impact that they’re about to have.
6. Catering for a single cloud maturity level
Every organisation will have a mixed level of maturity across its development and product teams.
A fundamental trap that every CCoE should avoid is to only cater for a single maturity level and force the others to fall in line.
This often leads to either developers ignoring their CCoE, creating their own cloud platforms and bypassing the CCoE.
At Contino, we recommend using Simon Wardley’s organisational model of Town Planners, Settlers and Pioneers (PST) to tailor and model the products and services being offered by the CCoE. The ‘PST’ model uses a cell-based organisational structure in which there are three groups of consumers that represent different levels of cloud maturity:
- Town Planners: we “build it” and “run it” for you
- Settlers: we help you “build it” and then “run it” for you
- Pioneers: we help you access cloud so you can “build it” and “run it”
For instance, if the CCoE is looking to deliver a Landing Zone, this should cater for a developer experience that can cater for all three of these maturity types, with the appropriate level of enablement.
Practical Next Steps: Overcoming 7 Common CCoE Challenges
Generally speaking, the most impactful CCoEs share the same DNA as high-performance teams. However, when you’re starting from scratch within your organisation, it’s not always obvious what the key building blocks of a successful CCoE should be.
Many of our customers face the same challenges around scalability and ownership during its mobilisation phase, leaving them unsure on how to progress.
Based on my experience with cloud transformations, I’m sharing Contino’s approach to overcoming some of the most common challenges businesses face when establishing their CCoEs.
Challenge #1: Building your CCoE - who should be part of it?
One of the first challenges you’ll face is deciding who to include in your CCoE. The roles and responsibilities within the CCoE will inevitably change over time as cloud adoption scales, however it’s crucial to start with a strong team.
CONTINO’S APPROACH: MULTI-DISCIPLINARY TEAM WITH A WIDE RANGE OF SKILLS
Members of the CCoE should be pooled from each facet of your organisation across engineering, security, compliance, architecture, finance and product delivery, to name but a few.
Crucially, we remind our customers that the CCoE should NOT be seen as its own “tower”. An enablement function, by its very nature, has to be cross-disciplinary in order to offer the right level of expertise and to guide the rest of the organisation with authority.
As for technical expertise, the CCoE should include experienced individuals with a history of architecting and building solutions within the organisation. It goes without saying that the CCoE should include members who will specialise in the cloud and cloud specific functions and these individuals should be able to do the hands-on work needed to build and test cloud solutions.
Challenge #2: Getting started - How big should it be?
Invariably, the scale and size of your CCoE are dictated by a number of factors. However, we find that the same basic rules apply across different types of organisations.
CONTINO’S APPROACH: SMALL AND NIMBLE
We generally advise that the CCoE should start as small as possible, with sufficient representation from the key business functions, while avoiding the trap of Brooks’ Law (that adding more people to a late software project makes it later).
Don’t make the mistake of starting with multiple work streams running in parallel without a cohesive set of goals or a vision with regards to the role of cloud in the organisation. The last thing you need is multiple work streams stepping over each other, not knowing where they fit in. That’s when your Centre of Excellence risks descending into a Centre of Entropy!
As a general rule of thumb, having a team no bigger than 15 members is a good starting point, using Dunbar’s number to scale and ensure trust and quality is being maintained as part of the process. These initial members should include the key Product Owners and Lead Engineers across the core domains listed above, before growing those functions via mitosis (i.e. once teams reach a certain maximum size they are split in two).
Challenge #3: How much and what involvement should the business have in the CCoE?
A major challenge is knowing where the CCoE stands within the organisation. How much ownership should it have with regards to the organisation’s cloud strategy and vision? It’s essential that the business is clear on this point at the start, otherwise it will face many more challenges further down the line.
CONTINO’S APPROACH: TRUSTED BY THE BOARD TO DELIVER THE ORGANISATION OF THE FUTURE
We advocate that the CCoE should have decision-making power and ability to influence long lasting change across the organisation. They should be granted a mandate by both IT and business leaders to cut through bureaucracy.
However, the Cloud CoE has to go a step further and deliver an organisational blueprint across people, process and technology in order for cloud adoption to be successful in the medium to long term. If not, the CCoE runs the risk of clashing with organisational values and structures that stood it up in the first place.
Ultimately, the success of a CCoE is dependant on how quickly the core building blocks (landing zones, control frameworks, shared tools/patterns, operational models etc.) can be put into place, so that it can focus more time and effort on the enabling the consuming product and applications team in realising the value of cloud.
The Contino Cloud Adoption Framework, as outlined below, looks to provide a blueprint of what organisational change a CCoE should look to deliver. By looking beyond the platform and applications layers, into cross-cutting areas such as the Financial, People & Security Controls models, the Contino Cloud Adoption Framework provides a set of engineering and technical disciplines to consider when focusing on engineering enablement, whilst keeping an eye on organisation wide concerns to address to achieve the CCoE’s transformation objectives.
Contino's Cloud Adoption Framework
Challenge #4: Instilling Modern Ways of working
As a centre of enablement, the CCoE should provide product teams with all the governance and support mechanisms necessary to take products to fruition, using modern ways of working. This requires a shift in perspective from both the product teams and the wider business.
CONTINO’S APPROACH: AGILE PRODUCTS NOT WATERFALL PROJECTS
We support CCoEs in instilling behaviours across the business to move towards iterative development cycles and coach the IT function that cloud platforms should be treated as products. They should not be based around traditional processes, organisational structures and ways of working.
The perfect way for an organisation to deliver upon this is by providing product teams with a Route-to-Live that enables them in delivering products and services to their customers, without shackling them with the traditional operational processes used on-premise.
Crucially, the way you build, plan, deliver and measure the success of your product should be based on product-focused measurements as opposed to project-focused. For example, the way in which a landing zone is built, consumed and iterated upon by the CoE should look to embody the principles of product focused delivery.
Challenge #5: How should your CCoE evolve over time?
As the cloud maturity in the organisation evolves, so too will your CCoE. But what does this growth typically look like?
CONTINO’S APPROACH: DESIGN, BUILD, ENABLE AND EVOLVE
The CCoE, as a governance/enablement function, should be enduring. However, while it should continue to provide an updated set of standards and patterns for teams to consume, one should expect the roles and responsibilities of the CCoE to evolve over time.
In its first year, for example, the CCoE typically fulfils the function of a platform team; the focus being on building a Landing Zone, Control Framework & Route to Live; whilst also supporting and educating other teams. However, going forward its role should move into more of an enablement function; rather than doing, a successful CoE will shift its focus towards enabling consuming teams.
Such an example is shown below, where in its first year of inception the CCoE bundles the function of the Landing Zone platform team and Developer Experience enablement team as part of the same group. However, as time evolves and the organisation’s cloud maturity increases, via the methodology of team mitosis (more on this below) the CCoE creates a dedicated Developer Experience function that looks to enable consuming teams on using the Landing Zone and build their federated route to live and operations.
Challenge #6: Should the CCoE be in charge of the cloud costs being incurred?
It’s no doubt that adopting cloud at scale requires an initial investment from the organisation in order to provide an enablement capability to the wider business, in addition to the cloud and technology costs to be incurred (software licenses, development machines etc.). However, the key pitfall the CCoE should avoid, just like many of the governance and control functions listed above, is centralising cost management and the cloud costs incurred within the CCoE and acting as a central gatekeeper.
CONTINO’S APPROACH: FINANCIAL AGILITY AND FINOPS
Individual product teams should be responsible for paying for the services they consume and the CCoE should be in charge of visibility around the services consumed and why. Just like every other control and operations related decision a product team makes, the financial implication of your architecture on cloud should be no different.
As the CCoE moves into a governance/enablement function, adopting a mature FinOps approach is critical for long term and financially sound cloud adoption within the organisation. As an enablement function, the CCoE should look to benchmark the product teams against each other, helping them understand and visualise the financial impact of their decisions and establish a Financial Trace between the products being delivered, costs being incurred and the subsequent benefits realised. Using the FinOps maturity model as a starting point, the CCoE should look to offer valuable insights and information for consuming teams prior to providing more complex cloud financial management services.
Challenge #7: How can the CCoE successfully scale cloud adoption across the organisation?
As previously mentioned, the key is to start ‘small and nimble’. However, in order for cloud adoption to scale, organisations need to put mechanisms in place that focus on organisation-wide education and cloud advocacy.
CONTINO’S APPROACH: INCREASE CLOUD ADVOCACY VIA EDUCATION DAYS, MITOSIS AND DOJOS
The measures that we have seen work best here are Education Days, Team Mitosis and Engineering Dojos:
- Cloud Education Days: This is a day dedicated to lightning talks and workshops around specific cloud topics. Having run these for some of the world’s largest institutions, we often recommend running education days and awareness sessions for various skill levels and roles within the organisation to drive education, generate excitement and provide strategic alignment to the organisation’s cloud strategy. It acts as a springboard to drive cloud understanding and adoption in the most valuable manner.
Objectives: What are your people's concerns?
- Team Mitosis: This is the process of having key advocates from the core CoE who are willing to work with newly onboarded teams and get their products and services running on cloud. These advocates have a varied skill set across architecture, security and engineering and the key role of providing a seamless developer experience, and feeding back changes and feature requests to the CoE (eg. new Shared Service required on the Landing Zone).
- Engineering Dojos: Taking a page from the ‘Learning by Doing' book (a theory of education based on a hands-on approach to learning), Engineering Dojos using the organisation's cloud landing zones are the perfect mechanism to get multiple engineering teams and developers to build products and applications in close collaboration. Not only does this provide the CCoE with a wide consumer base to gather feedback from, but also provides a highly effective way to get developers consuming a platform that they perhaps were unaware of. In fact, at the recent DevOps Enterprise Summit in London, Dojos proved to be the most effective and widespread methodology used by organisations in 2020 to scale their cloud and DevOps adoption.
Conclusion
Although it might sound like a traditional idea in 2020, building a CCoE continues to offer significant value, having evolved from a central governance and control function to one focused on enablement, developer experience, engineering excellence and meaningful education in order to drive an organisation’s cloud adoption forward.
That being said, a Cloud CoE will only be able to cement successful, sustainable and long lasting change if it also looks to instil modern ways of working, education and enablement functions for consuming teams to be able to deliver the customer experience and value the organisation stands behind. On top of this, organisations must be prepared for the role of their CCoE to change over time in line with its cloud maturity.
Fortunately, organisations can now lean upon proven, successful implementations of Cloud CoEs that work to accelerate the installation of the core building blocks of enterprise cloud adoption (landing zones, control frameworks, shared tools & patterns, operational models), in order to focus more time and effort on enablement.
