Data Products, Data Mesh, and Domain-Oriented Architecture

The modern enterprise data environment is becoming increasingly distributed.

Data is no longer created only in a small number of centralized systems and consumed by a relatively limited group of reporting teams. It is produced across operational applications, SaaS platforms, digital channels, devices, business processes, partner ecosystems, analytical platforms, and increasingly, AI applications.

At the same time, organizations expect data to be easier to discover, understand, access, and reuse. This creates a fundamental architectural challenge.

A centralized data team can provide consistency and enterprise control, but it can struggle to understand the detailed meaning and changing needs of every business domain. A completely decentralized model can give domains greater autonomy, but it can also produce duplication, inconsistent definitions, fragmented platforms, and difficult-to-manage governance.

The concepts of data products, data mesh, and domain-oriented architecture emerged partly in response to this tension. These concepts should not be interpreted as a single technology architecture. They are ways of thinking about how responsibility for data can be organized. A data product focuses on the quality and usability of a data asset. Domain-oriented architecture focuses on aligning data ownership with business domains. Data mesh is an organizational and architectural approach that emphasizes domain ownership, data as a product, self-service data infrastructure, and federated governance.

For the Enterprise Data Architect, the important question is not whether an organization should “implement data mesh.” The more useful questions are:

• Who owns enterprise information?
• Who is accountable for its quality?
• How should data be packaged for reuse?
• What capabilities should be centralized?
• What responsibilities should belong to domains?
• How should enterprise standards coexist with domain autonomy?
• How can data products support analytics, applications, and AI?

This chapter explores these questions and develops a practical architectural model for distributed data ownership.

10.1 From Centralized Data Warehousing to Distributed Data Ownership

Traditional enterprise data architecture often concentrated responsibility in a central data organization. Operational systems produced data. A central integration team extracted and transformed it. A central warehouse stored it. A central BI organization created reports. This model provided important advantages. It could establish:

• Centralized standards
• Common infrastructure
• Consistent security
• Enterprise reporting
• Centralized governance

However, as the enterprise expanded, the model also encountered limitations. The central data organization might not fully understand the business meaning of every dataset. A customer domain, for example, may have sophisticated knowledge of customer lifecycle, onboarding, relationships, segmentation, and regulatory requirements. A centralized team may understand the technology but not possess the same depth of business context. This creates an architectural problem. The people closest to the business process often understand the data best, but the people operating the enterprise platform often have the strongest technical capabilities.

Modern data architecture seeks to combine these strengths.

10.2 Business Domains as Data Ownership Boundaries

A business domain represents a coherent area of business responsibility. Examples include:

• Customer
• Product
• Finance
• Payments
• Claims
• Supply chain
• Human resources
• Marketing
• Risk

Domains are useful architectural boundaries because they often correspond to business capabilities and operational responsibility. A domain may own:

• Business processes
• Applications
• Business rules
• Information
• Data quality
• Subject-matter expertise

This makes the domain a natural candidate for data ownership. However, a business domain is not necessarily the same thing as a system boundary. A customer domain may span several applications. A finance domain may contain multiple platforms. A product domain may include information distributed across operational and analytical systems. The Enterprise Data Architect therefore needs to distinguish between business ownership and technical implementation. The business domain defines meaning and accountability. Technology implements the capabilities required to manage and distribute that information.

10.3 What Is a Data Product?

A data product is a managed data asset designed to serve identifiable consumers. It can be:

• A dataset
• A curated analytical table
• A set of APIs
• A streaming feed
• A semantic model
• A collection of data and metadata
• A governed retrieval-oriented information service

The important characteristic is not the physical format. The important characteristic is that the data is treated as a product with users, expectations, ownership, and lifecycle management. A data product should answer several questions:

• Who owns it?
• Who uses it?
• What does it mean?
• What quality can consumers expect?
• How is it accessed?
• How frequently is it updated?
• How is it secured?
• What happens when it changes?

This moves the organization away from thinking of data as simply a by-product of applications. Data becomes an enterprise asset with an explicit service relationship to consumers.

10.4 Data Products versus Datasets

Not every dataset is automatically a data product. A dataset may exist because an engineering team created it for an internal process. It may have:

• No owner
• Limited documentation
• No quality expectations
• No defined interface
• No lifecycle management

Such a dataset can still be useful. But it does not necessarily have the characteristics of a product. A data product introduces stronger expectations.

The distinction is valuable because simply renaming existing datasets as “data products” does not create a product operating model.

10.5 Characteristics of a Well-Designed Data Product

A mature data product should provide more than data. It should provide context. Consider a dataset called customer_revenue. The name alone is insufficient. A consumer needs to understand:

• What is a customer?
• What is revenue?
• Which transactions are included?
• Which currencies are used?
• What is the calculation period?
• How frequently is the data updated?
• What are the known limitations?
• Who owns the definition?

Without this context, consumers may interpret the same dataset differently. A useful data product therefore includes several dimensions.

Data

The actual information being provided.

Metadata

Definitions, ownership, lineage, classifications, and operational characteristics.

Quality

Expectations for completeness, accuracy, timeliness, and other relevant dimensions.

Access

The mechanisms through which consumers obtain the data.

Contract

The expectations governing changes, availability, and compatibility.

Documentation

The information consumers need to use the product correctly.

Governance

Policies governing security, privacy, retention, and permitted use.

The data product is therefore better understood as a bundle of data, metadata, interfaces, quality expectations, and governance.

10.6 Data Contracts

A data product requires an agreement between producer and consumer. This agreement is often represented through a data contract. A contract can define:

• Schema
• Field definitions
• Business meaning
• Data types
• Quality expectations
• Update frequency
• Service expectations
• Compatibility rules
• Ownership

The contract does not need to be a large legal document. It can be a machine-readable and human-understandable specification. For example, a customer data product might define that:

• customer_id is unique
• Country follows the enterprise reference standard
• Customer status uses an approved value set
• Updates occur within a defined period
• Personally identifiable information is subject to specified access controls

The contract creates predictability. Consumers can build against the product with greater confidence. Producers can change the implementation without unnecessarily breaking consumers as long as the contract remains compatible. This is another reason the concepts discussed in Chapter 8—schema evolution, integration, and interoperability—are foundational to data products.

10.7 The Meaning of Data Mesh

Data mesh is often misunderstood as a technology platform. It is better understood as an organizational and architectural approach to managing data in a large, distributed enterprise. The approach is commonly associated with four major principles:

1. Domain-oriented ownership
2. Data as a product
3. Self-service data infrastructure
4. Federated computational governance

These principles address different problems. Domain ownership addresses business accountability. Data as a product addresses usability and quality. Self-service infrastructure addresses engineering enablement. Federated governance addresses enterprise consistency. Together, they attempt to balance decentralization with enterprise control. The key architectural insight is that these principles are complementary. Implementing only one or two of them can create an incomplete model. For example, decentralizing data ownership without providing common platform capabilities may simply distribute operational complexity across the organization. Similarly, creating a centralized platform without domain ownership may leave the original ownership problem unresolved.

10.8 Domain-Oriented Data Architecture

Domain-oriented architecture changes where some data responsibilities sit. Instead of asking:

Which central team owns all enterprise data?

the organization asks:

Which business domain is accountable for the meaning, quality, and appropriate use of this information?

This can be particularly effective for business concepts that are deeply connected to domain processes. For example, the customer domain may be accountable for:

• Customer identity
• Customer status
• Customer lifecycle
• Customer relationships

The finance domain may own:

• Accounting structures
• Financial transactions
• Financial balances
• Financial reporting concepts

The risk domain may own:

• Risk classifications
• Risk measures
• Risk events

This does not mean that every domain builds its own infrastructure. Ownership and infrastructure are separate architectural concerns.

10.9 Centralized Capabilities and Federated Ownership

A mature enterprise does not have to choose between complete centralization and complete decentralization. A more practical model is often:

Federated Ownership + Centralized Enablement + Federated Governance

Domains own business data products. A central platform organization provides common technical capabilities. Enterprise architecture and governance establish common policies and standards. This creates a balance.

For example:

• Customer domain → customer data products
• Product domain → product data products
• Finance domain → finance data products
• Risk domain → risk data products

All of these can use common:

• Ingestion services
• Storage
• Processing
• Orchestration
• Metadata
• Observability
• Security
• Identity
• Data catalog capabilities

This is often more sustainable than asking every domain to independently build an entire data platform.

10.10 Federated Governance

Decentralized ownership does not eliminate the need for enterprise governance. In fact, distributed environments can make governance more important. The challenge is to govern what must be consistent while allowing domains autonomy over what legitimately belongs to them. Enterprise-wide standards may include:

• Security classifications
• Identity standards
• Privacy policies
• Data retention requirements
• Regulatory controls
• Enterprise identifiers
• Interoperability standards
• Metadata requirements

Domains may retain control over:

• Business-specific definitions
• Domain transformations
• Product implementation
• Domain-specific quality rules

This creates a distinction between global rules and local rules.

The Enterprise Data Architect should help determine which rules belong in each category.

10.11 Enterprise Standards and Domain Autonomy

The tension between standardization and autonomy is not unique to data architecture. Every enterprise architecture encounters it. Too much standardization can slow innovation. Too little standardization can create fragmentation. A useful principle is:

Standardize the things that must interoperate; allow variation where it does not create unacceptable enterprise risk.

For example, an enterprise may require every data product to provide:

• Ownership metadata
• Security classification
• Lineage
• Quality information

But it may allow domains to choose different internal transformation techniques. Similarly, the enterprise may require a common customer identifier while allowing individual domains to maintain additional domain-specific attributes. This creates controlled autonomy.

10.12 Data Products and Enterprise Information Architecture

Data products should not exist independently of enterprise information architecture. The information model provides the conceptual foundation. Consider the concept of Customer. Different domains may use the concept differently. Marketing may care about:

• Segmentation
• Campaign engagement
• Preferences

Risk may care about:

• Exposure
• Risk classification
• Financial relationships

Service operations may care about:

• Interactions
• Cases
• Service status

These are legitimate domain perspectives. Enterprise architecture should not necessarily force every domain to create one enormous physical customer model. Instead, the architect should establish shared semantic foundations. The enterprise may define:

• What a customer means
• How customer identity is represented
• Which attributes are authoritative
• Which reference standards apply

Domains can then create products aligned with their responsibilities. This is where enterprise information architecture and data product architecture meet.

10.13 Data Products and Master Data

Master data management remains relevant in a data-product-oriented architecture. In fact, data products can strengthen master-data practices if responsibilities are clearly defined. Suppose several domains maintain information related to customers. The enterprise may establish a customer master or authoritative identity capability. Other domains may then create specialized customer data products. For example:

• A Customer Identity Product may provide trusted identity information.
• A Customer Risk Product may provide risk-related information.
• A Customer Engagement Product may provide interaction information.

The architecture therefore does not require one physical dataset to satisfy every consumer. Instead, it creates multiple products that share common enterprise concepts and identifiers.

10.14 Data Products and Data Mesh Are Not the Same Thing

These concepts are related but distinct. An organization can create data products without implementing a full data mesh operating model. For example, a centralized data organization can own and operate high-quality enterprise data products. Conversely, an organization could decentralize ownership without creating well-managed data products. Therefore, a data product is primarily a design and operating concept for a data asset, while data mesh is a broader organizational and architectural approach. This distinction matters because enterprises should not adopt an organizational model simply because a particular architecture term is popular. The architecture should respond to business scale, organizational structure, regulatory environment, technology maturity, and actual data problems.

10.15 Data Products and the Modern Data Platform

The modern data platform provides the foundation on which data products operate. A domain should not need to independently implement:

• Identity management
• Encryption
• Pipeline orchestration
• Monitoring
• Metadata capture
• Deployment automation

These should ideally be reusable platform capabilities. The domain engineering team can then focus on:

• Domain logic
• Data transformation
• Product quality
• Business semantics
• Consumer requirements

This creates an important architectural separation:

• Platform capabilities are shared.
• Business data ownership is distributed.
• Enterprise policies are federated.

This is one of the central architectural patterns for large modern enterprises.

10.16 Data Product Lifecycle

A data product should have a lifecycle. It begins with a business need. The domain identifies the information required and its consumers. The product is designed, implemented, tested, published, monitored, evolved, and eventually retired. A conceptual lifecycle is:

Identify → Design → Build → Validate → Publish → Operate → Evolve → Retire

Each stage has architectural implications.

Identify

Understand consumers and business outcomes.

Design

Define semantics, interfaces, quality, and governance.

Build

Implement pipelines, transformations, and access mechanisms.

Validate

Test data quality, security, performance, and contract compliance.

Publish

Make the product discoverable and accessible.

Operate

Monitor usage, quality, freshness, and reliability.

Evolve

Manage changes while protecting consumers.

Retire

Deprecate the product responsibly when it is no longer needed.

The lifecycle prevents the data product from becoming another unmanaged enterprise dataset.

10.17 Data Product Discovery

A data product is valuable only if consumers can find and understand it. This makes discovery a critical platform capability. A consumer should be able to search for information using concepts such as:

• Customer
• Product
• Revenue
• Transaction
• Location
• Employee

The catalog should ideally provide:

• Description
• Owner
• Business domain
• Quality information
• Lineage
• Classification
• Access mechanism
• Usage guidance

This is where metadata and semantic architecture become increasingly important. A future enterprise data environment will not simply be a collection of datasets. It will be a network of discoverable information products connected through shared semantics.

10.18 Data Products and AI

The emergence of AI makes data products even more significant. AI applications require access to trusted enterprise context. A data product can provide that context in a controlled and reusable way. For example, an AI assistant supporting financial analysts may need:

• Customer information
• Account information
• Transaction history
• Regulatory policies
• Product definitions
• Risk information

Rather than allowing the AI application to connect directly to dozens of underlying systems, the architecture can expose governed information products. This creates a controlled boundary between enterprise information and AI applications. Data products may therefore become important building blocks for:

• RAG systems
• AI assistants
• Agentic applications
• Decision intelligence
• Machine learning
• Enterprise search

The architecture becomes:

Domain Data → Data Product → Governed Context → AI Application

rather than:

AI Application → Direct Access to Everything

The former provides a stronger architectural control point.

10.19 Data Products and Generative AI Context

Generative AI introduces a particularly important requirement: context. A language model can generate useful responses, but enterprise applications require access to current and authorized organizational information. Data products can provide structured and governed context. For example, a customer-service AI application might consume a customer-service data product containing:

• Customer profile
• Current service cases
• Product information
• Interaction history
• Service policies

The AI application does not need to understand the underlying operational architecture. The data product abstracts that complexity. This is an important evolution. Data products are not only analytical assets. They can become enterprise context interfaces.

10.20 Data Products and Semantic Consistency

Distributed ownership creates a potential problem. Different domains may use the same business term differently. Consider terms such as Customer, Revenue, Account, Product, Order, and Active Customer. These terms may have different meanings across domains. A data-product architecture therefore needs semantic governance. The enterprise glossary and information model should provide common definitions where shared understanding is required. This does not mean every domain must use identical terminology internally. It means that when information crosses domain boundaries, the meaning must be explicit. The Enterprise Data Architect plays an important role in identifying these semantic boundaries.

10.21 Anti-Patterns in Data Product Architecture

Data products can fail when organizations focus on terminology rather than architecture. Several anti-patterns are common.

Renaming Existing Datasets

Simply changing the name of a dataset to “data product” does not create ownership or consumer accountability.

Domain Decentralization Without Platform Support

Giving domains responsibility without providing shared infrastructure can create duplicated engineering effort.

Platform Centralization Without Domain Ownership

A highly centralized platform may still fail to establish business accountability.

Excessive Federation

If every domain defines its own standards without enterprise coordination, interoperability becomes difficult.

Excessive Standardization

If every domain is forced into identical implementation patterns, autonomy becomes meaningless.

Ignoring Consumers

A data product designed without understanding its consumers may become technically elegant but commercially irrelevant.

Treating Data Products as Permanent

Products need lifecycle management. Unused or obsolete products should be retired.

These anti-patterns reinforce the principle that data product architecture is fundamentally about operating model and accountability, not labels.

Case study: Meridian Financial Group

10.22 Data Products at Meridian Financial Group

Meridian’s centralized data organization had historically operated many enterprise datasets. The organization had created a large analytical environment, but business teams often complained that they could not easily determine:

• Who owned a dataset
• What a field meant
• Whether information was current
• Whether they could use it for a particular purpose

Meridian decided to introduce domain-oriented data products. The initial domains included:

• Customer
• Product
• Finance
• Risk
• Operations

The organization did not immediately reorganize every system around these domains. Instead, it began by identifying high-value information products.

Customer Domain

The customer domain established products covering:

• Customer identity
• Customer profile
• Customer relationships
• Customer lifecycle

Product Domain

The product domain established products covering:

• Product catalog
• Product attributes
• Product availability
• Product lifecycle

Finance Domain

The finance domain established products covering:

• Financial transactions
• Accounting information
• Revenue
• Balances

Risk Domain

The risk domain established products covering:

• Risk classifications
• Exposures
• Risk events
• Risk measures

These products shared enterprise identifiers and common metadata standards. Meridian’s central platform organization provided:

• Ingestion
• Storage
• Processing
• Orchestration
• Metadata
• Security
• Observability
• Deployment automation

Enterprise governance established common requirements for:

• Privacy
• Security
• Regulatory controls
• Data quality
• Lineage

Changing the Ownership Model

The most important change was not technical. It was accountability. Previously, the central data team was often expected to answer questions about business meaning. Under the new model, domains became accountable for the meaning and quality of their data products. The central platform team remained accountable for platform capabilities. Architecture remained accountable for enterprise alignment and standards. Governance remained accountable for policies and controls. This clarified responsibilities.

AI Use Case

Meridian later introduced an AI assistant for internal analysts. Rather than giving the assistant broad direct access to enterprise databases, the architecture allowed it to consume selected governed data products. This created a more controlled path to enterprise information. The AI application could retrieve appropriate context without needing to understand every underlying operational system. The data-product architecture therefore became part of Meridian’s AI architecture.

Practical Artifact: Enterprise Data Product and Domain Assessment

The following assessment can help determine whether an organization is ready to introduce domain-oriented data products.

Step 1: Identify Business Domains

Start with business capabilities and value streams. Identify domains that have:

• Meaningful business responsibility
• Identifiable information ownership
• Subject-matter expertise
• Significant data consumption

Do not begin by drawing technical system boundaries. Begin with business responsibility.

Step 2: Identify High-Value Data Products

For each domain, identify information that is:

• Frequently reused
• Business-critical
• Difficult to discover
• Expensive to reproduce
• Important to analytics or AI

Prioritize these products first.

Step 3: Establish Ownership

For every proposed product, identify:

• Business owner
• Technical owner
• Data steward
• Platform responsibility
• Governance responsibility

Avoid the ambiguous phrase “the data team owns it.” Ownership should be explicit.

Step 4: Define the Product Contract

Document:

• Business meaning
• Schema
• Identifiers
• Quality expectations
• Freshness
• Access mechanism
• Security classification
• Change policy

Step 5: Identify Shared Enterprise Concepts

Determine which concepts require enterprise consistency. Typical examples include:

• Customer
• Legal entity
• Product
• Location
• Currency
• Calendar
• Organization

Define the appropriate enterprise standards without unnecessarily centralizing all domain data.

Step 6: Assess Platform Enablement

Determine whether domains have access to shared capabilities for:

• Ingestion
• Processing
• Storage
• Orchestration
• Metadata
• Quality
• Observability
• Security
• Deployment

If every domain must build these independently, the organization may be decentralizing infrastructure rather than data ownership.

Step 7: Establish Federated Governance

Define which rules are enterprise-wide and which are domain-specific. Enterprise architecture should make the boundary explicit.

Step 8: Assess Consumer Experience

For each data product, determine whether a consumer can easily answer:

• What is this?
• Who owns it?
• Can I use it?
• How fresh is it?
• How reliable is it?
• How do I access it?
• What does each important field mean?
• What happens if it changes?

If these questions cannot be answered, the product is not yet sufficiently mature.

Data Product Maturity Model

This maturity model should be used as an assessment tool rather than as a mandatory transformation sequence.

Remember these

Key Takeaways

1. Data products make data ownership, quality, usability, and lifecycle explicit.
2. A data product is more than a dataset; it includes data, metadata, quality expectations, interfaces, documentation, and governance.
3. Business domains are often natural boundaries for data ownership because they contain business context and accountability.
4. Data mesh is an organizational and architectural approach, not simply a technology platform.
5. Domain ownership does not require every domain to build its own infrastructure.
6. Shared platform capabilities can enable decentralized ownership without creating duplicated technical foundations.
7. Federated governance balances enterprise standards with legitimate domain autonomy.
8. Data contracts establish predictable expectations between data producers and consumers.
9. Enterprise information architecture remains important because distributed data products still need shared semantic foundations.
10. Master data and enterprise identifiers continue to matter in domain-oriented architectures.
11. Data products can become important interfaces between enterprise information and AI applications.
12. Successful data-product architecture is fundamentally about accountability, consumer value, platform enablement, and governance—not terminology.

Think about your own organization

Architect’s Reflection

The most important lesson from data products and data mesh is not that enterprises should decentralize their data. It is that data ownership should be placed as close as practical to the business context that gives the data meaning. That distinction matters. Decentralization by itself is not an architectural objective. A distributed organization can easily become more complicated than a centralized one. The goal is not to maximize the number of teams that own data. The goal is to create clear accountability while maintaining enterprise interoperability.

This requires the Enterprise Data Architect to think beyond technology. The architect must understand:

• Business domains
• Organizational responsibilities
• Information ownership
• Platform capabilities
• Governance
• Semantics
• Consumer needs

The architect must also resist two opposite temptations. The first is to centralize everything because centralization feels easier to govern. The second is to decentralize everything because autonomy appears to increase agility. Neither is universally appropriate. The more sustainable architecture is usually somewhere between the two. Domains should own what they understand and control. Platforms should provide what should be reused. Enterprise architecture should define what must remain interoperable. Governance should define what must remain controlled. This creates an architecture in which autonomy operates within enterprise boundaries.

The emergence of AI makes this even more important. AI applications need access to enterprise context, but unrestricted access to every underlying system creates architectural, security, and governance challenges. Data products provide an intermediate layer. They allow the enterprise to expose information intentionally. That makes the data product concept larger than an analytics pattern. It can become part of the enterprise’s information delivery architecture. In this model, the enterprise does not simply expose databases. It exposes governed information capabilities. The distinction is subtle but significant. A database answers:

Where is the data stored?

A data product answers:

What information does the enterprise provide, who owns it, what does it mean, how trustworthy is it, and how can it be consumed safely?

That is a fundamentally more architectural question. As enterprises move toward intelligent applications, this distinction will become increasingly important. The future enterprise data architecture will likely not be a single centralized repository or a collection of disconnected domain systems. It will be a network of governed information products operating on shared platform capabilities and connected through common enterprise semantics. That network becomes one of the foundations of the intelligent enterprise.