Cloud center of excellence: Just do it, thank us later!
Harnessing the cloud advantage the CCOE way.
This blog is from Cloud Strategy Unboxed, a series that looks at the recommended organizational structure for the successful adoption and operation of the cloud. This approach breaks down silos, facilitates collaboration and agility, and provides a centralized approach to the cloud with clear responsibilities and accountability.
What is the CCoE?
A well-structured Cloud Centre of Excellence can solve many common challenges large organizations face when adopting the cloud. It is the cornerstone of successful cloud adoption and modern cloud management strategy.
The CCoE is effectively a centralized team that governs the use of the cloud within the organization. Its responsibilities include designing, building and operating the cloud platform, uplifting the organization’s cloud capabilities, and ensuring compliance requirements are enforced in the platform, and automated where possible. Its members collaborate closely with existing departments with opinions about the cloud and create and enforce cloud policies.
A CCoE will seek to modernize and automate processes as much as possible. This is required to ensure scalable cloud operations that a lean team can run. They will drive continuous improvement and optimization of the cloud platform, blueprints, and examples as the technology evolves.
Its members are advocates and mentors in the cloud, establishing best practices and providing examples, training and support to application and other teams within the organization. They are responsible for a technology and capability roadmap to evolve the organization’s use of the cloud.
A CCoE approach brings people together from previously segregated teams into a new central team with a key focus on the cloud. This breaks down silos, helps to democratize the cloud through collaborative ownership, and avoids the cloud strategy being biased towards a particular agenda or outcome.
The cloud blueprint describes the CCoE team structure and the actions required to go from the current state to the recommended CCoE structure. The operating model addresses how the CCoE will evolve and grow over time and the ‘business as usual’ activities such as recurring schedules, backlog prioritization, and the collection of internal feedback for continuous improvement.
What the CCoE requires
To achieve its goals, the CCoE requires organizational buy-in. Stakeholders, including C-level, need to be aligned and invested in the agreed outcomes. The cloud transformation outcomes, purpose, and quantifiable short-, mid-, and long-term goals need to be well-scoped and clearly described.
Each initiative’s scope and responsibilities must be agreed upon and assigned to the appropriate teams and individuals within the organization. Sufficient time and resources must be made available for the CCoE to execute the strategy. And lastly, a comprehensive plan must be clearly communicated to the application and other impacted teams. Always consider and give voice to “What’s in it for them?” when communicating transformational plans to teams.
CCoE structure
There are a few CCoE structures that have proven successful in one or more organizations. Different consultancies and cloud service providers propose different structures, and individual organizations often adapt structures to better suit their organization. It is more important that a given structure addresses the required CCoE responsibilities and achieves a similar outcome rather than trying to follow a particular one-size-fits-all approach.
The following structure is one that we have found works well, especially in this region, for large enterprises.
At the top is the Cloud Adoption Lead, who will be responsible for leadership and governance of the Cloud journey. This does not necessarily need to be a technical person. They need to have a strong network within the organization, know who they need to call and who they can rely on for different types of tasks, and be able to bridge the gap between technical and non-technical teams. A strong leader that knows how to rely on and make the best use of a competent team of individuals when executing a transformational strategy.
The Project Management Office and Advisory Board will support the Cloud Adoption Lead in ensuring standards and the smooth execution of the cloud strategy. Some organizations might prefer to place project management/delivery roles within the CCoE rather than second them from a separate PMO. Either approach can work as long as these capabilities are available to the CCoE.
At the bottom are the four core teams within the CCoE.
- Platform Architecture and Operations, responsible for designing, building, and operating the cloud platform. They will decide on tooling, operational practices, core security and compliance elements, and more. For example, they will design the tooling for application delivery and set security standards such as encryption and best practices for cloud architecture.
- Education and Advocacy, responsible for knowledge management, organizational cloud fluency, training programs, certification drives, and working closely with HR on cloud career progression and incentives. They will help garner support for new initiatives, raise awareness of new technology trends, and provide training to different levels within the organization. For example, when adopting modern cloud architectures such as Serverless, they will educate stakeholders to gain buy-in, train application teams to follow best practices, and provide architecture designs to help kick off new projects. This team will also be responsible for maintaining a view of inbound demand and ensuring upskilling programs are aligned with it.
- Application Enablement provides hands-on support helping application teams and vendors onboard projects, design cloud architecture according to organizational best practices, and use the cloud platform’s deployment approach and shared services. For example, when starting a new project, they will assist the application team with the architecture design, following best practices and security requirements. They are also a key point of contact between the technical teams and the CCoE, bridging the gap and turning feedback into backlog items.
- Lastly, Business and Product represents the organization’s business interests in the cloud. A key role here is a finance role focused on the organization’s cloud financial operations (FinOps). They will design policies related to optimising cost and work with the platform team to implement controls to enforce and automate the policies. Large organizations with multiple application portfolios can consider a representative from each portfolio in this team. They can consolidate the needs of all applications within their portfolio to help with the cloud platform’s service and feature prioritization.
Platform architecture and operations
Given that they will be building and running the cloud platform, it will consist mostly of architects and engineers, with some support roles such as a coordinator or project manager. Three leading roles are the Platform, Security and Operations architects. Together, they are the DevSecOps for the cloud management platform.
The Platform architect will design the platform and its core components, such as account structure, delivery pipeline, and testing and logging solutions. They need deep and broad experience in the cloud to create a comprehensive, efficient and cost-effective platform. This role will also design templates, blueprints, modules and similar Infrastructure-as-Code assets that the application teams can use. They will be responsible for the technical roadmap of the platform, including handling and prioritising service and feature requests.
The Security architect will take input from departments such as risk, IT security, and data privacy and design the necessary controls to enforce security and compliance in the platform. They will review platform architecture from a security perspective and address critical risks and incidents.
The Operations architect will design capabilities to monitor and automate the operation of live applications. Alerts, automated responses and notifications of events within the cloud fall under their responsibility. They will also be involved in designing controls that are less about security and more about optimization and cost-effectiveness.
Large enterprises, especially those with a multi-cloud or hybrid-cloud strategy, can consider a fourth role for an Integration architect. This role takes ownership of the network, connectivity and hybrid and multi-cloud integrations. These are described as roles, and a single individual could take up multiple roles, especially in the early days of the CCoE. Each of these roles might also implement the designs initially, but as the CCoE grows, they would create teams of engineers to help with implementation. Lastly, it is vital that these roles, and indeed the organization, do not operate as an island. Best practices and industry standards are well established. They can be looked at and, where needed, adapted to suit the organization and reduce the risk of gaps and other issues.
Advocacy and education
The advocacy & education team focuses on training and developing cloud skills within the organization. At the executive level and the broader organization, cloud fluency training will help everyone understand cloud basics and terminology. This will facilitate more efficient meetings as basic concepts don’t need to be explained. Business teams will receive non-technical training on cost optimization and the pros and cons of different cloud providers or architecture choices. Deep cloud technical training will be provided for the application teams and CCoE engineers.
This team should also drive the cloud community within the organization and run the cloud knowledge portal where ideas, knowledge and training can be freely shared.
Lastly, working with HR, this team will be responsible for recommending suitable KPIs, planning game days, organization certification rallies, and ensuring cloud skills are integrated into the organization’s career framework.
Application enablement
Application enablement supports application teams using the cloud platform and designing applications to the established best practices. They can be considered technical coaches or internal consultants, there to pair and help hands-on-keyboard as needed.
Given their interaction with the application teams - the cloud platform users- they are also expected to be active in the cloud community and in collecting, measuring, and compiling feedback, suggestions, complaints, optimizations, and features from all users and engineers of the platform. The information collected can then be brought to the attention of the CCoE for feature identification, prioritization, and development.
Business and product
The business & product team exists for large organizations with multiple major application portfolios, online products such as SaaS offerings, strategic partner relations, and other business needs that the cloud may impact. The team can include representatives from each of the organization’s application portfolios or digital products to ensure business views are considered in the cloud strategy and platform priorities.
A key role in this team is a financial representative. They drive the Financial Operations (FinOps) strategy and ensure cloud incentives, discounts, and programs are fully utilized. A FinOps strategy includes many policies that can be automatically enforced within a cloud platform. For example, resource tagging can be enforced during deployment to associate the resources with a particular application or team.
Advisory board
The Advisory board is where all others within the organization with an opinion on the cloud can be seated. Being on the advisory board provides them access to CCoE meetings where they can ensure their views are considered in shaping and executing the cloud strategy. Members of this team are all part-time and typically only advisory, not engineering or executive.
For example, the data protection office would send a representative to ensure privacy regulation is considered as part of the security controls and that adequate data monitoring and auditing capabilities are implemented in the platform. Representatives from each of the organization’s C offices may also join to keep up to date with progress and ensure the broader organizational strategy is considered.
For organizations that span multiple regions, the advisory board can be a suitable place to involve representatives from each geography. They will ensure that local cultural, regulatory, communication and other requirements are considered in the cloud strategy and help to drive local advocacy of the cloud and the organization’s cloud platform. Additional regional representatives that are more hands-on, such as local security control development, could be placed in the platform & operations core team.
Others that can be considered are an external Cloud SME to boost the cloud experience of the CCoE, HR or Recruitment for attracting new talent, legal, and many others depending on the organization and its use of the cloud.
Evolving the organization
There are three approaches to establishing a Cloud Centre of Excellence.
- Full transformation whereby the organization is restructured, and staff from several existing teams are permanently moved into the CCoE as full-time team members. Moving into the CCoE can often happen together with the applications they are responsible for that have been shortlisted for cloud migration. This reduces the need to hand over responsibilities to other team members. Existing teams will be smaller but still operational for the remaining on-premises applications. This approach is a lot of work, with significant change management and career movements of staff. The stress on staff is around upskilling and getting comfortable in a new role and structure.
- The second option sees team members in existing teams split between their current role and a CCoE role. This can also be a partial CCoE structure that includes only the most essential CCoE roles - a potential option for organizations struggling with resourcing and needing an interim solution. This approach is relatively easy to implement, but change may not be embraced due to the continued existence of the legacy org structure, including silos and a segregated mindset. The stress on staff is around managing what are essentially two jobs, and focus may be a struggle. The day-to-day work in the old team may be prioritized over CCoE actions. Certainly, if the former still has KPIs attached to it.
- A third option is to hire externally. The new CCoE team is populated mostly by new hires, and the legacy structure is retained as-is, focused on-premises. Sometimes this is the only option for organizations with strong resistance to change and upskilling, limited internal mobility, or very little internal cloud competency. However, new hires are not familiar with the organization. While this can be a good way to start fresh and push cultural change, they will struggle due to lacking network and experience within the organization, making it hard to collaborate with teams and gain buy-in for initiatives. There can be resentment from legacy teams who may consider the CCoE a threat to their own jobs, and many valuable lessons learned may be lost to the CCoE.
There are often concerns about how quickly the CCoE needs to be created and if application migrations should start before moving people into the CCoE. This is a bit of a chicken-and-egg situation. Building and training the CCoE faster, ahead of capacity, will provide the organization with a sufficiently sized and capable team to handle the cloud and any workloads that are to be migrated. Such a presence builds trust with application teams and can act as a catalyst. In contrast, if early-moving application teams run into many issues because of insufficient resources and a lack of knowledgeable support from the CCoE, the bad experience can cause cloud adoption to stagnate and ultimately fail.
In general, it can take 3-6 months to design, implement, and train a CCoE with the key roles required to execute a cloud strategy. It can take up to two years to establish a full CCoE capable of supporting hundreds of cloud-based applications.
Figure 2 shows how a simple example of a traditional organization structure (on the left) might evolve into a CCoE approach to cloud management (on the right).
Any existing head of cloud or similar role would become the CCoE’s Cloud Adoption Lead. If a CTO or similar was leading the cloud adoption effort, they should hire or move someone into the CCoE lead role that can be focused exclusively on the CCoE responsibilities.
The CTO or executive leadership might also assign a representative to the Advisory Board.
Teams not explicitly noted in this example but still have an opinion on the cloud, such as marketing or data teams, could have a representative in the Advisory Board.
Depending on the organization’s needs and available resources, the Advisory Board could also include an external cloud subject matter expert.
The PMO involvement typically remains the same. However, some organizations might opt to create a CCoE-specific PMO team within the CCoE.
Technical security engineers could be moved or seconded to Platform Architecture and Operations. Non-technical representatives from this team, such as legal or regulatory compliance, could be placed on the Advisory Board. For the various technical teams involved in the cloud, those previously building and operating infrastructure and components would move to the CCoE’s Platform Architecture and Operations team. Those supporting the application teams with onboarding and implementation would move into the CCoE’s Application Enablement.
Application teams
Lastly, depending on the organization and broader strategies, application teams can be split into three or more teams. While application teams are not part of the CCoE, taking a more dynamic approach will be more effective
Creating specialized application teams that each focus on a different phase of the application lifecycle often works well for organizations as each phase requires different skill sets.
For example:
- A rapid innovation team that is focused on prototyping and new ideas. They need to move fast, iterate through ideas, and be quite independent. This team will benefit considerably from developer enablement and a self-service approach to the cloud.
- A digital transformation team focused on migrating and modernising legacy applications and automating currently manual workflows. This team needs to be equally strong in on-premises legacy architectures and modern cloud architectures. With experience in both, they will be able to migrate and modernize applications to make the most out of what the cloud offers.
- Portfolio teams, each responsible for developing and operating a portfolio of applications. These teams are similar to existing application teams at large organizations. Focused on one or more specific applications and familiar with the deployment and operation of each one. A significant change for these teams is being responsible for provisioning the infrastructure themselves, but they will be well supported by the Application enablement team.
Conclusion
A Cloud Center of Excellence (CCoE) is a critical initiative in successful cloud adoption for large enterprizes. It comprises several teams, including platform architecture and operations, advocacy and education, application enablement, business and product, and an advisory board. Each team has a specific role in the organization’s cloud strategy, from designing and implementing the platform to training and upskilling employees, providing technical support to application teams, and ensuring the cloud aligns with business needs.
There are three approaches to establishing a CCoE, including a full transformation, splitting team members between their current and CCoE roles, and hiring externally. Regardless of the approach, creating a CCoE typically takes three to six months to design, implement and train, and up to two years to establish a full CCoE capable of supporting hundreds of cloud-based applications.
Finally, complementing the CCoE with dynamic application teams that focus on different phases of the application lifecycle often works well for large organizations. By doing so, they can migrate and modernize legacy applications, develop and operate application portfolios, and prototype and innovate new ideas, enabling the organization to get the most out of cloud adoption.
Don't miss out on unlocking the full power of the cloud. for a personalized consultation or to learn more.
