Domain Publishing Readiness

A CDO announces a federated model, twelve teams are relabelled domains, and each is told it now owns its data. Nothing else changes. Six months later there are 40 published datasets, no owner responds inside a week, three have SLOs written by people who have never measured them, and the central team is doing exactly what it did before with less authority and a longer queue.

Decentralisation moves the work, and moving work to a team that cannot carry it is not decentralisation. A readiness bar states what carrying it means, in capabilities the team can be shown to have rather than in intentions it can declare.

The bar is deliberately short. A long checklist becomes a compliance exercise that the eager domains pass and the important domains avoid.

Why it matters

The cost of a data product published by an unready domain is not paid by that domain. It is paid by every consumer who builds on a dataset with no deprecation policy and discovers a column gone on a Tuesday, and by the platform team who become the de facto support line for a product they did not build. That asymmetry is why publication needs a gate at all: the producer captures the benefit of publishing and the consumer carries the risk.

There is a second reason. A readiness bar gives the platform team a concrete backlog. Every capability on the list that domains cannot meet is a platform gap, so the bar doubles as the specification for the self-serve platform that federation is supposed to provide.

Implementation patterns

Five capabilities cover most of the risk, and each is verifiable by a machine rather than asserted:

• An owner group that resolves in the directory and has at least two members. One-person ownership is an outage waiting for annual leave.
• A measured service level, not a promised one. The domain must show 30 days of observed freshness and availability before declaring a target, because a target set without measurement is a number someone liked.
• A written deprecation policy with a notice period, typically 30 to 90 days, and a way to identify current consumers. Without consumer identification the notice period is decorative.
• Contract tests in the producer's own build, so a breaking schema change fails where the change is made rather than in someone else's pipeline overnight.
• Sensitivity labels on every column, because the platform cannot apply masking or access policy to fields it cannot classify.

Two rules make the bar workable. Run it in warn mode for a quarter and publish which domains would fail, so the gap is visible before it is enforced. And grant time-boxed exemptions with a named owner, never permanent ones, because a permanent exemption is the bar being deleted quietly.

Industry example

Characteristic of delivery marketplaces of the kind Swiggy operates rather than attributed: dispatch, payments and merchant domains each publish datasets that the others depend on within minutes of an order. The domains that fail a readiness bar in practice are not the unsophisticated ones, they are the fast-moving ones whose schema changes weekly, which is exactly the population the contract test requirement exists for. A common outcome is that two or three domains publish under the bar while the rest stay on the central path for a quarter, and the published set is the one consumers trust.

Failure scenarios

• The bar becomes a 40-item checklist, so passing it costs a month and domains route around publication entirely by sharing table access instead.
• Readiness assessed by self-declaration. Every domain declares itself ready, and the gate has measured nothing.
• Exemptions granted without expiry. Within two quarters the exempt set is larger than the compliant set and the bar is a document.
• The platform cannot yet provide a capability the bar requires, so the bar blocks domains for a gap they cannot close. Each requirement needs a platform-supplied way to satisfy it before it is enforced.
• Only new products are gated. The existing forty unready datasets keep running, which is where the actual risk lives.

Trade-offs

The momentum argument is not wrong, it is mistimed. Publishing broadly before the bar exists is recoverable in the first quarter and expensive after the second, because by then consumers have built on products that cannot honour a change.

When not to use it

With three or four domains and one platform team, the bar is slower than a conversation. The platform team knows every producer by name and can review a publication in an afternoon. It also does not apply to internal working datasets: a domain's own intermediate tables should not be gated at all, and gating them is how a readiness practice acquires a reputation for obstructing work. The bar applies at the moment a dataset is declared consumable by another domain, and nowhere earlier.

Interview question

Q: Leadership has announced a federated data model across twelve domains and expects products to start appearing next quarter. What do you require of a domain before it may publish, how do you enforce it without becoming the bottleneck federation was meant to remove, and what tells you the bar is working?

What a strong answer covers: a short machine-verifiable bar rather than a checklist; each requirement paired with a platform-supplied way to meet it; warn mode before enforcement with published pass rates; time-boxed exemptions with owners; gating at the moment of declaring a dataset consumable rather than on internal tables; and the signal that it is working, which is consumer behaviour, whether teams build on published products or go around them to raw tables.

Quick check

Quiz: Why must a domain show measured freshness before declaring an SLO? A target set without 30 days of observation is a number someone liked; consumers then design against a guarantee the producer has never met and cannot detect breaching.

Flashcard: Twelve teams were relabelled domains and told they own their data. What single practice separates that from real decentralisation? A short readiness bar verified by machine, resolving owner group, measured SLO, deprecation policy with consumer identification, contract tests in the producer's build, and column sensitivity labels, each with a platform-supplied way to satisfy it.