Skip to main content

Central Platform vs Domain-Run Infrastructure in Data Mesh: Clearing the Misconception

The common misconception (high level)​

A frequent misunderstanding in data mesh discussions is:

“If we want decentralized ownership and federated governance, then each domain must also own and operate its own infrastructure/utility plane.”

This is not what data mesh requires.

Data mesh requires decentralized ownership of data products and federated governance of policies and standards.
It does not require every domain to run its own platform engineering function, especially when the target operating model includes fully automated self-service and cross-domain / cross-organization composition (including derived data products).

Two scenarios to compare​

Both scenarios below assume:

  • True data products exist and expose output ports (e.g., APIs, events, query interfaces).
  • An enterprise-level Marketplace exists for discovery, request/grant, and access workflows.
  • An enterprise-level Catalog exists for metadata and discovery.
  • Self-service exists in both cases (the difference is its scope and consistency).

Scenario S1 — Shared Utility / Infrastructure Plane (centralized “factory”)​

A single shared utility plane (enterprise or division-wide) provides:

  • Standard runtime capabilities and “golden paths”
  • Automated provisioning and deployment pipelines
  • Built-in observability, lineage emission, audit evidence
  • Consistent security baselines and enforcement patterns
  • Consistent policy evaluation/enforcement integration

Self-service is uniform, typically delivered through a single portal experience.

Key property: Domains build and operate data products, but do not run the underlying platform. The infrastructure plane is transparent and consumed via automation.

Scenario S2 — Domain-owned Utility / Infrastructure Plane (many “factories”)​

Each domain owns and operates its own utility plane, including:

  • Runtime choices, deployment patterns, and platform services
  • Domain-specific self-service experience and tooling
  • Domain-specific implementation of observability, lineage, audit, enforcement integrations

Self-service is domain-specific (often uneven maturity and divergent tooling).

Key property: Domains build and operate data products and their own platform. This increases autonomy at the platform layer but introduces duplication and inconsistency risk.

How to compare scenarios: EA fitness functions​

Use fitness functions (quality attributes) to score each scenario against the operating model you actually want.

Scoring guidance​

  • 1 = Poor fit (structurally misaligned; high risk/overhead)
  • 3 = Workable (possible with significant controls and investment)
  • 5 = Strong fit (supported by design; scalable and repeatable)

Tip: These weights reflect a common enterprise reality where cross-domain sharing, consistent controls, and automation matter. Adjust weights if your context differs.

Fitness FunctionWeightWhat “Good” Looks LikeS1 ScoreS2 Score
Consistent global policy enforcement15One policy framework; consistent enforcement points; no drift52–3
Audit & compliance repeatability10Automatic audit evidence, uniform controls, consistent traceability52–3
Security baseline consistency10Standard IAM, encryption, egress controls, patching patterns52–3
Automation-only producer↔consumer interaction15Marketplace request/grant fully automated; no infra teams in loop52–3
Derived product safety (policy composition)15Derived products cannot violate upstream constraints; lineage is automatic52
Time-to-onboard/publish new products10Golden paths + templates; minimal specialist skills required4–53–4
Cost efficiency & reuse10Low duplication; shared capabilities; economies of scale4–52
Reliability/operability consistency10Uniform SLOs/observability; predictable incident response4–52–3
Talent feasibility5No need for platform experts in every domain51–2

Typical totals (out of 500)​

  • S1: ~470–500
  • S2: ~205–270

Baseline conclusion: Under operating models that require cross-domain composition, consistent global controls, and automation-first self-service, S1 is the better enterprise architecture fit.

Rationale for the scores (why S1 tends to win under these constraints)​

1) Policy and control consistency is “physics,” not preference​

When global and organizational policies must apply consistently, the enforcement and evidence-generation mechanisms must be standardized and repeatable.
S1 makes consistency the default; S2 must fight drift across domains.

2) Derived data products amplify risk and complexity​

Derived products are where:

  • constraints must propagate and compose,
  • lineage must be end-to-end,
  • compliance evidence must be reproducible.

S1 supports “safe by construction” derived products via a uniform factory pipeline.
S2 makes the derived-product story fragile unless every domain implements the same capabilities to the same standard.

3) “No infrastructure teams in the loop” requires one automated factory​

If producers and consumers should never depend on infrastructure engineers for access, deployment, or integration, then the platform must provide:

  • automated request/grant provisioning,
  • standardized deployment paths,
  • policy-as-code checks,
  • built-in audit and lineage.

S1 aligns naturally. S2 increases the number of integration surfaces and operational models, making “no human mediation” harder to guarantee.

4) Talent reality: platform engineering does not scale domain-by-domain​

S2 assumes each domain can staff platform engineering, security engineering, and SRE maturity.
If the strategy explicitly aims to avoid requiring expert engineering teams per domain, S2 conflicts with the target operating model.

What decentralized ownership and federated governance actually mean​

Decentralized ownership (in data mesh)​

Domains own the data product, meaning they are accountable for:

  • meaning and semantics (the “what” and “why”)
  • contracts and output ports (APIs/events/query)
  • quality and fitness-for-use
  • lifecycle and change management
  • consumer support within product scope
  • access decisions within policy constraints

Domains do not need to own infrastructure to own the product.

Federated governance (in data mesh)​

Federated governance means:

  • policies and standards are co-authored by a federation (domains + risk/compliance + security + architecture + platform)
  • rules are expressed as policy-as-code / controls-as-code
  • enforcement is consistent and automatic
  • exceptions are managed transparently with auditable rationale

Federated governance is about shared rule-making and shared accountability, not “every domain implements governance differently.”

The “factory” model: why a shared utility plane fits data mesh​

A useful distinction:

  • Domains own the product
  • The platform owns the factory

If self-service is the goal, then the utility/infrastructure plane is best treated as:

  • a shared factory that produces compliant, observable, interoperable products at scale
  • a productized capability that domains consume via templates, golden paths, and automation
  • largely invisible to producers and consumers during normal workflows

This model supports data mesh because it enables:

  • domain autonomy at the product layer
  • federated governance at the policy layer
  • consistent enforcement at the platform layer

In other words:

Decentralize meaning and accountability. Centralize repeatable primitives and enforcement.

Position:
A shared, centralized utility/infrastructure plane is fully compatible with data mesh when it operates as a transparent, productized self-service factory that enforces federated policies consistently and does not require direct interaction from producers or consumers.

Therefore:

  • Choose Scenario S1 as the default enterprise architecture pattern for scalable data mesh adoption, this is especially true when cross-domain sharing, derived products (epheremal or long lived) e.g for EBA Stress test or Client Portfolio Risk etc, and consistent global controls are critical.
  • Allow Scenario S2 only as a constrained exception where hard requirements exist (e.g., regulatory, residency, extreme latency), and only if the domain still conforms to the same policy framework, publication standards, and evidence-generation requirements.

One-line summary:

Domains own the data products; the platform owns the factory, and a shared factory is what makes federated governance and self-service real at scale.