Organizations and Child Tenancies: Structuring at Scale

For most of an OCI estate's life, the structural question has one answer: use compartments. The compartment tree carries policy, budgets, quotas, and tag defaults; it isolates teams and environments well enough for the overwhelming majority of purposes, and the patterns for growing it are well understood, we lay them out in compartment design patterns for growing tenancies. But a compartment is a boundary inside a tenancy, and some requirements refuse to live inside someone else's walls. A regulated subsidiary whose auditors want administrative separation, not a subtree. An acquisition arriving with its own cloud estate and its own identity domain. A sovereign workload whose data residency case is simpler to defend at tenancy level. A business unit that finance insists must hold its own commercial relationship with its own spend boundary, not a slice of a shared one.

That is the territory of OCI Organizations: multiple tenancies under one umbrella, with shared governance and, where wanted, shared commercials. It is the structural ceiling of the advanced OCI operations series, the decision layer above everything else, and the rule of thumb is worth stating before the detail: the right number of tenancies is the smallest number your hard requirements allow. Tenancies multiply operational surface, and nothing in this article changes that arithmetic.

What Organizations actually gives you

An organization in OCI is a parent tenancy plus the child tenancies attached to it. Children can be created fresh under the parent or, subject to the platform's rules, brought in from existing standalone tenancies. Three capabilities make the construct more than an org chart. Governance rules let the parent push selected controls down to children, so a baseline does not depend on every child team voluntarily rebuilding it. Subscription mapping lets children draw on the parent's commercial agreement, so one Universal Credits commitment can fund consumption across the family instead of each tenancy negotiating alone, which also means the family's combined usage burns down one commitment rather than fragmenting into several small ones. And consolidated visibility gives the center a view of cost and usage across all children, the estate wide version of the allocation discipline in cost allocation on OCI.

What Organizations does not do is equally important. It does not merge identity: each tenancy keeps its own identity domains, policies, and administrators, which is precisely the isolation you came for and precisely the duplication you will pay for. It does not make networks talk to each other; cross tenancy connectivity is its own engineering. And it does not operate the children. Every child tenancy needs its own landing zone, its own compartment tree, its own tagging defaults, budgets, quotas from service limits and quotas on OCI, and its own patch and backup calendars. The umbrella shares money and rules. It does not share the work.

Split or stay: the honest comparison

Read the table from the right column's middle row: the recurring cost of a split is operational duplication, and it never goes away. The benefit, structural isolation, is real but only valuable when a hard requirement demands it. Soft preferences, team autonomy, tidiness, a vague sense that production deserves its own tenancy, are almost always served better by compartments, policy, and the governance practices the rest of this series describes. The defensible triggers are few: regulatory or contractual separation that auditors will test, mergers and divestitures where a tenancy boundary matches a legal one, genuine blast radius isolation for an estate large enough that shared service limits chafe, and commercial boundaries that finance will not blur.

The seams: identity, networking, and shared services

The work of a multi tenancy estate lives in the seams between tenancies, and three seams dominate. Identity is the first. Each tenancy carries its own identity domains and its own policy set, which is the isolation working as intended, but the humans who administer the family do not want a login per tenancy. The usual answer is federation from one identity provider into every tenancy, with group naming conventions that make a person's role legible across the family, and a deliberate decision about which few identities hold parent level power, because the parent tenancy's administrators are the family's real blast radius and deserve the strictest controls in the estate.

Networking is the second seam. Tenancy boundaries do not stop packets, but they do stop convenience: cross tenancy connectivity has to be designed, typically through remote peering between dynamic routing gateways, with route control and security rules owned somewhere explicit. The clean pattern is a hub: one tenancy, often the parent or a dedicated shared services child, owns the interconnect, the inspection points, and the connectivity to on premises, and every child reaches the world through it. The anti pattern is the mesh that grows one expedient peering at a time until nobody can draw it.

Shared services are the third seam, and the quietest source of friction. Logging targets, monitoring, bastion access, golden images, artifact repositories, and the deployment tooling itself all need a home, and either every child duplicates them, which multiplies cost and divergence, or a shared services tenancy hosts them, which reintroduces a dependency the split was partly meant to remove. There is no universally right answer, only a deliberate one: decide per service, write the decision down, and price the duplication honestly when the answer is everyone for themselves.

A decision and rollout framework

Operating a family of tenancies

The estates that run multiple tenancies well treat the family as one operating model with several enforcement points, not as several estates with a shared invoice. The golden landing zone is the central trick: when every child is stamped from the same template, the operations team's knowledge transfers across the family, the runbooks work everywhere, and the fleet practices from the rest of this series, patching trains, backup calendars, drift detection, scale across tenancies the same way they scale across databases. The center holds a short list of nonnegotiables pushed through governance rules and template, security baseline, required tags, budget wiring, audit log retention, and leaves everything else to the child's own team, because a center that tries to administer every child becomes the bottleneck the split was supposed to remove.

The commercial layer deserves the same deliberateness as the technical one. Subscription mapping decides which tenancies draw on which funding, and the mapping doubles as a governance instrument: a child that consumes from the parent's commitment is visible to the center by construction, while a child with its own contract is a financial island whose habits the center learns about at renewal time. Estates negotiating a Universal Credits commitment should also size it for the family's combined consumption rather than tenancy by tenancy, because aggregated volume is negotiating weight, and a commitment fragmented across separate agreements gives that weight away for nothing in return.

Two failure modes account for most multi tenancy regret. The first is the premature split, tenancies created for autonomy theater, which buys years of duplicated operations for a benefit a compartment would have delivered. The second is the orphan child, a tenancy created in a hurry for an acquisition or a deadline, never templated, never wired into consolidated visibility, quietly becoming the least governed corner of the estate. Both are design failures rather than platform ones, and both are avoidable with the framework above applied before the create button is pressed. Tenancy structure is also one of the few decisions in this series that is genuinely painful to reverse, which is why it belongs in the same category as region and subscription choices: decided deliberately, with the long term operating cost in the business case. Structural decisions of exactly this kind are the core of our OCI consulting practice, on a fixed project fee, where the deliverable is a structure the estate can still defend five years in.