Most data governance programmes I encounter have all five of these artefacts in some form. Few can explain how they relate, where one ends and another begins, or who is actually responsible for keeping them aligned.
A business glossary lives in a spreadsheet. An ontology exists as a half-finished modelling exercise. A data model sits in a modelling tool nobody has opened since go-live. The data dictionary is generated from database schemas, and the data catalogue was bought last year but mostly contains auto-scanned table names.
Each artefact exists. Yet together they do not necessarily form a foundation.
The problem is rarely the tools themselves. It is the lack of clarity about what each artefact is supposed to do, how they relate, and who has the authority to make decisions when they disagree.
There are three underlying concerns: meaning, relationships and implementation. The five artefacts provide different perspectives on those concerns. They are not five independent documentation exercises, nor are they simply five steps in a linear process.
The glossary: agreeing on meaning
The business glossary is where an organisation establishes a shared vocabulary. It defines the terms people use when they talk about the business, explains what those terms mean and identifies who is accountable for the definitions.
Take the term Customer.
The term can be used in different ways. In one process, Customer may refer to the Person or Organisation buying from us. In another, people may use the same word when they really mean a customer account, a contractual relationship or a particular customer status. These are not interchangeable concepts. The glossary should make the intended meaning explicit for each business context, and use more precise terms such as Customer Account or Customer Relationship where that is what the process actually means.
The answer depends on the business context. A sales process, a credit process and a service process may legitimately need different customer concepts or perspectives. That does not mean the underlying concepts should be blurred together. The differences should be explicit, with clear definitions and relationships between them, rather than hidden behind one supposedly universal definition.
A glossary is not a technical dictionary. It should be understandable to the people who operate the business. Its value comes from agreement, ownership and consistent use, not from the number of terms recorded.
And ownership matters. Someone must have the authority to decide what a term means, resolve conflicting interpretations and approve changes. A definition without an accountable business owner is simply a suggestion.
The ontology: describing how concepts relate
Knowing what the business means by Customer is a good start, but it rarely tells us enough.
In the real world, a customer does not exist in isolation. Customers place orders, orders contain products, people and organisations can act on behalf of customers, and contracts establish relationships between parties.
These relationships are part of how the business actually works.
This is where an ontology becomes useful. It describes the concepts in a domain, their meaning and the relationships between them. It gives us a connected representation of business knowledge rather than a list of isolated definitions.
For example, an ontology might express that:
- A Person or an Organisation can fulfil the business role of Customer.
- A Customer places an Order.
- An Order contains one or more Order Lines.
- An Order Line refers to a Product.
- A Customer may have one or more Accounts, depending on the business context.
- A Contract establishes an agreement or relationship between parties, which may include a Customer.
The important point is not the notation or modelling language. It is the ability to express what the organisation understands about its business, including the relationships and constraints that give individual concepts their context.
But isn’t that what a conceptual data model does?
This is an interesting question, and it is one of the areas where the terminology can become confusing.
An ontology and a conceptual data model can look remarkably similar. Both may contain concepts, relationships and cardinalities. Both can describe a business domain without referring to database tables or physical implementation.
The distinction is primarily one of purpose.
A conceptual data model is generally a structured view of the important business concepts and their relationships, created for a particular modelling or design purpose. It helps architects and business stakeholders agree what information matters, how concepts relate, and sometimes the business rules and constraints that apply. It is not merely a picture of entities; it can express meaning too.
An ontology places particular emphasis on making that meaning explicit and reusable. It formalises what concepts represent, how they relate, how they are classified, and what those relationships and constraints mean. This can support consistent interpretation across domains and systems, and may enable semantic reasoning. The distinction is therefore about emphasis and intended use, not a claim that conceptual models cannot capture semantics.
Consider the difference:
A conceptual model might show that Customer places Order.
An ontology can describe what qualifies as a Customer, whether a Person or Organisation can fulfil that role, what it means to place an Order, and how the relationship should be interpreted across different business contexts.
There is no absolute dividing line. A rich conceptual model can contain much of the same information as an ontology, and some organisations quite reasonably use one model to serve both purposes.
The important question is not whether an organisation owns two separate modelling tools. It is whether it has captured both the structure of its information and the meaning of its business concepts.
This distinction becomes particularly important when connecting information across domains, building knowledge graphs or making enterprise data useful to AI. Retrieval alone is not understanding. Systems need context: what things represent, how they relate, and which relationships are meaningful in a particular business situation.
The data model: turning concepts into structure
The data model translates business understanding into a structured representation. It defines entities, attributes, relationships and, where appropriate, constraints. It is where we decide how concepts are represented for a particular purpose.
There are different levels of modelling:
- Conceptual models communicate the important business concepts and their relationships.
- Logical models describe the information structure independently of a specific technology.
- Physical models describe how that structure is implemented in a particular platform.
These models serve different purposes, and they should not be confused with the business vocabulary or the semantic foundation behind them.
A logical data model might represent Customer and Order as separate entities, with a one-to-many relationship between them. It may define customer identifiers, order dates and status attributes, together with rules about cardinality and optionality.
The model should be informed by business meaning, but it does not replace the glossary or ontology. A perfectly normalised model can still represent the wrong business concept. Technical consistency is not the same as semantic correctness.
There is also an ownership question here. Who maintains the model? The business should be accountable for the meaning and business rules. Architecture and data modelling functions should be accountable for the integrity and design of the representation. Those responsibilities need to work together, but they are not interchangeable.
The canonical model: where meaning becomes shared structure
The canonical model deserves a closer look because it is the point where the semantic artefacts meet the technical ones. The glossary tells us what business terms mean. The ontology describes the concepts and how they relate. The canonical model turns that understanding into a shared, implementable structure that systems can map to and consumers can rely on.
I would not treat the canonical model as a sixth artefact alongside the five discussed here. It is better understood as a particular role played by the logical data model: a system-neutral representation of the business information that sits between source-specific structures and the models required by individual consumers. It is not owned by one source application, nor designed around the needs of a single downstream solution.
That distinction matters. A source system may call something Customer, Account or Sold-to. The glossary helps establish whether those terms describe the same business concept or different roles. The ontology provides the wider context: perhaps a Person or Organisation can play the role of Customer, Supplier or Partner. The canonical model then defines the agreed structure for representing that party and its roles in a consistent way.
In other words, the canonical model is not simply a common set of column names. It is a governed logical contract. It defines the entities, attributes, identifiers, relationships and constraints that participating systems agree to exchange or consume. It should contain the genuinely shared information, while allowing domain extensions where a source or consumer has legitimate requirements that do not belong in the common core.
This is also why I favour canonical models scoped to meaningful domains, such as Product, Customer or Supplier, rather than one enormous enterprise model. A model that tries to represent everything often becomes either a lowest-common-denominator structure or a union of every system’s fields. Neither is useful. The shared core should be deliberately small, meaningful and stable, with controlled extension points for what is specific.
How the five artefacts connect through the canonical model
The glossary and ontology inform the canonical model, but they do not dictate every implementation detail. A canonical entity should be traceable to the terms and concepts it represents. An ontology may describe a rich set of relationships, classifications and constraints; the canonical model captures the subset that needs to be made explicit and operational in shared data structures. Taxonomies and agreed code lists can become canonical reference data where consistent classification is required across systems.
The data dictionary makes the canonical model executable. It records how source columns map to canonical attributes, including data types, formats, nullability and transformations. It also documents the physical implementation: for example, which Fabric lakehouse tables or published data products realise the canonical entities. The mapping is important. A source field called KUNNR and another called CustomerNumber may both map to a canonical Party identifier, but only after their meaning and rules have been checked.
The catalogue then exposes these relationships. It should connect glossary terms to canonical entities and attributes, record source-to-canonical-to-consumer lineage, and make ownership, classification and quality status discoverable. In Microsoft Purview, for example, business terms can be associated with data assets and columns, while scanned metadata and lineage help connect the technical implementation. The catalogue makes the chain visible; it does not decide the meaning or resolve ownership disputes on its own.
The complete traceability chain should be possible to follow:
- Glossary term: the agreed business meaning and accountable owner.
- Ontology concept: the wider context, relationships, classifications and constraints.
- Canonical entity or attribute: the shared logical structure that represents the concept.
- Mapped source columns: the fields and transformations that provide the data.
- Published data assets: the structures consumers use, with lineage back to the canonical definition.
If one of these links is missing, the weakness becomes visible. A glossary definition may never reach an actual field. A canonical attribute may have no accountable source mapping. A physical table may be called canonical without following the agreed model. Or a consumer may use a local interpretation that cannot be traced back to the shared definition.
For master data, this connection is especially important. The canonical model provides the structure within which an MDM capability can create and maintain a trusted record: identifiers, match attributes, relationships, survivorship rules and the roles an entity can play. The model does not perform matching or establish trust by itself. Those responsibilities belong to the MDM processes and governance that operate against it.
I have written about canonical models from several angles over time. Canonical Model introduces the idea of a shared, source-agnostic structure for a data domain. Turning the Outside-In View into a Common Language applies it to legal entities, identifiers and corporate hierarchies. When Data Changes, So Does the Business takes the next step, exploring how canonical changes can become events that trigger action. And in Adding Ontologies and Taxonomies: A Foundation for AI, I look at how canonical structure, ontology and classification combine to provide context for AI. More recently, Data Architecture Patterns: Decisions for the AI Era places canonical models and ontologies in the wider architecture of semantic contracts and AI consumption.
The important point is that the canonical model is the joining structure, not another disconnected document. It gives the meaning captured in the glossary and ontology a shared form, while the dictionary and catalogue connect that form to real systems, data and consumers. That is how the five artefacts become one working foundation.
The data dictionary: documenting the implementation
The data dictionary describes the technical reality. It records the structures that exist in databases, applications and other systems: tables, columns, data types, keys, constraints, formats and often source information.
For example, it might tell us that dbo.Customer contains a column called CustomerID, that the column is an integer, and that the data originates in a core banking system. It can also tell us where the field is used and how it is transformed.
But one relationship makes the dictionary much more valuable: the link back to the business meaning.
Which glossary term does CustomerID implement? Which model element does it realise? Is it the identifier of a legal entity, an account, or a customer relationship?
Without those links, a dictionary is largely technical documentation. Equally, a glossary with no connection to the structures that implement its terms risks becoming a vocabulary list with little operational relevance.
The dictionary also provides an important source of feedback. It shows what has actually been implemented, not just what a design document says should exist. A difference between the physical implementation and the logical model is not automatically a defect. It may be an intentional, documented design choice driven by platform constraints, performance, legacy integration or other technical needs. The dictionary should make that difference visible and traceable. The important questions are whether the deviation is understood and documented, whether it preserves the agreed business meaning, and whether it has been approved by the appropriate architecture and business owners. Accidental divergence, or an implementation that changes the meaning of the data, needs to be addressed.
The technical team is responsible for maintaining accurate implementation metadata. The relevant business and architecture owners must be involved when the implementation no longer reflects the agreed meaning or design.
The data catalogue: connecting and exposing the picture
The catalogue is often described as a place to search for data. That description is too narrow.
A useful data catalogue connects business meaning with technical metadata. It should allow someone to move from a business term to its definitions, related concepts, data models, physical assets, lineage, ownership, governance requirements and quality information.
Imagine searching for Customer.
A useful result should not simply return twenty-seven tables containing a column with the word Customer in its name. It should help explain which customer concept is represented, where the data originates, which processes use it, who is accountable for it, how it is transformed and whether it is trusted for the intended purpose.
That is a very different proposition from a searchable inventory of technical assets.
The catalogue is therefore an integration and navigation layer across the five artefacts. It brings their relationships into view and makes them accessible to the people who need them.
But the catalogue does not become the authority simply because it displays the information.
It cannot create genuine business agreement by scanning databases. It cannot reliably determine business ownership from technical metadata. Nor should it silently resolve conflicting definitions or decide which implementation is correct.
Those decisions belong to the accountable business and architecture roles. The catalogue should expose the decisions, their owners and the evidence behind them.
A catalogue can make a poor foundation easier to search. It cannot turn it into a good one.
How the five fit together
The five artefacts have different responsibilities, but they should describe the same business reality.
| Artefact | Primary responsibility |
|---|---|
| Glossary | What does the business term mean, in which context, and who owns the definition? |
| Ontology | What are the concepts, and how are they semantically related? |
| Data model | How should the information be structured for a particular purpose? |
| Data dictionary | Where and how is that structure implemented in actual systems? |
| Data catalogue | How can people discover, navigate and understand the assets and their relationships? |
It is tempting to describe this as a sequence: establish meaning, connect concepts, design the structure, document the implementation and make everything discoverable.
That sequence is useful when starting the work, but it is not how the architecture behaves over time.
The relationships are bidirectional.
A data quality problem may reveal that a business definition is ambiguous. A system implementation may expose a missing relationship in the model. A change to a business process may introduce a new concept or make an existing distinction important. A new regulatory requirement may change the meaning or ownership of an attribute.
These observations must be able to travel back through the architecture.
The foundation is therefore not a one-way pipeline from business definition to physical database. It is a connected set of artefacts that continuously inform and challenge one another. Bidirectional does not mean that every artefact has equal authority to change every other artefact. It means that evidence and feedback can travel in both directions, while decisions remain with the accountable owners.
Ownership is what keeps the foundation coherent
Relationships between artefacts do not maintain themselves. Someone must be accountable for the decisions behind them.
- Business authority: Decides what business concepts mean, in which contexts they apply, and which business rules are authoritative.
- Architecture and modelling authority: Maintains the conceptual and logical integrity of the models and ensures that the representations are consistent with the agreed business meaning.
- Implementation responsibility: Maintains accurate technical structures and metadata, and raises deviations between implementation and design.
These responsibilities may sit in different teams, but the decision rights must be clear.
When a physical implementation conflicts with a business definition, the database developer should not quietly redefine the business concept. Equally, a business owner should not dictate a physical implementation without considering architectural consequences.
The disagreement needs to be visible, assigned to the right decision-makers and resolved with traceability.
This is where the catalogue can help. It can expose ownership, relationships, lineage, status and unresolved issues. It should make accountability easier to exercise, not replace accountability.
A simple test: follow the term Customer
There is a practical way to find out whether these artefacts form a coherent foundation in your organisation. Pick one important business term. Customer is usually a good candidate.
- Can you find an agreed definition of Customer in the glossary, including its owner and business context?
- Can you see how Customer relates to Person, Organisation, Account, Contract or other relevant concepts in the ontology?
- Can you trace the concept into the conceptual and logical data models and understand how it is represented?
- Can you identify the actual tables, fields and source systems in the data dictionary?
- Can a business or technical user find the information in the catalogue and follow its lineage to a report, product or process where it is used?
- If the implementation does not match the agreed meaning, can you identify who has the authority to resolve the difference?
There is another useful test: what happens when the business changes its definition of Customer? Can the organisation identify the affected models, systems, data assets and processes?
If the answer is yes, you have more than five artefacts. You have a connected foundation with traceability and accountability.
If not, you probably have five separate tools, each telling a different part of the story.
Build the relationships before buying another tool
The temptation is to start with the catalogue. It is visible, easy to demonstrate and often comes with an attractive promise of automated discovery and governance.
But buying a platform before agreeing on the meaning and responsibilities of the information is one of the most common reasons catalogue initiatives disappoint.
Start smaller.
Choose a business process that matters. Identify the terms and concepts it depends on. Agree on their meaning and ownership. Connect those concepts to the models and systems that support the process. Make the relationships and responsibilities explicit. Then expose the result through the catalogue.
And keep the feedback loop open. Implementation findings, process changes and data quality issues should be able to challenge the existing definitions and models.
The result is not just better documentation. It is a shared vocabulary, more reliable data, faster integration, clearer accountability and a stronger basis for compliance.
It also gives AI something far more useful than a collection of scanned table names: business context that can be understood, connected and governed.
Ultimately, the goal is not to maintain five artefacts. It is to give the organisation a coherent, connected understanding of the information it depends on, including legitimate differences in meaning between business contexts, and a clear way to keep that understanding aligned with the business as it changes.
Leave a Reply