15.10 Governance Playbook & Architect Checklist
Production governance checklist
Governance
- Enterprise governance principles are documented.
- Domain ownership is explicit.
- Decision rights are defined.
- Escalation paths exist.
- Criticality tiers are defined.
Catalog
- Critical assets are discoverable.
- Ownership metadata exists.
- Business descriptions exist.
- Classification is applied.
- Glossary relationships are meaningful.
- Lineage is available where supported.
- Stale metadata is monitored.
Glossary
- Critical business concepts have approved definitions.
- KPI definitions include formula and grain.
- Ambiguous terms have explicit ownership.
- Deprecated terms are managed.
Quality
- Critical assets have quality rules.
- Thresholds are documented.
- Quality incidents have owners.
- Remediation SLAs exist.
- Consumer notification is defined.
Data products
- Product purpose is explicit.
- Consumers are identified.
- Product owner exists.
- Steward exists.
- Data contract is documented.
- Freshness expectations exist.
- Lifecycle is defined.
- Change policy exists.
- Retirement process exists.
Architect interview framework
When asked:
"How would you implement data governance in SAP Datasphere?"
Answer in this order:
1. Business objective
Explain why governance is required.
2. Operating model
Describe centralized standards plus domain ownership.
3. Catalog
Explain discovery and metadata.
4. Glossary
Explain shared business meaning.
5. Quality
Explain measurable fitness for purpose.
6. Lineage
Explain provenance and impact analysis.
7. Security
Explain access independently from governance.
8. Data products
Explain reusable consumer-oriented data.
9. Lifecycle
Explain publication, change, deprecation, retirement.
10. Measurement
Explain how governance success is measured.
Common interview traps
"Catalog equals governance."
No. Catalog is a major governance capability, not the entire governance operating model.
"Data product equals table."
No. A product requires consumer context, ownership, lifecycle, and supported consumption.
"Lineage means data is trusted."
No. Lineage proves provenance, not correctness.
"Security is governance."
Security is one governance dimension. Governance is broader.
"Every object needs certification."
Usually unnecessary. Use criticality tiers.
"Central team should own all data."
Usually does not scale. Domain ownership is closer to business meaning.
Architect decision matrix
| Decision | Prefer | Avoid |
|---|---|---|
| Governance model | Federated with central standards | Fully centralized execution |
| Metadata | Automated extraction + targeted enrichment | Manual duplication |
| Quality | Risk-based controls | Same controls for every asset |
| Glossary | Business concepts | Every technical column |
| Products | Consumer-oriented boundaries | One product per table |
| Lifecycle | Explicit change/deprecation | Silent breaking changes |
| Catalog | Discovery and governance | Treating it as the only metadata system |
| Ownership | Domain accountability | Orphaned central ownership |
Final architect test
You are ready for enterprise governance architecture when you can defend:
- why the organization needs governance,
- why the operating model scales,
- how the catalog supports discovery,
- how glossary terms create semantic consistency,
- how quality becomes measurable,
- how lineage supports impact analysis,
- how security and governance interact,
- how data products create reusable interfaces,
- how lifecycle and change are controlled,
- how governance cost is justified.
Phase 15 completion statement
The goal of this phase is not to turn you into a catalog administrator.
The goal is to make you capable of designing a governed data operating model around SAP Datasphere.
That distinction matters at architect level.