Data Product

A data product must be easily found and understood by its intended consumers. This requires comprehensive documentation, including:

• Clear ownership and contact information.
• Business and technical metadata (e.g., definitions, schema, data types).
• Usage examples and sample queries.
• Data quality metrics and freshness indicators. This documentation is typically published in a centralized metadata catalog or data marketplace, enabling self-service discovery and reducing dependency on the producing team.

Each data product has a unique, stable identifier and a standardized access protocol. Consumers interact with it through a well-defined interface, not by accessing raw storage paths. Key mechanisms include:

• Unique URIs or API endpoints for programmatic access.
• Standardized authentication and authorization (e.g., OAuth, API keys).
• Versioned schemas to manage evolution without breaking consumers.
• Support for common data formats (Parquet, Avro) and query languages (SQL). This decouples consumers from the underlying storage technology, allowing the product's infrastructure to evolve independently.

Consumers must have confidence in the data product's quality and availability. This is enforced through service-level objectives (SLOs) and automated monitoring, covering:

• Data Quality SLOs: Metrics for accuracy, completeness, and uniqueness.
• Freshness SLOs: Guarantees on data update frequency and latency.
• Operational SLOs: Uptime and performance guarantees for APIs.
• Automated Observability: Continuous monitoring for data drift, schema changes, and anomaly detection. Violations trigger alerts and are managed via data incident management processes.

Data products are designed to be building blocks. They adhere to global standards within an organization, enabling them to be securely combined and reused. This involves:

• Adherence to a global data ontology or semantic layer for consistent business terminology.
• Standardized data models and serialization formats (e.g., Protobuf, managed via a schema registry).
• Explicitly defined dependencies on other data products, tracked via data lineage.
• Compatibility with central data governance and security policies (e.g., data classification). This characteristic is foundational for architectures like Data Mesh.

Access to and usage of the data product is controlled according to organizational policy and regulatory requirements. This encompasses:

• Fine-grained, attribute-based access control (ABAC) at the row and column level.
• Data masking and encryption for sensitive fields.
• Audit logging of all access and queries for compliance.
• Policy enforcement for data retention, privacy (e.g., GDPR), and residency.
• Clear data stewardship responsibilities. Security is a built-in feature, not an afterthought, ensuring the product can be safely consumed across the enterprise.

A data product is created to solve a specific business problem or enable a capability for a well-defined set of consumers. It is managed through its full lifecycle by a dedicated, cross-functional team (the domain data product team). This involves:

• Product roadmaps aligned with consumer needs.
• Usage analytics to measure adoption and value.
• Feedback loops and versioning strategies.
• Cost management and chargeback/showback models.
• Deprecation policies for end-of-life. It is treated as a capital asset with ongoing investment, not a one-time project deliverable.

A formal, versioned agreement between a data producer and its consumers that specifies the interface, schema, semantics, and service-level expectations for a Data Product. It defines:

• Schema and data types
• Semantic meaning of fields
• Quality guarantees (e.g., completeness SLO)
• Freshness and latency SLAs
• Breaking change policies Contracts enable reliable, autonomous consumption and are central to productizing data.

A logical bounded context representing a specific business area or subject matter (e.g., customer, inventory, finance). In a Data Mesh, Data Domains are the owners of Data Products. This alignment ensures that data is managed by teams with deep business context, who are responsible for the quality, evolution, and lifecycle of their domain's data assets.

A business representation of data that sits between raw data sources and consuming applications (e.g., BI tools). It translates complex data structures and logic into familiar business terms, metrics, and definitions. For a Data Product, the semantic layer provides the consumable interface, ensuring all users interpret key metrics like Monthly Recurring Revenue or Active Customer consistently.

The role responsible for the end-to-end lifecycle of a Data Product, analogous to a Product Manager for software. Key responsibilities include:

• Defining the product vision and roadmap
• Understanding consumer needs and use cases
• Prioritizing features and data quality improvements
• Managing the Data Contract and SLAs
• Driving adoption and measuring value delivery This role bridges technical execution, data governance, and business value.