Ownership model
Each attribute has one system of record, enforced and documented.
Why. Master data without ownership is just another copy.
Trade-off. Needs business agreement, which is the hard part.
Integration and multi-application · Master data
Master data management and integration across HR, finance and CRM
Agree who owns each core entity (person, organisation, product, cost centre), publish the golden record to the systems that need it and reconcile the differences before they reach a report or an auditor.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- Australian Privacy Principles
- ACSC Essential Eight
- Records management obligations
Architecture
- SaaS and business systems
- Databases and data
- Messaging, events and workflow
- Monitoring, audit and analytics
- Security and identity
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Each system of record sends changes for the entities it owns, via CDC, API or file, with its own identifier.
The hub validates and standardises (names, addresses, ABNs, codes) and rejects or flags poor-quality records at the boundary.
Match and merge rules link records for the same real-world entity and choose surviving attribute values by documented survivorship rules.
The golden record is stored with history and lineage back to every contributing record.
Uncertain matches go to a data steward queue for a human decision, which becomes a rule or an override.
Changes are published as events and APIs. Consumers receive the golden identifier with their local key.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Ingestion (CDC, APIs, files) | Brings entity changes into the hub. | Do not make source systems call the hub synchronously for their daily work. |
| Standardisation and validation (ABN lookup, address validation) | Cleans data at the edge. | Cleaning once is cheaper than every report cleaning it again. |
| Match and merge engine (rules, optionally ML-assisted) | Entity resolution. | Start deterministic, add probabilistic only where you can measure it. |
| Golden record store (PostgreSQL, or a commercial MDM such as Informatica, Reltio or Profisee) | Authoritative, versioned entities. | Many organisations do well with a well-designed database. Buy MDM when the number of domains and stewards grows. |
| Steward console | Review, approve and override. | People decide the hard cases. |
| Publish layer (events, APIs, files) | Distributes golden data. | Consumers choose the integration mode that suits them. |
| Data catalogue and lineage | Where fields come from and who owns them. | Auditability. |
| Data quality monitoring | Rules and dashboards. | Quality is a measure, not a project. |
Design decisions and trade-offs
Hub style
Registry or coexistence style first, centralised only if needed.
Why. Less disruption than forcing all edits through the hub.
Trade-off. Eventual consistency between systems.
Matching
Deterministic first with steward review.
Why. Explainable and safe.
Trade-off. Some duplicates remain until reviewed.
Product vs build
Build on a relational store for one or two domains, buy when you have many.
Why. Cost proportionate to the problem.
Trade-off. Build needs engineering discipline.
Well-architected pillars
Security
Role-based stewardship, field-level access for HR data and logged changes.
Reliability
Replayable ingestion and versioned golden records, so a bad rule can be rolled back.
Performance
Incremental matching and indexed keys.
Cost optimisation
Mostly people (stewards) and licences. Compute is modest.
Operational excellence
Data quality scorecards by domain and monthly steward reviews.
Sustainability
Fewer duplicate records and fewer reconciliation spreadsheets.
Network, identity and data
Networking
Private connectivity to systems of record and private endpoints to the hub's data store. Published APIs behind the integration gateway.
Identity and least privilege
Stewards and consumers use SSO with separate roles. HR attributes are visible only to roles with a business need. Service accounts per source connector.
Data and encryption
Employee and customer data are personal information. Restrict sensitive attributes, apply retention and destruction rules, and keep lineage to demonstrate correct handling (APP 11 and 13).
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Data quality and correction | Golden record and stewardship support APP 10 (quality) and APP 13 (correction). |
| Restrict administrative privileges | Separate steward, admin and consumer roles. Essential Eight. |
| Logging | Change history and lineage for audit. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOHours, with sources replayed
- Target RPONear zero for the golden store, with point-in-time recovery
- Scaling and limitsMillions of records are manageable on a relational store with proper indexing.
| Failure mode | Mitigation |
|---|---|
| Wrong merge | Versioned records and an unmerge capability. |
| Conflicting edits at two sources | Survivorship rules and system-of-record enforcement. |
| Consumer uses stale data | Publish events and show data age. |
| Steward queue grows without limit | SLAs, auto-rules for repetitive cases and owners. |
Observability and runbooks
- Duplicate rate and match confidence distribution.
- Steward queue age.
- Per-source data quality scores.
Cost drivers and levers
Steward time, MDM licences if bought, integration runtime.
- Start with one domain.
- Automate frequent decisions.
- Fix at the source.
Implementation and fit
Phased approach
- Choose the first entity and agree ownership.
- Build ingest, standardise and deterministic matching.
- Stand up steward review and publish.
- Add the next domain.
Anti-patterns to avoid
- An MDM tool bought before ownership is agreed.
- Cleansing in every report.
- Fuzzy matching without review.
- No steward role.
When to use it
- Duplicate customers, suppliers or employees across systems.
- Reporting that never reconciles.
When not to
- One system holds the master already.
- No business owner for the data.
More in integration and multi-application
Modernisation
Legacy system modernisation with the strangler fig pattern, APIs and RPA
Replace a legacy system one capability at a time. A routing facade sends each request to the old or new implementation, anti-corruption layers protect the new design and RPA covers the gaps until APIs exist.
Partners
B2B file and EDI exchange with partners and suppliers
Secure, auditable exchange of orders, invoices and reports with partners that still send files: managed SFTP, validation, translation, acknowledgements and monitoring that proves nothing was lost.
AWS and Azure
API-led integration hub with an event bus, API gateway and iPaaS
A small number of governed APIs and an event backbone in front of many systems, so each application integrates once with the hub instead of with every other application.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.