15.8 Enterprise Governance Architecture
1. From features to operating model
At enterprise scale, governance is an organizational architecture problem.
The platform provides capabilities.
The enterprise must define:
- ownership,
- decision rights,
- standards,
- processes,
- controls,
- metrics.
2. Reference operating model
DATA GOVERNANCE COUNCIL
|
+---------------+---------------+
| | |
Enterprise Domain Owners Architecture
Standards | Board
| |
+-----+-----+ +---+---+---+
| | | | | |
Meta Quality Access Stewards
Data Policy Policy |
Policy |
v
Data Products
|
v
Consumers
3. Responsibility model
| Responsibility | Enterprise | Domain | Engineering | Steward |
|---|---|---|---|---|
| Policy | A | C | C | C |
| Business definition | C | A | C | R |
| Technical implementation | C | C | A | C |
| Data quality remediation | C | A | R | R |
| Access implementation | A | C | R | C |
| Product roadmap | C | A | R | R |
| Metadata maintenance | A | R | R | R |
A = accountable, R = responsible, C = consulted.
Adjust this model to the organization.
4. Domain architecture
A practical enterprise model can use:
- Finance,
- Procurement,
- Sales,
- Supply Chain,
- HR,
- Customer,
- Product.
Each domain has:
- accountable owner,
- steward network,
- governed assets,
- glossary terms,
- quality rules,
- data products.
5. Governance boundaries
Do not make every domain completely independent.
Enterprise-level concepts must remain standardized where cross-domain consistency matters.
Examples:
- Customer ID,
- Company Code,
- Currency,
- Fiscal Calendar,
- Supplier,
- Product.
These are candidates for enterprise semantic governance.
6. Governance and Datasphere spaces
Spaces provide technical and security boundaries.
Governance domains are business boundaries.
They do not have to map one-to-one.
Example:
Business Domain: Finance
|
+--> Finance Acquisition Space
+--> Finance Curated Space
+--> Finance Consumption Space
A domain can therefore span multiple technical spaces.
Likewise, a technical space should not automatically become the governance owner.
7. Governance architecture layers
Layer 1: Policy
Layer 2: Ownership
Layer 3: Metadata
Layer 4: Catalog
Layer 5: Quality
Layer 6: Security
Layer 7: Lineage
Layer 8: Data Products
Layer 9: Consumption
Layer 10: Measurement
8. Governance metrics
Track:
Adoption
- governed asset usage,
- product reuse,
- catalog searches.
Trust
- certified asset ratio,
- quality compliance,
- metadata completeness.
Operations
- incident rate,
- freshness compliance,
- remediation time.
Efficiency
- time to discover,
- time to access,
- duplicate asset reduction.
9. Architecture decision record
For major governance decisions, record:
- context,
- decision,
- alternatives,
- consequences,
- ownership,
- review date.
Example:
Decision: federated stewardship.
Alternative rejected: fully centralized stewardship.
Reason: domain scale and business context make centralized execution a bottleneck.
10. Enterprise governance maturity
Level 1 — Informal
People know who to ask.
Level 2 — Documented
Policies and ownership are documented.
Level 3 — Governed
Catalog, glossary, quality, and access processes are operational.
Level 4 — Measured
KPIs and compliance are monitored.
Level 5 — Product-oriented
Domains publish reusable, governed data products with explicit consumer contracts.
Architect capstone
Design governance for:
- 15 domains,
- 3 Datasphere tenants,
- 10,000 assets,
- 500 Tier 1 assets,
- 100 data products,
- 5,000 consumers.
Your architecture must explain:
- central governance,
- domain ownership,
- catalog administration,
- glossary,
- quality,
- security,
- data products,
- lifecycle,
- metrics,
- escalation.