Deep Battle Cards G–L
G — Global ID vs Source ID vs X-Ref
Definition: Source ID = local application identifier; Global ID = enterprise identifier for reconciled entity; X-Ref = mapping/history between them.
Purpose: preserve local identity while establishing stable enterprise identity and traceability.
Outputs: one Global ID plus source-to-global mapping history.
Scenario: CRM 381, Billing 99, Service C-44 → Global G-100; mapping table = X-Ref.
Common confusion: X-Ref is not another ID; Global ID does not erase Source IDs.
Trap: a country-code crosswalk is Reference Data cross-reference, not Master identity X-Ref.
Memory: Global = enterprise tag; X-Ref = trail to local tags.
Source: pp. 346–347.
H — Registry vs Transaction Hub vs Consolidated
Definition: Registry indexes source-held Master Data; Transaction Hub owns/stores updates and is SOR; Consolidated copies/reconciles source data into a central System of Reference while sources keep writes.
Purpose: balance source disruption, central control, latency, integration, and consumer access.
Inputs: SOR count, update authority, governance maturity, latency, consumers, organizational structure.
When used: minimal source disruption/index → Registry; central writes → Transaction Hub; stored shared read view/source writes remain → Consolidated.
Common confusion: Registry and Consolidated both may leave sources as SORs; only Consolidated stores the shared integrated copy.
Trap: “central hub” is insufficient; inspect write authority and data location.
Memory: Registry points; Transaction Hub owns; Consolidated copies.
Source: pp. 349–351.
I — Standardization vs Enrichment
Definition: standardization normalizes representation; enrichment adds trusted supplementary information.
Purpose: make existing evidence comparable vs make records more complete/useful.
Inputs: raw source attributes + standards/reference values vs trusted enrichment sources.
Scenario: 9015551212 → (901) 555-1212 = standardize; add verified latitude/longitude = enrich.
Trap: poor match quality can result from skipped standardization; do not jump directly to matcher replacement.
Memory: standardize = comparable; enrich = fuller.
Source: pp. 343–344.
J — Data Sharing Agreement vs Technical Interface Specification
Definition: sharing agreement defines rights, conditions, responsibilities, service/quality/privacy/security obligations; interface specification defines structures, mappings, endpoints, protocols, formats.
Purpose: govern accountability vs enable technical exchange.
Owners: governance/legal/privacy/security/business for agreements; architecture/development/integration for interface specs.
Scenario: “approved analytics use + defect reporting obligation” = agreement; “POST JSON maps customer_id to enterprise_party_id” = interface spec.
Trap: technically correct exchange does not create permission or accountability.
Memory: permission/promises vs pipes/payloads.
Source: p. 357.
K — SLA vs Data Quality Rule
Definition: SLA = service level such as availability/latency/delivery time; DQ rule = condition on content such as validity/completeness/conformity.
Purpose: distinguish service failure from content fitness failure.
Scenario: valid feed four hours late = SLA; on-time feed with invalid status code = DQ.
Common confusion: one incident may violate both; use the stem’s primary evidence.
Memory: SLA = service promise; DQ rule = content test.
Source: pp. 357–359.
L — Tool Implementation vs MDM Program
Definition: tool implementation installs/configures technology; MDM program coordinates people, process, governance, stewardship, architecture, DQ, integration, and technology.
Purpose: sustain trusted shared Master Data, not merely automate matching.
Inputs: drivers, requirements, sources, authority, rules, roles, architecture, DQ, technology.
Outputs: trusted/shared Master Data plus governance, stewardship, monitoring, roadmap, adoption evidence.
Scenario: matcher deployed but no steward owns false-match exceptions → incomplete MDM program.
Trap: when failure is organizational, prefer governance/stewardship/root-cause repair over buying more software.
Memory: a tool can match; a program makes the result trustworthy.
Source: pp. 340–359.