15.2 Catalog & Metadata
1. What the catalog solves
The catalog provides an enterprise discovery surface for governed data and analytical assets.
Current SAP documentation distinguishes between assets and data products.
Assets can include data and analytical objects made available for discovery. Data products are packaged, consumer-oriented datasets exposed for use across supported systems and products.
The catalog is therefore not simply a list of tables.
It is a discovery and evaluation layer.
2. Catalog mental model
Source Systems
|
| metadata extraction
v
+--------------------+
| Catalog |
+--------------------+
| Search |
| Filters |
| Assets |
| Data Products |
| Terms |
| KPIs |
| Tags |
| Lineage / Impact |
+--------------------+
|
v
Consumer evaluates
|
+--> open source asset
|
+--> request / obtain data product
|
+--> build governed model
3. Metadata categories
Technical metadata
Examples:
- object name,
- column name,
- data type,
- source system,
- technical relationships.
Business metadata
Examples:
- business description,
- domain,
- owner,
- steward,
- business term,
- KPI definition.
Operational metadata
Examples:
- refresh expectation,
- last successful load,
- quality status,
- SLA/SLO,
- lifecycle state.
Governance metadata
Examples:
- classification,
- sensitivity,
- criticality,
- usage constraints,
- policy relationships.
4. Metadata is a product
A common mistake is treating metadata as administrative decoration.
For a consumer, metadata answers:
"Can I safely use this data?"
The answer requires more than a column list.
A high-quality catalog entry should allow a consumer to determine:
- what the data represents,
- whether it is authoritative,
- how fresh it is,
- where it originated,
- who owns it,
- what it means,
- how it can be accessed,
- what limitations exist.
5. Discovery workflow
Use this sequence:
- Search.
- Filter.
- Inspect description.
- Inspect business terms.
- Review lineage.
- Review impact.
- Check quality and freshness.
- Check ownership.
- Check access requirements.
- Decide whether to consume.
This is materially different from:
"I found a table with the right columns."
6. Catalog enrichment
Governed enrichment can include:
- descriptions,
- tags,
- glossary relationships,
- KPI relationships,
- classification,
- ownership context.
Enrichment should be targeted.
Do not create hundreds of low-value tags that nobody understands.
7. Search taxonomy
A useful enterprise taxonomy has several dimensions.
| Dimension | Example |
|---|---|
| Domain | Finance |
| Subject | Accounts Receivable |
| Data sensitivity | Confidential |
| Criticality | Tier 1 |
| Geography | Europe |
| Lifecycle | Production |
| Quality | Certified |
| Consumer type | Analytics |
Avoid encoding every business concept into one giant tag hierarchy.
8. Catalog governance workflow
Metadata extracted
|
v
Catalog administrator reviews
|
+--> classify
+--> enrich
+--> validate
|
v
Publish
|
v
Consumer discovery
|
v
Feedback / corrections
|
v
Continuous governance
SAP documentation describes catalog administration as a process of connecting sources, classifying and enriching assets, and publishing governed assets for discovery.
9. Catalog versus source system
The catalog should not become the system of record for every technical fact.
Prefer:
- source system for operational metadata,
- Datasphere for modeling metadata,
- catalog for enterprise discovery and governance context.
Where the catalog extracts metadata automatically, governance teams should enrich rather than manually duplicate information.
10. Catalog quality metrics
Measure:
- percentage of critical assets with owners,
- percentage with business descriptions,
- percentage with glossary relationships,
- percentage with lineage,
- stale metadata count,
- unpublished critical assets,
- duplicate assets,
- search success rate,
- consumer reuse rate.
Architect exercise
Define the metadata contract for a Tier 1 Finance asset.
Specify:
- mandatory fields,
- automated fields,
- steward-maintained fields,
- review frequency,
- quality gate,
- publication criteria.