DATA GOVERNANCE & MASTER DATA MANAGEMENT
Trusted, owned and explainable enterprise data.
People cannot confidently find, trust, own or control the data they depend on. We build the governance operating model and the mastered entities underneath it, so a number can be explained, a customer means one thing, and an auditor's follow-up question is a lookup rather than an investigation.
Uncertain → Trusted
Does this sound familiar?
If several of these are already true, this is the right conversation. If none of them are, it probably is not.
- The same customer, product or supplier exists several times, and no system is authoritative.
- Two teams report the same measure differently and neither definition is written down.
- You can produce a regulatory figure on time but cannot always demonstrate how it was derived.
- Data ownership is described as 'everyone' or sits with a committee that meets quarterly.
- Data quality is discussed after an incident rather than monitored before one.
- AI use cases are being approved with no view of what data they may lawfully use.
What it costs you
- Critical entities are duplicated and definitions are undocumented
- Every trust question becomes a manual investigation by senior people
- Reporting, regulatory response and remediation all slow down
- Decisions and controls rest on figures nobody can fully explain
- AI and automation scale those defects faster than anyone can review them
A report that is correct but unexplainable is a finding waiting to happen. The exposure is rarely the arithmetic — it is the inability to answer a follow-up about provenance without pulling senior people off other work for days.
What materially changes
| Today | With PaWa |
|---|---|
| Ownership described as 'everyone' | One accountable owner per domain and per critical term |
| Definitions in people's heads | A glossary with owners, tied to the reports that use it |
| Duplicate customers, products and suppliers | Mastered entities with survivorship rules agreed per attribute |
| Quality discussed after incidents | Rules attached to definitions, monitored, with a named owner on breach |
| Lineage reconstructed by hand | Automated lineage from report to source |
| AI approved without data controls | Use-case intake, risk tiering and permitted-use rules before build |
Today
Ownership described as 'everyone'
With PaWa
One accountable owner per domain and per critical term
Today
Definitions in people's heads
With PaWa
A glossary with owners, tied to the reports that use it
Today
Duplicate customers, products and suppliers
With PaWa
Mastered entities with survivorship rules agreed per attribute
Today
Quality discussed after incidents
With PaWa
Rules attached to definitions, monitored, with a named owner on breach
Today
Lineage reconstructed by hand
With PaWa
Automated lineage from report to source
Today
AI approved without data controls
With PaWa
Use-case intake, risk tiering and permitted-use rules before build
How we solve it
Mechanisms, not adjectives. Each of these is something we build, document and hand over.
Governance strategy and operating model
Decision rights, accountability, domain ownership and stewardship — sized to your organisation. A governance council that meets quarterly and owns nothing is worse than no council, because it looks like coverage.
Data quality
Critical data elements identified first, then rules, profiling, monitoring, issue management and remediation. Quality rules attach to the business definitions they protect, so a breach names an owner rather than a table.
Data observability
Freshness, volume, schema drift, lineage and anomaly monitoring, with incident detection and operational accountability. Observability sits under governance here, not as a separate product pillar.
Metadata, catalog and business glossary
Discoverability, definitions, ownership and context. One accountable owner per term rather than a committee, because shared ownership of a definition is how two teams end up with two numbers.
Data lineage
Technical and business lineage supporting trust, change-impact analysis and auditability. The derivation path for a reported figure becomes navigable rather than reconstructed.
Master and reference data
Authoritative entities for customer, product, supplier, organisation and location: matching, merge and unmerge, survivorship, hierarchies, reference domains and controlled change. Detailed below.
Policy, privacy, security and access governance
Classification, retention, access control and the evidence trail that shows the controls were actually applied, not merely documented.
AI governance
Use-case intake and approval, risk tiering, data provenance and permitted use, model and agent documentation, human-in-the-loop boundaries, evaluation gates, drift monitoring and audit evidence from experiment to retirement. This page owns the framework; the AI Readiness page applies it.
Reference architecture: the mastered data lifecycle
Source systems feed data quality, where records are profiled and validated before any attempt to match them. Matching, linking and merging produce a golden record for each entity, with survivorship rules agreed per attribute rather than per system. Stewardship and governance sit on top: the scored middle band of ambiguous matches goes to a person, not a threshold. Mastered entities are then distributed through APIs, events and batch to operations, analytics and AI. Metadata, lineage, observability, security and policy span the whole lifecycle, which is why they are drawn across it rather than placed at one stage.
1Source systems
- CRM
- ERP
- Billing
- Supplier systems
- External reference
2Data quality
- Profiling
- Validation rules
- Standardisation
- Issue management
3Match, link, merge
- Deterministic rules
- Probabilistic scoring
- Merge and unmerge
4Golden record
- Survivorship per attribute
- Hierarchies and relationships
- Reference domains
5Stewardship & governance
- Steward queue
- Exception workflow
- Approvals
- Policy and access
6Distribution
- APIs
- Events
- Batch and CDC
- Syndication
7Consumers
- Operations
- Analytics
- AI and agents
Across the whole flow
Metadata and catalog · Lineage · Observability · Security and access · Policy and AI governance
What you receive
Written artifacts you keep and can act on with any firm, including without us.
- Governance operating model: decision rights, domain ownership and stewardship roles, with names in them
- Critical data element inventory and the quality rules that protect each one
- Business glossary with one accountable owner per term, linked to the reports that consume it
- Match and survivorship design per mastered domain, tested against cases your team already knows
- Golden record model, hierarchies and reference data domains
- Stewardship workflows for the ambiguous middle band, including merge and unmerge
- Automated lineage from reporting layer through transformation to source
- AI governance framework: use-case intake, risk tiering, permitted-use rules and evaluation gates
- Policy, classification, retention and access controls with the evidence trail
- MDM architecture decision: registry, consolidation, coexistence or centralised, with the reasoning
How an engagement runs
- 1
Discover
Identify the critical data elements and the domains that actually carry risk. Most estates have hundreds of candidates and perhaps a dozen that matter.
- 2
Design
Agree ownership, definitions, survivorship and the MDM architecture style. Where two areas disagree on a definition, that disagreement is surfaced and resolved rather than averaged.
- 3
Deliver
Build quality rules, matching, golden records, stewardship workflows and lineage. Match rules are tuned against known cases your team can judge.
- 4
Enable
Hand over the operating model and the stewardship practice. Governance that depends on us being there is not governance.
Relevant experience
Each item below is labelled with what kind of evidence it is. Nothing here claims a client outcome we cannot support.
Entity resolution for financial crime investigations
A Tier 1 North American bank whose retail, commercial and wealth lines each held their own version of a customer. Deterministic rules covered identifier matches, probabilistic scoring covered the rest, and the scored middle band went to a stewardship queue so an ambiguous match reached a person rather than a threshold. Lineage was retained from the mastered record back to every contributing source, so a match could be explained rather than asserted.
Delivered by our principal in a previous role, before PaWa Data Solutions.
Making regulatory figures explainable
A Canadian financial institution producing regulatory numbers on time but unable to demonstrate derivation. Each reported measure was traced back through its transformations to source, and the owning business definition captured with a named owner. Where two areas disagreed on a definition, the disagreement was surfaced and resolved during the work rather than during a review.
Delivered by our principal in a previous role, before PaWa Data Solutions.
Representative pattern: MDM modernisation
An organisation running a registry-style MDM that no longer fits: downstream systems need attributes the registry does not hold, and stewards work in a tool nobody trained them on. The work assesses whether the architecture style is wrong or the implementation is, because replatforming an implementation problem is expensive and does not fix it.
What the engagement leaves behind: a target MDM style with the reasoning, a migration path for mastered domains, and stewardship workflows people will actually use.
Representative engagement — a realistic pattern used to explain our approach, not a client result.
Technology experience
MDM and data quality
- Informatica MDM
- Informatica Data Quality
- Reltio
- Semarchy
- Profisee
Governance and catalog
- Collibra
- Informatica Axon
- Alation
- Microsoft Purview
- OpenMetadata
Lineage and observability
- OpenLineage
- Monte Carlo
- Great Expectations
- dbt tests
Platforms
- Snowflake
- Databricks
- Azure
- AWS
- Google Cloud
Platforms and tools we have worked with directly. This is experience, not a partnership claim: PaWa Data Solutions holds no reseller agreement or partner status with any vendor listed here, which is what keeps the recommendation neutral.
Papa S. Nguer
VP of Technical Sales & Engineering, PaWa Data Solutions
Governance and MDM work is led by our principal, whose depth sits where financial services meets data: KYC and AML, entity resolution, MDM, governance, lineage and the regulatory reporting that has to survive an audit. Fifteen years at Informatica, and more than 300 customer-facing engagements with Tier 1 institutions.
Full profileQuestions buyers actually ask
Do we need to buy an MDM platform?
Not necessarily, and not first. The architecture style — registry, consolidation, coexistence or centralised — should be decided by what downstream systems need, and several organisations get a long way with the platform they already own. A platform bought before the survivorship rules are agreed usually just relocates the argument.
What is the difference between data governance and MDM?
Governance sets ownership, definitions, policy and control. MDM produces the authoritative entities those definitions describe. They fail separately: governance without mastered data is a document, and MDM without governance is a matching engine nobody trusts. We treat them as one practice for that reason.
Where do data quality and observability sit?
Under this practice, even though the controls are implemented inside pipelines and platforms. Quality rules attach to the business definitions they protect, so a breach names an owner rather than a table, and that ownership is a governance question rather than an engineering one.
How long before we see anything?
The Governance QuickStart runs in weeks, not quarters, and is deliberately narrow: critical data elements for one or two domains, the ownership model, and the first quality rules in monitoring. A governance programme that produces its first artifact in month six has usually lost the room by month four.
Who does the stewardship afterwards?
Your people. Stewardship workflows are designed around roles you actually have, and the exception queue is sized so it can be worked. A design that assumes three full-time stewards you have not hired is a design that quietly stops.
How does AI governance relate to this?
This page owns the framework: use-case intake, risk tiering, permitted-use rules, model and agent documentation, human-in-the-loop boundaries, evaluation gates and audit evidence. The AI Readiness page explains how those controls get applied to specific use cases, data access, models and agents.
Can you work with our existing governance team?
Yes, and often the work is helping an existing team get traction rather than replacing it. Most governance programmes stall on decision rights rather than on tooling, and that is a different conversation from a platform selection.
Governance QuickStart
A focused engagement for organisations that need governance to produce something visible quickly. Critical data elements for one or two domains, an ownership model with names in it, the first quality rules in monitoring, and a defensible sequence for what comes next.
Scope and commercial terms are agreed in writing before the engagement starts.