Buying a data catalogue? Ask it which revenue number to use

“Which revenue number should I use?” is a demanding question for a data catalogue. Search may return a warehouse table, a sales dashboard, an exported spreadsheet and a finance report. Finding all four is useful. Helping an analyst choose between them is where the investment has to earn its place.

For the data platform lead selecting a catalogue, this makes the evaluation a test of a working relationship: can the product connect the person asking a question with the meaning, owner and access route they need? A technically extensive inventory can still leave the analyst sending the same messages to the same colleagues.

The strongest pilot starts with that problem. Choose a business process where confusion costs time or leads to disputed decisions, then let its users test the shortlist. A catalogue should reduce the work required to reach a defensible answer.

Follow the question beyond the search result

Consider a hypothetical analyst preparing a monthly trading pack. Sales records bookings when an order is accepted. Finance reports recognised revenue. A dashboard shows both but uses a short label that makes the distinction easy to miss.

The analyst’s task is to locate the approved source for the pack, explain why it is suitable and identify any limitation affecting the current period. A catalogue that ranks a table first has only started that task. The useful result needs to connect the table to the intended measure and show who can resolve an ambiguity.

Let users search in their own language. If success depends on knowing a database name that only the implementation team understands, the test has not demonstrated business discovery. Then ask the analyst to explain the selected result to someone else. This is a more revealing acceptance test than asking whether the interface looks intuitive.

Some disagreements will be outside the product’s power to settle. The distinction between bookings and recognised revenue requires an agreed business definition. That is the problem behind inconsistent business definitions: making competing answers easier to find does not decide which answer belongs in a particular decision.

Read the connector’s small print

Microsoft Purview illustrates why the word “supported” needs unpacking. Its Data Map source matrix distinguishes metadata, classification, policies, lineage and live-view capabilities. A source appearing in the matrix does not mean every capability is available for it.

That matters when a supplier demonstrates a beautifully connected lineage view. The buying question is whether the same path can be captured across your database, transformation process and reporting layer. Ask for that path, including the part implemented outside the supplier’s preferred ecosystem.

The limits can be quite specific. In Microsoft’s Power BI lineage documentation, column-level lineage and transformations are supported for Azure SQL Database as the source, with exceptions including Dataflows. The page also lists gaps involving dynamic M query parameters. These are scope details to test against a proposed deployment, not a verdict on Purview as a whole.

For a team trying to explain a disputed report, an asset-level connection and a traceable column transformation answer different questions. The first can show that a dashboard depends on a dataset. The second may help explain how a value was derived. Make the required level explicit before treating a lineage diagram as proof of coverage.

Where the path cannot be collected automatically, establish whether a manual relationship or another integration can fill the gap. Then price the maintenance. A workaround that is reasonable for ten important datasets may be impractical across thousands.

Run the pilot through an ordinary change

The first scan is the easiest moment to admire a catalogue. The more valuable test comes after something changes.

Rename a field in a permitted test source, replace a report or retire a dataset. Observe when the catalogue reflects the change and what happens to the previous metadata. Can a user distinguish a current source from a stale entry? Does the person responsible for a business definition discover that its technical reference has changed?

This is also where ownership becomes tangible. The UK government’s data ownership model separates accountable owners from stewardship work and gives owners responsibility for definitions and understanding how data is used. It is a public-sector model, but the division is a useful design reference for an enterprise pilot: naming a senior owner is different from arranging who maintains the entry next Tuesday.

Ask a steward to make a correction and an owner to approve a meaningful change. Their time belongs in the evaluation. If every update must pass through the platform team, the catalogue may create a central queue that grows faster than that team can service it.

A useful discovery still needs an access route

After choosing the right dataset, the analyst needs permission to use it. Test the full request with a user who does not already have access. Establish what is approved in the catalogue, what happens in the source system and how the user knows the request has succeeded.

Do not assume that a metadata permission also grants access to the underlying data. Equally, decide which metadata is appropriate for wider discovery. A restricted dataset may have a description, sample or business context that itself deserves limited visibility. The test should reflect the organisation’s intended boundary.

For the platform lead, the commercial question is how much of this journey arrives with the product and how much requires another workflow, integration or licence. A connector can reduce discovery work while leaving access fulfilment largely manual. That may still be worthwhile, provided the business case recognises the remaining work.

Choose a manageable first domain

A sensible purchase can begin with a limited scope. Cover the revenue reporting path, establish the definitions and ownership, and measure whether analysts complete the task with fewer interruptions. Use that experience to estimate the effort of extending to another domain.

The alternative, indexing the whole estate before anyone has a reason to return, risks paying for an expanding inventory with little evidence of use. Measure completed tasks, unresolved questions and maintenance effort alongside the number of assets collected.

Before committing, define the data quality rules for the pilot’s critical process. Those rules give users something concrete to judge when they find a dataset. The catalogue can then be evaluated as a route to usable data, with a realistic operating cost and a clear reason for analysts to come back.