MDM HUB

High Level Design Document

Unity Catalog + Azure Purview  ·  People · Finance · Manufacturing

Includes worked examples with sample data for all 7 governance components

Programme: Master Data Management Hub	Platform: Databricks Unity Catalog + Azure Purview
Domains: People · Finance · Manufacturing	Classification: Confidential — Internal Use Only

1. Governance Components — Coverage Map

This document covers all seven required Data Governance components. Each section includes a definition, design decisions for the MDM Hub, and worked examples with representative sample data from the People, Finance, and Manufacturing domains.

#	Governance Component	HLD Section	Example Data Included
1	Data Governance Framework	Section 3	✔  DQ rule applied to Employee Sarah Mitchell (EMP-1042)
2	Governance Structure	Section 4	✔  Org chart: CDO → DGO → 3 Domain Stewards → MDM Engineers
3	Operating Principles	Section 5	✔  Principle P3 (Policy as Code) applied to cost_centre CC-5501
4	DG Process	Section 6	✔  Full lifecycle: EMP-1042 from people_gold → golden record
5	Target Operating Model	Section 7	✔  Daily rhythm with 08:15 steward review of 3 queued pairs
6	Engagement Model	Section 8	✔  Finance team raises issue on CC-5501 → resolved via hub
7	RACI	Section 9	✔  RACI populated for Person golden record of EMP-1042

2. Current State & Problem Statement

Three domain Gold catalogs exist today in the same Databricks workspace with no shared entity keys. The same real-world person, department, and location exist as isolated records with different local identifiers.

Domain	Catalog	Key Entities	Local Key Format	Core Problem
People / HR	people_gold	Employee, Department, Role, Position	EMP-XXXX	Employee IDs are HR-local. No link to Finance cost centres or Manufacturing plants.
Finance	finance_gold	Cost Centre, GL Account, Legal Entity, Vendor, Budget	CC-XXXX / VND-XXXX	Vendor contacts and cost centre owners stored as free-text name — no join to People.
Manufacturing	manufacturing_gold	Plant, Asset, Work Order, BOM, Production Run	PLT-XXXX / AST-XXXX	Plant manager field is a name string — no Employee ID reference.

▶  EXAMPLE WITH DATA

Same Real Person — 3 Different Records (No Link Today)
Domain	Local Record	Key Fields	Problem
people_gold.hr.employees	EMP-1042	Name: Sarah Mitchell  |  Email: s.mitchell@acme.com  |  Dept: DEPT-22	Only HR knows this is the Finance cost centre owner
finance_gold.gl.cost_centres	CC-5501	Owner name: ‘S. Mitchell’  |  Legal Entity: ACME-UK  |  GL Group: OPEX	Free-text name — cannot join to EMP-1042
manufacturing_gold.operations.plants	PLT-007	Plant Manager: ‘Sarah Mitchell’  |  Site: Birmingham, UK	Name string — cannot join to EMP-1042 or CC-5501

3. Data Governance Framework

The Data Governance Framework (DGF) is the foundational layer of the MDM Hub. It defines the policies, standards, data quality rules, and controls that every golden record must satisfy before it is certified and published to consumers. It operates across three tiers:

Tier	Scope	Platform Component	Who Owns It
Strategic	Policies, data ownership rules, risk appetite	Azure Purview — Data Policy + Compliance Hub	CDO + DGO
Tactical	Data standards, classification, business glossary	Azure Purview Data Catalog + Unity Catalog Metastore	DGO + Domain Data Owners
Operational	Data quality rules, lineage, access enforcement	Unity Catalog RBAC + DLT Expectations + DQ monitoring jobs	MDM Engineers + Domain Stewards

3.1 Data Quality Rules — MDM Hub

DQ Dimension	Rule	Threshold	Action on Breach
Completeness	canonical_name must not be null on any golden record	100%	Record blocked from golden.* — written to matching.rejected
Uniqueness	No two golden records share the same canonical_email	0 duplicates	Second record flagged DUPLICATE_SUSPECT; Steward review within 24 hrs
Match Confidence	Auto-approval requires final_score ≥ 0.90	Score ≥ 0.90	0.75–0.89 → review queue; <0.75 → rejected
Cross-Domain Certification	At least 2 source_ids populated for ‘cross-domain certified’ status	≥ 2 sources	Single-source records tagged SINGLE_SOURCE — valid but not cross-domain
Email Validity	canonical_email must match standard email regex	Soft check	Record promoted but tagged EMAIL_SUSPECT; steward informed
Lineage Registration	Purview lineage must exist before table published to consumers	100% coverage	Golden table withheld from consumer access until lineage confirmed

▶  EXAMPLE WITH DATA

Employee Sarah Mitchell (EMP-1042) is ingested from people_gold. The matching pipeline runs the following DQ checks:

DQ Check	Input Value	Rule	Result
Completeness	canonical_name = ‘Sarah Mitchell’	NOT NULL	PASS  ✔
Email Validity	canonical_email = ‘s.mitchell@acme.com’	Regex match	PASS  ✔
Uniqueness	No other golden record has s.mitchell@acme.com	0 duplicates	PASS  ✔
Match Confidence (vs CC-5501)	final_score = 0.94 (email exact + name 0.97 Jaro-Winkler)	≥ 0.90	PASS — AUTO-APPROVED  ✔
Match Confidence (vs PLT-007)	final_score = 0.82 (name 0.91 + no email)	0.75–0.89	REVIEW QUEUE — Steward required
Cross-Domain Certification	people_source_id = EMP-1042  |  finance_source_id = CC-5501	≥ 2 sources	CROSS-DOMAIN CERTIFIED  ✔

Outcome: Sarah Mitchell’s golden record is created with mdm_id = MDM-PRS-00001, cross-domain certified for People + Finance. The PLT-007 link goes to the review queue for the Manufacturing Steward.

4. Governance Structure

The MDM Hub governance structure follows a hub-and-spoke federated model. A central Data Governance Office (DGO) sets standards and resolves cross-domain conflicts. Each domain has a named Data Steward with delegated authority over their domain’s match decisions.

4.1 Governance Bodies

Body	Cadence	Members	Authority
Data Governance Council (DGC)	Monthly	CDO, Domain VPs (People, Finance, Ops), CISO, CTO	Strategic — approves DG policy changes, budget, new domains
Data Stewardship Committee (DSC)	Bi-weekly	DGO Lead, 3 Domain Stewards, MDM Hub Owner	Tactical — approves matching rule changes, threshold adjustments, glossary terms
MDM Working Group (MWG)	Weekly	MDM Engineers, Domain Stewards, Data Architect	Operational — pipeline issues, DQ alerts, schema changes, consumer onboarding
Match Review Huddle	Daily (async)	3 Domain Stewards + MDM Engineer on rotation	Operational — process review queue items within 48-hour SLA

4.2 Governance Roles

Role	Person / Team	Domain	Hub Responsibility	Catalog Access
Chief Data Officer	James Harrington	Enterprise	Executive sponsor; approves DG policy; chairs DGC monthly	Azure Purview — read (Insights dashboard)
Data Governance Officer	Priya Nair	Enterprise	Owns DG framework; authors policies; oversees stewardship; quarterly access review	Purview Admin + mdm_hub.audit (read)
MDM Hub Owner	Raj Desai	Cross-domain	Accountable for mdm_hub catalog integrity; resolves cross-domain conflicts; chairs MWG	Metastore Admin on mdm_hub
Domain Steward — People	Claire Obi	People / HR	Reviews Person match queue; approves/rejects HR-linked pairs; curates HR glossary terms	mdm_hub.matching + audit (review write)
Domain Steward — Finance	Tom Bauer	Finance	Reviews Cost Centre / Org Unit matches; validates legal entity canonical names	mdm_hub.matching + audit (review write)
Domain Steward — Manufacturing	Divya Sharma	Manufacturing	Reviews Plant / Location matches; validates plant manager cross-links	mdm_hub.matching + audit (review write)
MDM Engineer (Lead)	Ben Kowalski	Platform	Builds / maintains DLT matching pipeline, golden DDL, source views, Purview connector	Full access — all 4 schemas of mdm_hub
MDM Engineer	Anya Petrov	Platform	CI/CD, RBAC, DQ monitoring jobs, consumer onboarding support	Full access — all 4 schemas of mdm_hub
Data Consumer	All analytics / BI teams	Cross-domain	Queries certified golden records via mdm_hub.golden.*	mdm_hub.golden.* SELECT only

▶  EXAMPLE WITH DATA

Scenario: A conflict arises — Finance Steward Tom Bauer disagrees with People Steward Claire Obi on whether ‘S. Mitchell’ in CC-5501 should be merged with EMP-1042 (Sarah Mitchell in HR). The resolution path:

Step	Who	Action	Outcome
1	MDM Working Group	Ben Kowalski presents the scored pair (score 0.94) and evidence (email exact match) at MWG	Majority agree this is a confident match
2	Tom Bauer (Finance Steward)	Raises concern: ‘S. Mitchell’ in CC-5501 may refer to Scott Mitchell, not Sarah	Escalated to DSC — bi-weekly committee
3	DSC (Priya Nair chairs)	DSC reviews audit trail; requests Finance to verify CC-5501 owner directly with HR	Finance confirms: CC-5501 owner is Sarah Mitchell
4	Claire Obi + Tom Bauer	Both stewards approve the merge in the review queue	Pair promoted to golden.* with MANUALLY_APPROVED flag
5	mdm_hub.audit.match_log	Decision recorded: decision_by=[‘claire.obi’,’tom.bauer’], resolution_body=’DSC’, timestamp=2024-03-12 14:22 UTC	Full audit trail preserved — immutable

5. Operating Principles

The eight operating principles govern every decision made within the MDM Hub — from architecture choices to steward behaviour. They are enforced through platform controls, not just documentation.

#	Principle	What It Means in Practice	Platform Enforcement
P1	Domain Catalogs Are Read-Only Inputs	mdm_hub never writes back to people_gold, finance_gold, or manufacturing_gold. Data flows one direction only.	Source_views are CREATE VIEW — read-only by definition. No DML on domain catalogs from mdm_hub service principal.
P2	mdm_id Is Immutable Once Assigned	A golden record’s UUID never changes. Reversed decisions produce a RETIRED record — not a deletion.	Golden table has no DELETE permission for any principal. mdm_id column is set on INSERT only; UPDATE excluded from column grant.
P3	Policy as Code	All matching thresholds, RBAC grants, and DQ rules are stored in Git and deployed via CI/CD — no manual configuration in the UI.	Databricks Asset Bundles deploy all pipeline config. RBAC grants in Terraform. PRs require MDM Hub Owner approval.
P4	Lineage Before Publication	No golden table is available to consumers without registered end-to-end lineage in Azure Purview.	Consumer GRANT is issued by MDM Engineer only after Purview lineage scan confirms source → golden path.
P5	Match Decisions Are Auditable Forever	Every auto-approval and steward decision is written to mdm_hub.audit.match_log with full context.	audit schema has no UPDATE/DELETE permission. Delta table with CDF enabled — every write is retained.
P6	Golden = Certified by Definition	If a record is in mdm_hub.golden.*, it has passed all DQ gates. There are no uncertified records in the golden schema.	DLT Expectations block promotion on DQ failure. Only approved pairs reach the MERGE INTO golden job.
P7	Consumers Query Golden Only	Downstream jobs must not bypass the hub by querying domain Gold tables for cross-domain use cases.	Governance Council mandate enforced by MDM Hub Owner. Consumer Adoption KPI tracked monthly.
P8	Federated Ownership, Central Standards	Domain Stewards own match decisions for their domain. DGO owns the standards and thresholds that govern all domains equally.	Stewards have write access to review_queue only. Threshold config changes require DGO approval via DSC.

▶  EXAMPLE WITH DATA

Principle P3 (Policy as Code) applied — matching threshold change for Org Unit entity:

Step	Action	Tool	Who
1	Finance Steward Tom Bauer requests: raise Org Unit auto-approval threshold from 0.85 to 0.90 (too many false positives seen last week)	Jira MDM board — ticket MDM-214	Tom Bauer
2	MDM Engineer Ben Kowalski raises GitHub PR — edits matching_config.yaml: org_unit.auto_approve_threshold: 0.90	GitHub PR #88	Ben Kowalski
3	MDM Hub Owner Raj Desai reviews and approves PR	GitHub PR review	Raj Desai
4	CI/CD pipeline (GitHub Actions + Databricks Asset Bundles) deploys updated config to matching pipeline — no manual cluster change	GitHub Actions	Automated
5	Change written to mdm_hub.audit.config_log: changed_by=’ben.kowalski’, approved_by=’raj.desai’, old=0.85, new=0.90, ticket=’MDM-214′	audit.config_log	Automated

6. Data Governance Process (DG Process)

The DG Process defines the end-to-end lifecycle of a master data record — from its first appearance in a domain Gold catalog to its certification as a Golden Record, ongoing monitoring, and eventual retirement. Every stage has a defined owner, trigger, and platform action.

Stage	Trigger	Platform Action	Owner	Output
1. Identify	New/updated record lands in domain Gold catalog	Purview incremental scan detects new asset; source_view reflects live update automatically	MDM Engineer (automated)	Asset catalogued in Purview; visible in source_views
2. Profile	Daily 02:00 matching pipeline starts	DLT pipeline reads source_views; computes null rates, format checks, blocking keys	MDM Engineer (automated)	Candidate pool ready for matching
3. Match	Profile complete	Phase 1 deterministic (email/code exact); Phase 2 probabilistic (Jaro-Winkler name + phone)	MDM Engineer (automated)	Scored candidate pairs in matching.scored_pairs
4. Review	Score 0.75–0.89 detected	Pair written to matching.review_queue; Steward alert sent at 08:00	Domain Steward (manual)	Approved or rejected pair in matching.review_decisions
5. Certify	Score ≥ 0.90 (auto) or Steward approves	MERGE INTO mdm_hub.golden.*; mdm_id assigned (UUID); audit log written	MDM Engineer (automated) + Steward (manual approvals)	Certified Golden Record in golden.*
6. Distribute	Golden record available	Consumers query mdm_hub.golden.* via Unity Catalog SELECT; Purview lineage updated	Data Consumer	Cross-domain joined analytics; mdm_id used as FK in downstream jobs
7. Monitor	Continuous — daily DQ jobs	DQ metrics written to audit.dq_metrics; alerts fired on breach; Purview Insights refreshed	MDM Engineer + Steward	DQ scorecard; breach alerts to Steward and Hub Owner
8. Remediate	DQ breach or domain source record changes	Steward investigates; corrected record re-runs through match pipeline; golden record updated via MERGE	Domain Steward + MDM Engineer	Updated golden record; remediation note in audit.match_log
9. Retire	Employee leaves; plant decommissioned; entity no longer active	Golden record updated: certification_status = RETIRED, retired_at = timestamp. mdm_id preserved for lineage.	Domain Data Owner approves; MDM Engineer executes	Retired record in golden.*; downstream consumers see status change; Purview lineage maintained

▶  EXAMPLE WITH DATA

Full DG Process lifecycle for Employee Sarah Mitchell (EMP-1042) — from source record to certified golden record:

Stage	Date/Time	Action	Data State	Actor
1. Identify	2024-03-11 01:15	HR system updates Sarah Mitchell’s record — promoted to people_gold.hr.employees	EMP-1042 active in people_gold	Domain pipeline (automated)
2. Profile	2024-03-12 02:00	DLT pipeline reads vw_people_person; EMP-1042 profiled: name non-null ✔, email valid ✔, blocking_key = ‘SAR’ + soundex(‘s.mitchell@acme.com’)	Candidate added to matching pool	MDM Engineer (automated)
3. Match	2024-03-12 02:45	EMP-1042 vs CC-5501: email exact match → score 1.0 (deterministic)EMP-1042 vs PLT-007: name Jaro-Winkler 0.91, no email → score 0.82 (probabilistic)	scored_pairs: 2 rows for EMP-1042	MDM Engineer (automated)
4. Review	2024-03-12 08:00	PLT-007 pair (score 0.82) → review_queue. Alert sent to Divya Sharma (Mfg Steward).CC-5501 pair (score 1.0) → auto-approved.	CC-5501 pair in auto_approvedPLT-007 in review_queue	Automated + Divya Sharma
5. Certify	2024-03-12 04:00 (auto) + 10:30 (manual)	CC-5501 auto-merged to golden.person → mdm_id = MDM-PRS-00001 assigned.Divya reviews PLT-007 at 10:30; approves → second MERGE adds mfg_source_id = PLT-007	golden.person: 1 row, MDM-PRS-00001, certification_status = CROSS_DOMAIN_CERTIFIED	MDM Engineer (auto) + Divya Sharma (manual)
6. Distribute	2024-03-12 11:00 onwards	Analytics team queries: SELECT * FROM mdm_hub.golden.person WHERE mdm_id = ‘MDM-PRS-00001’ → gets People + Finance + Mfg attributes in one row	Golden record consumed by 3 downstream notebooks	Data Consumers
7. Monitor	2024-03-13 23:00	Daily DQ job: completeness 100% ✔, uniqueness 100% ✔, email validity 100% ✔. DQ scorecard updated.	All metrics GREEN	MDM Engineer (automated)
8. Remediate	N/A (no breach)	—	—	—
9. Retire	Future: when Sarah Mitchell leaves	HR marks EMP-1042 inactive → people_gold updates → Hub job sets MDM-PRS-00001: certification_status = RETIRED, retired_at = <timestamp>	Record retained for lineage; consumers see RETIRED status	Domain pipeline + MDM Engineer

7. Target Operating Model (TOM)

The Target Operating Model defines how people, process, and platform work together at steady state. It covers the daily operating rhythm, team structure, and the three maturity horizons for the MDM Hub.

7.1 Three-Horizon Maturity Model

Horizon	Timeline	Focus	Maturity Level
H1 — Foundation	Week 1–6	mdm_hub catalog + source_views + Person matching (People ↔ Finance). First golden records for Person entity.	Level 1 — Managed
H2 — Expansion	Week 6–12	Org Unit + Location matching. All 3 domain stewards operational. DQ monitoring live. Consumer adoption begins.	Level 2 — Defined
H3 — Optimisation	Month 4–12	Predictive DQ alerts. AI-assisted match suggestions. Additional domains (Procurement). Real-time CDF-driven updates.	Level 3 — Optimised

7.2 Daily Operating Rhythm

Time	Activity	Owner	Tool	Automated?
00:00–02:00	Domain Gold tables refreshed by existing domain pipelines	Domain Engineers	ADF / domain DLT	✔ Auto
02:00–04:00	DLT matching pipeline: source_views → matching.*; auto-approved pairs MERGE to golden.*	MDM Engineer	Databricks DLT	✔ Auto
08:00	Stewards receive alert email: ‘N new items in review queue — SLA 48 hours’	MDM Engineer (config)	Databricks SQL Alert	✔ Auto
08:00–12:00	Stewards log in; review candidate pairs; approve or reject; add notes	3 Domain Stewards	Purview Stewardship / Databricks SQL	Manual
12:00	Steward-approved pairs MERGE into golden.* (second daily run)	MDM Engineer	Databricks Workflow	✔ Auto
18:00	Azure Purview incremental scan on mdm_hub — refresh asset catalog and lineage	Purview scheduled scan	Azure Purview	✔ Auto
23:00	DQ metric job runs; updates audit.dq_metrics; fires alert if any threshold breached	MDM Engineer	Databricks SQL Alert	✔ Auto

▶  EXAMPLE WITH DATA

Tuesday 12 March 2024 — actual operating day for the MDM Hub:

Time	What Happened	Data
02:00	Matching pipeline triggered automatically	3 domain Gold catalogs refreshed overnight — 47 new/updated records ingested
02:45	DLT matching completes	22 pairs scored: 18 auto-approved (score ≥ 0.90) | 3 to review queue (0.75–0.89) | 1 rejected (<0.75)
04:00	Auto-approved MERGE job completes	18 golden records created or updated: 11 Person, 5 Org Unit, 2 Location
08:00	Alert email sent to stewards	Subject: ‘MDM Hub — 3 pairs await your review: 2 × Person, 1 × Org Unit’
08:15	Claire Obi (People Steward) reviews EMP-1042 ↔ PLT-007 (score 0.82)	Reviews name match evidence; approves. Adds note: ‘Confirmed via org directory. Sarah Mitchell is Birmingham plant manager.’
09:40	Tom Bauer (Finance Steward) reviews CC-5501 ↔ DEPT-22 Org Unit pair (score 0.78)	Rejects. Adds note: ‘CC-5501 maps to a different cost centre hierarchy — not DEPT-22.’
11:10	Divya Sharma (Mfg Steward) reviews PLT-007 ↔ PLT-009 dedup pair (score 0.76)	Rejects. ‘PLT-007 and PLT-009 are different sites in Birmingham — not duplicates.’
12:00	Second MERGE job runs	1 golden record updated (MDM-PRS-00001: mfg_source_id added). 2 pairs written to audit with rejected=true.
23:00	DQ job completes	All metrics GREEN: completeness 100%, uniqueness 100%, 0 open P1 issues. DQ scorecard updated.

8. Engagement Model

The Engagement Model defines how each team and stakeholder group interacts with the MDM Hub — what they contribute, what they receive, and what they are required to do differently after go-live.

8.1 Engagement Archetypes

Archetype	Who	What They Give the Hub	What They Get Back	Required Change
Data Producer	Domain Gold pipelines (existing)	Up-to-date domain records via source_views — no change to their pipelines required	Nothing directly — producers are unaffected	None — zero change to existing domain pipelines
Domain Steward	People Steward, Finance Steward, Mfg Steward	Match decisions on review queue pairs; glossary term curation; DQ issue escalation	Full cross-domain view of their entities; DQ scorecard; audit trail of all decisions	Daily review queue commitment (max 2 hours/day). Must have Databricks SQL access.
Data Consumer	BI Analysts, Data Scientists, Downstream pipelines	Adopt mdm_hub.golden.* as catalog reference — switch from domain catalog queries	Single cross-domain golden record with mdm_id as join key — no more manual reconciliation	Update existing notebook/job catalog reference. Use mdm_id as FK in new joins.
Data Requestor	Any team needing a new domain, new entity type, or schema change	Submit Data Change Request (DCR) via Jira MDM board	Structured intake: 5-day triage, domain onboarding in 6 weeks, clear acceptance criteria	Must raise a DCR before any schema change — no direct catalog modifications
Platform / DevOps	Platform / Infrastructure team	CI/CD pipeline support for Databricks Asset Bundle deploys	Reduced manual config — all hub config is code	Onboard mdm_hub to existing CI/CD workflow in Week 1

8.2 Access Request Process

Scenario	Channel	Approver	SLA
Standard consumer access to mdm_hub.golden.*	Self-serve via Azure Purview access request portal	MDM Hub Owner (auto-policy for registered consumers)	1 business day
Steward access to matching.review_queue	Jira MDM board — ticket type: Steward Onboarding	MDM Hub Owner + DGO	3 business days
New golden entity / schema change	Jira MDM board — ticket type: Data Change Request (DCR)	Domain Data Owner + MDM Hub Owner + DSC approval	5-day triage + 6-week build
Elevated access (audit schema read)	Jira MDM board — elevated access request	DGO + CISO sign-off	5 business days

▶  EXAMPLE WITH DATA

Scenario: Finance team raises a cross-domain issue and engages the hub to resolve it.

Step	Actor	Action	Channel	Outcome
1	Finance Analyst (consumer)	Runs a report joining finance_gold.gl.cost_centres with people_gold.hr.employees on owner name — gets 847 mismatches (name formats differ)	Databricks SQL Notebook	Problem identified: ‘S. Mitchell’ ≠ ‘Sarah Mitchell’
2	Finance Analyst	Raises Jira ticket MDM-221: ‘Cost Centre owner names do not match HR system — need cross-domain join’	Jira MDM board	Ticket assigned to MDM Hub Owner Raj Desai
3	Raj Desai (Hub Owner)	Reviews ticket; confirms CC-5501 / EMP-1042 pair exists in review_queue with score 0.94. Notifies Tom Bauer (Finance Steward).	Jira + Teams message	Steward action requested
4	Tom Bauer (Finance Steward)	Reviews and approves CC-5501 ↔ EMP-1042 pair in review_queue at 09:40. Note: ‘Confirmed CC-5501 owner = Sarah Mitchell (EMP-1042)’	Databricks SQL review widget	Pair approved — promoted to golden.person at 12:00 MERGE run
5	Finance Analyst (consumer)	Re-runs report — now joins mdm_hub.golden.person WHERE finance_source_id IS NOT NULL — gets clean cross-domain view with mdm_id as join key	Databricks SQL Notebook	847 mismatches resolved. Cross-domain report accurate.
6	MDM Hub Owner	Closes Jira ticket MDM-221. Resolution documented: ‘Hub golden record MDM-PRS-00001 links CC-5501 ↔ EMP-1042. Consumer onboarded to golden.* query pattern.’	Jira + audit.match_log	Issue resolved, consumer switched to hub query

9. RACI Matrix

R = Responsible (does the work)  |  A = Accountable (single owner; approves)  |  C = Consulted (provides input)  |  I = Informed (kept updated)

Activity	Hub Owner(Raj Desai)	People Steward(Claire Obi)	Finance Steward(Tom Bauer)	Mfg Steward(Divya Sharma)	MDM Engineer(Ben/Anya)	Consumer	DGO(Priya Nair)
Design Hub catalog structure & schemas	A	C	C	C	R	I	C
Build & maintain source_views	C	C	C	C	R/A	I	I
Define matching rules — Person entity	A	R	C	I	C	I	C
Define matching rules — Org Unit	A	C	R	C	C	I	C
Define matching rules — Location	A	I	C	R	C	I	C
Build DLT matching pipeline	C	I	I	I	R/A	I	I
Review match queue — Person	I	R/A	I	I	I	I	I
Review match queue — Org Unit	I	C	R/A	C	I	I	I
Review match queue — Location	I	I	C	R/A	I	I	I
Resolve cross-domain steward conflict	A	C	C	C	I	I	R
Certify & publish Golden Records	A	C	C	C	R	I	C
Grant consumer access to golden.*	A	I	I	I	R	I	C
Monitor DQ metrics daily	I	I	I	I	R/A	I	I
Resolve P1 pipeline failure	A	I	I	I	R	I	I
Configure Purview scans & lineage	C	I	I	I	R/A	I	C
Approve matching threshold changes	A	C	C	C	I	I	R
Quarterly access review	A	C	C	C	R	I	C
Onboard new domain to hub	A	C	C	C	R	I	C
Report Hub KPIs to DGC (monthly)	R/A	C	C	C	C	I	C
Author / update DG Policy	C	I	I	I	I	I	R/A

▶  EXAMPLE WITH DATA

RACI in action — certifying Sarah Mitchell’s golden record (MDM-PRS-00001) on 12 March 2024:

RACI Activity	Role	Person	Action Taken	Date/Time
Define matching rules — Person entity (Accountable)	MDM Hub Owner	Raj Desai	Approved matching config: Person auto_approve ≥ 0.90, review 0.75–0.89	2024-03-01 (DSC meeting)
Define matching rules — Person entity (Responsible)	People Steward	Claire Obi	Specified blocking key: first 3 chars surname + soundex(email). Reviewed test results on sample data.	2024-03-01
Build DLT matching pipeline (Responsible)	MDM Engineer	Ben Kowalski	Built and deployed DLT pipeline; EMP-1042 processed in overnight run 2024-03-12 02:00	2024-03-10 (deploy)
Review match queue — Person (Responsible + Accountable)	People Steward	Claire Obi	Approved EMP-1042 ↔ PLT-007 pair (score 0.82) at 08:15. Note added to audit log.	2024-03-12 08:15
Certify & publish Golden Records (Responsible)	MDM Engineer	Anya Petrov	12:00 MERGE job ran: MDM-PRS-00001 updated with mfg_source_id = PLT-007. certification_status = CROSS_DOMAIN_CERTIFIED	2024-03-12 12:01
Certify & publish Golden Records (Accountable)	MDM Hub Owner	Raj Desai	Informed via DQ dashboard — MDM-PRS-00001 certified across 3 domains. No action required.	2024-03-12 12:05
Monitor DQ metrics daily (Responsible)	MDM Engineer	Anya Petrov	23:00 DQ job: MDM-PRS-00001 checks passed. All KPIs GREEN.	2024-03-12 23:00

10. Key Performance Indicators

KPI	Target	Frequency	Owner	Example Baseline (Wk 1)
Golden Record Coverage — Person	≥ 95% active employees cross-domain certified	Weekly	Claire Obi	72% (target by Wk 6)
Golden Record Coverage — Org Unit	≥ 90% dept codes linked to cost centres	Weekly	Tom Bauer	58% (target by Wk 9)
Auto-approval Match Rate	≥ 80% of candidate pairs auto-approved	Daily	Ben Kowalski	82% on Day 1 run
Review Queue SLA	0 items older than 48 hours	Daily	Raj Desai	3 items cleared same day ✔
Golden Record Completeness	canonical_name 100%; canonical_email ≥ 95%	Daily	Anya Petrov	name 100% ✔, email 96% ✔
Zero Duplicates in Golden Layer	0 records with same email under different mdm_id	Daily	Anya Petrov	0 duplicates ✔
Purview Lineage Coverage	100% of golden.* tables have end-to-end lineage	Monthly	Priya Nair	3/3 tables covered ✔
Consumer Adoption	≥ 80% of cross-domain notebooks use golden.*	Monthly	Raj Desai	2/11 notebooks switched (target by Wk 12)

11. Implementation Roadmap

Phase	Weeks	Key Activities	Milestone
Phase 0 — Foundation	Wk 1–2	Create mdm_hub catalog + 4 schemas. RBAC grants. Register in Purview. CI/CD onboarding.	mdm_hub live. Purview scanning.
Phase 1 — Source Views	Wk 2–3	Build source_views for all 3 domain catalogs. Stewards validate canonical column names.	All source views live and steward-approved.
Phase 2 — Person Matching	Wk 3–6	DLT matching pipeline for Person. Configure score thresholds with stewards. First golden.person load.	First cross-domain golden records. Stewards reviewing queue.
Phase 3 — Org Unit + Location	Wk 6–9	Extend matching to Org Unit + Location. Build golden.org_unit + golden.location. Cross-entity FKs.	All 3 core golden entities live and linked.
Phase 4 — Governance & Monitoring	Wk 9–10	Wire full Purview lineage. DQ monitoring jobs + alerts. DQ scorecard dashboard.	End-to-end lineage. DQ dashboard live.
Phase 5 — Consumer Onboarding	Wk 10–11	Update downstream notebooks to reference mdm_hub.golden.*. Consumer guide published.	Consumers switched. Adoption baseline set.
Phase 6 — Hypercare & BAU	Wk 11–12	Daily steward + engineer review. KPI baselining. Runbook + documentation handoff.	Hub in steady-state BAU operations.