Data Catalogue, Business Glossary or Data Dictionary: Which Do You Need First?
A glossary settles what words mean. A dictionary describes what is in the data. A catalogue helps people find it. Which to build first depends on which of those problems is costing you most.
A business glossary records what the organisation’s terms mean. A data dictionary records how data is structured, field by field. A data catalogue is an inventory that lets people find data and judge whether it suits their purpose. They answer three different questions for three different audiences, and they are easily discussed as though they were one thing.
The confusion matters most when a purchase is on the table. A catalogue product is proposed as the answer to “our metadata problem”, and nobody has established which problem that is. What follows defines the three by the question each answers, shows how they fit together, and gives a way to decide where to start, including the cases in which buying a catalogue tool is premature.
Three artefacts, three questions
The UK Government Data Architecture Community published working definitions of these terms in 2020 that are useful because they were written to separate them. Its own notes list “confusion over definition and with related concepts” as the common misunderstanding for each one1.
A business glossary answers: what do we mean by this term? The community defines it as a repository of approved, governed and maintained business terms and their definitions, “the vocabulary of an organisation”, used to promote a consistent understanding of that vocabulary1. Its audience is everyone. Its entries are concepts such as “active customer”, “net revenue” or “delivered order”, written in plain language, each with a named steward.
A data dictionary answers: what exactly is in this dataset? The community defines it as a centralised repository “used to define and communicate the structure and content of data sets”, extending to the technical description of data: types, structure, default values, relationships and other attributes of each data element. Its own example is a user consulting the dictionary “if they wanted to know if ‘Customer ID’ is a character field or numerical field”1. Its audience is the people who build with data: engineers, analysts, developers. A dictionary can be large and authoritative in its own right. The NHS Data Model and Dictionary, for instance, is published as a reference point for information standards across the health service in England2.
A data catalogue answers: what data do we have, where is it, and can I use it? The community defines it as “an inventory of available data assets supported by a collection of metadata” that lets users search for data, see what is available and evaluate its suitability1. The W3C’s Data Catalog Vocabulary, the web standard for describing catalogues, defines a catalogue more tersely as “a curated collection of metadata about resources”3. Its audience is anyone looking for data they do not already know about.
The table sets the three side by side.
Glossary, dictionary and catalogue compared
| Business glossary | Data dictionary | Data catalogue | |
|---|---|---|---|
| Question answered | What does this term mean? | What is in this dataset, field by field? | What data exists, and can I use it? |
| Unit described | A business term | A field or data element | A dataset or other data asset |
| Main audience | Everyone, especially the business | Engineers, analysts, developers | Anyone searching for data |
| Produced by | Business owners and stewards | Largely generated from systems, then annotated | Harvested from systems, then curated by owners and stewards |
| Fails when | Nobody has authority to settle a definition | It is not regenerated as systems change | Nobody curates it, so entries are found and not trusted |
The first three rows follow the definitions cited above. The last two are our analysis.
How the three fit together
The three are layers, and they connect. A glossary term such as “active customer” is a concept. Somewhere in the systems there are fields that implement it, and the dictionary describes those fields. The catalogue lists the datasets that contain them and can link each dataset to the terms it uses and the fields it holds.
That is why the community’s definition adds that catalogues “should not exist in isolation” but should exchange metadata with other tools1, and why the UK government’s data ownership model expects stewards to maintain “a business glossary, in the data catalogue”4. In a mature arrangement the catalogue is where the glossary and the dictionary are found. That describes the end state, and an organisation does not have to start there.
The distinction between the layers survives even when one product holds all three. The business owns the meaning in the glossary. The structure in the dictionary is largely a fact about systems. The inventory in the catalogue depends on curation. Each of the three is produced by different people and decays at a different rate.
Which problem do you have?
The decision is made by diagnosis. Each artefact relieves a different pain. The useful question is which of them your organisation feels most sharply.
People argue about what a number means. Two reports show different figures for the same measure, and meetings begin by reconciling them. This is a problem of meaning. Start with a glossary, limited to the terms in dispute. The related discipline for measures specifically is covered in how to define KPIs and metrics that mean the same thing everywhere.
People cannot work out what a field contains. Analysts guess at column meanings, integrations break on unexpected values, and knowledge of a system lives in two people’s heads. This is a problem of structure. Start with a dictionary for the systems that matter most. It becomes urgent before a migration or when key staff are leaving.
People cannot find data, or do not know it exists. Teams rebuild datasets that already exist, nobody can say who owns a table, and requests for data go through personal contacts. This is a problem of discovery. Here a catalogue is the right answer, and its value grows with the number of datasets and the number of people looking.
A regulator or auditor asks what you hold. This is an inventory requirement with a deadline. A catalogue, or a register that does a catalogue’s job, is required, and the scope is set by the obligation. Sensitivity labels belong in the same record, which is one reason classification and cataloguing are worth planning together, as discussed in how to build a data classification scheme people will apply.
If you feel all four at once, do not start with all three artefacts. Choose a narrow set of data that matters and do all three for that set, which is the approach described in starting with critical data elements.
A sensible starting order
Where an organisation is early in governance and none of the four pains is urgent, we suggest the order below. It costs little at the start and exposes the real constraints soon. It is a default for that situation and not a rule.
- A glossary of the terms that are actually contested. Perhaps twenty to fifty terms, each with an owner who can settle the definition. It needs no software beyond a shared document, and it tests whether ownership works.
- A dictionary for the datasets behind those terms. Generate what you can from the systems and annotate the fields that implement the glossary terms. This connects meaning to data.
- A catalogue, when finding data has become the constraint. By then you have owners, definitions and descriptions to put in it.
The order reverses when discovery or a regulatory inventory is the pressing need. Then the catalogue comes first, kept deliberately thin: for each dataset a title, a description and an owner. The UK government’s guidance on recording critical data assets takes that position, noting that although “there are hundreds of attributes for describing data assets”, its central catalogue will collect only the core information needed for each listing5. A minimal record that is complete is more useful than a rich one that covers a tenth of the estate.
When buying a catalogue tool is premature
Catalogue software does one thing very well. It connects to systems and harvests technical metadata at a scale no team could manage by hand. That is valuable, and beyond a certain size it becomes hard to keep an inventory current any other way. It is also the part of the problem that was already tractable.
What the tool cannot supply is the part that makes a catalogue trusted: an owner for each dataset, a description a stranger can understand, an agreed meaning for the terms. In their framework for data governance, Khatri and Brown treat metadata as an area of decision, with questions such as how the semantics of data will be documented and how different types of metadata will be kept up to date6. Those decisions belong to the organisation and come before the product.
A purchase is premature when any of the following is true.
- There are no data owners. A catalogue’s first act is to show who owns each asset. With no owners it shows blanks. Settle ownership first, as set out in the governance model in what data governance is and what a working programme contains.
- Nobody has time to curate. Harvested metadata without descriptions is a list of table names. If stewards have not been given the time, the catalogue will fill up and still tell users little.
- The estate is small enough to hold in a spreadsheet. For a few dozen important datasets, a maintained register can do the job without the cost of a platform.
- The problem is meaning. If the pain is disputed definitions, a catalogue is an expensive way to host a glossary.
- There is no plan for upkeep. The UK guidance expects metadata for critical assets to be reviewed every twelve months and makes owners responsible for it5. A catalogue with no review cycle goes stale, and a stale catalogue can be worse than none because people act on it.
The purchase is timely when the opposite conditions hold: owners exist, the number of datasets and of people searching has outgrown manual methods, several systems need to be covered consistently, and there is a named team to run it. At that point the decision becomes which product to buy, and it should be made against requirements written beforehand. We have not assessed individual products, and this article does not recommend any.
What each costs to keep
Whether any of the three survives depends on upkeep. The amounts will differ in every organisation, and we offer no figures. What can be described is where the cost comes from in each case. This is our analysis of the mechanics. It is not a measured comparison.
A glossary costs little to store. Its cost lies in ownership and in semantic disagreement: each definition is a decision between competing interests, so changing one takes an owner with authority and a route for disputes.
A dictionary’s cost depends on how it is produced. Where it is generated from the systems and regenerated when they change, the continuing effort is limited to annotating what cannot be derived. Where it is typed and maintained by hand, every system change creates work, and the dictionary falls behind when that work is not done.
A catalogue has the widest set of costs: connecting to each system and harvesting its metadata, integrating with other tools, stewards’ time to describe and curate entries, and periodic review. Harvesting can be automated. Judging whether a description is right, and whether a dataset is fit for a given use, still needs someone who knows the data, so stewardship should be budgeted as a running cost. Where the catalogue also records lineage, it depends on the kind of work described in how to map data flows across systems.
Making the decision
Three questions frame the decision. Which of the four pains is costing the organisation most today? Are there owners who can make and maintain the content? What is the smallest version that would relieve the pain?
Then start with the answer to the third. In our judgement, a glossary of thirty terms that people use is worth more than a catalogue of thirty thousand tables that they do not trust.
For those who have reached the point of implementing a catalogue, the Metadata & Data Catalogue Implementation Guide sets out a vendor-neutral method, beginning with outcomes and a readiness check before any tool is chosen. Two reference Resources may also help. The Data Glossary gives plain-language definitions of common data and analytics terms. It is a reference for the field’s own vocabulary and does not replace your organisation’s business glossary. The Data Dictionary is a working structure for documenting datasets, fields and code sets.
Sources
- UK Government Data Architecture Community (GDAC). GDAC Business Glossaries Definitions 2020 (working definitions). April 2020.
- NHS England (NHS Data Model and Dictionary Service). About the NHS Data Model and Dictionary.
- World Wide Web Consortium (W3C). Data Catalog Vocabulary (DCAT) – Version 3. 22 August 2024.
- Government Digital Service (UK Government). Data ownership model (part of “Data ownership in government”). 16 April 2026.
- Government Digital Service (UK Government). Identifying and recording critical data assets. Updated 16 April 2026.
- Khatri, V. and Brown, C. V. Designing data governance. Communications of the ACM, 53(1), 148-152. 2010.
This article is general professional information. It does not assess or recommend any product.