Master data management is how an organisation ends up with one record per customer, product or supplier when six systems each hold part of it and none of them agree. The diagram below shows the hub, what it does to the fragments, and the four standard ways it can be run.
What the hub actually does
- 1Match: decide which records are the same real-world thing. R. Smith, Rob Smith and Robert Smith Ltd may be one customer or three. Matching is a set of rules and thresholds you have to agree on, and it is the part that cannot be bought pre-configured.
- 2Merge: decide which value wins. When the CRM and the ERP disagree about the billing name, survivorship rules pick one – most recently updated, most trusted source, or most complete. Writing these rules down is the real MDM project.
- 3Publish: send the result back. A golden record nobody consumes is an expensive report. The hub distributes the resolved record to the systems that need it, or exposes it for them to read.
The four implementation styles
- Registry: stores only the matches and global IDs, leaving data in place. Lightest to adopt, but no single clean record physically exists.
- Consolidation: copies data in, cleans it, and publishes a golden record for analytics. Source systems keep operating on their own versions and are never written back to.
- Coexistence: the golden record is mastered in the hub and synced back to the sources, which carry on running operationally. The usual middle ground.
- Centralised: the hub becomes the system of record and applications read and write through it. Cleanest result, hardest and slowest to adopt.
Organisations generally move along that order as complexity grows, rather than starting at the end of it.
Why MDM projects stall
Almost never for technical reasons. They stall because matching and survivorship are business decisions dressed as configuration, and nobody with the authority to settle them is in the room. The practical route is to master one entity – usually customer – agree the rules for it, and prove the value before extending to product or supplier.
MDM and the warehouse
A consolidation-style hub often lives in the same warehouse as your analytics, which is why MDM and modelling blur together in practice. The consuming side of that picture is on our data warehouse architecture diagram, and pushing the resolved record back into operational tools is reverse ETL.
What this looks like in Peliqan
With 300+ sources landing in one place, matching and survivorship can be written as SQL or Python against every contributing system at once, and the resolved record pushed back out to the tools that need it – rather than reconciled by hand in a spreadsheet each quarter.
Use this diagram wherever you like
The diagram is free to use, including commercially, as long as there is a visible link back to this page. Download the PNG for slides and documents, or the SVG if you want to edit the labels. No email required. You can browse the rest of the set in the Peliqan diagram library.
Ready to build this on your own data? Get started with Peliqan.
