Data engineering · Master data
Master data management for customers, materials and assets
We build master data management for customers, materials and assets, and for suppliers and locations: golden records assembled from several systems, matching and survivorship rules, stewardship workflows where people resolve what rules cannot, and distribution of clean data to the systems that use it. The same customer, part or asset means the same thing everywhere, and you own the platform, the rules and the code.
Reference architecture · Data and integration
Data platform and integration reference architecture
A reference checklist for enterprise integration, modernisation and data platform projects: domains, integration patterns, contracts, platform layers, master data, quality, security and operating model.- 01Eight areas to decide before you modernise, integrate or build a data platform.
- 02Contract, schema and versioning items that stop integrations breaking.
- 03Quality and ownership items that make a platform trusted.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Domain and ownership model
The master data domains in scope, such as customer, product, supplier, asset and location, with business owners, definitions and the attributes each must hold. - 02
Source integration
Ingestion of records from ERP, CRM, MES, maintenance and other systems, with identifiers retained so every source record links to its master. - 03
Matching and merge rules
Deterministic and probabilistic matching to find the same entity across sources, with thresholds and a queue for uncertain matches. - 04
Survivorship
Rules that decide which source supplies each attribute of the golden record, by source reliability, recency or completeness, and explained for each value. - 05
Data quality rules
Validation, standardisation and enrichment, including address, tax and identifier checks, with quality scores by domain and source. - 06
Stewardship workflow
Queues, tasks and approvals for stewards to resolve matches, fix errors and approve new or changed records, with service levels. - 07
Hierarchies and relationships
Corporate hierarchies, product classifications, asset structures and relationships, managed with history and effective dates. - 08
Distribution and synchronisation
Publication of golden records and changes to consuming systems through events and APIs, and feedback of source changes. - 09
Reference data and governance
Managed code lists and a governance process for definitions, change requests and metrics on the health of master data.
Reference architecture.
Standards and interfaces
What we design against.
- ISO 8000-110 and master data quality
- Requirements for the quality of master data in exchange, including identifiers, provenance and syntax.
- GS1 standards
- GTINs and the Global Data Synchronisation Network for sharing product master data with trading partners.
- Legal entity identifiers
- LEI under ISO 17442 for identifying legal entities consistently across systems and regulators.
- ISO 15926 and CFIHOS
- Reference data and handover specifications for asset and equipment master data in process industries.
- DAMA-DMBOK
- Practices for governance, stewardship and data quality management.
- Data protection law
- Lawful processing, accuracy and retention of personal data held in customer and supplier masters.
Data model
The core entities.
- Golden record
- Master identifier, attributes with source and survivorship rule, status and version.
- Source record and cross-reference
- Source system, local identifier, link to the golden record and the match score.
- Match candidate
- Record pair, score, rule, decision and the steward who decided.
- Hierarchy and relationship
- Parent, child, type, effective dates and source.
- Quality score
- Rule, record or domain, result, trend and owner.
- Change request
- Proposed change, requester, approvals, status and effective date.
- Reference value
- Code list, value, meaning, mappings to other systems and validity.
When custom development is the right call.
Controls designed in, not added later.
Controlled change to masters
Creation and change of master records follow approval rules, with a complete history.Access by domain and role
Stewards, owners and consumers see only the domains and attributes they need, and sensitive data is protected.Merge safety
Merges can be undone, with the original records kept and linked.Integration integrity
Distribution is idempotent, and consumers acknowledge changes so no system is left behind.Audit trail
Every match decision, change and publication records user and time.
From discovery to a system you run.
- 01
Domain and pain-point review
We pick the first domain by cost of poor data and breadth of use, and measure duplicates, gaps and conflicts across the systems that hold it. - 02
Model, rules and ownership
The golden record model, matching and survivorship rules, stewardship roles and distribution approach are designed with the owners. - 03
Build and load the first domain
Records from source systems are loaded, matched and merged, and the results are reviewed by stewards. - 04
Distribute and operate
Golden records flow to consuming systems, the stewardship process runs and quality metrics are published. - 05
Add domains
Further domains follow on the same platform and governance, with hierarchies and reference data.
Relevant work
Where to see our work.
Common questions.
- Do we need master data management software?
- Not always. For a single domain in a single ERP, good data governance and the ERP's own tools may do. MDM pays off when the same entities live in several systems and conflict, or when decisions depend on a consistent view.
- How do you match records across systems without common keys?
- With rules and statistical scores on names, addresses, identifiers and other attributes, tuned on your data, with uncertain matches sent to a steward. Matching improves as decisions are fed back.
- Does MDM replace our ERP's master data?
- It sits beside the ERP and other systems. Depending on the style chosen, it either consolidates and publishes golden records, or becomes the place where masters are created and then distributed.
- Who should own master data?
- The business. Each domain has an owner and stewards who decide definitions and resolve conflicts. The platform makes their decisions visible and enforceable.
- Who owns the platform and code?
- You do. The code, the rules and the data stay yours.