This is Part 4 of our SAP Business Data Cloud for Data Engineers series. In Part 1 we covered what BDC is. In Part 2 we mapped the architecture. In Part 3 we covered the Databricks integration in depth. Now we get into the concept that sits at the heart of everything BDC does — Data Products.
The concept that changes how you think about enterprise data
Marie had been on the BDC project for three weeks when Laurent asked her to design the Data Product architecture for RetailCo.
She opened a blank architecture document and stared at it.
She had built Delta Lake tables. She had built dbt models. She had built Power BI datasets. She had built ADF pipelines. She had a strong mental model of what each of those things was, what it was for, and how to design it well.
She was not entirely sure what a Data Product was. And she was even less sure how it was different from everything she had already built.
This is the question that every data engineer asks on their first BDC project. And it deserves a proper answer — not the marketing answer, but the engineering answer.
What a Data Product actually is — the engineering definition
Data Products are the fundamental building block of SAP Business Data Cloud. They serve as a standardised and efficient way to share and consume data across applications and domains. They enable analytic scenarios, AI applications, and facilitate data integration while being optimised for intensive reads. Managed with a product mindset, they are supported by high-quality metadata and governed by decentralised ownership principles. (Sap)
That is the official definition. Now let us translate it into something a data engineer can work with.
A Data Product in BDC is a governed, documented, versioned, and published dataset — with a stable interface, a defined owner, clear SLAs, and business semantics embedded in its structure.
The key word that separates a Data Product from a regular table or view is the word product. A product is something designed for someone else to use. It has a stable interface that consumers can rely on. It has documentation that explains what it contains and how to use it. It has an owner who is accountable for its quality. It has a version history. It changes according to a defined contract with its consumers rather than arbitrarily whenever the builder feels like it.
A table in your Delta Lake is not a Data Product. It might be one — if it has all of those properties. But most Delta Lake tables do not. They are internal implementation details of a pipeline, not stable interfaces designed for broad consumption.
The distinction matters enormously in a large enterprise. When fifty teams consume data from a single source — the question of whether that source is an internally managed pipeline detail or a formally governed Data Product determines whether changes cause silent breakage across fifty downstream consumers or are managed through a versioned contract that gives consumers time to adapt.
The two types of Data Products in BDC
The unifying layer is the BDC Data Product Studio — a central hub where data architects define, govern, and publish data products that can be consumed by Joule’s AI agents, SAC planning models, and third-party BI tools alike. (SAVIC Technologies)
In practice every BDC implementation works with two categories of Data Products and understanding the distinction is the first design decision you make.
SAP-Delivered Data Products are pre-built by SAP and shipped as part of the BDC platform. They cover standard SAP business processes — Financial Accounting, Procurement, HR Headcount, Supply Chain, Asset Management. When you install BDC and connect your S/4HANA system, these Data Products become available automatically after configuration. You do not build them. You do not maintain them. When SAP releases a new version of S/4HANA, SAP updates the corresponding Data Products. Your consumers get the update without any engineering work from your team.
The practical analogy — SAP-Delivered Data Products are like the operating system libraries that come with your Mac. You do not build them. You use them. They are maintained by the vendor. They follow a stable interface. When you update the OS, the libraries update and your applications continue to work.
Data product search and creation: Joule Agents simplify how users discover and create data products. With natural language prompts, users can identify relevant SAP and third-party data sources, perform joins and transformations automatically, and apply business context and governance policies. (SAP)
Customer Data Products are built by your data engineering team using the Data Product Studio. They take SAP-Delivered Data Products as inputs, combine them with non-SAP data from your Databricks Delta Lake or Azure Data Lake, apply organisation-specific business logic, and publish the result as a governed Data Product that the rest of the organisation can consume.
These are where data engineers create the most value on BDC projects. The SAP-Delivered Data Products give you a governed, contextually rich starting point. Your Customer Data Products build on that starting point to answer the business questions that SAP’s standard content does not cover.
For RetailCo, Marie’s team built four Customer Data Products. The Unified Revenue Data Product combined S/4HANA financial actuals with e-commerce transaction data from Azure. The Store Performance Data Product joined S/4HANA cost data with the loyalty programme engagement data and external foot traffic metrics. The Demand Forecast Data Product published the ML model outputs from Databricks back into BDC as a governed dataset. The Sustainability Data Product combined SAP procurement data with carbon emissions data from an external provider.
None of those existed in SAP standard content. All of them were built on top of SAP-Delivered Data Products that provided the governed SAP data foundation.
The Data Product Studio — your engineering environment
The Data Product Studio — the main tool for creating governed, reusable datasets inside BDC — became generally available in H1 2026. This is important because it moves BDC from a concept into something teams can actually use day-to-day without heavy technical involvement. (Crave Infotech)
The Data Product Studio is the tool you use to build Customer Data Products. Understanding what it provides and where its boundaries are is essential before designing your implementation approach.
The Data Product Studio brings structure to the full data product lifecycle, enabling faster innovation while maintaining consistency across the business data fabric. Teams can leverage metadata from the data catalogue to define schemas, lineage, and transformation logic, apply SQL-based transformations, and manage versioning and governance through a shared domain catalogue. (Sap)
In practice the Data Product Studio gives you four capabilities that work together:
Visual data modelling — a graphical interface where you connect source Data Products, define joins, apply filters, and shape the output schema. Similar to the graphical transformation interface in Azure Data Factory or the diagram view in dbt. The visual interface is accessible to data engineers who think graphically — and to data architects who need to review and approve Data Product designs without reading SQL.
SQL-based transformations — for engineers who prefer code, the Data Product Studio supports SQL transformations directly. You write the transformation logic in SQL, the Studio validates it against the source schemas, and the result becomes part of the Data Product definition. Version controlled. Reviewable. Auditable.
Metadata and documentation management — the Studio enforces documentation as part of the Data Product creation process. You define business descriptions for the Data Product and for each field it exposes. You assign an owner. You specify the refresh frequency and SLA. You tag it with business domain classifications. This metadata is not optional — it is part of the publication process. You cannot publish a Data Product without it.
This enforcement is initially annoying to data engineers who are used to creating tables and views without documentation requirements. It is also genuinely valuable. A Data Product catalogue where every dataset has complete business descriptions, clear ownership, and explicit SLAs is dramatically more useful for data consumers than a Delta Lake catalogue where most tables have no description and ownership is unclear.
Lifecycle management — the Studio manages versioning of Data Products. When you need to change the schema of a published Data Product — adding a new field, renaming a column, changing a data type — the Studio provides a versioning workflow that notifies consumers of the change, provides a deprecation timeline for the old version, and manages the transition period where both versions coexist. The equivalent of semantic versioning for APIs.
The five engineering decisions that determine Data Product quality
Designing a good Data Product is different from designing a good database table. The difference is the consumer orientation — a Data Product is designed from the consumer’s perspective, not the producer’s perspective.
Here are the five decisions that determine whether a Data Product becomes a trusted asset that the organisation builds on — or a technical liability that everyone works around.
Decision 1 — Granularity
The most common Data Product design mistake is choosing the wrong level of granularity. Too granular and consumers spend all their time aggregating and joining. Too aggregated and consumers cannot answer the questions they need to answer.
For a Financial Statement Data Product the question is whether to expose individual GL line items or pre-aggregated period totals. Line items give consumers maximum flexibility — they can aggregate any way they need. But a Data Product exposing 50 million GL line items per year is slow to query and expensive to share via Delta Sharing.
Period totals by cost centre and account give consumers fast query performance and cover 80 percent of reporting use cases. But a consumer who needs to analyse individual transaction patterns cannot use it.
The right answer for most BDC implementations — design at the lowest granularity that covers your highest-priority use cases, and build aggregated Data Products on top for consumers who need summary-level performance. Two Data Products serving different consumer needs rather than one Data Product trying to serve all needs simultaneously.
Decision 2 — Business context completeness
The entire value proposition of BDC Data Products over regular Delta Lake tables is the preservation of business context. If you build a Customer Data Product that strips out the organisational hierarchy, removes the currency dimension, or flattens the account structure — you have built a Delta Lake table with extra steps.
Before publishing any Customer Data Product, audit what business context from the underlying SAP-Delivered Data Products is still present in your output. Ask these questions:
Can a consumer understand what cost centre hierarchy this data belongs to? Can they filter by profit centre without joining another table? Is currency and exchange rate information embedded or do they need to look it up elsewhere? Can they navigate the account hierarchy to get from individual accounts to P&L line items? Is the fiscal calendar represented so that period comparisons work correctly?
If the answer to any of these is no — your Data Product is losing business context that it should be preserving. Fix the design before publishing.
Decision 3 — Consumer contract design
A Data Product’s schema is a contract with its consumers. The fields you expose, the names you give them, the data types you use, and the relationships between them define what consumers can build on top.
Breaking changes to that contract break every consumer simultaneously. In a large enterprise where a Data Product might be consumed by SAC dashboards, Databricks ML models, Joule AI agents, and SAP HANA Cloud applications — an unexpected schema change is a significant incident.
Design the consumer contract carefully before first publication. Use consistent naming conventions across all Data Products in your domain. Define explicit nullability for every field — a consumer who discovers that a field they depend on can be null in production after building a model on it will not trust your Data Products again. Document what each field means in business terms, not just technical terms.
And most importantly — version your Data Products from the first release. Treating version 1.0.0 as a throwaway prototype that you will clean up later leads to technical debt that never gets cleaned up because by the time you want to do it, consumers have already built on version 1.0.0 and cannot absorb breaking changes.
Decision 4 — Ownership and domain alignment
Data Products are managed with a product mindset, supported by high-quality metadata and governed by decentralised ownership principles. (Sap)
Decentralised ownership means different domains own different Data Products. The finance domain owns the Financial Statement Data Product. The supply chain domain owns the Inventory Data Product. The HR domain owns the Headcount Data Product.
This sounds obvious until you try to implement it. In most organisations the data engineering team is a centralised function that has historically owned all data assets. Transitioning to a model where domain teams own their Data Products — with the data engineering team providing platform support and governance standards rather than owning the data itself — requires a change in organisational mindset that is often more difficult than any technical challenge.
The practical advice — start with the domains that have the clearest ownership of their data and the most mature data culture. Finance teams that have been doing their own month-end data reconciliation for years are often better prepared for Data Product ownership than teams that have always relied on central data engineering for everything.
Decision 5 — Refresh strategy and SLA definition
A Data Product without a defined refresh SLA is not a product. It is a promise with no commitment. Consumers need to know how current the data they are consuming is — whether it was refreshed in the last hour, the last day, or the last week — and they need to know they can rely on that refresh happening consistently.
Define explicit SLAs for every Data Product before publication. The Financial Statement Data Product refreshes daily at 06:00 CET with a maximum acceptable delay of 30 minutes — if the refresh has not completed by 06:30, an alert fires and the SLA breach is logged. Consumers who build morning CFO dashboards on this Data Product can reliably schedule their reports at 07:00 knowing the data will be current.
The Demand Forecast Data Product refreshes weekly on Monday mornings using the previous week’s Databricks ML model run. The Inventory Data Product refreshes every 15 minutes via a near-real-time BDC replication flow from S/4HANA.
Different Data Products. Different SLAs. All explicitly defined. All monitored. All communicated to consumers in the Data Product catalogue metadata.
How Joule changes Data Product design
SAP Master Data Governance is now a core component of SAP Business Data Cloud, governing master data and policies across your business data fabric. To ensure data is AI-ready, governance must shift from regulator to value accelerator. (SAP)
The emergence of Joule as a primary consumer of BDC Data Products introduces a design constraint that most data engineers have not had to think about before — AI readability.
A Data Product designed for human analysts who understand the business domain can use technical field names, implicit relationships, and domain-specific codes that the analyst knows how to interpret. A Data Product that Joule needs to answer business questions must be designed so that an AI system can understand what each field means and how it relates to other fields.
Practically this means:
Business descriptions are not optional decoration — they are the semantic layer that Joule uses to understand what a field contains. A field named cost_ctr_id with no description gives Joule nothing to work with. A field named cost_ctr_id with the description “The unique identifier for the organisational cost centre responsible for this expense, linked to the cost centre hierarchy in the Organisational Structure Data Product” gives Joule enough context to answer questions about cost centre spending correctly.
Relationships between Data Products need to be explicit — Joule needs to know that the cost_ctr_id in the Financial Statement Data Product relates to the cost_ctr_id in the Organisational Structure Data Product. Implicit joins that an analyst would figure out from domain knowledge need to be formally defined in the Data Product metadata.
Code fields need decode Data Products — a field containing values like A, B, C for document type codes is useless to Joule without a companion Data Product that maps those codes to business descriptions. Build decode or lookup Data Products for every code field that business users and Joule need to interpret.
With natural language prompts, users can identify relevant SAP and third-party data sources, perform joins and transformations automatically, and apply business context and governance policies automatically. (SAP)
The direction SAP is heading — Joule will eventually help users build Data Products themselves using natural language. “Create a Data Product combining revenue from S/4HANA with customer lifetime value from our CRM” becomes a Joule prompt that generates the Data Product definition, which a data engineer then reviews and approves before publication. Data Product design shifts from a purely technical activity to a collaborative one between business users, Joule, and data engineers.
That future is not fully here yet in 2026. But designing your Data Products with AI readability in mind now prepares you for it.
The Data Product governance framework — what you actually implement
Governance across every layer is underpinning all of this, embedded by design. This includes end-to-end lineage across data, models, and decisions. (Sap)
Governance in BDC is not a separate layer you bolt on after building your Data Products. It is embedded in the Data Product lifecycle from the first line of definition.
Here is what the governance framework looks like in practice on a BDC implementation:
Data catalogue — every published Data Product appears automatically in BDC’s central data catalogue. Consumers can discover Data Products, read their business descriptions, understand their ownership and SLAs, and request access — all through a single interface. No separate catalogue tool. No manual catalogue maintenance. The catalogue is a live reflection of what has been published in the Data Product Studio.
Access control — access to Data Products is managed through BDC’s governance layer. Data engineers define which roles can consume which Data Products. When a Databricks data scientist needs access to the Financial Statement Data Product — they request access through the catalogue, the Data Product owner approves, and access is granted automatically across all consumption channels simultaneously. The same approval grants access in Databricks via Unity Catalog, in SAC, and in SAP HANA Cloud if applicable.
Lineage — BDC tracks complete end-to-end lineage for every Data Product. The lineage graph shows that the Unified Revenue Data Product was built from the Financial Statement SAP-Delivered Data Product and the E-commerce Customer Data Product, that the Financial Statement Data Product comes from S/4HANA via a BDC replication flow, and that the E-commerce Data Product comes from a Databricks Gold layer table via Delta Sharing. When a consumer asks why their revenue number changed — lineage lets you trace the data back to its source in minutes rather than days.
Quality monitoring — BDC supports data quality rules defined at the Data Product level. A rule that the Financial Statement Data Product must contain complete data for all 80 RetailCo cost centres fires an alert if any cost centre’s data is missing after refresh. A rule that no revenue figure should be negative catches extraction errors before they propagate to consumers. Quality rules are defined once on the Data Product and apply to every consumption channel automatically.
Real engineering patterns from the field
Based on current BDC Data Product implementations here are the patterns that consistently work well — and the ones that consistently cause problems.
Pattern that works — SAP Data Product plus Azure Data Product combination
Take an SAP-Delivered Data Product as your governed foundation. Identify the non-SAP data from your Azure or Databricks environment that your business users need alongside it. Build a Customer Data Product in the Data Product Studio that joins the two. Publish the result.
This is the highest-value Data Product pattern because it creates something that neither SAP nor your existing data platform could produce alone. The business context from SAP combined with the breadth of your non-SAP data landscape.
RetailCo’s Store Performance Data Product is a textbook example. SAP cost data for each store from S/4HANA combined with foot traffic data from external sensors combined with loyalty programme engagement from Azure. No single source contained all three. The Data Product combined them into a single governed dataset that the retail operations team consumed in SAC without knowing or caring where each element came from.
Pattern that works — ML output as governed Data Product
Train your ML model in Databricks. Publish the model outputs back to BDC as a governed Data Product via the BDC Python SDK. Consumers access the forecast in SAC Planning as if it were any other Data Product — with lineage showing exactly which model version produced it and which input Data Products it was trained on.
This pattern solves the auditability problem that plagues ML-in-planning implementations. When the CFO asks why the forecast changed significantly from last month — lineage shows that the Demand Forecast Data Product version 2.1.0 was produced by ML model version 3.4.2 trained on the Inventory Data Product and the Historical Sales Data Product. Auditable. Explainable. Trustworthy.
Pattern that causes problems — too many fine-grained Data Products
A common first-project mistake is creating a separate Data Product for every table or view in your domain. Fifty SAP tables becomes fifty Data Products. Consumers then need to join fifteen Data Products to answer a simple business question — which defeats the purpose of the Data Product abstraction.
The right pattern — group related data into business-oriented Data Products that answer specific analytical questions. The Financial Statement Data Product contains everything a finance analyst needs to build a P&L report — not the five individual tables that underlie a P&L calculation. Design from the consumer question backwards, not from the source table structure forwards.
Pattern that causes problems — ignoring SLA definition until go-live
Data Product SLAs defined after go-live are not SLAs. They are retrospective descriptions of what the system happened to deliver before anyone paid attention. Consumers who built dashboards and ML models assuming hourly refresh discover at go-live that the actual refresh frequency is daily. Significant rework follows.
Define SLAs in the first design workshop. Build the refresh infrastructure to meet those SLAs. Test SLA compliance in UAT before go-live. Make SLA compliance a go-live criterion.
What Part 5 covers
Part 4 gave you the complete Data Product picture — what they are, the two types, the Data Product Studio, the five key design decisions, how Joule changes your design approach, the governance framework, and real engineering patterns.
Part 5 connects BDC to Azure specifically — the integration architecture, connection patterns, identity management, and the specific engineering decisions that determine whether a BDC and Azure implementation is robust or fragile.
The complete BDC for Data Engineers series:
- Part 1 — What is SAP Business Data Cloud and why should data engineers care? (published)
- Part 2 — SAP BDC Architecture — the data engineer’s translation guide (published)
- Part 3 — SAP BDC and Databricks — partners not competitors (published)
- Part 4 — SAP BDC Data Products — design, governance and engineering decisions (you are here)
- Part 5 — Connecting SAP BDC to Azure — the integration architecture (coming soon)
- Part 6 — SAP BDC vs your current stack — honest migration considerations
- Part 7 — SAP BDC governance and security — for engineers who care about data quality
- Part 8 — SAP BDC certification guide — C_BCBDC for data engineers
Subscribe below to get notified when Part 5 publishes.
Related reading on Data Cloud Insights
- SAP Business Data Cloud for Data Engineers — Part 1
- SAP BDC Architecture — Data Engineer Translation Guide
- SAP BDC and Databricks Integration
- SAP BDC Architecture Explained with Real Examples
Published by the Data Cloud Insights team — SAP data professionals with hands-on implementation experience across Europe, bridging modern cloud data engineering and the SAP BDC ecosystem.
