Data Mesh

The foundational principle that shifts responsibility for analytical data from a central team to the business domains that create it. Each domain, such as 'Factory Operations' or 'Supply Chain,' owns, ingests, and serves its data. This federated model eliminates the bottleneck of a central data team that lacks the domain expertise to understand the semantic meaning and quality nuances of source data.

• Accountability: Domain teams are accountable for the correctness and availability of their data.
• Context: The team closest to the data's origin is best equipped to model and interpret it.
• Scalability: Prevents the organizational scaling bottleneck of a monolithic data platform team.

Analytical data is treated as a first-class product, not a byproduct. Domain teams must provide their data with explicit quality guarantees, discoverability, and self-serve interfaces for consumers. A data product encapsulates all the structural components—code, data, metadata, and infrastructure—needed to serve trustworthy data. It must adhere to baseline qualities: discoverable, addressable, trustworthy, self-describing, interoperable, and secure.

• Service Level Objectives (SLOs): Data products have defined uptime, freshness, and quality metrics.
• Discoverability: Published in a central registry for other domains to find and use.
• Interoperability: Adheres to global standards for schema and access.

A dedicated platform team provides a domain-agnostic infrastructure to abstract the complexity of building data products. This platform enables domain teams to manage the full lifecycle of their data products—from ingestion and storage to serving and monitoring—without deep expertise in distributed systems. It provides capabilities like declarative pipeline management, automated schema enforcement, and scalable storage.

• Declarative APIs: Define data products using configuration, not custom code.
• Blueprints: Reusable templates for common data product patterns.
• Frictionless Consumption: Standardized access patterns for consumers across domains.

A governance model that balances global standardization with local domain autonomy. A central governance body defines a minimal set of global rules—such as data product interoperability standards, access control policies, and master data management—that are automatically enforced by the self-serve platform. This ensures a cohesive mesh without stifling domain innovation.

• Automated Policy Enforcement: Rules are encoded into the platform, not managed via manual review boards.
• Global Standardization: Ensures data products can be joined and analyzed across domains.
• Local Autonomy: Domains retain full control over their data models and release cadence.

The atomic unit of a Data Mesh. A data product is a self-contained, discoverable, and trustworthy dataset owned by a specific domain. It is not just raw data; it bundles code, metadata, and infrastructure to serve a defined set of consumers. Each product exposes clear output ports and adheres to a global governance standard.

• Key Attributes: Discoverable, addressable, self-describing, interoperable, and secure.
• Example: A 'Finished Goods Quality' domain publishes a data product containing real-time defect rates, batch IDs, and machine calibration parameters for downstream predictive maintenance models.

The principle that analytical data should be owned by the business domain that creates it, not a centralized data lake team. The manufacturing quality team, for instance, owns the quality data product end-to-end. This shifts responsibility for data quality, schema evolution, and SLOs to the people who understand the data's context best.

• Anti-Pattern: Centralized bottlenecks where a data engineering team becomes a blocker.
• Industrial Context: A 'Welding Cell 4' domain team publishes its own telemetry product, owning the ingestion pipeline from the PLC to the mesh.

The underlying infrastructure that enables domain teams to build and run data products without deep centralized expertise. It abstracts the complexity of streaming infrastructure, storage, and policy enforcement. The platform provides a declarative interface for domains to define their data product's shape and guarantees.

• Capabilities: Automated provisioning, schema registry integration, access control, and lineage tracking.
• Goal: Make creating a new, compliant data product as simple as a few API calls, not a six-month infrastructure project.

A governance model that standardizes what must be global while allowing local autonomy. A central team defines global standards for data product interoperability—such as naming conventions, data types, and access control policies—which are then executed automatically by the platform. Domains are free to innovate within these guardrails.

• Mechanism: Policies-as-code that are version-controlled and automatically enforced.
• Example: A global rule mandates all industrial data products must expose a machine_state field using the OPC UA enum, but domains choose their own aggregation logic.

A formal, machine-readable agreement between a data product's producer and its consumers. It explicitly defines the schema, semantics, quality guarantees (SLOs), and terms of use. Breaking changes to a contract are versioned and communicated, preventing cascading pipeline failures.

• Contents: JSON Schema, Avro definition, freshness SLO (e.g., max_lag: 5s), and semantic tags.
• Role in Mesh: The contract is the API for data, enabling true decoupling between domain teams.

A complementary architectural pattern that provides a single source of truth for industrial data, structured around the ISA-95 asset hierarchy. While Data Mesh organizes data by business domain, a UNS organizes it by physical equipment topology. The two patterns converge when a UNS serves as the real-time ingestion backbone for a domain's data product.

• Relationship: UNS provides the normalized, contextualized event stream that a domain team packages into a governed data product.
• Benefit: Decouples OT data producers from IT consumers, enabling the self-serve platform.