SAP Data Products: Governed, Reusable Data as Business Assets

What Makes a Data Product Different From Data

Raw data is passive. A data product is intentional, governed, and designed to deliver business value. SAP Data Products bundle three elements: standardized data, business metadata (definitions, semantics, quality), and governance controls (versioning, access policies, ownership). This combination transforms data from a liability (unclear meaning, hidden quality issues, fragmented ownership) into a reusable asset. In one large enterprise I advised, the same "customer master" dataset had been rebuilt again and again by different teams. Each version had slightly different deduplication logic, different enrichment rules, different update cadences. The moment they converted one version into a formal data product with governance and versioning, adoption skyrocketed—not because the tool was better, but because everyone now had permission to stop rebuilding it.

A customer dataset sitting in a data lake is data. The same records curated with clear ownership, quality scorecards, documented dimensions (how is "customer" defined?), documented measures (revenue, tenure, lifetime value), access controls, versioning, and discoverable in a catalog — that is a data product. Other teams can find it, understand it, trust it, and build on it without rebuilding the same transformation fifty times. I have seen integration lead times fall sharply once organizations commit to data product discipline, because a large share of new requests can then be answered by composing existing products instead of building from scratch.

SAP Data Products carry business meaning along with data. When a consumer accesses a data product, they inherit the semantic definitions established by the product owner. This ensures consistency: all downstream analytics reference the same "customer," the same "revenue," the same business rules. The caution: data product governance is not free. I have also seen organizations declare "data products" without investing in stewardship, only to end up with a catalog of half-maintained datasets that no one trusts. The right path is to start with 3-5 high-value products, build deep governance and ownership around those, and expand systematically.

Data Product Lifecycle: From Studio to Consumption

SAP's data product lifecycle spans five stages: define, build, govern, share, and consume. Each stage is supported by specific SAP products and capabilities.

SAP data product lifecycle: define and build custom products in Datasphere today (Data Product Studio once generally available), govern them in the BDC catalog, and share them through BDC Connect.

Data Product Studio: Central Workspace (Announced, GA Not Yet Confirmed)

Data Product Studio is SAP's planned central, visual workspace to design, configure, and manage custom data products. It was announced at SAP TechEd 2025 with general availability planned for H1 2026, but general availability had not been confirmed when this guide was reviewed in November 2026. Here is what SAP has said it will do — and what you can already use today.

Reltio Integration: Master Data and Entity Resolution in Data Products (2026)

SAP's acquisition of Reltio (announced March 2026, completed May 7, 2026) brings enterprise master data management and entity resolution capabilities into the Business Data Cloud ecosystem. This is significant for data products because it addresses a critical bottleneck: the quality and consistency of foundational entities (customers, suppliers, products, locations) that data products depend on.

In traditional data product approaches, you often inherit master data quality problems. Your customer data product might define "customer" one way in your ERP and another way in your CRM. A Reltio-enabled data product approach connects data sources at the entity level, deduplicates records, and creates a golden record. When you publish that data product, it surfaces a single, reconciled, truth about that entity across all source systems—not conflicting definitions.

How Reltio Strengthens Data Products

In practical terms: at a financial services organization I worked with, their customer master data product was built on unreconciled SAP and Salesforce records. Loan officers, credit analysts, and operations teams all pulled different "customer" datasets. The same customer appeared three times with different hierarchies, credit limits, and contact information. Adding an MDM reconciliation layer before data product publication took a focused, multi-week effort, but it eliminated a systemic data trust issue. They went from "I don't know which customer dataset to believe" to "there's one golden record, maintained centrally, published as a data product," and decisions stopped stalling on reconciliation debates.

Since SAP Connect in October 2026, SAP Reltio has been generally available inside Business Data Cloud as a core multi-domain master data management capability rather than a third-party add-on. SAP has announced that unified data-product capabilities for SAP Reltio are planned for general availability in Q1 2027, so publishing reconciled golden entities directly as BDC data products is a near-term roadmap item rather than something to design around today. SAP's direction is clear: entity resolution becomes a first-class step in the data product lifecycle.

When to Invest in Reltio + Data Products

Consider Reltio-enabled data products if:

• You have master data fragmentation across multiple source systems (SAP, Salesforce, Legacy ERP, external data feeds).
• Downstream analytics depend on reconciled customer, supplier, product, or asset definitions.
• You need real-time or near-real-time golden records for customer 360, vendor risk, or product portfolio analytics.
• You are building data products that will be shared across functions or external platforms (via BDC Connect).

Defer Reltio if your data products are narrowly scoped (e.g., one finance cube, one supply chain view) and master data is already clean. Reltio's value scales with the breadth and complexity of your entity ecosystem.

BW Data Product Generator: Accelerate Legacy Migration

Organizations with SAP BW/4HANA or SAP BW 7.50 can accelerate data product adoption with the Data Product Generator for SAP Business Data Cloud, available once the BW system runs as a private cloud edition in BDC. It replicates data from BW InfoProviders into the object store of SAP Datasphere, where it can be published as custom data products, so teams reuse proven BW data instead of re-extracting it from source systems.

Supported BW Versions

• BW/4HANA 2023 SP0 and later
• BW/4HANA 2021 SP4 and later
• NetWeaver 7.50 SP24 and later

In practice, the generator moves the data; you still decide which subscriptions become data products (created in the Data Sharing Cockpit), how they are modeled in Datasphere, and who may consume them. Configuration is described in SAP Note 3590400. That split is healthy: it reduces migration effort without pretending that BW semantics translate automatically, and the resulting data products can be shared with SAP Databricks or, through BDC Connect, with external Databricks workspaces.

Not limited to BW: Datasphere-native data products are also supported, allowing teams that skipped BW to build custom data products from scratch in Datasphere today (and in Data Product Studio once it is generally available).

BDC Connect: Zero-Copy Sharing Across Clouds

BDC Connect enables SAP Data Products to be shared zero-copy (without replicating data) across enterprise and cloud platforms. This is critical for organizations using Databricks, Snowflake, or BigQuery alongside SAP analytics.

The key innovation is zero-copy sharing from the BDC object store over Delta Sharing. Rather than exporting data to each platform (expensive, stale, duplicate), BDC Connect gives every consumer a shared reference to a single source of truth. Consumers in Databricks, Snowflake, or BigQuery query the same underlying data as of its latest refresh in BDC; BDC decides which data products are shared with which platform, and each platform's own controls decide who can query them there.

Design Patterns for Self-Describing Data Products: Practical Guidance

A well-designed data product is self-documenting and requires minimal support from the owner. I've seen organizations ship hundreds of data products and struggle because none answered the most basic consumer questions: "Is this current? Can I trust it? What does this metric actually mean?" The design patterns below eliminate that friction.

Clear Naming and Semantics: Make Definitions Mandatory

Avoid cryptic abbreviations. Column names like CUST_ID, ACCT_REVENUE, CUST_CREATED_DT are instantly meaningful. But clear naming is not enough. In practice: Embed a data product dictionary directly in the product metadata. Define a "customer" once—legally. Is it a sold-to party, a bill-to party, or a parent account? Capture this in the data product's semantic definitions (in Datasphere today, and in Data Product Studio once it is available). When a consumer accesses the customer dimension, they see: "Customer = bill-to party per customer master data source records. Includes active and inactive as of last refresh. One record per customer ID. Refreshed daily at 06:00 UTC." This eliminates the spreadsheet passing, the repeated questions to the owner, and the divergent definitions across teams.

Focused, Reusable Building Blocks: The Modular Strategy

Instead of a monolithic "customer" data product with 200 columns, create three focused products: customer master (identity, attributes, geography), customer financials (revenue, margin, payment history), customer segmentation (tier, churn risk, value). Consumers combine building blocks based on their specific needs. I recommend this pattern: If your data product documentation is longer than one page, it's too large. If a consumer wants half your columns and ignores the other half, you've not split it correctly. Small, focused products scale because teams can onboard them quickly and understand exactly what they get. When Sales needs to enhance their reporting with Finance data, they don't rebuild revenue calculations—they subscribe to the Finance customer financials product.

Documented Lineage and Quality: Build Consumer Confidence

Every data product should answer: Where does this data come from (lineage)? How fresh is it (refresh frequency)? How complete is it (missing values)? Are there known data quality issues (error bounds)? Embed this metadata in the data product itself so consumers can assess fitness for use without contacting the owner. In real projects, I attach a "data product SLA" directly to the product in Datasphere. Example: "Customer Revenue Product v2.0 | Source: S/4HANA VBRK (billing documents) | Refresh: daily 06:00 UTC, 30-minute SLA | Completeness: 99.2% (0.8% records missing cost center due to BOM explosion issues, known in ERP—fix scheduled for the next ERP release) | Validation: revenue amounts reconcile to GL within 0.01% | Known Limitations: excludes disputed invoices (separate product available)." Consumers read this before building 17 reports on top of it. They know the failure modes. They know to contact you only when the SLA is breached, not every time they have a question.

Versioning and Backwards Compatibility

When you add a dimension or fix a calculation, keep old versions available for a transition period. Signal breaking changes well in advance. Implement semantic versioning: v1.0 (initial), v1.1 (backward-compatible enhancement), v2.0 (breaking change, requires consumer migration).

Governed Consumption Patterns

Some data products can be queried arbitrarily; others restrict to specific dimensions to protect privacy. Define these policies once, with the data product, and then implement them on both sides: BDC controls which platforms receive a data product, and each consuming platform (Unity Catalog, Snowflake roles, Google Cloud IAM) enforces who can query it there.

Key Data Product Metrics and Governance

Decision Framework: When to Invest in Data Products

Not every organization needs data products immediately. Here is a pragmatic decision framework:

Start with Data Products if...

• You have multiple teams rebuilding the same transformations (customer revenue, product cost, churn scoring). Duplication signals opportunity for a data product.
• You manage distributed analytics across multiple domains (Finance, Supply Chain, HR). Federated ownership via data products will scale better than centralized warehousing.
• You plan to share data across cloud platforms (Datasphere → Databricks/Snowflake via BDC Connect). Data products bundle the governance needed for zero-copy sharing.
• You want to delegate analytics infrastructure to business domains. Domain-owned products, governed in the BDC catalog, make that delegation safe; Data Product Studio is meant to make it easier once generally available.
• You are building a data mesh. Data products are the fundamental unit of a mesh-informed architecture.

Defer Data Products if...

• Your organization is in early analytics maturity. Start with Datasphere semantic layer and federated views; graduate to data products once teams understand semantic modeling.
• You have a single, stable analytics use case (e.g., one financial reporting system). Data products add governance overhead that may not pay off.
• You have not yet established source system data quality. Data products inherit quality problems; fix sources first.

Recommended Pilot Approach

Start small. Choose one high-value, high-reuse domain (often Finance or Supply Chain). Design 2-3 focused data products in that domain in Datasphere (or Data Product Studio once it is generally available). Pilot with 3-5 consuming teams. Track metrics: How many teams stopped rebuilding transforms? How much faster are they shipping analytics? Once pilot shows ROI, expand to other domains.

Implementation Roadmap: Progress So Far and the Road Ahead

Phase 1 — Foundation

• Choose the business domains (customer, product, finance) that would benefit most from governed, reusable data products.
• If BW runs as a private cloud edition in BDC, assess which InfoProviders to publish through the BW Data Product Generator.
• Pilot the BDC catalog and custom data products in your Datasphere environment.

Phase 2 — Build-out

• Set up data product governance in the BDC catalog (terms of use, steward approval, access agreements — available since September 2026).
• Share with partner platforms where they are already strategic: BDC Connect is generally available for Databricks (since October 2025), Snowflake (since May 2026), and Google BigQuery (since July 2026).
• Define versioning and breaking vs. non-breaking change criteria for published data products.

Phase 3 — Scale (what to watch next)

• Data Product Studio: general availability was planned for H1 2026 but had not been confirmed at the time of this review. When it lands, decide which products move to studio-managed lifecycle.
• SAP Reltio data-product capabilities (GA planned for Q1 2027), the Apache Iceberg lakehouse (Q1 2027), and BDC Connect for Amazon Athena (H1 2027); Microsoft Fabric remains in preview.
• Retire legacy, non-data-product data assets; migrate consumers to governed data product equivalents.

Why SAP Data Products Matter

Data products solve three critical problems:

Discovery: Consumers no longer must ask "Where is the current revenue definition?" or "Who owns the customer master?" Data products are discoverable in the Business Data Cloud catalog with clear ownership, documentation, and terms of use.

Governance: Data products eliminate shadow definitions. When Sales says "customer" and Finance says "account," a data product enforces one definition. Versioning and access controls prevent uncontrolled changes that break downstream analytics.

Scaling: With data products, teams stop rebuilding the same transformations. Instead of twenty analysts writing twenty versions of "customer revenue," they reuse one data product. This multiplies analytics velocity while reducing maintenance burden.

SAP's building blocks—the BW Data Product Generator, data product governance in the BDC catalog, BDC Connect zero-copy sharing, and Data Product Studio still to come—position data products as first-class assets in the SAP analytics platform. Combined with Datasphere's semantic layer, SAP data products carry business context from SAP's application portfolio into Databricks, Snowflake, and BigQuery rather than competing with them.