Skip to main content

15.6 Data Products

1. What is a data product?​

A data product is not simply a table with a better name.

A useful architectural definition is:

A data product is a governed, consumer-oriented data offering with a clear purpose, owner, contract, lifecycle, and supported consumption path.

Current SAP documentation describes data products as coherent datasets accessible through APIs and distinguishes marketplace data products created and used within SAP Datasphere from data products provided by SAP and supported partners.

2. Data product versus dataset​

DatasetData Product
Technical objectConsumer offering
Producer-focusedConsumer-focused
May lack ownershipExplicit ownership
May have implicit meaningDefined business meaning
May be temporaryLifecycle managed
Often implementation-orientedContract-oriented

3. Data product anatomy​

                 DATA PRODUCT
                      |
       +--------------+--------------+
       |              |              |
    Purpose        Contract       Ownership
       |              |              |
    Domain       schema / meaning   provider
    Consumers    freshness          steward
    Use cases    access model
       |
       +--------------+--------------+
                      |
                Quality & Trust
                      |
             +--------+--------+
             |        |        |
          lineage  quality  documentation
                      |
                  Lifecycle
                      |
          Draft -> Listed -> ...

The exact lifecycle states and capabilities depend on the SAP data product mechanism being used.

4. Product thinking​

Start with consumer need.

Bad:

"We have a table containing sales data. Let's publish it."

Better:

"Sales Operations needs a governed daily customer-order dataset for regional performance analysis."

Then define:

  • consumer,
  • use case,
  • grain,
  • scope,
  • refresh,
  • quality,
  • access,
  • ownership.

5. Data product contract​

A strong contract states:

Identity​

  • product name,
  • provider,
  • domain,
  • purpose.

Data​

  • entities,
  • grain,
  • keys,
  • important fields,
  • semantic definitions.

Operational​

  • freshness expectation,
  • availability,
  • known latency,
  • quality expectations.

Governance​

  • classification,
  • permitted use,
  • owner,
  • steward,
  • lifecycle.

Consumption​

  • access method,
  • supported consumers,
  • request process,
  • documentation.

6. Product granularity​

Do not make one enormous enterprise product.

Do not make one product per column.

A useful product boundary usually follows:

  • business capability,
  • consumer need,
  • ownership boundary,
  • stable semantics,
  • manageable lifecycle.

7. Product architecture​

Source Domains
     |
     v
Curated / Semantic Layer
     |
     v
Governed Data Product
     |
     +--> Analytics
     +--> Planning
     +--> Data Science
     +--> Other supported consumers

8. Internal versus marketplace products​

Current SAP Datasphere documentation distinguishes data products in the Catalog from Data Products (Marketplace), which is specifically associated with data products created and used within SAP Datasphere.

Architects must understand the actual product mechanism before promising:

  • licensing,
  • external distribution,
  • cross-landscape behavior,
  • installation,
  • updates.

Never infer product capabilities from the generic phrase "data product."

9. Product success metrics​

Measure:

  • active consumers,
  • reuse rate,
  • failed access requests,
  • quality incidents,
  • freshness compliance,
  • product adoption,
  • consumer satisfaction,
  • time to discover,
  • time to obtain access.

Architect exercise​

Design a Customer 360 data product.

Include:

  • business purpose,
  • entities,
  • grain,
  • owner,
  • quality rules,
  • freshness,
  • classification,
  • access model,
  • lifecycle,
  • three consumer personas.