mobile-logo
 

SAP has three names for a data product. Which one will you build?

11 nov

SAP has three names for a data product. Which one will you build?

by Clemens Krom
in Business Data Cloud, BW, Evenementen, SAP Datasphere
Comments

Part 2 of 6 on SAP TechEd 2026. Question one from the intro: which data product am I supposed to build?

SAP said “data product” in every session I attended, and I’m quite sure most of us don’t really know what it entails. Well, I didn’t anyway ;-). The word didn’t come from our world, and SAP put its own meaning on top of it. So before I get to the three names SAP uses, here is what a data product is, where the term comes from, and why you have built a few without calling them that.

A data product is a data set that is built and maintained the way a software product is. It has an owner, a known group of consumers, a defined interface, documentation, quality guarantees and a lifecycle. The data is no longer a by-product of a load that happens to land in a warehouse. It’s a deliverable someone is accountable for, and the people who use it are customers. The prevalent meaning comes from Zhamak Dehghani, who introduced it in 2019. Her starting point was the central lake that nobody owns and nobody trusts. Her answer was to make the domain that produces the data responsible for publishing it, as a product, with a checklist: discoverable, addressable, trustworthy, self-describing, interoperable and secure.

Now read that checklist with your BW hat on. BW Business Content was SAP-managed data products twenty years before the term existed. Extractors, InfoObjects, DSOs, cubes and queries, versioned, documented and activatable. A HANA delivery unit with calculation views, semantics and analytic privileges fits the description too. The reporting layer in LSA++ or the Virtual Data Model is the product-facing side in all but name, and an InfoObject or dimension view with its texts, attributes and hierarchies is more self-describing than most tables in a lake are today.

What our models often didn’t have was the other half of the checklist. A BW query wasn’t really reachable from outside SAP. The metadata could only be found inside BW and not outside it. Quality and freshness lived in the process chain monitor, where we looked but the user didn’t. Nobody in the business owned a cube, we owned all of them. And there was no real contract with the consumer about the data. Transports and versions were for us, not for them.

So that is how data products relate to BW and HANA. The thing we built could have been one, and the best ones effectively were. What was missing was everything around it: the owner, the interface and the promise to the consumer. Keep that in mind when SAP shows an agent building a data product in ten minutes. The ten minutes are mostly for the data part. The more difficult part of meaning and access will not be built.

Now to SAP’s version of the word. Slide 7 of DA100, SAP’s session on trusted business data for agents, defines a data product as data, meaning and access, and names who builds which one. SAP ships the existing products. Customer- and partner-built ones follow on the road map. The derived product “is what the agent creates”. I was looking for us, the BI professionals, in this presentation, but we’re not there. I use AI in almost all parts of my work these days, so an agent drafting a data product is familiar. Not being part of the creation process at all is new. Which of these products is still ours to build, and where did my SQL go?

DA100 slide 7

What SAP puts inside one data product: data, meaning and access, with the three questions underneath. At the bottom, who builds what: SAP, customers and partners later, and the agent. Slide: SAP, session DA100.

Before I can answer either question, I need to sort out what SAP means by data products.

SAP’s definition, and the “three types”

SAP used three words all week: primary, derived and custom data products. At first I thought there were three types. But that is incorrect. To understand why, we have to look at Open Resource Discovery (ORD), where the attributes behind the words are defined. ORD is a metadata standard that lets a system describe what it exposes, such as data products, in a machine-readable document so that a catalog can discover it without anyone registering it by hand. SAP wrote it for its own landscape, and every Business Data Cloud data product is described in it.

“In SAP, a Data Product is a dataset exposed for consumption outside the boundaries of the producing application via APIs and described by high quality metadata that can be accessed through the Data Product Catalog.” That is SAP’s definition, and slide 7 compresses it to data, meaning and access. In other words, a data product is a table plus a contract about what the table means and who may read it.

Primary and derived are two values of one attribute in that contract, called type. The ORD specification defines primary as “a producer aligned data product … typically served directly from an application and might not have input ports”. Think of the billing document from S/4HANA or the employee from SuccessFactors for example. Derived is “a data product that typically aggregates and combines data from multiple sources” and “must provide at least one input port”, which is a lengthy way of saying it is built from other data products. For example, “Billing and customer” in the DA100 demo joins two primary products and adds nothing new at the source. So it is derived.

SAP-managed and custom are not a type. They are ownership, a separate attribute in the same contract. In DA161 it is the field called Responsible, and for the product the agent built it read Customer. SAP-managed is what SAP ships and maintains. Custom, or customer-managed, is what we build.

DA161 step 12

Step 12 of the DA161 hands-on: the requirements document in the middle, the product metadata the agent proposes in the panel on the right. Responsible, in the red box, defaults to customer:vendor:Customer, and the agent asks whether to keep it. Screenshot: SAP, hands-on session DA161.

So there are not three types of data products but two. Primary and derived. Interestingly, there might be a third type in the future. Within the ORD specification the following is written: “To be clarified if we need an additional analytical type for data products that focus on calculating KPIs.” The KPI data product, the thing we build most, is the one SAP is not sure how to classify. Do these types sound familiar? They should, we’ve seen this before.

We have seen SAP’s models before

SAP-managed data products are, according to SAP’s own training material, built from the source tables and CDS views of the application, with SAP managing the extraction from source system to Business Data Cloud. So this is the fourth time SAP hands us its data model. BW Content, HANA Live, the CDS virtual data model in S/4HANA, and now the same kind of views packaged with ORD metadata. One thing though, I don’t know many customers who reported on HANA Live or the CDS views directly. Do you? We built our own models instead, and I expect most of you did the same.

The difference this time is the consumer. An agent can only see what is in the catalog. According to session AD263 the Knowledge Graph knows “what SAP systems can expose”, not “which APIs are active on your specific tenant”. SAP’s models will be used this time, because the agents have nothing else to look at. Your Z fields should be in there as well. The same training material says custom fields “are automatically included in the data extraction and land in SAP BDC as part of the SAP-managed data product”. However, the data models SAP ships on top of these data products ignore them. SAP’s advice is that customers “build their own custom data models” if they want to use them. So for the fields that are ours, we are back to building our own models.

What the agent actually does

Slide 14 of DA100 walks through the demo. You type one sentence: “Create a data product that combines billing documents and customer data.” The Data Product Creation Agent interprets the intent, asks the SAP Knowledge Graph which data products already exist, proposes joins and transformations, and persists and registers the result. About ten minutes from sentence to draft. The slide is just as explicit about what the agent does not do: “The review stays with you: join, grain, access policy, test, deploy.”

DA100 slide 14

One sentence in, a draft out in about ten minutes. The four steps in the middle are the agent’s. The review on the bottom line is yours. Slide: SAP, session DA100.

So the agent drafts and you decide. I wanted to know what that looks like in practice, so I attended the hands-on session DA161, Develop and Create Data Products in Joule Studio. The agent works like a coding agent with a plan mode. It writes an intent document, a product requirements document and a specification, all in markdown, and you confirm each one. Then you type “execute” and it builds. The result is a file tree: a transformation in CDS, a data product definition, an asset descriptor and a solution manifest. The graphical view of the transformation is read-only, with a SQL toggle next to it, and any change goes through the chat. SAP published the exercise on GitHub, so you can read all seventeen steps yourself.

DA161 step 3

The four stages on the left, the agent “investigating your business challenge against SAP’s Reference Business Architecture” on the right. Screenshot: SAP, hands-on session DA161.

Those three documents hold the business goal, the metric, the persona and every scope decision. I wonder if they end up in the Knowledge Graph next to the product. I couldn’t find anything that suggests they do. SAP’s TechEd news guide says the Knowledge Graph will take in customer-managed data products from Q1 2027, and the Ontology Manager, beta in November 2026, is where “your own relationships, rules and processes” go. So for now the intent stays a markdown file in the solution. It would be a waste if it stayed there.

DA161 step 13

The generated requirements document in the middle, the design decision on the right: precompute the share with a full refresh, or leave it to the consumer. At the bottom of the chat the agent runs into a SELECT alias it cannot reference. Screenshot: SAP, hands-on session DA161.

The exercise says up front that no experience with SQL, CDS or data modeling is required, and the persona in the generated requirements is a procurement manager. Then it asks you, by radio button, to decide five things I consider modeling.

  1. The purchase order has no supplier country, so the agent proposes the VAT registration country from the header as the best available field. Do you accept the proxy?
  2. Spend share and the risk flag can be computed inside the product, which forces a full refresh on every load, or left to the consumer. Which do you want?
  3. The share is computed within each currency, so the 30 percent threshold applies per currency and not to total spend, which is what the business goal said. Fine?
  4. A validity date filter cannot use the current date, so “active” becomes a key date the consumer applies. Omit the filter or hardcode a date?
  5. The agent proposes row-level authorization on the only two dimensions it has, country and currency. Expose both?

Each question is about a join, a level of detail, performance or an access policy. The agent is honest about all of them. But does the person deciding truly understand and oversee the decisions being made?

Which brings me back to my missing SQL. It’s a CDS file now, transformation.cds, written by the agent, with the SQL one click away in the viewer. And it’s SQL I recognize. Halfway through the build the agent’s chat reads “I realize I can’t reference a SELECT alias within the same SELECT list”, and it fixes that. Reading the agent’s code is the job now, and you cannot read what you could not write. The need for SQL skills doesn’t go away. The way you use them changes.

However, the above exercise is the happy flow. A colleague and I set out to break the system. And, much to the hilarity of SAP Product Management, ‘break’ it we did. We translated the exercise prompt into the words of a standard Dutch business user, one who doesn’t know data or BI architecture, but sure thinks they do ;-). Then, when the intent summary came, the agent thought it was a good idea to put features out of scope. As any BI consultant knows, putting something out of scope is quite difficult, especially if you don’t explain why. So the business user inside of us went full power and decided to put everything in scope. What the agent offers, I want! Before we knew it the agent tried creating n8n workflows, CAP applications and dashboards on top of the data model. Unfortunately, the Joule Studio we were working with wasn’t ready for this and it didn’t really lead to anything. But the potential, and its danger, is there. This also shows the importance of governance, of which I haven’t seen anything concrete yet. The last thing we want is any user spinning up CAP applications left and right.

At one point one of the product managers came to me and said, you’re doing stuff way beyond the scope of what should have been allowed. They said they would save the session logs to see how we did it. Compliments to the SAP team for being great sports and having fun with us.

DA161 n8n workflow

What “everything in scope” got us. On the left, the n8n workflow the agent built on top of the data product: a webhook trigger, a check against the concentration threshold, and Outlook and Teams alerts. On the right, Joule reports, in Dutch because that is how we talked to it, that all three components are ready: the data product, the alerting workflow and a dashboard. None of it deployed. Photo: hands-on session DA161.

Some small print. The hands-on ended at a Deploy button we were told not to press. Testing and deployment are “the next stage of the roadmap”, the preview is five rows of simulated data, and the authorization policy is configured but, in SAP’s words, enforcement “must be validated in a deployed runtime”. Ten minutes to a draft is real. Ten minutes to a data product is not yet. Furthermore, only S/4HANA Cloud Public Edition is supported in the beginning. If your customers run BW and S/4HANA in private cloud, this agent is not your tool this year.

DA100 slide 16

The road map for the Data Product Creation Agent: S/4HANA Cloud Public Edition only in Q4 2026, the rest from H1 2027, custom data products through the canonical model in that same column. Slide: SAP, session DA100.

What you can build today, with or without an agent

Custom data products exist already. You build them in Datasphere and publish them through the Data Sharing Cockpit: create a data provider profile, make sure the tenant is in a Business Data Cloud formation, create the product, set it to listed. Then it shows up in the catalog and can be shared with Databricks through Delta Sharing. At Interdobs we already build data products this way, and the data models behind them, with the help of AI tools. Not in Joule Studio, and not limited to S/4HANA Cloud Public Edition: it works today, on the systems our customers run now. What it does require is knowing those systems and how to get the metadata out of them.

How will all of this affect my work?

Here is my take, for now. The agent will help you a lot. The product it creates looks like the thing you can build by hand today. The review it leaves to you is the part that needs a data person: which join, which level of detail, which access policy. Slide 10 of DA100 puts the three layers next to each other, governance, meaning and data, and then asks the question that matters. “Who builds it?”

DA100 slide 10

A private copy per consumer breaks. Read the four red bullets on the left and you have most BW landscapes. Slide: SAP, session DA100.

The answer still sounds like us. We are never mentioned at TechEd. However, during the sessions I learned that we are still needed. What changes is where we spend our time. Less in data modeling, more in meaning and governance. I will come back to that in the last blog of this series.

Conclusion

  • A data product is a table plus an owner, an interface and a promise to the consumer. The agent’s ten minutes are for the data. The rest was always the hard part.
  • Primary and derived are the type attribute of a data product’s metadata and describe lineage. SAP-managed and custom are ownership. A product can be derived and custom at the same time, and a custom product can be primary.
  • SAP’s models will be used this time, because an agent can only see what is in the catalog. Your Z fields arrive with them, but nothing SAP ships on top knows them.
  • The Data Product Creation Agent drafts a derived product in about ten minutes and asks you to decide join, level of detail and access policy along the way, by radio button.
  • In Q4 2026 the agent covers S/4HANA Cloud Public Edition only. Everything else follows in 2027. Until then, custom data products can be built in Datasphere.
  • In DA161 the artifact was a CDS transformation, readable and changeable through the chat. Nothing was deployed or tested on real data. Make sure the review stays in code in your tenant, and add the test yourself.

At the end of the hands-on a product manager asked me whether I could see myself working like this. I already do. In VS Code, with agents that work on the Datasphere CSN files. I see the potential. However, when I thought about it more, I had some doubts. Right now I really enjoy it, because it’s new and offers possibilities I didn’t have before. But one of the great pleasures in BI, for me, is the difficult data model that doesn’t work and the hours it takes to find out why. That part goes to the agent. Maybe the pleasure moves too. I don’t know yet. I am sure of one thing: the old way of working is gone, and a career built only on that goes with it.

Next in this series: question two, where does my BW model end up living?

Questions about data products in SAP Business Data Cloud or Datasphere? You can always contact us. We would like to hear from you.

Sources

Header photo: SAP SE, from the SAP News Center.

Clemens Krom