They fail on sponsorship, sequencing, adoption, integration politics and the cost of being wrong. This document is about those things — what actually goes wrong in master data programmes, and what we changed in MDM Studio so that it goes wrong less often.
By the time master data reaches an executive agenda, the organisation has usually already tried. There was a programme. It had a steering committee, a systems integrator and a three-year horizon. Somewhere around month fourteen it became a data quality reporting exercise, and somewhere around month twenty-two it became a line item nobody defended.
So the question in the room is rarely which platform has the better matching engine. It is harder and more political than that:
What is different about the approach, not the feature list — because the last feature list also looked complete.
New platform, new skills, new licences, new egress, and a supplier we cannot leave without a second migration.
Not a roadmap. A corrected record, in a system I use, that stays corrected.
These are patterns, not statistics. Each one has a recognisable early symptom, and each one is usually visible long before the budget conversation that ends the programme.
A sponsor is named on a slide and never again. Decisions about which system wins, which definition is canonical and who arbitrates a conflict get made by whoever is in the room — usually an architect. The business discovers the golden record after it has been built, disagrees with it, and keeps using their own extract. Early symptom: the programme cannot name, per domain, the one person who can approve a change to a definition.
Every domain is in scope because excluding one is politically expensive. Modelling runs for months because the model must be complete before anything is loaded. The first governed record appears after the sponsor has changed jobs. Early symptom: the plan’s first business-visible outcome is more than one quarter out.
Stewardship is a role assigned on top of an existing full-time job, with no queue, no prioritisation and no evidence that the work matters. The exceptions report is emailed weekly and read by nobody. Data quality becomes a number in a governance pack rather than a thing anyone does. Early symptom: nobody can say how many open exceptions there are, who owns them, or how old the oldest one is.
The hub is ready. The source system owners are not. Core banking will not accept writes. The ERP team has a change freeze. Security wants to know why master data is leaving the perimeter. Six months of the programme is spent negotiating access rather than mastering anything, and the eventual compromise — a one-way extract into a hub nothing consumes — produces a very well-governed data set that changes no decision. Early symptom: the integration plan requires a behaviour change from a team that does not report to the sponsor.
An automated merge combines two customers who are not the same person. It reaches a statement, or a clinician, or a regulator. Nobody can explain why the system decided they matched, and undoing it means a support ticket. From that day the golden record is “the system’s view”, to be checked against the real one. Early symptom: stewards cannot see, in one screen, the evidence behind a merge — and cannot reverse it themselves.
The master data lives in a proprietary store, the match logic lives in a proprietary rules format, and the annual cost rises with a metric the business does not control. Replacing the platform means a second migration as expensive as the first, so the organisation stays — unhappily, and without leverage at renewal. Early symptom: the answer to “what would it take to leave?” is a project plan.
Most MDM platforms are engines. They model, ingest, match, survive and publish extremely well, and they assume that sponsorship, sequencing, stakeholder management and change control arrive separately — as a methodology, in a consultant’s deck, in spreadsheets that are not connected to the hub and stop being updated by month four.
MDM Studio ships that layer as part of the product, wired to live hub state. That is the substantive difference, and it is the answer to five of the six failure modes above.
| Failure mode | What MDM Studio ships against it | What to make us prove |
|---|---|---|
| IT project wearing a business name | A per-domain stakeholder register inside the hub — sponsor, owner, steward, SME, custodian, consumer — each with RACI, decision rights, stated concerns, influence and interest, and a current-versus-target engagement level. Owner and steward seed automatically from the domain. | Open a domain and show the named sponsor, their decision rights, and the date of the last recorded interaction. |
| Boiling the ocean | A domain portfolio that scores each domain’s business criticality — operational impact, regulatory exposure, number of downstream consumers, volatility — and plots business value against maturity gap. The sequencing question becomes a chart rather than a negotiation. | Score three of your domains live and show which one the portfolio says to master first, and why. |
| Stewards never arrived | Failed quality rules become assignable exceptions with severity, owner, ageing and SLA state, grouped into owned remediation campaigns with target dates, surfaced in a personal task inbox. Resolutions are typed and automatically re-validated. | Show one steward’s queue: what is overdue, what is unassigned, and what the actual failing value is. |
| Integration became the project | Nothing is written to a source system unless you enable it, per connection, per entity, per attribute. Write-back can be delivered as a generated SQL script the source owner runs themselves — so the hub never needs credentials into the system that refuses to give them. | Produce the hand-off script for a change to one attribute, and the eligibility matrix that governs it. |
| Trust collapsed on a bad merge | Every merge keeps its scoring evidence. Unmerge is one governed action a steward performs — the pair is permanently declined, the cluster splits, the golden record is marked and superseded, and the decision is audited. | Merge two records, then split them back, and show the audit trail of both decisions. |
| A commitment nobody can unwind | Golden records live in your own database, on a platform you already run. Configuration exports to a portable, versioned JSON archive. If a licence key lapses the product falls back to the free Community edition rather than locking you out. | Export the configuration archive, and query the golden records directly in SQL without going through us. |
“Change management” usually means a communications plan and two town halls. The reason it fails is not that people resist change; it is that nobody can see whether it is working until it visibly is not.
Every domain carries its own stakeholders — internal ones linked to a user account, external ones by name and email and notifiable. Each has a role, a RACI position overall and per activity, an influence and interest rating, a communication cadence and channel, their stated concerns, the message that matters to them, and a running interaction log.
Each stakeholder records where they are on an engagement ladder and where the programme needs them to be. The gap between the two is the change-management backlog, and it is visible to the sponsor rather than living in a consultant’s spreadsheet.
The maturity assessment reads live hub state and proposes a level with the evidence behind it — how many entities are modelled, whether an owner and steward exist, whether a sponsor is recorded, what the measured quality score is. A workshop can override it, but it starts from what is actually true in the hub.
The assessment turns its own gaps into a roadmap: dated actions sized by effort and impact, grouped into Now / Next / Later, each with an owner resolved from that domain’s stakeholders and a link to the thing that tracks the work — a governance change request, a quality campaign, a model change, a mastering configuration. Re-run it and the actions re-sync to current gaps while keeping their status.
A steward who has to be trained into a tool before they can be useful is a steward who quietly stops. MDM Studio is built to be learnable in place:
The training budget is the first thing cut and the last thing that should be. The Adaptive Canvas Academy is free at every tier, including the free one: four certification tracks — Associate, Data Steward, Modeler & Integrator, Administrator — with graded exams, a guided lab that builds a complete Customer 360 in a real environment in roughly 150 minutes, and credentials that carry a verifiable ID and stay valid for 24 months. Because anyone can verify a certificate, you can require it of an implementation partner before they touch your estate.
When a source system owner says no, they are rarely saying the interface is hard. They are saying: I am accountable for this system, I did not ask for your programme, and I am not accepting writes from something I do not control. Platforms that assume write access as the normal case turn that into a governance escalation. We assumed the opposite.
The hub reads. Mastering, quality, governance and reporting all work with no write access to any source system, ever.
Write-back is enabled through an eligibility matrix per connection, per entity, per attribute — a specific, auditable grant, not a system-level one.
A preview computes exactly what would change and how many rows, and persists nothing. The source owner sees the blast radius before agreeing to anything.
An approved batch can be emitted as idempotent SQL, or as a source-side stored procedure, for their DBA to run under their own change process.
Every item in a batch is reviewed and approved or rejected individually or in bulk, applied, then verified by re-reading the source to confirm the value actually landed — and can be rolled back from a stored before-image. That sequence is what converts “you want write access to core banking” into a conversation a change advisory board can approve.
Replacing an incumbent hub is a different sale from a first-time implementation, and it is governed almost entirely by fear rather than by feature comparison. There are four fears, and they are all reasonable.
Years of merge decisions, survivorship rules, crosswalks and manual corrections represent real money and real institutional knowledge. That work is the asset — the platform around it is not. Two things protect it. First, your existing hub becomes just another source: its golden records and cross-references connect like any other relational system, so the decisions already made arrive as data you can read, compare against and carry forward. Second, MDM Studio is built to re-derive configuration rather than ask you to re-author it — canonical domain templates give you a starting model instead of a blank canvas, schema discovery reads your real sources, and advisors propose match, survivorship, quality and crosswalk configurations with a written rationale for a steward to accept or reject.
To be straight about the limit: there is no one-click importer that reads a competitor's proprietary rule format and reproduces it. Nobody has one that works. What there is, is a much faster path from your sources to an equivalent configuration, and a way to prove the result matches before you rely on it — which is the next fear.
Yes — briefly, and deliberately. This is the part most vendors gloss over, so it is worth being specific. MDM Studio includes a read-only twin of its own matching engine. It runs the full ingest, standardise and match pipeline over your sources and reports how those sources disagree — field by field, cluster by cluster, classified as agreement, agreement after normalisation, genuine conflict, or missing — without writing to any pipeline stage and without creating or touching a single golden record. Because it compares standardised values, “ZA” and “South Africa” read as agreement rather than as a false conflict.
Practically, that means you can point MDM Studio at exactly the sources your incumbent masters, and compare the two answers on your own data, before anything is cut over and before anyone commits. It is also the single most effective proof-of-value exercise we run, because it produces an agreement rate and a conflict list rather than an opinion.
You unmerge it, in one action, and it stays unmerged. The declined pair is suppressed on every subsequent run by both matching engines, the cluster splits, the affected golden record is marked and superseded, and every step is in the audit trail. Thresholds for automatic merge and for clerical review are yours to set, and a blocking analysis shows the candidate reduction before a run happens rather than after. The point is not that matching is perfect — it is that being wrong is recoverable by a steward in the product, which is what keeps the business using it.
A fair question to ask us, and the answer should be uncomfortable for any vendor who cannot give it. Your golden records sit in your own database, in your own schema, queryable with SQL and backed up by your existing process — no export request, no vendor in the path. The configuration exports to a portable versioned archive. Licences are signed keys, and if one lapses the product degrades to the free Community edition rather than denying you access to your own data. Metering informs; it never blocks a record from being mastered.
Very few MDM business cases fail on the year-one licence. They fail in year two and three, when the lines nobody modelled turn out to grow faster than the value does. Figures are in the companion briefing; what matters here is the behaviour of each line.
| Cost line | How it usually behaves | How it behaves here |
|---|---|---|
| Licence | Priced per domain, per module or per source, so every extension of scope is a new commercial negotiation — and the programme quietly stops extending. | One product, banded by the number of golden records you master. Domains, entities and attributes are unlimited on every paid edition. Modelling a second or a tenth domain costs nothing. |
| Growth | A meter that runs against you, with a mid-term true-up invoice when you cross a line you could not see. | A band is pre-paid capacity with headroom above it. Sustained growth beyond that moves you a band at renewal, pro-rated. Your live usage against your limit is a screen your administrator can open at any time. |
| Hub database | A proprietary store, or a mandated platform you must now license, staff and operate. | Free on PostgreSQL or MySQL. If you prefer SQL Server or Oracle, you are using licences you almost certainly already own. |
| Infrastructure & egress | Master data is shipped to a vendor cloud to be processed, and the volume that makes MDM valuable is the volume that makes egress expensive. | One VM to start, inside your perimeter, beside the databases it masters. Nothing is shipped to us, so there is nothing to charge egress on. |
| Training & certification | Per-seat, per-course, and the first line cut — after which nobody is qualified and adoption stalls. | Free at every tier, four certification tracks, verifiable credentials. Certify as many people as you like, including your partner’s team. |
| Implementation | The largest and least predictable line, and often a multiple of the licence. | Still the variable line — scoped by domain and source count, delivered by us or a certified partner. We do not pretend otherwise, and we do not publish a duration figure we cannot stand behind. |
| Exit | Not modelled at all, and discovered at renewal to be a second migration. | The data is already in your database. The configuration exports. A lapsed licence degrades rather than locks. Exit cost is a design property, not a concession. |
The pattern is deliberate: the lines that most often cause the second-year surprise — per-domain licensing, per-record metering, training, egress and exit — are the ones we removed or fixed. The one that remains genuinely variable is implementation effort, and that is the one we would rather size against your real sources in a working session than guess at in a document.
A business case built on things that turn out not to be true is worse than no business case, so here is what we are not going to tell you.
We publish no “reduced duplicates by X%” figures. Our deployment scenarios are illustrative composites, not audited results from a named installation, and presenting them as outcomes would be dishonest.
We publish no installation or go-live timeline, because the honest answer depends on your source estate rather than on our software.
MDM Studio holds no ISO 27001 or SOC 2 certification and no third-party penetration-test attestation, and we publish no uptime SLA. We will answer your security questionnaire in full and give your assessor an audit trail they can reconstruct events from.
We describe the platform as built for POPIA and GDPR obligations — not compliant or certified, because compliance is a property of your deployment and your processes, not of our software.
Established suites bring deeper capability breadth, more packaged industry models, large partner ecosystems and analyst coverage. If those are decisive for you, they should be.
Our partner bench, reference base and certified community are growing. We would rather say so than oversell it — and the free certification programme exists precisely to grow it faster.
Use these in a shortlist. They are chosen because each one maps to a failure mode in section 02, and because a vendor who cannot demonstrate the answer in a session is telling you something.
| Ask every vendor | Our answer |
|---|---|
| 1. Show me, in the product, who the named sponsor and owner of a domain are and what they can decide. | Per-domain stakeholder register with RACI, decision rights and engagement targets. |
| 2. Show me how the product decides which domain we should master first. | Criticality scoring and a value-versus-gap domain portfolio. |
| 3. Show me a steward’s actual daily queue, with ageing and ownership. | Task inbox and exception queues with severity, owner, ageing and SLA state. |
| 4. Show me why two records were judged to be the same person. | Per-rule scoring evidence retained on every merge. |
| 5. Undo that merge, in front of me, and show me the audit entry. | Governed unmerge in one action; the decision is sticky and audited. |
| 6. Master a domain without any write access to any source system. | Read-only is the default; write-back is opt-in per attribute. |
| 7. Give my DBA a script they can run themselves instead of taking credentials. | Generated idempotent SQL or a source-side stored procedure, with post-apply verification and rollback. |
| 8. Run against the same sources as our current MDM and show me where you disagree, without changing anything. | Read-only cross-source comparison that writes to no pipeline stage and creates no golden record. |
| 9. Show me my golden records without using your product. | They are tables in your own database on a platform you already run. |
| 10. Tell me what happens on the day we stop paying. | The product falls back to the free Community edition. Your data and your database are untouched. |
We would rather be measured against this list than against a feature matrix, because a feature matrix is where the last programme also looked fine.
We will stand up a hub on a single VM inside your perimeter, connect a sample of your own sources, and walk your data from first extract to golden record — live. If you already run an MDM platform, we will run the read-only comparison against the same sources and show you, on your records, where the two answers differ.
You will see the match evidence, the survivorship decisions, the audit trail and the exception queue on data you recognise, and you will leave with a defensible estimate for the full estate. That is a better basis for a business case than any number we could print here.
info@adaptivecanvas.co.za · adaptivecanvas.co.za · Partner enquiries: partners@adaptivecanvas.co.za