Skip to main content

07.11 Governance Hub, Data Products & Enterprise Governance Operating Model

Unity Catalog gives an enterprise the technical foundation for governance. The architect's next problem is organizational:

How do we turn technical controls into a usable enterprise data operating model?

Modern Databricks governance combines:

  • centralized platform controls;
  • domain ownership;
  • discoverability;
  • trusted data products;
  • business semantics;
  • certification;
  • quality;
  • lineage;
  • classification;
  • access requests;
  • governance observability.

Databricks' current Governance Hub is a centralized account-level experience for monitoring governance across an account. It currently provides Data, AI, and Cost areas and is in Beta. The Data page gives administrators a consolidated view of data-estate health and coverage while respecting underlying Unity Catalog permissions. Governance Hub

Enterprise governance operating model

1. Governance is an operating model​

A platform can technically enforce permissions and still have poor governance.

For example:

  • nobody owns a table;
  • users cannot find the correct dataset;
  • three teams publish different definitions of revenue;
  • sensitive columns are classified but not protected;
  • dashboards depend on deprecated tables;
  • access requests have no accountable owner;
  • data quality failures have no business escalation path.

Therefore:

Governance = controls + ownership + semantics + discovery + evidence + accountability.

2. Centralized, decentralized, federated and hybrid governance​

Databricks currently describes four governance operating models:

ModelDescriptionBest fit
CentralizedOne governance team controls policies and assetsSmaller or highly regulated enterprises
DecentralizedDomains independently govern their assetsStrong autonomous business units
FederatedCentral policies with domain-level executionLarge enterprises
HybridDomain autonomy with centralized control of critical assetsMost complex enterprises

For a large enterprise, federated or hybrid governance is often the most practical architecture.

The important distinction is:

centralize standards, not necessarily ownership.

Databricks governance architecture guidance

3. Platform team vs data domain​

A healthy operating model separates responsibilities.

Central platform / governance office​

Owns:

  • Unity Catalog architecture;
  • security baseline;
  • naming standards;
  • identity integration;
  • audit;
  • classification;
  • global policies;
  • platform reliability;
  • governance tooling.

Domain team​

Owns:

  • business definitions;
  • data-product SLAs;
  • quality rules;
  • data contracts;
  • subject-matter interpretation;
  • domain-level access decisions;
  • lifecycle decisions.

Data consumer​

Owns:

  • responsible use;
  • reporting interpretation;
  • feedback;
  • access-request justification.

This is the foundation of federated governance.

4. Governance Hub​

Governance Hub is designed as an account-level governance view.

The current Beta experience includes:

  • Data — data-estate health and coverage;
  • AI — AI usage and spend;
  • Cost — cost drivers and budgets.

Access is role-aware.

Account admins have broad visibility, while metastore and workspace administrators receive views appropriate to their scope. The Data page respects underlying Unity Catalog permissions.

Governance Hub documentation

Architect interpretation​

Governance Hub is not the governance policy engine.

Think of it as:

governance control plane visibility

rather than:

the place where every policy is implemented.

5. Data discovery​

Enterprise governance fails when trusted data cannot be found.

Current Unity Catalog discovery capabilities include:

  • Discover page;
  • Catalog Explorer;
  • domains and subdomains;
  • governed Pages;
  • tags;
  • certification and deprecation;
  • semantic definitions;
  • AI-assisted recommendations.

The Discover page is business-aligned, while Catalog Explorer exposes the complete catalog hierarchy and technical object details.

Data discovery in Unity Catalog

6. Technical catalog vs business catalog​

These are different perspectives.

Technical catalog​

catalog ↓ schema ↓ table ↓ columns ↓ permissions / lineage

Business discovery layer​

Business domain ↓ Business concept ↓ Certified data product ↓ KPI / metric ↓ Owner / SLA / quality

An enterprise should connect both.

7. Domains and subdomains​

Business domains provide a business-aligned organization for discovery.

Examples:

  • Finance
  • Procurement
  • Sales
  • Supply Chain
  • HR
  • Customer
  • Risk

A domain can then contain subdomains.

Example:

Finance ├── Accounts Payable ├── Accounts Receivable ├── Controlling └── Treasury

This is different from creating a catalog for every small organizational concept.

Use domains for discovery and business context.

Use catalogs and schemas for technical isolation and governance boundaries.

8. Data products​

A data product is not simply a table.

A production data product should have:

  • clear business purpose;
  • owner;
  • consumers;
  • documented contract;
  • quality expectations;
  • refresh SLA;
  • security classification;
  • access model;
  • lineage;
  • lifecycle;
  • support model.

A useful model is:

DATA PRODUCT | +-- Data +-- Contract +-- Semantics +-- Quality +-- Security +-- Lineage +-- SLA +-- Owner +-- Support

9. Data product lifecycle​

Use an explicit lifecycle.

Idea ↓ Design ↓ Build ↓ Validate ↓ Certify ↓ Publish ↓ Operate ↓ Review ↓ Deprecate ↓ Retire

The governance system should make each transition visible.

10. Certification vs ownership​

These are not the same.

Owner

Who is accountable for this asset?

Certified

Has the organization reviewed and approved this asset as trustworthy?

An asset can have an owner but not be certified.

That distinction is extremely useful in enterprise discovery.

11. Deprecation is a governance control​

Deprecated data should not silently remain the default dependency.

A strong deprecation process:

  1. identify replacement;
  2. identify downstream consumers;
  3. publish migration date;
  4. notify owners;
  5. monitor remaining usage;
  6. block new dependencies where appropriate;
  7. retire after the migration window.

Lineage and usage telemetry make this possible.

12. Business semantics​

Technical names are rarely enough.

For example:

net_revenue

could mean:

  • gross revenue minus returns;
  • invoiced revenue;
  • recognized revenue;
  • revenue excluding tax;
  • revenue after discounts.

A governed business definition eliminates ambiguity.

Current Unity Catalog discovery capabilities include Pages, metric views, domains, certification and deprecation to provide business-aligned context and reusable semantics.

Data discovery and Unity Catalog semantics

13. Metric governance​

Enterprise KPIs should have:

  • definition;
  • formula;
  • grain;
  • dimensions;
  • owner;
  • refresh expectation;
  • source;
  • certification state.

Example:

On-Time Delivery %

shipments delivered on/before promised date​

eligible shipments

Without governed metric definitions, two dashboards can both be technically correct and still disagree.

14. SAP/BW perspective​

This is particularly important for SAP-centric enterprises.

A traditional BW landscape may have:

InfoObject ↓ ADSO ↓ CompositeProvider ↓ Query ↓ AFO / SAC

A Databricks data-product architecture can evolve toward:

SAP / S4 ↓ Bronze ↓ Silver ↓ Gold data product ↓ Governed metric / semantic layer ↓ BI / AI

The migration should not merely move tables.

It should migrate:

  • ownership;
  • business definitions;
  • quality rules;
  • authorization intent;
  • lineage;
  • SLAs;
  • certified reporting logic.

15. Data-product architecture​

A practical enterprise pattern:

Enterprise Sources | +------+------+ | | SAP Non-SAP | | +------+------+ | Lakehouse | +------+------+ | | Domain A Domain B | | +------+------+ | Governed Data Products | +------+------+------+ | | | | BI ML AI Apps | Unity Catalog | Governance controls

Unity Catalog cuts across the entire architecture rather than belonging to one pipeline.

16. Governance policy layers​

Separate policies by scope.

Global​

  • identity;
  • encryption;
  • audit;
  • naming;
  • mandatory classification.

Domain​

  • business ownership;
  • quality;
  • domain-specific retention;
  • access rules.

Product​

  • SLA;
  • contract;
  • consumer support;
  • release lifecycle.

Asset​

  • table permissions;
  • row filters;
  • column masks;
  • tags.

This avoids putting every rule into one central team.

17. Governance scorecard​

Measure governance maturity.

Discoverability​

  • percentage of critical assets documented;
  • percentage with business owner;
  • percentage certified.

Security​

  • sensitive-data classification coverage;
  • policy coverage;
  • privilege exceptions;
  • stale access.

Quality​

  • critical-data-quality pass rate;
  • unresolved incidents;
  • SLA adherence.

Lineage​

  • critical asset lineage coverage;
  • undocumented external dependencies.

Adoption​

  • certified product usage;
  • deprecated asset usage;
  • duplicate data products.

18. Governance maturity model​

Level 1 — Reactive​

  • manual permissions;
  • undocumented assets;
  • no ownership.

Level 2 — Controlled​

  • Unity Catalog;
  • RBAC;
  • basic audit;
  • basic lineage.

Level 3 — Governed​

  • classification;
  • ABAC;
  • certified assets;
  • quality;
  • domains;
  • ownership.

Level 4 — Product-oriented​

  • reusable data products;
  • contracts;
  • SLAs;
  • semantic layer;
  • automated governance.

Level 5 — Intelligent​

  • governance observability;
  • automated classification;
  • AI-assisted discovery;
  • proactive recommendations;
  • policy automation;
  • measurable governance outcomes.

The target for an enterprise architect is not simply "Level 5 everywhere."

It is risk-appropriate governance at scale.

19. Governance-as-code​

Governance decisions should increasingly become version-controlled artifacts.

Examples:

  • catalog definitions;
  • grants;
  • tags;
  • policies;
  • data-product contracts;
  • quality rules;
  • deployment configuration.

Use:

  • Git;
  • Databricks Asset Bundles;
  • Terraform;
  • CI/CD;
  • automated validation.

The goal is:

change ↓ review ↓ test ↓ approve ↓ deploy ↓ observe

20. Access-request operating model​

A mature access process is:

Consumer ↓ Request access ↓ Identify data owner ↓ Evaluate sensitivity ↓ Evaluate purpose ↓ Approve / reject ↓ Grant ↓ Audit ↓ Periodic review

Do not make access permanently manual.

Where appropriate, use policy-based access and governed request workflows.

21. Data-product contract​

A useful contract contains:

SectionExample
ProductSupplier Spend
OwnerProcurement Analytics
Business purposeSupplier performance
GrainSupplier × PO line × date
RefreshDaily
SLAAvailable by 06:00
Quality>99.5% valid supplier keys
SecurityInternal
Sensitive dataSupplier bank details masked
ConsumersProcurement / Finance
CertificationCertified
ReplacementN/A

This turns a table into an accountable product.

22. Hands-on Lab 1 — Design enterprise domains​

Create domains for:

  • Finance;
  • Procurement;
  • Sales;
  • Supply Chain.

For each define:

  • owner;
  • steward;
  • critical assets;
  • security classification;
  • major data products.

Do not automatically create four catalogs just because you created four domains.

23. Hands-on Lab 2 — Build a data-product template​

Create a template containing:

  • purpose;
  • owner;
  • contract;
  • grain;
  • SLA;
  • quality;
  • security;
  • lineage;
  • certification;
  • lifecycle.

Use a Supplier Spend product as the example.

24. Hands-on Lab 3 — Certification lifecycle​

Take an existing Gold table through:

Draft ↓ Validated ↓ Certified ↓ Deprecated

For each state define:

  • entry criteria;
  • owner;
  • evidence;
  • exit criteria.

25. Hands-on Lab 4 — Governance scorecard​

Build a dashboard showing:

  • critical assets;
  • owner coverage;
  • certification coverage;
  • classification coverage;
  • quality health;
  • lineage coverage;
  • deprecated usage;
  • privilege exceptions.

This becomes your first enterprise governance scorecard.

26. Hands-on Lab 5 — SAP to data product​

Design:

S/4HANA Procurement ↓ Bronze ↓ Silver ↓ Supplier Spend Data Product ↓ Certified KPI ↓ SAC / BI

Document:

  • business owner;
  • technical owner;
  • contract;
  • quality rules;
  • security;
  • lineage;
  • SLA;
  • retirement strategy.

27. Common anti-patterns​

1. Catalog explosion​

Creating a catalog for every team, project and environment without a clear isolation requirement.

2. Domain ≠ catalog​

Business discovery and technical isolation are related but different concepts.

3. Table = data product​

A product requires ownership, contract, quality, security and lifecycle.

4. Central team owns everything​

Centralize standards and controls; keep business accountability close to domains.

5. Certification without evidence​

Certification must have measurable criteria.

6. Governance without adoption​

A perfect catalog nobody uses is not successful governance.

7. Dashboard-only governance​

Dashboards show problems; operating processes resolve them.

28. Architect decision framework​

Need technical isolation?​

Use catalog/schema/workspace boundaries.

Need business discovery?​

Use domains, subdomains and curated discovery.

Need reusable trusted data?​

Create a data product.

Need consistent KPI meaning?​

Govern metrics and business semantics.

Need accountability?​

Assign owner + steward + SLA.

Need automated enforcement?​

Use Unity Catalog policies + governance-as-code.

Need enterprise visibility?​

Use Governance Hub + governance data marts.

29. Enterprise governance reference architecture​

+------------------------------------------------------+ | GOVERNANCE OFFICE | | Standards • Risk • Compliance • Architecture | +--------------------------+---------------------------+ | +--------------+--------------+ | | Platform Controls Domain Governance Unity Catalog Finance / Sales / HR RBAC / ABAC Owners / Stewards Classification Contracts / SLAs Lineage Quality Audit Semantics | | +--------------+--------------+ | GOVERNED DATA PRODUCTS | +--------------------+--------------------+ | | | BI ML AI | | | +--------------------+--------------------+ | Governance Observability Audit • Quality • Usage | Governance Hub

30. Interview questions​

What is the difference between governance and data management?

Data management handles the lifecycle and engineering of data. Governance defines accountability, rules, trust, security, semantics and acceptable use.

Why use domains?

Domains provide a business-aligned discovery and ownership structure without forcing every business concept into a technical catalog boundary.

What makes a data product different from a table?

A data product has an owner, contract, semantics, quality expectations, security, SLA, lineage and lifecycle.

What is Governance Hub?

A centralized account-level Databricks experience for monitoring governance across the data, AI and cost estate. It is currently Beta.

Should every domain have its own catalog?

Not necessarily. Catalogs should represent meaningful technical isolation and governance boundaries; domains are a business discovery construct.

What is federated governance?

Central standards and controls with domain-level ownership and execution.

31. Production checklist​

  • Governance operating model is explicitly selected.
  • Central vs domain responsibilities are documented.
  • Business domains are defined.
  • Catalog boundaries have clear isolation rationale.
  • Critical data products have owners.
  • Data-product contracts exist.
  • Quality SLAs are measurable.
  • Sensitive-data classification is operational.
  • Critical assets are certified.
  • Deprecated assets have replacement paths.
  • Business definitions are governed.
  • KPI definitions are reusable.
  • Access requests have accountable owners.
  • Governance changes are version controlled.
  • Governance metrics are reviewed regularly.
  • Governance Hub or equivalent scorecards are operational.
  • Audit, lineage and quality evidence can be connected.
  • Domain teams participate in governance.

32. Final mental model​

The enterprise progression is:

UNITY CATALOG ↓ GOVERNANCE CONTROLS ↓ BUSINESS DOMAINS ↓ TRUSTED DATA PRODUCTS ↓ SEMANTICS + QUALITY ↓ DISCOVERY + CERTIFICATION ↓ GOVERNANCE OBSERVABILITY ↓ ACCOUNTABILITY ↓ DATA-DRIVEN ORGANIZATION

The architect's principle:

Centralize the platform and guardrails; federate business ownership; productize trusted data; measure governance outcomes.

That is how Unity Catalog becomes an enterprise operating model rather than merely an authorization layer.