Lesson 9 — Stewardship, Sharing, Reference Change, and Culture
Automation can compare records, standardize values, assign scores, and publish data. It cannot decide every business exception or create accountability. Chapter 10 therefore treats stewardship and governance as the human control plane around shared data.
What stewardship adds
Data Stewards can: - review uncertain duplicate candidates; - resolve identity and attribute conflicts; - investigate false positives/negatives; - approve or route Reference changes; - maintain definitions and mappings; - review survivorship outcomes; - communicate changes to consumers; - feed recurring errors back into rules and source-process improvements.
Stewardship should not become permanent manual cleanup. If the same exception appears repeatedly, the program should improve upstream quality, rules, models, or process design.
RDM stewardship vs MDM stewardship
RDM stewardship focuses on domains, definitions, versions, mappings, hierarchies, change requests, effective dates, and publication.
MDM stewardship focuses heavily on entity identity, match exceptions, identifiers, survivorship, relationships, and trusted entity attributes.
Reference Data change workflow
Because Reference values are widely shared, change should be controlled:
Receive request → identify stakeholders → identify impact → decide/approve → update → communicate/inform.
This applies whether the change is planned or ad hoc, although the rigor can vary with risk.
Data Sharing Agreement vs technical interface specification
Data Sharing Agreement
Defines governance obligations: - what data may be shared; - permitted purposes and conditions of use; - provider/consumer responsibilities; - security/privacy/retention obligations; - quality/service expectations; - issue/escalation processes; - accountability for failures or changes.
Technical interface specification
Defines exchange mechanics: - structures and mappings; - endpoints/protocols; - schemas/formats; - technical transformations.
A technically correct interface does not grant permission or establish accountability.
Memory cue: Agreement = permission and promises; interface = pipes and payloads.
SLA vs Data Quality rule
An SLA concerns service behavior such as availability, delivery time, refresh time, or latency.
A Data Quality rule tests content fitness such as validity, completeness, conformity, or an accuracy proxy.
Examples: - “Customer Master feed must arrive by 6 a.m.” → SLA. - “Country code must belong to the approved ISO set.” → DQ rule.
Late correct data = primarily an SLA issue.
On-time invalid data = primarily a DQ issue.
One incident can violate both, so use the stem’s primary evidence.
Monitor data movement
Monitoring should show: - providers and consumers; - lineage; - sharing/usage; - latency and ingestion effectiveness; - integration/transformation behavior; - root-cause path for defects.
Fixing a bad value only in a downstream consumer hides the upstream problem and allows repeated inconsistency.
Culture and local control
Enterprise Reference and Master Data can challenge departmental ownership habits. Teams may resist: - giving up local code sets; - accepting enterprise identifiers; - changing source processes; - using central publication services; - submitting changes through governance.
A repository can exist while adoption remains low. “We built the RDM hub” is not the same as “applications consume the governed Reference values.”
Governance, practical integration, communication, incentives, and measurement are needed to create enterprise use.
Stop and check
If a central RDM repository is populated but applications still use local values, the primary problem is adoption/governance/publication, not “add more rows to the repository.”
Source anchor: pp. 353–359.