Unified Catalog Turning a Data Map Into Owned Data Products at a 6,800-employee Bank
Three years of scanning had produced 410,000 catalogued assets and almost no adoption, because a technical inventory answers questions nobody in the business was asking. We rebuilt governance around domains, data products and named stewards, and cut time to find a trusted dataset to from days to under an hour.
About the Client
The Challenge
The bank had adopted Purview early and used it as a scanner. Registered sources, scan rule sets, classification rules, a schedule — and after three years, 410,000 assets in the Data Map across 64 sources. Technically complete, practically unused. The monthly active user count was lower than the number of people who attended the launch briefing.
The reason is structural. A Data Map describes tables, columns, files and their classifications. The questions the business asks are different in kind: which dataset is the one I should use for regulatory capital reporting, who decided that, is it fit for purpose, and who do I ask when it looks wrong. A technical inventory with no owner attached cannot answer any of them, so analysts kept doing what they had always done and asked a colleague.
Regulatory pressure removed the option of leaving it there. Risk data aggregation expectations require the bank to demonstrate lineage and ownership for the data behind risk reporting, and the model risk function needed the same evidence for model inputs. Producing that evidence took weeks of manual work each cycle, assembled by hand from pipeline documentation and the memory of a small number of long-serving engineers.
Meanwhile the glossary had become a graveyard. Several hundred terms loaded in a single import, none linked to actual assets, many contradicting each other across divisions, and nobody with the authority to settle a definition. Two business units used different meanings of exposure at default in reports consolidated upward without reconciliation.
Our Approach
The new Unified Catalog inverts the old model. Instead of starting from what the scanners found, you start from who is accountable for what, and attach the technical assets underneath. That inversion is the whole project.
Governance Domains and Accountability (Weeks 1-5)
Defined governance domains before touching any metadata. Domains were drawn along the lines the bank already manages itself — retail lending, commercial banking, treasury, risk and finance, and a regulatory reporting domain that cuts across them. Each domain got a named owner with the standing to make decisions, not a committee. The old collection hierarchy from the classic catalog did not map cleanly onto domains and we did not force it; collections had been organised by source system, and domains are organised by business accountability.
Data Products People Can Actually Consume (Weeks 4-10)
A data product bundles the assets that serve a business purpose — tables, files, reports — with a description, terms of use, an owner and a documented request-access path. We published 31 of them, starting with the datasets behind regulatory reporting because those had the clearest consumers. The discipline that made the difference was refusing to publish a data product without an owner who had agreed to be its owner. An unowned data product is a catalog entry, and the bank already had a hundred thousand of those.
Glossary, Critical Data Elements and Lineage (Weeks 8-15)
Rebuilt the glossary as governed terms inside domains with an explicit acceptance workflow, and deleted the terms nobody would claim. Defined 180 critical data elements — the fields that regulatory and risk reporting actually depend on — and mapped each one to its physical columns across source systems, which is where the exposure at default disagreement finally got settled. Lineage was captured automatically from Fabric and Data Factory pipelines and from Power BI, and the gaps were documented rather than papered over with manual lineage nobody would maintain.
Health Controls and the Steward Operating Model (Weeks 12-18)
Turned on catalog health controls — twelve measures grouped under access and use, discoverability, estate curation, value creation, trusted data and metadata quality management, each scored as a current percentage against a target the bank sets. They are concrete enough to argue with, which is the point: the data product useability control counts a product only when its description runs past 100 characters, its parent domain description does too, and its glossary terms past 25. Health actions fall out of the scores as tasks with a name attached, which converts governance from an annual audit into a work queue. 24 stewards were appointed across the domains with time formally allocated, and the health score became a standing item in the governance forum.
Data Quality Rules and Scan Cost Control (Weeks 16-22)
Applied data quality rules and profiling to the data products behind regulatory reporting so that quality is expressed as a score on the product a consumer sees rather than a report in a separate tool. In parallel we reviewed scan scope and frequency: full scans of everything on a nightly schedule consume capacity for no benefit, and moving to incremental scans on a tiered schedule cut consumption materially. The data quality rules and the Fabric pipelines share the same critical data element definitions.
Solution Architecture
Governance domains: Business-aligned domains with a single named owner each, replacing a collection hierarchy that had been organised by source system
Data products: Curated bundles of assets with description, terms of use, owner and a request-access path, published only where an owner has accepted accountability
Business semantics: Governed glossary terms with an acceptance workflow, critical data elements mapped to physical columns across core banking, ADLS, Snowflake and Fabric
Lineage and quality: Automatic lineage from Fabric and Data Factory pipelines and Power BI, with data quality rules scored at data product level on the Azure data platform
Operating model: Twelve health controls generating assigned actions, stewards with allocated time, and tiered incremental scanning to keep Data Map consumption predictable
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
A complete Data Map is not governance. Scanning tells you what exists. It does not tell you what to trust, who decided, or who to ask. Those are ownership questions, and the Unified Catalog is built around them in a way the classic catalog never was.
Do not migrate collections into domains one for one. Collections were usually organised by source system or by who ran the scan. Domains are organised by business accountability. They are different shapes, and forcing the old structure into the new one reproduces the problem you are trying to escape.
No owner, no data product. The single rule that changed adoption. An entry with an owner who has accepted the role is something a consumer can act on. An entry without one is inventory, and the estate was already full of inventory.
Critical data elements are where glossary work finally bites. Abstract term definitions get ignored. Mapping a named field that regulatory reporting depends on to its physical columns in every system forces the disagreements into the open and gets them settled.
Health controls turn governance into a work queue. Twelve controls scored against a target, with thresholds you set, generate specific actions with specific names attached. That is a different thing from an annual maturity assessment nobody acts on.
Is Your Catalog an Inventory or a Governance Programme?
Scanning everything and owning nothing is the most common outcome of a Purview deployment. We rebuild governance around domains, data products and stewards who have actually agreed to the job.