Case study · Master data management platform
Four core business domains, each with its own decade-long history of tables, rules and exceptions. Every domain called its own data the truth. None of them had a way to prove it. We built the one governed source of record every downstream system could finally trust.
StatusDelivered
A global automotive safety systems manufacturer running commercial, product, organizational and regional master data for 150+ users across sales, engineering and operations.
Every domain called its own data the truth. None of them had a way to prove it. Identity withheld at the client's request.
Four core business domains, each with its own decade-long history of tables, rules and exceptions.
Sales, engineering and operations, all depending daily on master data none of them could prove.
Every organization's most important data exists to answer one question the same way, everywhere it's asked: what's actually true right now? That promise has seven concrete parts.
Exactly one authoritative version of any given record, not one version per system that happens to reference it.
The system actively stops a record from becoming wrong, rather than storing whatever it is given.
The whole shape of a hierarchy is visible and trustworthy, not just one record in isolation.
Who can edit this record has exactly one governed answer, not several that might disagree.
Who changed a record, when, and what it looked like before, all visible. History, not assertion.
At financial close and regulatory reporting, the record is provably frozen, not merely unlikely to change.
Other systems consume the source of truth rather than maintaining their own shadow copy.
A platform that keeps all seven is managing master data. A platform that keeps some of them is just a database with good intentions. Here's what the client had, pillar by pillar, and what we built instead.
There should be exactly one authoritative version of any given record, not one version per system that happens to reference it.
Four domains, each maintaining its own definition of "valid" for over a decade, with no shared foundation forcing agreement between them. Data wasn't necessarily wrong. It just had no mechanism guaranteeing it stayed right, or stayed the same, everywhere it was referenced.
A metadata-driven engine where every table's structure, constraints and relationships are defined once, as data, not once per screen, once per integration and once per report. Every part of the platform reads from that same definition, so a rule declared once is true everywhere it applies, by construction, rather than by hoping 130 separate implementations happen to agree.
A record only deserves to be called master data if the system actively stops it from becoming wrong, not just stores whatever it's given.
The rule that keeps a hierarchy trustworthy, that a parent record can't be invalid while a valid child still depends on it, existed on the large majority of the platform's tables, implemented independently, by different people, more than a hundred times over a decade. A consistency rule enforced a hundred different ways isn't really guaranteeing consistency.
One shared validation engine enforcing that rule centrally, plus a no-code constraint builder covering the standard 90% of data-quality rules (format, mandatory fields, cross-references), and a single pluggable rule engine for the genuine exceptions: a code that must match its parent's prefix, a record type permitted exactly one active instance system-wide.
Master data is rarely flat. A product belongs to a category, a facility belongs to a region, a brand belongs to a customer, and the truth about a hierarchy means being able to see the whole shape of it, not just one record in isolation.
Product classifications, organizational structure and regional groupings were each built as separate, one-off navigation screens. A fix to how one hierarchy displayed data taught the platform nothing about the other four.
A single, reusable hierarchy-navigation component, built once against the shared foundation and parameterized per structure, so trusting the shape of one hierarchy means trusting the shape of all of them, built to the same standard.
A source of truth is only as trustworthy as the control over who's allowed to change it. "Who can edit this record" should have exactly one governed answer, not several that might disagree.
Fifteen-plus overlapping legacy access roles had accumulated over a decade, each answering a version of the same permission question slightly differently, to the point that auditing who actually had access to what required manual reconciliation.
A single role-based access model, enforced down to the individual table and column, with a defined path to consolidate roughly 150 legacy accounts down to around 40 by removing access tied to administration that had already moved elsewhere.
People trust a record because they can see how it got to its current state: who changed it, when, and what it looked like before. A source of truth without a visible history is just an assertion.
A decade of change history existed, but under a legacy structure complex enough that carrying it forward unmodified risked becoming its own maintenance burden.
Full historization of every insert, update and deletion, read-only even for administrators, to preserve audit integrity, migrated under a deliberately simplified structure agreed with the client specifically to keep every historical record intact without carrying forward legacy complexity that no longer served a purpose.
There are moments, financial close and regulatory reporting among them, where the record of truth has to be provably frozen, not just unlikely to change.
A monthly freeze protected certain tables from edits through the application's own screens. Sufficient, until administration of three tables moved to a separate system and a new integration was built to sync them, without anyone checking whether it respected the freeze.
Freeze state enforced at a single checkpoint every write must pass through, regardless of source, so the new integration inherited the same protection automatically, because it was built against that checkpoint from its first version rather than retrofitted onto it later.
The whole point of a single source of truth is that other systems consume it, rather than maintaining their own shadow copy. A master data platform that isolates its data has failed at the one job that matters most.
Downstream reporting tools, data pipelines and direct data consumers all depended on the existing platform's data. Any replacement that couldn't serve them identically would just create a second, competing version of the truth.
REST APIs, direct database access for reporting, and full compatibility with existing data-distribution pipelines, so every existing consumer of master data continued reading from the same authoritative source, unmodified, through the transition.
One row per promise. Four of the seven are the same shape, many independent implementations replaced by one, and a fifth replaced every consumer at risk with zero.
Master data management isn't a database. It's seven separate promises: one truth, enforced quality, trustworthy hierarchy, governed access, visible history, protected lifecycle and honest distribution. They only count as kept if you can prove each one, not just claim it.
If four teams can each show you a different number and none of them can show you why, the problem isn't the reporting. It's that nothing underneath is obliged to agree.