bluetelligence Blog

From SAP Data Silo to Data Product—Rethinking Transparency, Governance, and Self-Service BI

Our guest author hits the nail on the head when he says, “The critical issue with data products isn’t just whether they work well on a platform. The real question is: Who owns the data and context?” If domain-specific definitions, quality rules, lineage, and data contracts exist only within a single solution’s metamodel, the result is not a data product but a lock-in product. Companies should therefore insist on data sovereignty: Data products must be able to function in SAP, but their significance must not be trapped within SAP.”

– Timm Grosser, Senior Analyst, Data & Analytics at BARC

That is exactly what this article will explore, drawing on a recent webinar on the topic. Why are data products necessary in the first place? What problems do they solve? And how can they be implemented in practice, particularly in the SAP environment?

What does Amazon have to do with Data Products?

Like in the webinar, we’ll start with an unusual comparison: Amazon.

In the past, looking for a book meant visiting various libraries or bookstores until you found the copy you wanted. Today, we expect information right away: We open Amazon, search for a product, and within seconds we get all the relevant information—from price and delivery time to reviews and recommendations.

We are increasingly applying this very same expectation to corporate data: Data should be easy to find, clearly described, and ready to use—just like a product in an online store.

The reality: Accessing data is often more complicated than it needs to be

In many companies, however, the reality is different: Employees often have no idea,

  • whether the required data even exists,
  • where it is stored,
  • whoever has access to it,
  • who is responsible for them, or
  • whether it can be trusted at all.

On top of that, data often has to be requested through the IT department first. Departments have to wait for access permissions or analyses, thereby losing valuable time.

This often leads to data silos or even shadow IT, because departments build up their own data sets. So the real problem isn’t a lack of data—it’s the difficulty in accessing it.

The Solution: Data Democratization and Data Products

To solve this problem, the concept of data democratization was developed a few years ago.

The idea was simple: Companies should move away from the traditional “need-to-know” principle. Until then, employees had to justify why they needed data. Access was primarily controlled by the IT department.

Instead, the “right-to-know” principle became increasingly established : Data should, as a general rule, be accessible to all authorized individuals. The goal was to enable self-service analytics and make business units less dependent on IT.

At first, this seemed to solve the original problem—but a new challenge soon emerged: The more data became available, the harder it was to make sense of it all. Suddenly, entirely different questions arose:

  • What data can I trust?
  • Which metric is the right one?
  • Who is responsible for this data?
  • Is the information up to date?
  • Am I even allowed to use this data?

While this openness led to greater accessibility, it also often resulted in reduced transparency and less trust in the data.

This is exactly where data products come in, and in the webinar, Timm Grosser (BARC) provided the following definition:

“The purpose of a data product is to democratize access to trustworthy, business-ready data while reducing complexity and shortening the time it takes for data users to gain insights.”

Source: BARC

Data products thus combine the openness of data democratization with the rules of clear data governance. A data product consists of more than just data.

It also combines

  • technical context,
  • Metadata,
  • Responsibilities,
  • Quality Information,
  • Rules of Use and
  • often also so-called “data contracts”.

This makes data not only accessible, but also understandable, trustworthy, and reusable.

Data Products in the SAP Environment

SAP is also consistently pursuing this approach: With the SAP Business Data Cloud (BDC), data from various SAP systems can be consolidated and then made available as data products, primarily in the BDC Catalog.

SAP distinguishes between two types of data products:

SAP Managed Data Products are delivered by SAP in a standardized form and can be used with relatively little effort. However, this requires a largely standardized SAP landscape without extensive custom developments.

In practice, however, things often look different: Many companies work with custom Z-tables, their own ABAP code, or specially developed data models. For these scenarios, Customer Data Products must be created using tools provided by SAP, allowing companies to model and maintain their own data themselves.

In addition, many companies today do not rely exclusively on SAP. Power BI, Microsoft Fabric, Snowflake, and Databricks are now just as much a part of the analytics landscape as traditional SAP systems. While data and data products can be integrated into the SAP Business Data Cloud with relative ease, data exchange in the opposite direction often runs into technological—and in some cases, contractual—limitations. This creates the risk of becoming more heavily tied to a single platform than originally planned.

In hybrid environments in particular, this raises the question of how data products can be implemented in a way that is as technology-agnostic as possible. One possible approach is to supplement existing systems with solutions that operate directly at the source system level—such as SAP S/4HANA, SAP ECC, or SAP BW. Instead of first cataloging data in a central SAP platform, these solutions provide transparency regarding existing data and metadata right where it is generated. This gives companies a complete overview of their SAP data while simultaneously laying the groundwork for data products that can be used independently of any specific target platform.

That’s correct for Data Products that are used externally. Within SAP, Data Products can also be built in Datasphere (+Marketplace).

The Enterprise Glossary by bluetelligence

If your company is amongst those who do not yet use a business data cloud or wish to remain technology-agnostic, implementing data products can be challenging. A logical first step would be to establish transparency regarding existing data assets and make existing data products discoverable and usable by business units.

For this purpose exaclty, we’ve developed a solution: the Enterprise Glossary. As a central web application, the Enterprise Glossary synchronizes metadata from SAP and Power BI systems, catalogs it centrally, and makes it available to business users in an easy-to-understand format.

Whenever departments need specific data, they can easily search for and find existing data products in the Enterprise Glossary:

Search/Find Published Data Products

Business users then gain a clear understanding of the technical background—without having to rely on IT support:

View the Technical Structure of Data Products (CDS View)

At the same time, you can check the sources of the data product at a glance: either in a list or in a graphical data flow:

Visualize cross-system data flow (e.g., from CDS views)

In addition to providing technical transparency, the Enterprise Glossary also enables the enrichment of data objects with domain-specific information. This transforms purely technical metadata into understandable, domain-specific data products that can be published and used in a targeted manner.

Enrich data products with subject-matter expertise and publish them as data products

In doing so, organizations create the essential conditions for successful data products:

  • Transparency over existing data

  • Discoverability for Business Users

  • Technical Context and Significance

  • Clear Responsibilities

  • Centralized Deployment and Governance

For example, if a business user wants to check whether a data product is already being used in front-end applications such as SAP Analytics Cloud, SAP BusinessObjects, or Power BI, the relevant relationships can be traced directly:

In which front-end objects are data products used? (Example: BW>SAC)

In future versions, the Enterprise Glossary will also make it possible to provide technical metadata and semantic enrichments to other platforms or AI use cases via a REST API in machine-readable formats.

In this way, the Enterprise Glossary provides a technology-neutral foundation for gradually developing and documenting data products and making them available company-wide.

Conclusion

Data Products make corporate data understandable, trustworthy, and usable by linking data to business context, responsibilities, and quality information.

With the Business Data Cloud, SAP offers an approach for delivering data products within the SAP environment. For many companies, however, the challenge remains of mapping heterogeneous system landscapes and maintaining flexibility over the long term.

The Enterprise Glossary provides the semantic foundation for this: It links technical metadata with domain-specific context across system boundaries and enables companies to make data products understandable, discoverable, and usable regardless of individual platforms.

For more information about the solution and to request a trial version, please visit our website:

back