Skip to main content

15.7 Data Product Lifecycle & Access

1. Lifecycle is an operating process​

A product should not jump from:

"Someone built it"

to:

"Everyone uses it."

Use controlled lifecycle stages.

Idea
 |
 v
Design
 |
 v
Build
 |
 v
Validate
 |
 v
Publish / List
 |
 v
Consume
 |
 v
Maintain
 |
 v
Deprecate
 |
 v
Retire

SAP data product features have their own lifecycle states. Current SAP documentation, for example, describes states including Draft, Listed, Delisted, and Deactivated for Data Marketplace data products.

2. Publication gate​

Before publication, verify:

  • ownership,
  • description,
  • glossary relationships,
  • quality,
  • lineage,
  • access requirements,
  • documentation,
  • operational readiness,
  • consumer support model.

3. Access request lifecycle​

Consumer
   |
   v
Discover
   |
   v
Request access
   |
   v
Business / steward review
   |
   v
Decision
   |
   +--> Reject
   |
   +--> Approve
            |
            v
       Install / provision
            |
            v
       Consume
            |
            v
      Review / expire

Current SAP documentation includes catalog-based access requests and agreements for data products. Exact privileges and workflows depend on the product and tenant configuration.

4. Access is not ownership​

A consumer having access does not mean the consumer owns the product.

The provider remains accountable for:

  • product quality,
  • lifecycle,
  • documentation,
  • supported behavior.

5. Change management​

Classify product changes.

Non-breaking​

Examples:

  • metadata enrichment,
  • additional optional information,
  • performance improvement without semantic change.

Potentially breaking​

Examples:

  • key changes,
  • grain changes,
  • meaning changes,
  • removed fields,
  • unit changes,
  • time semantics changes.

6. Versioning strategy​

For important products, define:

  • compatibility policy,
  • release cadence,
  • deprecation window,
  • notification policy,
  • migration guidance.

Do not introduce versioning merely because it sounds enterprise-grade. Use it when consumers need compatibility guarantees.

7. Product deprecation​

A deprecation process should include:

  1. identify consumers,
  2. announce timeline,
  3. publish successor,
  4. provide migration guidance,
  5. monitor remaining usage,
  6. restrict new adoption,
  7. retire after agreed window.

8. Data product operational KPIs​

Recommended measures:

Freshness compliance
Quality compliance
Availability
Access-request lead time
Consumer adoption
Incident rate
Mean time to recovery
Deprecation completion

9. Schema evolution​

A schema change is also a governance event.

For a material change:

Change proposed
    |
Impact analysis
    |
Consumer classification
    |
Compatibility assessment
    |
Approval
    |
Test
    |
Release
    |
Monitor

Current SAP documentation also provides mechanisms for checking and resolving schema inconsistencies for installed data products. Treat such changes as operational events rather than silent technical updates.

Architect exercise​

A Tier 1 data product has 70 consumers. A key column must change.

Design:

  • impact assessment,
  • communication,
  • compatibility strategy,
  • migration period,
  • monitoring,
  • rollback or recovery plan.