Every enterprise cloud engagement I have joined in the last three years has had the same gap. The landing zone is designed. The subscription topology is mapped. The network architecture is documented. The identity model is defined. Then the engagement ends, the team moves on, and six months later the landing zone is pristine, well-architected, and largely empty.
The architecture was not the problem. The operating model was. Nobody defined who could request a new subscription, how workloads get onboarded, who approves exceptions to the network segmentation, or what happens when a team needs to deploy something that doesn't fit the pre-defined patterns.
Architecture without operations
The Cloud Adoption Framework does an excellent job of describing what a landing zone should look like. Management group hierarchy, subscription organization, network topology, identity integration, policy assignments. A skilled architect can design all of this in a few weeks.
What CAF describes less well is how that landing zone gets used. The framework covers the "what" comprehensively. The "how" tends to live in scattered references to governance and operations that most teams read as optional. They are not optional. They are the difference between a landing zone that accelerates cloud adoption and one that sits unused while teams keep deploying to their original subscriptions.
What the operating model needs to answer
The questions are straightforward, and almost none of them are technical:
- Intake: How does a team request cloud resources? Is there a form, a portal, a Slack channel? Who reviews the request? What's the SLA?
- Decision rights: Who can approve a new subscription? Who decides when an exception to the architecture pattern is warranted? Where does that decision get documented?
- Onboarding: When a new business unit or application team needs to use the landing zone, what do they need to know? Is there a self-service path or does every onboarding require a meeting?
- Exception handling: What happens when a workload doesn't fit the standard patterns? How does the team get unblocked without bypassing governance?
- Cost accountability: Who sees the bill? How are costs allocated? What happens when spend exceeds the forecast?
These questions sound operational, and they are. But answering them is an architecture problem because the landing zone design needs to support the answers. If cost accountability requires per-team visibility, the subscription model needs to reflect team boundaries. If exception handling requires approval workflows, the policy framework needs to support exemptions without disabling the entire policy set.
Governance as code, not as a document
The most effective governance models I have built treat governance as a product, not a policy binder. The governance artifacts are interactive tools, not PDFs. The standards are embedded in templates, not written in documents that engineers are expected to find and read.
At Quanta Services, the governance layer included naming convention generators, security baseline checkers, landing zone wizards, cost calculators, and maturity scorecards. These tools enforced the standards by design. A team using the naming generator could not produce a non-compliant name. A team deploying through the pre-approved Terraform modules could not skip the required security controls. Compliance became a side effect of using the tools rather than a separate activity.
This approach also solved the communication problem. Leadership could see governance adoption through tool usage metrics rather than asking each team whether they had read the latest policy update.
The gap is not accidental
Enterprises skip the operating model because it's harder than the architecture. Designing a landing zone is a technical problem with well-documented solutions. Defining decision rights, intake processes, and exception handling requires organizational consensus, which means meetings, disagreements, and compromises that take longer than the architecture design itself.
The temptation is to ship the landing zone first and define the operating model later. This never works. Teams form habits in the first 90 days of a new platform. If the operating model isn't in place by then, teams will have already built their own informal processes, and replacing informal processes with formal ones is an adoption challenge that most CCoEs are not equipped to handle.
A landing zone without an operating model is a house without a front door. The architecture might be sound, but nobody knows how to get in.