SSOT architecture: how to build a single source of truth in a large organization
Single Source of Truth is not a single product but an architectural principle. This article walks through how to build SSOT across key data domains in a bank, an operator, or a government organization, which components are mandatory, which political obstacles are typical, and how to overcome them.
Discuss Your ChallengeThis architectural article covers SSOT as an architectural principle — not a single product but an approach to assigning accountability and update flows between systems.
What architecture challenge is being solved
In a large organization, every data domain (customers, products, contracts, operations) lives in multiple systems simultaneously. Each system considers itself the source of truth but lacks the full picture. Discrepancies between copies accumulate over years and become a systemic problem — reports do not reconcile, the regulator asks questions, business decisions are made on different versions. SSOT is an architectural approach where one source of truth is assigned per data field; other systems are consumers.
Which systems, data flows and teams are involved
- Domain systems — core banking (bank), BSS (operator), government registries, ERP, CRM
- Identity and entity resolution layer — customer, contract, product, transaction
- Master data store (MDM) — unified profile with source-of-truth attribution by field
- Event bus — update flow between sources and consumers
- Data steward as a role — conflict resolution, quality control
- Consent and audit layer — who, when, used what data
Typical architecture mistakes
- Declaring SSOT without assigning field accountability — every agency/block continues considering itself the source
- Trying to build a unified store of all data — a copy of all systems in one place, without an operating model
- MDM without a data steward — the system degrades from garbage in months
- SSOT launch in isolation from consumers — no one uses it because data is considered stale
- Ignoring inter-agency/inter-block politics — technology does not resolve disputes about whose data is right
- No historization — impossible to know what was true at a past moment
Possible approaches
- Full MDM — centralized master data store, update flows from sources. Mature approach for large organizations
- Distributed SSOT — each domain lives in its source but publishes events to a shared stream. Lightweight approach with lower load
- Federated SSOT — combination: critical domains in MDM, others through distributed model
- Read replica SSOT — shared read-only copy for analytics and channels, sources remain master
How to avoid unnecessary core replacement
SSOT is built around existing systems, not in their place. Each system remains the source of truth for its fields but publishes updates to a shared stream. When one system ages out, it can be replaced without rebuilding the SSOT layer — the layer consumes events from any source implementing the shared contract. System replacement is a separate program, not an SSOT precondition.
Risks, dependencies, constraints
- Political work between system owners is the main risk, not technology. Without inter-agency/inter-block agreement, SSOT stalls
- Data steward as a mandatory role with mandate to resolve conflicts
- Source data quality — SSOT makes garbage visible but does not auto-clean it
- Historical data migration complexity — can take years on large volumes
- Regulatory data protection and consent requirements — embed from day one
How a phased roadmap should look
- Months 1-3: domain inventory, source-of-truth negotiations by field, data steward role formation
- Months 4-9: identity resolution layer and unified profile for the priority domain (usually customer)
- Months 10-15: event flows from sources into SSOT, profile consumption by channels
- Months 16-24: expansion to next domains (products, contracts, transactions)
- After 24 months — gradual historical data migration, expansion to minor domains
What else is worth exploring
Topics from the same area we usually explore together
CRM
Not an off-the-shelf CRM, but a properly built customer management contour — from first contact to loyalty.
→SolutionBI
Analytics is not pretty charts on the wall. It's the answer to 'why?' before the problem becomes a loss.
→SolutionContact Center
The contact center is not a phone station — it's the point where a client decides: stay with you or leave. The question is how it's built…
→SolutionOnboarding
Onboarding is your company's first impression. If it takes 5 days and 12 paper forms, there won't be a second impression.
→I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.
Discuss applying this →Ready to discuss your challenge?
Tell me what's not working or what needs to be built. First conversation — no obligations.
Usually respond within a few hours