Building a Federated Governance Model for Distributed Data Ecosystems

Why Both Extremes Fail

Every large organisation eventually discovers that its governance model has an optimum size, and that it has outgrown it.

The centralised failure

A central team owns definitions, approves changes and curates the catalog. It works well up to a point. Past that point, the central team becomes a queue. Domain teams wait weeks for a definition change, discover the central team lacks the context to judge their request, and begin routing around the process. Governance becomes something that happens to reporting layers while the actual work occurs elsewhere.

The tell: a central glossary that is authoritative on paper and contradicted in practice by every domain’s local documentation.

The devolved failure

The reaction is to push everything to domains. Each owns its data, defines its terms and manages its own quality. Velocity improves immediately. Then finance tries to consolidate and finds four definitions of “active customer”, three incompatible customer identifiers and no shared understanding of what counts as a transaction.

The tell: a data mesh initiative that produced excellent domain-level data products and a cross-domain reporting problem worse than the one it replaced.

Drawing the Global–Local Line

The most useful artefact a federated model produces is a single table naming what is decided centrally and what is decided locally. Organisations that skip this argue the same question repeatedly for years.

Decision	Global	Local
Policy framework and principles	Yes	Implementation approach
Classification taxonomy	Yes	Applying it to assets
Shared business entities (customer, product, employee)	Yes	Domain-specific attributes
Metrics reported to the board	Yes	Domain operational metrics
Quality dimensions and how they are scored	Yes	Thresholds per asset
Interoperability standards (identifiers, formats, SLAs)	Yes	Internal implementation
Platform selection	Yes	Configuration within it
Who is accountable for a domain’s data	Requirement that someone is	Who it is
Domain-specific terms	No	Yes
Prioritisation within a domain	No	Yes

Two principles make this durable. First, global should be as small as it can be — every item added to the left column is a queue you are creating. Second, the boundary needs an arbiter. When a domain believes a term is local and another domain depends on it, someone must decide. Naming that person in advance prevents months of standoff.

Shared Entities Are the Hard Part

Almost all federation disputes reduce to a small number of entities that multiple domains legitimately need to define differently.

“Customer” is the canonical example. Sales means an account with an open opportunity. Finance means an entity with a billing relationship. Support means anyone with a service contract. Marketing means anyone who consented to contact. All four are correct within their domain, and treating any one as the enterprise definition breaks the other three.

The pattern that works

Define a minimal shared core and permit domain extensions:

• A canonical identifier that all domains resolve to, even where their populations differ.
• A small set of shared attributes with a single agreed definition — typically fewer than ten.
• Domain qualifiers that are explicitly namespaced: Sales.ActiveCustomer, Finance.BillableCustomer. Namespacing removes the ambiguity without forcing a false consensus.
• A mapping between domain definitions, maintained as a governed asset, so consolidation is a documented transformation rather than a rediscovery each quarter.

The mistake to avoid is convening a working group to agree one enterprise definition of customer. These groups run for months and conclude either in an unusable compromise or in deadlock, because the disagreement is not semantic — it reflects genuinely different business realities.

The Operating Structure

A federated model needs three tiers, and each needs a defined purpose or it becomes a meeting.

Central function — enable and arbitrate

Small. Deliberately smaller than feels comfortable. Its work is: maintain the policy framework and taxonomy; own the platform and the standards; arbitrate cross-domain disputes; provide templates, training and tooling so domains do not each solve the same problem; and report on the whole estate.

What it should not do: curate domain metadata, approve routine domain decisions, or act as the stewardship team for domains that have not staffed their own.

Federated council — decide, not discuss

Domain representatives with actual decision authority in their area. Meets on a defined cadence with a decision agenda, not a status agenda. Its outputs are rulings on cross-domain questions and changes to the global set.

A council whose minutes record updates rather than decisions is a reporting forum wearing a governance label.

Domain teams — own and operate

Each domain has a named accountable owner and stewards with funded time. They classify their assets, define their local terms, set quality thresholds, resolve their issues and publish data products that meet the interoperability standards.

The critical enabler is that stewardship is a funded allocation, not an unfunded addition to someone’s existing role. Federation devolves work; if the resource does not follow, the model collapses back to centralised in practice while remaining federated on paper.

Data Products and the Contract

Federation works best when domains publish data products with explicit contracts rather than exposing tables and hoping consumers cope.

A useful contract specifies:

• Schema, with a stated versioning and deprecation policy
• Freshness and availability commitments
• Quality guarantees on named fields, with what happens when they are breached
• Semantics — what each field means, and explicitly what it does not mean
• Owner and support route
• Classification and permitted uses, including whether it may be used for AI training

That last item has become materially important. In a federated model, a domain may publish a product whose consumers include a model training pipeline in another business unit, under a different legal basis. The contract is where that gets settled, and it needs to be machine-readable so the feature store can enforce it rather than relying on a consumer reading a document.

What the Platform Must Support

Federation puts specific demands on tooling that centralised models do not.

• Domain-scoped permissions. Domains must curate their own assets without the ability to alter global terms. Atlan’s personas and purposes model and Collibra’s domain and responsibility framework both address this directly.
• Namespaced glossary. The catalog must represent Sales.ActiveCustomer and Finance.BillableCustomer as distinct governed terms with a documented relationship, not force one to win.
• Federated workflow. Approval routing to the correct domain owner automatically, with escalation to the council for cross-domain changes.
• Cross-domain lineage. The whole point of federation is that domains interconnect; lineage that stops at a domain boundary hides the dependencies that matter most.
• Roll-up reporting. The central function needs estate-wide visibility without central curation.

None of this is exotic — all the major platforms support some version of it. The failure mode is configuring a federated organisation into a centralised tool model, which reintroduces the queue you were trying to remove.

Getting There from Centralised

Federation is rarely greenfield. The usual starting point is a struggling central function and a set of domains with varying appetite.

1. Write the global–local split first. One page. Circulated, argued over, agreed, published. Everything else depends on it.
2. Pilot with two willing domains. Not the biggest or the most regulated — the most willing. You are building a template and a reference, and both need a domain that wants to succeed.
3. Fund stewardship explicitly in those domains. If this proves impossible, stop; the model will not work and it is better to know in month two.
4. Establish the council with real decisions. Give it a genuine cross-domain dispute to resolve in its first quarter. A council that has never decided anything contentious has not been tested.
5. Shrink the centre deliberately. As domains take on curation, the central function must actively hand work over. This does not happen by itself, and it is uncomfortable for people whose roles were defined by the old model.
6. Expand domain by domain, using the pilot as evidence.

Federation succeeds when the centre does less every quarter and the estate gets more governed. If the centre is growing, you have a centralised model with extra meetings.

Published by KRISID · 30 April 2026. This paper reflects our delivery experience and publicly available sources at the time of writing. It is general guidance, not legal advice — regulatory obligations vary by jurisdiction and by how a system is used.