I was brought in to create and lead a brand-new Cloud Center of Excellence – a team that didn’t exist before – inside a global holding with over 5k people across multiple countries. The CCoE team is the central authority for cloud strategy, infrastructure governance, and delivery standards across the entire company. Initially primary cloud was Oracle Cloud Infrastructure, but just in half year we expanded to Amazon AWS, making this a live multi-cloud operation, and we’re now driving the full migration of all applications from aging physical data centers, with geopolitical risk from a location of infrastructure as one of the key drivers.
CCoE from zero
Oracle Cloud (OCI)
OCI + AWS multi-cloud
Geopolitical resilience
5,000+ people
DC migration
24/7 regulated platform
Oracle Cloud (OCI)
OCI + AWS multi-cloud
Geopolitical resilience
5,000+ people
DC migration
24/7 regulated platform
OrganisationGlobal Holding
Scale5,000+ people, multiple countries
CloudOracle Cloud (OCI) + AWS (multi-cloud)
My roleLead / Head of CCoE
StatusSuccessfully completed
5,000+
people across the company
0 → live
CCoE built from nothing
OCI + AWS
multi-cloud in production
24/7
live regulated platform
All teams
CCoE leads company-wide
Published thought leadership: Architecture in an Unstable World – CloudTweaks ·
OCI Multi-Tenancy SSO — pototskyy.net
The Context
The industry: why this is harder than it looks
Regulated industry is a 24/7, high-availability business. Downtime is not a minor inconvenience – it is immediate, measurable revenue loss and a regulatory compliance event. The infrastructure powering odds engines, real-time settlement, and serving real customer requests must be available at all times. Cloud governance in this context is not a background function – it is a safety-critical discipline.
CCoE as company-wide authority
The CCoE was created to help teams use cloud better and to set the standard that all teams follow – on infrastructure governance, cloud architecture, delivery processes, security posture, and cost management. Every engineering team operates within the framework this team defines and enforces. That is a fundamentally different scope from a centre of expertise that teams can optionally consult.
Geopolitical risk is a part of modern architecture decisions
Part of the physical data center infrastructure runs on hardware and facilities in the risky region. The geopolitical risk of this is not theoretical – it is a board-level concern that directly shapes the migration strategy. Moving to cloud is not only about operational efficiency or cost. It is about removing geographic infrastructure concentration risk before it becomes an incident. Architecture decisions must be made with this context as a first-class design input.
The cloud: Oracle Cloud first, multi-cloud now
OCI is the primary cloud. This is unusual – most cloud governance and CCoE literature assumes AWS or Azure. OCI has a different architectural model, different naming conventions, different IAM structure, and different multi-tenancy requirements. Building governance frameworks for OCI from scratch requires OCI expertise, not recycled AWS patterns. Later the company expanded to AWS, making this a live OCI + AWS multi-cloud environment.
What I Did
1
Build and lead the CCoE team – from zero
The team did not exist when I joined. Creating a CCoE from scratch means simultaneously hiring the right people, defining the team’s mandate and scope, establishing authority with other engineering teams across organisation, and delivering real output fast enough to justify the investment. A CCoE that takes 18 months to produce value will lose organisational credibility before it earns it. Early wins – standards published, governance tooling deployed, first migrations delivered – are the mechanism for earning the authority to set standards company-wide.
2
Define and enforce infrastructure governance company-wide
Setting standards for a company is not documentation work – it is organisational change management. Naming conventions, compartment structures, network policies, IAM frameworks, Terraform module standards, tagging strategies, and security baselines all need to be defined, communicated, and adopted by teams who previously operated however they chose. This requires both technical authority and the ability to bring teams along rather than create blockers. OCI-specific: multi-tenancy SSO architecture, IAM compartment design, OCI network topology patterns. AWS-specific: account structure, landing zone, SCPs. Multi-cloud: consistent governance across both providers simultaneously.
3
Drive the physical data center migration to cloud
The CCoE owns the cloud side of migrating all applications from physical data centers. The drivers are both operational – aging infrastructure with increasing maintenance risk, and strategic – removing geopolitical infrastructure concentration risk. This is not an optional modernisation exercise. It is an infrastructure survivability decision. The migration must be sequenced and executed carefully in a 24/7 live platform context, where applications cannot be taken offline, and failures during migration directly impact real users and real money.
4
Build and operate the multi-cloud platform (OCI + AWS)
The expansion to AWS one month ago means the CCoE now manages live infrastructure on two major cloud platforms simultaneously – with different architectural models, different tooling, and different teams consuming them. Multi-cloud governance requires consistent standards applied across both providers: unified Terraform module approach, consistent tagging and cost visibility, comparable security baselines, and integrated monitoring. The complexity of multi-cloud grows non-linearly. Getting governance right from the start, rather than trying to retrofit it later – is exactly the function of a CCoE.
What This Engagement Demonstrates
🏛️
Building a company-wide governance function from nothing – in a regulated industry
A CCoE is not a technical project. It is an organisational construct that changes how an entire company operates its cloud infrastructure. Building it from zero requires creating the team, earning authority with other engineering teams, defining standards that people will follow, and delivering tangible value before the organisation loses patience. In a regulated, 24/7 business where infrastructure directly affects compliance obligations, this needs to be done correctly, not iteratively discovered through failure.
🔮
Oracle Cloud Infrastructure expertise – rare and in demand
Most cloud governance experience in the market is AWS or Azure. OCI is architecturally different – its multi-tenancy model, IAM compartment structure, network topology, and identity federation approach all require genuine expertise, not AWS knowledge repainted in OCI colours. Building governance frameworks for OCI from first principles, solving novel problems like multi-tenancy SAML SSO integration (which I’ve written about in depth), and expanding that into a multi-cloud architecture is a profile the market rarely finds in a single person.
🌍
Geopolitical risk as a first-class architecture input
In our modern world, infrastructure in a geopolitically sensitive location needs to be migrated to cloud before the risk becomes an incident. I have written about this directly in a CloudTweaks article – providing a framework for how architects should think about military, political, and hybrid geopolitical risks, with real incidents from Egypt, Ukraine, and the Middle East as reference points. This experience and published thinking is extremely relevant for any organisation with infrastructure or operations in geopolitically complex regions.
⚡
Cloud governance for a 24/7 platform with zero tolerance for downtime
Governance is not just about cost efficiency and standardisation. Every infrastructure change, every migration step, every new cloud service adoption, and every governance enforcement mechanism must be evaluated against its potential to cause downtime in a live platform. This forces a discipline of risk assessment, change management, and rollback planning that most cloud governance frameworks don’t explicitly address, but that every high-availability regulated platform desperately needs.
📋
Multi-cloud governance built correctly from the start
Most multi-cloud complexity is caused by teams who adopted cloud independently and are now trying to create governance across inconsistent environments. Building OCI governance first, then expanding to AWS within the same governance framework – with consistent naming conventions, Terraform module standards, IAM approaches, and cost visibility – is the architecturally correct way to build multi-cloud. Doing it right from the start avoids years of painful remediation that most organisations eventually face.
Skills This Engagement Evidences
CCoE design and leadership from zero
Created a brand-new Cloud Center of Excellence – team, mandate, governance framework, and organisational authority – in a large company. Built the function that leads all other teams on cloud, not a function that supports them.
Oracle Cloud Infrastructure expertise
Rare OCI-specific depth: multi-tenancy architecture, IAM compartment design, OCI network topology, SAML SSO for multiple tenancies. Published technical article on OCI multi-tenancy SSO. Most cloud governance experience in the market is AWS/Azure only.
Multi-cloud governance (OCI + AWS)
Designing and managing consistent governance across OCI and AWS simultaneously – unified Terraform modules, consistent naming conventions, comparable security baselines, integrated cost visibility. Built correctly from day one, not retrofitted.
Geopolitical risk architecture
Treating geopolitical risk as a first-class architecture input alongside performance, cost, and compliance. Published framework on CloudTweaks. Direct experience in Ukraine banking crisis. Active practitioner on Asia DC migration risk.
High-availability cloud governance – 24/7 platform
Every governance decision evaluated against downtime risk in a live platform. Infrastructure changes, migration steps, and governance enforcement in a zero-tolerance context require different discipline than standard enterprise cloud governance.
Enterprise-wide DC migration leadership
Owning the cloud side of migrating all applications from physical data centers. Sequencing driven by operational risk, geopolitical risk, and platform availability constraints simultaneously – not just technical migration order.
Infrastructure as Code at scale (Terraform / OCI + AWS)
Building reusable Terraform module libraries for OCI and AWS. Establishing IaC as the governance enforcement mechanism – not just a delivery tool. Standardising delivery processes across all engineering teams through automation rather than documentation.
Where This Is Heading – The Challenges Ahead
Multi-cloud cost visibility and FinOps at scale
OCI and AWS have different cost models, different billing structures, and different optimisation strategies. Building unified cost visibility across both providers, and shifting financial accountability to the engineering teams consuming cloud – is a FinOps challenge at significant scale.
Platform engineering model – from CCoE to enabler
The long-term evolution of a CCoE is from a governance authority to a platform engineering function – building self-service infrastructure capabilities that let engineering teams move fast within safe guardrails. The goal is a CCoE that enables speed, not one that creates bottlenecks.
Cloud security for a high-value target
Regulated platforms are high-value targets for fraud, DDoS, and credential attacks. Cloud security governance – identity, network perimeter, secrets management, and incident response – must be built to a higher standard than typical enterprise environments, and maintained continuously against an active threat landscape.
Who This Is Relevant For
You need to build a CCoE, or your existing one isn’t working
Building a CCoE from zero is different from improving an existing one. Creating the team, the mandate, the governance framework, and the organisational credibility simultaneously is a distinct challenge. CCOEs that fail typically do so in the first 18 months – before they’ve earned the authority they were given on paper.
Your primary or secondary cloud is Oracle Cloud
OCI-specific expertise – multi-tenancy architecture, IAM compartments, network topology, identity federation – is rare in the market. If your organisation uses OCI and is struggling to find people who genuinely understand it (rather than people who know AWS and are guessing at OCI), this matters.
You’re managing or planning a multi-cloud environment
Multi-cloud governance that isn’t designed from the start becomes an expensive, complex remediation project. The right time to establish consistent naming, IAM, Terraform, and cost visibility standards across providers is when you’re expanding – not two years later when the mess is already entrenched.
Your infrastructure has geopolitical exposure
Data centers in politically unstable regions, operations in countries with internet shutdown risk, hardware supply chains dependent on specific geographies – these are architecture risks that most organisations don’t have a systematic framework for. Having done this as a live decision, not a theoretical exercise, is the difference.
You run a high-availability platform where downtime is unacceptable
Healthcare, financial services, gaming, e-commerce, critical infrastructure – any platform where downtime is not a SLA number but a compliance event and a direct financial impact. Cloud governance for these environments requires a different quality of risk discipline than standard enterprise IT.
Your board or CTO needs cloud transformation to be a strategic capability, not a project
A cloud transformation project has an end date. A cloud transformation capability does not. Building the CCoE as a permanent function that evolves alongside the business – covering AI/ML, FinOps, regulatory changes, new cloud services, and new providers – is the difference between a one-off migration and a lasting competitive advantage.
Building a CCoE, managing a complex multi-cloud, or navigating a major cloud transformation?
In 30 minutes I can tell you whether your situation maps to what I do – what the real governance and architecture challenges are in your specific context, and what the first concrete steps look like.
No pitch. A direct conversation about your cloud transformation, its constraints, and where the complexity actually lives.