GCP Cloud Adoption Framework: Operating Model & Epics — Designing the Cloud Operating Model, the Epic Backlog as Your Execution Engine, and Wiring It Into the Landing Zone & Enterprise Foundations Blueprint

In a nutshell

A cloud operating model is the answer to a deceptively simple question: now that we have Google Cloud, who does what, who decides what, and who pays for what? It is the organizational machine — the teams, their decision rights, the funding flows, and the way one team serves another — that runs the cloud day after day. Google’s Cloud Adoption Framework (CAF) spends parts 1–5 scoring how ready you are across four themes (Learn, Lead, Scale, Secure). This part, part 6, is where that score becomes a machine that can actually run: an operating model plus a sequenced epic backlog of work, wired down into a real, deployed landing zone.

Here is the analogy that makes it click. Think of a serviced office building (a co-working space). The building operator provides the wired desks, the meeting rooms, the WiFi, the security badges, the cleaning, and the fire-safety systems — a ready-to-use, safe environment you just move into. Each company renting a floor runs its own business however it likes inside the building’s rules: they don’t lay their own electrical wiring or install their own fire alarms. There’s a short house-rules document (who’s allowed to do what), and rent is split by the desks each company actually uses. In this picture the platform team is the building operator, the product teams are the companies renting floors, the paved road is the wired-and-ready desk, the decision rights are the house rules, and chargeback is the per-desk rent. A mature cloud operating model is exactly this: a small platform team ships a safe, self-service, opinionated environment, and product teams move in and build with real autonomy inside guardrails they didn’t have to invent.

Why should a beginner care? Because this is the difference between a cloud that gets faster as it grows and one that seizes up. The same Google Cloud, with the same engineers, produces either a smooth self-service platform or a three-week-ticket bottleneck — and the only variable is the operating model. Get it right and “secure by default” and “fast by default” become the same default instead of a trade-off.

Level: Intermediate → Advanced · Time: ~45 min · This is part 6 of the Google Cloud Adoption Framework series; it stands on the four themes but is written so a newcomer to operating models can follow every step.

Read the diagram left → right: a sponsor and a Cloud Center of Excellence charter the model; a decision-rights RACI says what the platform team mandates, recommends, or delegates; the platform team encodes the mandated guardrails as Cloud IAM and Organization Policy and ships a self-service paved road; product teams build with autonomy inside it; and a funding/showback loop plus a versioned maturity scorecard keep the machine durable as it matures Tactical → Strategic → Transformational.

Before you start

What to know first. This part assumes you have met the framework’s vocabulary in the earlier lessons. If any of the terms below feel unfamiliar, skim these siblings first:

• The four themes and three phases — CAF overview.
• Sponsorship, governance, and the Cloud Center of Excellence — the Lead theme, which this part turns into a standing machine.
• Productizing the platform and paved roads — the Scale theme.
• How the resource hierarchy and Organization Policy actually enforce guardrails — resource hierarchy & org-policy guardrails.

You do not need to have built a landing zone yet; this part is where you decide how to build one.

After this lesson you will be able to:

• Name and choose an operating-model archetype (centralized, decentralized, federated, platform + paved road) for a given estate, and justify it.
• Design a team topology — platform team, stream-aligned product teams, and the CCoE as an enabling team — and explain how it maps onto Google Cloud.
• Write a decision-rights RACI that classifies each decision as mandate / recommend / delegate, and encode the mandated ones as Cloud IAM (Groups at folders) and Organization Policy constraints rather than as prose.
• Design the funding model — showback vs chargeback — with a label taxonomy and BigQuery billing export.
• Sequence an epic backlog with five mandatory attributes and a dependency graph, and connect the foundational epics to the enterprise foundations blueprint layers.
• Describe how each dimension of the operating model matures Tactical → Strategic → Transformational, and evidence the movement in a versioned scorecard.

Where this fits

Parts 1–5 of this series built the diagnostic half of Google’s Cloud Adoption Framework: the four themes (Learn, Lead, Scale, Secure), the three maturity phases (Tactical, Strategic, Transformational), and an honest, scored assessment of where your organization sits on each. This article is part 6 — the synthesis-and-execution capstone that turns that scored picture into something an enterprise can actually run. Two artifacts do that work: the operating model (who owns what, how decisions are made, how product teams pull from a platform team) and the epic backlog (the sequenced, ownable program of work that moves the gating themes up a phase). The third thing this part nails down is the hand-off most programs fumble — how the operating model and the foundational epics translate into a concrete, deployed Google Cloud landing zone built on the enterprise foundations blueprint and the Cloud Foundation Toolkit. Get this part right and the framework stops being a slide deck and becomes a funded roadmap landing real resource hierarchy, Shared VPC, and Organization Policy into your organization resource; skip it and you have four theme scores and no machine to act on them.

Designing the cloud operating model

What it is. The cloud operating model is the organizational machine that runs Google Cloud day to day: the set of teams, their decision rights, the funding and accountability flows, and — above all — the interaction pattern between the people who build the platform and the people who build products on it. Google’s CAF measures readiness across four themes, but those themes only become durable if there is a standing operating model that owns them. The operating model answers the questions a scorecard cannot: Who owns the resource hierarchy? Who can change an Organization Policy? When a product team needs a new project, do they file a ticket or push a button? Who pays for the shared VPC? Who is accountable when Security Command Center flags a misconfiguration? It is the connective tissue between the Lead theme (sponsorship and the cross-functional team) and the Scale/Secure themes (the platform and guardrails those teams operate).

Why it matters. Two organizations with identical theme scores can have wildly different outcomes, and the difference is almost always the operating model. The classic failure is the central-IT bottleneck: a well-meaning platform team that insists on hand-building every project and approving every firewall rule, which throttles adoption until product teams route around it into shadow IT. The opposite failure is the anarchy of full delegation: every team gets Owner on its own projects, invents its own networking, and the security posture fragments into a hundred snowflakes that no one can audit. Google’s CAF treats the mature answer as a platform-and-paved-road model — a small platform team (often the Cloud Center of Excellence) that ships self-service, opinionated, guardrailed building blocks, and product teams that consume them with autonomy inside those guardrails. The operating model is what makes “secure by default” and “fast by default” the same default rather than a trade-off.

How to do it well. Pick an operating-model archetype deliberately, then encode it in the resource hierarchy and IAM rather than in a wiki page. The decisions that matter:

• Choose the team topology. The dominant pattern is a Platform team (owns the landing zone, paved roads, guardrails, FinOps tooling, shared networking) serving many Stream-aligned product teams (own their workloads end to end inside the guardrails), with the CCoE acting as the enabling team that sets standards and diffuses skills. This is Team Topologies mapped onto Google Cloud, and it is the topology the enterprise foundations blueprint quietly assumes.
• Define decision rights explicitly. Write down, per decision class, whether the platform team mandates, recommends, or delegates. Org-wide guardrails (Organization Policy constraints, the IAM baseline, the network perimeter) are mandated; application architecture inside a project is delegated; the choice of database is recommended-with-guardrails. Ambiguity here is the single most common reason a platform team is either ignored or resented.
• Encode the model in the hierarchy, not in prose. The operating model becomes real when it is expressed as Organization → Folders → Projects with IAM inherited at the right level, Organization Policy constraints set at the org and folder nodes, and Shared VPC host projects owned by the platform team. Where a Group (from Cloud Identity) is granted a role at which folder is the operating model.
• Decide the funding and showback flow. Who owns the billing account(s), how costs are attributed back to teams (labels + BigQuery billing export), and whether the platform is a cost centre or a charged-back internal product. FinOps is an operating-model decision before it is a tooling one.
• Define the platform/product contract. The platform team’s deliverable is a catalog of self-service building blocks (project vending, network attachment, baseline observability, golden CI/CD) with published SLAs and an intake for anything not yet self-service. The product team’s obligation is to consume the paved road and stay inside the guardrails.

The operating-model archetypes compared:

Artifacts, decisions, and Google Cloud tooling. The artifacts are an operating-model design document (the chosen archetype, team topology, and the platform/product contract), a RACI / decision-rights matrix mapping each decision class to mandate/recommend/delegate, the resource-hierarchy design (folder structure, project naming, IAM inheritance plan), and a FinOps model (billing-account structure, label taxonomy, showback/chargeback policy). The Google Cloud tooling that operationalizes the model is the resource hierarchy itself (organization, folders, projects), Cloud Identity / Google Workspace Groups for role assignment, Cloud IAM (custom roles, least privilege, IAM Conditions), Organization Policy Service for the mandated guardrails, Shared VPC for the platform-owned network, Cloud Billing with BigQuery billing export and Budgets & alerts for the FinOps flow, and Service Catalog / a project factory for the self-service vending that makes the paved-road archetype real.

Team topologies for the cloud operating model

The archetype table above tells you how much to centralize; team topologies tell you which teams to actually staff and how they should talk to each other. This is where the operating model stops being an abstraction and becomes an org chart you can hire against. The framing comes from Team Topologies (Skelton & Pais), and it maps almost one-to-one onto Google Cloud.

The four fundamental team types.

The three interaction modes are just as important as the team types, because most operating-model dysfunction is really a broken interaction:

• X-as-a-Service — the platform team offers projects, networks, and pipelines as a service; product teams consume them with minimal conversation. This is the steady state you are aiming for, and the project factory is what makes it possible.
• Collaboration — high-bandwidth, temporary pairing when something new is being figured out (e.g. the platform team and a squad co-designing the first GKE paved road). Deliberately time-boxed: collaboration is expensive and should converge into an as-a-service offering.
• Facilitating — the enabling team (CCoE) coaches a stream-aligned team over a fixed period to lift a capability, then withdraws.

The Cloud Center of Excellence, precisely. The single most misunderstood box in the whole model. A CCoE is an enabling team, not an operations team. Its job is to set standards, build the first golden paths, diffuse skills across the organization, and then deliberately work itself out of a job — handing steady-state ownership to the platform team and the product teams. Concretely, on Google Cloud the CCoE authors the first version of the paved road (the project-factory modules, the Organization Policy baseline, the reference architectures), runs the enablement and certification program, and chairs the standards forum — but it should not be the standing owner of every production project forever. When a CCoE never withdraws, it silently becomes the central-IT bottleneck under a nicer name. The clean pattern in a mature org: the CCoE incubates the platform, the platform team productizes and runs it, and the product teams consume it. In smaller organizations one small group may wear all three hats early on — that is fine, provided the interaction modes are still explicit and the group is consciously trying to move work into the as-a-service column.

Conway’s Law is the hidden force here. Systems mirror the communication structures of the organizations that build them, so your resource hierarchy will end up shaped like your org chart whether you plan it or not. The mature move is the Inverse Conway Maneuver: design the team topology you want (small platform team, autonomous product teams), and let the Google Cloud folder/project structure and IAM boundaries follow that topology deliberately, rather than accreting a hierarchy that fossilizes yesterday’s org chart.

Decision rights and the RACI

“Define decision rights explicitly” is the bullet that programs nod at and then skip — and it is the one that decides whether the platform team is ignored (too little authority) or resented (too much). The tool is a decision-rights matrix: for every recurring decision class, record who is Responsible (does the work), who is Accountable (the single owner who signs off — exactly one per row), who is Consulted, and who is Informed — and, crucially, whether the platform team mandates, recommends, or delegates that class.

• Mandate — org-wide, non-negotiable, uniform. Kept deliberately small: the network perimeter, the IAM baseline, the Organization Policy set, data-residency regions, CMEK for regulated data. If everything is mandated, you have rebuilt central IT.
• Recommend — a strong default with an escape hatch. “Use Cloud SQL for relational unless you can justify otherwise.” Recommendations come with guardrails, so an exception is still safe.
• Delegate — the product team’s own call. Application architecture inside a project, service boundaries, most managed-service choices. Delegation is where autonomy lives; protect it fiercely.

A worked decision-rights matrix for a platform + paved-road org:

The discipline that makes this real: every “Mandate” row must have a matching control in configuration. A mandate that isn’t an actual Organization Policy constraint or IAM binding is an aspiration, and drift will erase it. For example, encoding the mandated data-residency and Groups-at-folder rows looks like:

# Grant a Cloud Identity GROUP (never an individual) at the FOLDER node,
# so every project born under that folder inherits the binding.
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
  --member="group:gcp-prod-platform-admins@example.com" \
  --role="roles/resourcemanager.folderAdmin"

# Mandate data residency as an Organization Policy v2 constraint at the org node.
# policy.yaml:
#   name: organizations/ORG_ID/policies/gcp.resourceLocations
#   spec:
#     rules:
#       - values:
#           allowedValues:
#             - in:europe-west2-locations
#             - in:europe-west1-locations
gcloud org-policies set-policy policy.yaml

Now the RACI row and the running configuration are the same object: change the mandate, change the policy; audit the policy, audit the mandate.

Funding the platform: showback, chargeback, and the FinOps operating model

Who pays for the Shared VPC, the logging project, the Security Command Center subscription, and the platform team’s time? “Funding is an operating-model decision before it is a tooling one” — decide it wrong and the platform is starved, over-built, or politically resented. There is a maturity ladder here, and most enterprises should climb it in order rather than jump to the top:

Showback before chargeback is the near-universal right sequence. Chargeback without accurate, trusted attribution just moves the argument from “the cloud is too expensive” to “your numbers are wrong,” and it can perversely incentivize teams to abandon the paved road to dodge a shared-cost allocation. Show the numbers first, let teams optimize against a bill they can see but don’t yet pay, then switch on chargeback once the attribution is trusted.

The attribution machinery is the same regardless of model, and it is a foundation concern, so mandate it early:

• A label taxonomy, mandated and enforced — e.g. cost-centre, bu, env, app, owner. Labels that aren’t mandated are never applied, so tie them to the paved road (the project factory stamps them) and to Organization Policy where possible.
• BigQuery billing export turned on at the billing account, so every line item is queryable and joinable to the label taxonomy. This is the system of record for both showback dashboards and chargeback invoices.
• Budgets & alerts per project/folder/BU, plus Active Assist / Recommender for rightsizing and idle-resource findings that give teams something actionable to do with the showback they see.

# A per-BU budget with threshold alerts, tied to the billing account.
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="bu-diagnostics-monthly" \
  --budget-amount=25000GBP \
  --filter-labels=bu=diagnostics \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

The subtle part is shared and unallocated cost: the Shared VPC, the logging sink project, org-wide SCC, and the platform team’s own projects don’t belong to any one product team. Decide the allocation rule up front — split platform cost evenly, by consumption, or absorb it centrally — and publish it, because an opaque “platform tax” is the fastest way to lose the product teams’ trust in the whole model.

How the operating model matures: Tactical → Strategic → Transformational

The four themes each mature along Google’s three phases, but so does the operating model as a whole — and it is worth reading the model dimension by dimension, because a program is usually at different phases on different dimensions at once. The point of the CAF phases here is diagnostic: find the dimension that is lagging and holding the others back, and make that the next epic.

Two things make this table more than a poster. First, the gating dimension is the one to fund next — the dimension that is both low and blocking others. A team stuck Tactical on guardrails cannot safely move provisioning to Strategic, because self-service without enforced Organization Policy is just faster sprawl. Second, maturity must be evidenced, not asserted. “We’re Strategic on funding” should mean there is a showback dashboard built on BigQuery billing export with a mandated label taxonomy, not we talked about FinOps. Version the scorecard over time so each phase movement is a re-assessable, evidenced change — which is exactly how the epic backlog (next) ties its definitions of done back to the model.

The epics as a work backlog

What it is. Epics are how Google’s CAF converts a scored assessment and a chosen operating model into work that can be funded, staffed, sequenced, and finished. An epic is a discrete, outcome-oriented body of work that advances one or more themes toward a higher maturity phase — the framework’s unit of execution. Where part 1 introduced epics as a concept, this part treats the backlog as a managed, living instrument: a prioritized, dependency-aware queue of epics that the steering committee funds iteration by iteration, each epic decomposing into the engineering-level user stories and workstreams that teams actually pick up in a sprint. The backlog is the bridge between “you are Tactical on Secure” (a finding) and “this quarter we deploy org-wide guardrails and reach Strategic on Secure” (a plan with an owner, a budget, and a definition of done).

Why it matters. The chasm where cloud programs die is between assessment and action, and the epic backlog is the only thing that spans it. A scorecard with no backlog is an opinion; a pile of recommendations with no sequencing is a recipe for doing the exciting epics (analytics, AI, self-service) before the foundational ones (resource hierarchy, identity, landing zone, guardrails) and discovering nine months in that nothing rests on solid ground. A well-run backlog imposes three disciplines the framework depends on: prioritization (fund the epics that move the gating theme — the one that is both low-scoring and blocking a priority outcome), sequencing by dependency (you cannot vend self-service projects before the project factory exists, which cannot exist before the resource hierarchy and IAM baseline exist), and traceability (every epic answers “why are we doing this?” with “to move theme X from phase A to phase B, which unblocks the outcome that executive Y owns”). The backlog is also what keeps the program funded: a steering committee will keep paying for work it can see advancing on a board with measurable definitions of done.

How to do it well. Write and run the backlog with these rules:

• Give every epic five mandatory attributes. (1) The theme(s) and target phase it advances; (2) a single accountable owner and the executive sponsor; (3) explicit dependencies on other epics; (4) a definition of done expressed as a re-assessable change in maturity — “moved Secure to Strategic, evidenced in Security Command Center,” not “ran a security workshop”; (5) the Google Cloud building blocks it deploys.
• Sequence by dependency and leverage, not by excitement. Foundational epics unblock almost everything and must come first even though they demo poorly. The canonical dependency chain on Google Cloud runs: resource hierarchy & identity → landing zone foundation → org-wide guardrails → networking & connectivity → self-service vending → migration waves → analytics/AI platform. Drawing this as a dependency graph is the most valuable hour the program office will spend.
• Keep the active set small. A handful of in-flight epics per iteration that move the gating theme, not twenty launched in parallel and none finished. Work-in-progress limits apply to programs, not just sprints.
• Map epics to themes and to the Architecture Framework. The CAF epic “harden the platform” decomposes into work that should satisfy the Google Cloud Architecture Framework pillars (operational excellence, security, reliability, cost optimization, performance). Use the Architecture Framework as the acceptance criteria for the technical epics.
• Track it where the program already lives. Jira, GitLab/GitHub issues, or Google Cloud’s own delivery tooling — the tool matters far less than the discipline of the five attributes and the dependency graph being kept current.

A representative epic backlog, in roughly the order dependency forces, with the operating-model and foundation linkage made explicit:

Artifacts, decisions, and tooling. The artifacts are the epic backlog (each epic carrying the five mandatory attributes), the dependency graph that fixes the sequence, the iteration/roadmap plan (which epics this quarter, gated by dependency and gating theme), and the definition-of-done register that ties each completion to a re-assessable maturity change. The decision the backlog drives is the entire sequenced program; the most consequential single decision is placing the foundational epics (1–5 above) ahead of the headline epics (analytics, AI, self-service) because every later epic stands on them. The tooling is the program-management system of record plus the maturity scorecard versioned over time, so each “done” epic can be evidenced as a phase movement rather than an activity.

How the framework connects to the landing zone and foundation setup

What it is. This is the hand-off the rest of the framework exists to produce: the point where the operating model and the foundational epics become a deployed Google Cloud landing zone — a secure, scalable, well-governed environment built from Google’s enterprise foundations blueprint and instantiated with the Cloud Foundation Toolkit and Terraform. The CAF tells you whether you are ready and what to build first; the landing zone is what gets built. Concretely, the foundational epics (resource hierarchy, identity, guardrails, networking) are not abstract — each one maps onto a specific layer of Google’s reference foundation, so the epic “deploy the landing zone foundation” is literally “run the enterprise foundations blueprint, parameterized to our operating-model decisions.” This section is where Google’s CAF (the readiness framework) shakes hands with the Google Cloud Architecture Framework (the design framework) and the enterprise foundations blueprint (the reference implementation).

Why it matters. The most expensive mistake in a Google Cloud program is building the foundation by hand, inconsistently, before the operating model is decided — because the foundation is the one thing you cannot cheaply re-do later. Get the resource hierarchy or the network topology wrong and you are re-parenting projects and re-IP-ing VPCs a year in, with production on top. The CAF prevents this by forcing the operating-model decisions (team topology, decision rights, isolation strategy, network model, FinOps) to be made before the foundation is laid, so the landing zone encodes the right answers from day one. Equally, the enterprise foundations blueprint prevents the opposite failure — re-deriving from scratch what Google has already distilled into an opinionated, auditable, Terraform-delivered reference that bakes in the security and reliability the Architecture Framework demands. The connection runs both ways: the CAF assessment parameterizes the blueprint (your org structure, your perimeter, your folders), and the blueprint operationalizes the foundational epics (it is the deliverable for epics 2–5 above).

How to do it well. Treat the landing zone as the materialization of your operating model, layer by layer, delivered as code:

• Use the enterprise foundations blueprint as the spine, not from-scratch IaC. Google’s blueprint defines the canonical layering — the bootstrap (org-level Terraform state, seed project, CI/CD for the foundation itself), the organization layer (folder hierarchy, org policies, baseline IAM), the environments layer (dev/non-prod/prod folders and projects), the networking layer (Shared VPC, hybrid connectivity, DNS, firewall policy), and the project/app layer. Each layer maps to a foundational epic.
• Deliver it with the Cloud Foundation Toolkit and Terraform. The Cloud Foundation Toolkit (CFT) publishes the production-grade Terraform Google modules (project factory, networking, org policy, logging, IAM) that implement the blueprint. Manage foundation state and drift with CI/CD; for teams who want Google-managed reconciliation, Config Controller (KRM/Config Connector) provisions and continuously reconciles GCP resources from declarative config. Mature alternatives such as Fabric / FAST exist for teams wanting a more modular, end-to-end opinionated foundation.
• Encode every operating-model decision as a foundation parameter. The folder structure is your team topology; the org-policy set is your mandated guardrails; the Shared VPC host-project ownership is your network decision-right; the label taxonomy is your FinOps model. There should be a traceable line from each row of your decision-rights matrix to a parameter in the foundation code.
• Bake in the security and observability baseline at the foundation layer. Security Command Center enabled at the org, VPC Service Controls perimeters around sensitive data, Cloud KMS / CMEK where required, centralized Cloud Logging sinks to a logging project, Organization Policy constraints (disable default network, restrict external IPs, restrict service-account key creation, enforce CMEK, restrict resource locations for data residency). These are foundation concerns, not per-app afterthoughts.
• Make the foundation the substrate for self-service. Once the foundation is live, the “self-service vending” epic adds the project factory and Service Catalog on top of it, so product teams provision compliant environments by button rather than ticket — closing the loop back to the paved-road operating model.

How the foundational epics map onto the enterprise foundations blueprint layers and the tooling:

Artifacts, decisions, and tooling. The artifacts are the landing-zone design document (the blueprint parameterized to your operating-model decisions, layer by layer), the foundation Terraform repository (bootstrap, org, environments, networking, projects — with CI/CD), the org-policy and IAM baseline as code, the network topology design (Shared VPC, address plan, connectivity), and the security/observability baseline (SCC, VPC-SC perimeters, logging-sink architecture, CMEK policy). The headline decision is the isolation and network model — single vs multiple host projects, the dev/non-prod/prod folder split, and the hybrid-connectivity topology — because it is the most expensive thing to change after the fact. The tooling is the enterprise foundations blueprint as the reference, the Cloud Foundation Toolkit / Terraform Google modules (or Fabric FAST, or Config Controller) as the delivery engine, and the Google Cloud Architecture Framework as the acceptance standard the deployed foundation must satisfy.

Real-world enterprise scenario

Northwind Pathology is a fictional but realistic clinical-diagnostics network: ~7,500 staff across 40 lab sites in the UK and Ireland, a regulated estate (UK GDPR, NHS DSP Toolkit, ISO 27001), one datacenter on a lease expiring in 16 months, and a board mandate to consolidate a sprawl of lab-information-system data into a single analytics platform that can power AI-assisted reporting. Parts 1–5 of their CAF journey left them with a clear, lumpy scorecard — Strategic on Scale (a strong engineering group already running GKE), but Tactical on Lead, Secure, and Learn — and a clear gating theme: Secure is blocking everything, because clinical data cannot move until guardrails and a perimeter exist. Their principal architect, Aoife, runs part 6 to turn that into an operating model, a backlog, and a deployed foundation.

Designing the operating model. Northwind chooses the platform + paved-road archetype with a federated twist: a central Platform team (8 engineers, the home of the CCoE) owns the landing zone, guardrails, Shared VPC, and FinOps; each of three clinical business units gets a stream-aligned squad that owns its workloads inside the guardrails. Decision rights are written down explicitly: the Platform team mandates the org-policy set, the IAM baseline, the network perimeter, and CMEK; recommends managed-service choices; and delegates application architecture inside a project. The model is encoded in the hierarchy — an Organization with folders for bootstrap, common (logging, security, network host projects), and dev / non-prod / prod, each with a per-BU sub-folder — and IAM is granted to Cloud Identity Groups at the folder level, never to individuals. FinOps is decided as showback first, chargeback by year two, attributed via a mandated cost-centre / bu / env label taxonomy and BigQuery billing export. The artifacts: an operating-model design doc, a decision-rights RACI, the resource-hierarchy design, and the FinOps model.

The epic backlog. Aoife sequences the backlog by dependency, foundational epics first, with Secure (the gating theme) front-loaded:

Connecting to the landing zone and foundation. Epic 3 is delivered as the enterprise foundations blueprint parameterized to Northwind’s decisions and instantiated with the Cloud Foundation Toolkit Terraform modules: the bootstrap layer holds org-level state in a seed project with its own CI/CD; the organization layer applies the org-policy set (disable default network, restrict external IPs, restrict service-account key creation, enforce CMEK, restrict resource locations to europe-west2/europe-west1 for data residency) and the Groups-based IAM baseline; the environments layer lays down the dev/non-prod/prod folders with per-BU sub-folders; and the networking layer (epic 5) deploys Shared VPC host projects in common, HA VPN then Cloud Interconnect to the datacenter, Cloud NAT, Cloud DNS, and the VPC Service Controls perimeter (epic 4) that rings the clinical-data projects so BigQuery and Cloud Storage cannot be reached from outside the perimeter. Security Command Center Premium is enabled at the org, Cloud KMS CMEK is mandated for clinical data, and centralized Cloud Logging sinks land in a logging project in common. Every one of these is a parameter traceable back to a row in the decision-rights matrix. Once the foundation is live, epic 8 adds the project factory and Service Catalog on top, so the three BU squads provision compliant projects by button — the paved road closing the loop back to the operating model.

The measurable outcome. Thirteen months later Northwind re-assesses. Secure reaches Strategic — org-wide guardrails enforced and evidenced in Security Command Center, a VPC-SC perimeter around all clinical data, CMEK on every regulated bucket, and a clean NHS DSP Toolkit submission citing the foundation as evidence. Lead reaches Strategic (funded Platform team/CCoE, COO-chaired steering, signed RACI). Scale reaches Strategic with the landing zone live, the first two LIS workloads migrated, the datacenter-exit on track for the lease deadline, and 74% of new projects provisioned through the project factory rather than by hand. The clinical analytics platform on BigQuery + Dataplex + Vertex AI goes live inside the perimeter and begins powering AI-assisted draft reporting — a Transformational capability on the Scale theme that the board is now funding as a product line. The scorecard that started spiky and Tactical on three themes is balanced and a phase higher, and — the part that matters to an auditor — every control is evidenced in a tool, not asserted in a slide.

Going deeper

For the experienced reader, the operating model is where organizational design and Google Cloud primitives fuse. A few advanced nuances separate a model that survives contact with reality from one that looks good on a slide.

Encode decision rights with precision, not just folder IAM. Mandate/recommend/delegate is a coarse instrument; Google Cloud gives you finer ones for the hard cases:

• IAM Conditions let a mandate be contextual — grant roles/container.developer only when the target resource carries the prod environment tag, so the same Group is powerful in one context and constrained in another:

  gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
    --member="group:gcp-prod-deployers@example.com" \
    --role="roles/container.developer" \
    --condition='expression=resource.matchTag("ORG_ID/environment", "prod"),title=prod-only,description=Only on prod-tagged resources'
  

• IAM deny policies express a mandate as a hard “no one, not even an Owner” — the cleanest way to encode a non-negotiable (e.g. nobody may create service-account keys) that an over-privileged role would otherwise permit.

• Organization Policy custom constraints cover the mandates the built-in constraint catalog misses, letting you write a CEL predicate against a resource’s own fields (e.g. require a specific label, forbid a machine family) and enforce it org-wide.

Roll guardrails out in dry-run before you enforce. The scariest moment in the operating model is switching on a mandate across thousands of existing projects. Organization Policy supports a dry-run mode — a dryRunSpec on the policy (or dry-run enforcement in the console) — so a constraint’s violations are logged without blocking anything. You watch the audit logs, find the workloads that would break, remediate them, and only then promote the same rule to live spec. Treat every new mandated constraint as dry-run → observe → enforce; skipping the dry run is how a well-intentioned guardrail causes an outage.

Policy-as-code and drift are what make maturity real. A mandate encoded once and never checked degrades silently. Mature orgs run the guardrails as code with continuous reconciliation: Config Controller / Config Connector to provision and re-converge GCP resources from declarative KRM; Policy Controller (Gatekeeper/OPA) to block non-compliant config at admission time on GKE; and Security Command Center posture management to detect drift from the intended baseline. Terraform in CI is the source of truth for the foundation; a nightly plan that shows drift is your early-warning that someone changed a mandate by hand. The operating-model dimension “guardrails: Transformational” means exactly this — admission-time enforcement plus drift detection, not a review board.

Treat the platform as a product, and measure it. The difference between a platform team and central IT under a new name is whether the platform has customers, a roadmap, and metrics. Track adoption of the paved road (what % of new projects come through the factory — Northwind’s 74%), lead time to provision a compliant environment, DORA metrics for the golden CI/CD, and support-ticket volume (which should fall as self-service rises). If paved-road adoption is flat, the road isn’t paved well enough — the fix is product work, not a mandate forcing teams onto a bad path.

Mind cognitive load and the thinnest viable platform. Team Topologies’ core insight is that the platform exists to reduce the cognitive load on stream-aligned teams. That implies a discipline: build the thinnest viable platform that removes the most load, and resist gold-plating. A platform team that ships everything imaginable becomes a bottleneck of a different kind — a huge surface no small team can run. Keep the platform team small and senior precisely so it is forced to prioritize the highest-leverage paved roads.

Federation without a second bottleneck. The federated/hub-and-spoke archetype is powerful for multi-BU enterprises but has a failure mode: each BU sub-platform quietly re-creates the central-IT bottleneck at BU scale. The mature pattern keeps the mandated guardrails (org policy, IAM baseline, perimeter) strictly central and non-negotiable, while genuinely delegating the recommended and delegated classes to BU sub-platforms — so autonomy is real but the org-wide invariants still hold. When two BUs must interoperate, define an explicit contract (shared VPC attachment, a published API, a data-exchange perimeter bridge) rather than letting one BU reach into another’s projects.

Know the hard edges of the hierarchy. Some operating-model decisions are expensive precisely because Google Cloud makes them sticky: the folder hierarchy is limited in depth (up to 10 levels) and you cannot re-parent an Organization; projects can be moved between folders but re-parenting a live estate is disruptive; and Organization Policy inheritance has real merge semantics (inheritFromParent, reset, and allow/deny value merging) that you must reason about deliberately — a child folder can loosen or tighten an inherited constraint in ways that surprise people. When strict isolation is a hard requirement (M&A, a regulated ring-fence, a sovereign boundary), the right primitive is sometimes a second Organization rather than a folder, accepting the cost of cross-org identity and billing federation. These are the “measure twice, cut once” decisions the CAF wants made before the foundation is laid — because they are the ones you cannot cheaply undo.

Deliverables & checklist

By the end of the Operating Model & Epics phase you should have produced:

• An operating-model design document: chosen archetype (platform + paved road / federated), team topology (platform, stream-aligned, enabling/CCoE), and the platform/product contract.
• A decision-rights RACI mapping each decision class to mandate / recommend / delegate.
• A resource-hierarchy design: folder structure, project naming, and the IAM-inheritance plan (Groups granted at folder level, no individual Owner).
• A FinOps model: billing-account structure, label taxonomy, and showback/chargeback policy with BigQuery billing export.
• A prioritized, dependency-aware epic backlog, each epic carrying theme tags, target phase, a single owner, an executive sponsor, dependencies, and a re-assessable definition of done.
• A dependency graph fixing the foundational epics (hierarchy → foundation → guardrails → networking → vending) ahead of the headline epics.
• An iteration / roadmap plan sequencing epics by dependency and gating theme, with a small in-flight set.
• A landing-zone design document: the enterprise foundations blueprint parameterized to your operating-model decisions, layer by layer.
• A foundation Terraform repository (bootstrap, org, environments, networking, projects) delivered via the Cloud Foundation Toolkit, with CI/CD and drift management.
• An org-policy + IAM baseline as code, a network topology design (Shared VPC, address plan, hybrid connectivity), and a security/observability baseline (SCC, VPC-SC perimeters, logging sinks, CMEK policy).
• A traceability map from each decision-rights row to a foundation parameter.

Common pitfalls

1. Laying the foundation before deciding the operating model. Hand-building the resource hierarchy and network “to get moving,” then discovering the team topology or isolation strategy demands a different shape — and re-parenting projects with production on top. Avoid it by making the operating-model decisions (topology, decision rights, isolation, network, FinOps) explicit before the foundation, and encoding each as a foundation parameter.
2. The central-IT bottleneck. A platform team that insists on hand-building every project and approving every firewall rule throttles adoption until product teams route around it into shadow IT. Avoid it by shipping self-service paved-road assets (project factory, Service Catalog, golden Terraform) so the compliant path is the fast path, and measuring paved-road adoption %.
3. Epics whose “done” is an activity, not a maturity change. “Ran a security workshop” is an activity; “moved Secure to Strategic, evidenced in Security Command Center” is an outcome. Avoid it by writing every epic’s definition of done as a re-assessable phase change tied to an owner and sponsor.
4. Sequencing by excitement instead of dependency. Launching the analytics/AI or self-service epics before the resource hierarchy, identity, and guardrails exist builds a penthouse with no building under it. Avoid it by drawing the dependency graph and front-loading the foundational epics, even though they demo poorly.
5. Re-deriving the foundation from scratch. Writing bespoke Terraform that re-invents what the enterprise foundations blueprint already distils — and missing the security and reliability defaults Google has baked in. Avoid it by starting from the blueprint and the Cloud Foundation Toolkit (or Fabric FAST), parameterized to your decisions, and using the Architecture Framework as the acceptance standard.
6. An operating model that lives in a wiki, not in IAM and Org Policy. A decision-rights document nobody enforces is fiction; if “mandated” guardrails are not actually set as Organization Policy constraints, they are aspirations. Avoid it by encoding the model in the hierarchy, IAM (Groups at folders), and Organization Policy — so the model is the configuration, and drift is detectable.

Practice challenges

Work these in order — they climb from reading a symptom to designing a rollout. Try each before opening the solution.

1. (Beginner) Name the anti-pattern and the target. A product team complains that every new project takes three weeks because the central team hand-builds and approves each one. Name the operating-model anti-pattern and the archetype they should move toward. <details><summary>Solution</summary>

   The anti-pattern is the central-IT bottleneck (over-centralized, ticket-driven). The target is the platform + paved-road archetype: a small platform team ships self-service, guardrailed project vending so a compliant project is created in minutes.

   Why: the fix is to make the compliant path the fast path, not to add more approvers. </details>

2. (Beginner) Classify three decisions. For a platform + paved-road org, classify each as mandate, recommend, or delegate: (a) the data-residency region for regulated data; (b) which NoSQL database a team uses; © the microservice boundaries inside a team’s own project. <details><summary>Solution</summary>

   (a) Mandate — data residency is an org-wide, non-negotiable guardrail (gcp.resourceLocations). (b) Recommend — a strong default with guardrails and an escape hatch. © Delegate — in-project application architecture is the product team’s own call.

   Why: mandate the few org-wide invariants; delegate everything that is safely a team’s own concern; recommend the middle. </details>

3. (Intermediate) Grant at the right level. Write the gcloud that grants the group gcp-network-admins@example.com the roles/compute.networkAdmin role on folder folders/223344556677, and state why you grant to a Group at a folder rather than to a user on a project. <details><summary>Solution</summary>

   gcloud resource-manager folders add-iam-policy-binding folders/223344556677 \
     --member="group:gcp-network-admins@example.com" \
     --role="roles/compute.networkAdmin"
   

   Why: granting to a Group means membership changes (joiners/leavers) never require touching IAM; granting at the folder means every project born under it inherits the binding — the operating model is expressed once, not re-applied per project. </details>

4. (Intermediate) Encode a mandated guardrail. Write the Organization Policy v2 YAML that restricts resource locations to europe-west2 and europe-west1 for the whole organization 123456789012, and the command to apply it. Where in the hierarchy should it live? <details><summary>Solution</summary>

   # policy.yaml
   name: organizations/123456789012/policies/gcp.resourceLocations
   spec:
     rules:
       - values:
           allowedValues:
             - in:europe-west2-locations
             - in:europe-west1-locations
   

   gcloud org-policies set-policy policy.yaml
   

   Set it at the organization node so every folder and project inherits it; a specific folder may tighten (never loosen a compliance mandate) if needed.

   Why: a mandated decision-rights row is only real when it is an actual inherited constraint on the hierarchy. </details>

5. (Advanced) Design a RACI row and roll it out safely. For the decision class “restrict external IPs on VMs org-wide,” write the RACI (who is Accountable, Responsible, Consulted) and describe how you would roll the constraint out across thousands of existing projects without causing an outage. <details><summary>Solution</summary>

   RACI — Accountable: Security lead; Responsible: Platform team; Consulted: product tech leads, network lead; classification Mandate. Encode as the compute.vmExternalIpAccess boolean constraint. Roll out dry-run first: apply the policy with a dryRunSpec (enforce) so violations are logged, not blocked; watch audit logs to find VMs relying on external IPs; remediate (Cloud NAT for egress, load balancers for ingress); then promote the rule from dryRunSpec to live spec.

   name: organizations/123456789012/policies/compute.vmExternalIpAccess
   spec:                 # start with this section EMPTY of enforce, or absent
   dryRunSpec:
     rules:
       - enforce: true
   

   Why: dry-run → observe → enforce turns a potentially org-wide outage into a measured migration. </details>

6. (Advanced) Choose and design the funding model. A three-BU federated org is in its first year on Google Cloud. Choose showback vs chargeback for year one, and design the minimum label taxonomy plus the data source that makes it work. <details><summary>Solution</summary>

   Choose showback for year one (chargeback in year two once attribution is trusted). Minimum mandated label taxonomy: bu, cost-centre, env, app, owner, stamped automatically by the project factory. Data source: BigQuery billing export at the billing account, joined to the labels, driving per-BU showback dashboards and Budgets & alerts. Decide the shared/unallocated-cost rule (Shared VPC, logging, SCC) up front.

   Why: chargeback without trusted attribution just relocates the argument to “your numbers are wrong” and can push teams off the paved road to dodge allocations; show first, bill later. </details>

Common beginner mistakes

• “The operating model is an org chart / a strategy doc.” It is neither if it isn’t enforced. The right model: the operating model is configuration — Cloud Identity Groups bound at folders, Organization Policy constraints at org/folder nodes, a project factory that stamps labels. If a “mandate” isn’t a control, it’s a wish, and drift will erase it.
• “Centralize everything so nothing goes wrong.” Over-centralizing creates the central-IT bottleneck; adoption stalls and teams route around you into shadow IT. The right model: guardrails, not gates — mandate a small set of org-wide invariants, then let teams self-serve fast inside them.
• “Decentralize everything so teams move fast.” Full delegation produces a hundred unauditable snowflakes and a fragmented security posture. The right model: bounded autonomy — product teams own their workloads end to end, but inside guardrails the platform team mandates.
• “The CCoE should own and run everything, forever.” A CCoE that never withdraws is the bottleneck under a friendlier name. The right model: the CCoE is an enabling team — it incubates the paved road, diffuses skills, and hands steady-state ownership to the platform and product teams.
• “Turn on chargeback from day one to force cost discipline.” Premature chargeback without trusted attribution breeds “your numbers are wrong” and perverse incentives. The right model: showback first, chargeback later, on a mandated label taxonomy and BigQuery billing export.
• “Decision rights just means who approves the ticket.” Approval queues are the bottleneck you’re trying to escape. The right model: classify each decision as mandate / recommend / delegate, keep the mandated set small, and encode it so most decisions need no approval at all.
• “You build it, you run it means we abandon the teams.” Handing teams a pager with no support is how “DevOps” burns people out. The right model: the platform reduces cognitive load — golden paths, paved-road on-call tooling, SLO templates — so owning your workload is sustainable.

Glossary

• Operating model — the organizational machine that runs the cloud day to day: teams, decision rights, funding flows, and the interaction pattern between platform and product teams.
• Cloud Center of Excellence (CCoE) — a small, senior, cross-functional enabling team that sets standards, builds the first golden paths, diffuses cloud skills, and then works itself out of a job.
• Platform team — owns the landing zone, the paved road (project factory, golden modules, CI/CD), Shared VPC, the Organization Policy set, and FinOps tooling; treats the platform as a product with internal customers.
• Stream-aligned team — a product team that owns one value stream end to end — build and run — inside the platform’s guardrails (“you build it, you run it”).
• Enabling team — a team (typically the CCoE) that coaches other teams to raise a capability, then withdraws; interacts via facilitating.
• Complicated-subsystem team — a team owning a genuinely deep specialism (data platform, ML platform, network core) that warrants dedicated expertise.
• Paved road / golden path — the opinionated, guardrailed, self-service way to do a common task (e.g. get a compliant project) that is also the fastest way.
• Decision rights — the explicit record of who decides each class of decision, and whether the platform team mandates, recommends, or delegates it.
• RACI — a matrix marking, per decision, who is Responsible, Accountable (exactly one), Consulted, and Informed.
• Mandate / recommend / delegate — the three strengths of a decision right: uniform and non-negotiable; a strong default with an escape hatch; the team’s own call.
• Guardrails vs gates — automated, inherited constraints that let teams move fast safely (guardrails) versus manual approval checkpoints that create queues (gates).
• Project factory / vending — automated provisioning (Terraform modules + CI/CD, or Service Catalog) that creates compliant, fully-governed projects on demand.
• Showback — attributing and showing each team its cloud cost without billing it.
• Chargeback — actually billing teams for their consumption, including a share of platform cost.
• FinOps — the practice of managing cloud cost as a shared, data-driven responsibility (attribution, budgets, optimization).
• Team Topologies — the model (Skelton & Pais) of four team types and three interaction modes that this operating model maps onto Google Cloud.
• Cognitive load — the mental burden on a team; the platform exists to reduce it for stream-aligned teams.
• Conway’s Law — systems mirror the communication structures of the organizations that build them; the Inverse Conway Maneuver designs teams to get the architecture you want.
• Resource hierarchy — Google Cloud’s Organization → Folders → Projects tree; the inheritance boundary for IAM and Organization Policy.
• Organization Policy — the service that sets inherited constraints (guardrails) at org/folder/project nodes; supports dry-run before enforcement.
• Cloud Identity Group — a group used to grant IAM roles collectively, so membership changes never touch IAM bindings.
• Shared VPC — a platform-owned host project’s network shared to service projects, so networking is centrally governed.
• Federated / hub-and-spoke — a central platform plus per-BU sub-platforms, keeping org-wide mandates central while delegating the rest.
• Tactical / Strategic / Transformational — Google’s three CAF maturity phases; the operating model matures through them dimension by dimension.
• Enterprise foundations blueprint — Google’s opinionated, Terraform-delivered reference landing zone that the foundational epics deploy.
• Cloud Foundation Toolkit (CFT) — Google’s production-grade Terraform modules (project factory, networking, org policy, logging, IAM) that implement the blueprint.

What’s next

With the operating model designed, the epic backlog sequenced, and the landing zone connected to the enterprise foundations blueprint, part 7 of the Google Cloud Adoption Framework series turns to running the program in steady state — governance, FinOps, and continuous re-assessment that keep every theme advancing after the foundation is live.