Lesson 7 — Registry, Transaction Hub, and Consolidated Architecture
Architecture questions become much easier when you ignore the word “hub” and ask two things:
- Where is the Master Data stored for enterprise use?
- Who owns authoritative writes and updates?
Chapter 10 presents three major patterns.
Registry — the hub points
A Registry maintains enterprise identity/indexing while Master Data remains in source Systems of Record.
Pattern: Registry/index → source SORs.
Strengths
- minimizes source-system disruption;
- can establish enterprise identity across many systems;
- source applications can retain maintenance authority.
Trade-offs
- complete consumer views may require assembling data from distributed sources;
- distributed business rules and access can be complex;
- availability/performance can depend on source systems.
Exam clue
“Enterprise index,” “minimal source changes,” or “Master Data remains in existing SORs.”
A Registry does not mean the hub centralizes all writes.
Transaction Hub — the hub owns
A Transaction Hub becomes the authoritative Master Data maintenance point. Applications create/update Master Data through the hub.
Pattern: Applications ↔ Hub = SOR.
Strengths
- strong central consistency and governance;
- common write rules;
- one authoritative maintenance process.
Trade-offs
- significant technical and organizational change;
- source applications/processes may need redesign;
- central availability and operating requirements become critical.
Exam clue
“All updates must go through the hub,” “central write authority,” or “hub becomes SOR.”
Consolidated — the hub copies
Source systems remain Systems of Record, while data is copied, standardized, matched, and reconciled into a central repository used as a System of Reference.
Pattern: source SORs → replicated/reconciled central System of Reference → consumers.
Strengths
- provides one stored enterprise view for consumers;
- sources retain local write authority;
- consumers do not need to query every source directly.
Trade-offs
- replication/synchronization;
- latency between source changes and the shared view;
- semantic reconciliation and DQ still required.
Exam clue
“Sources keep writes,” “one stored enterprise read view,” “replicated/consolidated copy.”
Registry vs Consolidated
Both can leave source systems as SORs.
The difference: - Registry primarily indexes/points to source-held data. - Consolidated stores a reconciled shared copy for enterprise consumers.
Transaction Hub vs Consolidated
- Transaction Hub = central write authority; hub is SOR.
- Consolidated = source systems keep writes; hub centralizes a read-oriented replicated view.
No universally best architecture
Choose based on: - number and distribution of SORs; - organizational structure and global scale; - governance maturity; - latency/access needs; - number and type of consumers; - integration complexity; - source-change feasibility; - cost and operating constraints.
Architecture should follow business/data requirements, not a product demo.
Example
Five acquired businesses keep separate CRMs.
- If the enterprise wants one identity index but minimal changes → Registry may fit.
- If all future customer updates must occur centrally → Transaction Hub.
- If local CRMs keep writes but analytics needs one nightly reconciled customer repository → Consolidated.
Stop and check
“Central hub” alone is not enough to answer. Inspect write authority and whether the hub stores a shared copy.
Source anchor: pp. 349–351, 355–356.