Unified Catalog - Why I Think About Governance Domains Vertically and “Domains of Data” Horizontally

One of the more useful ways I have found to think about Microsoft Purview is to separate ownership from meaning.

For me, that creates two different but connected structures:

Vertical = Ownership

Governance Domains tell us WHO owns and governs the data.

They provide the organisational structure for accountability.

A Governance Domain can contain:

Data Products → Data Assets → Critical Data Elements → Columns and Attributes

It also gives us the governance context around those objects:

• Ownership
• Stewardship
• Accountability
• Governance responsibilities
• Data quality
• Access
• Controls

So when I look at a Governance Domain, I am really asking:

Who is responsible for this data?

That is the vertical view.

Horizontal = Meaning

Enterprise Glossary Terms give us a different perspective.

Rather than focusing on who owns the data, they can represent what the data means across the organisation.

This is what I think of as a “Domain of Data”.

I use the phrase “Domain of Data” as a conceptual way of describing an enterprise business concept that can span multiple Governance Domains.

Take Personally Identifiable Information (PII) as a simple example.

PII is unlikely to fit neatly within a single Governance Domain.

It may exist across:

• Customer information
• Complaints and incidents
• HR and work force data
• Case management
• Regulatory data
• Operational systems
• Contact information
• Financial and administrative processes

Each Governance Domain may own and govern the PII within its own area.

But the concept of PII itself spans all of them.

That is where an Enterprise Glossary Term becomes particularly useful.

It provides a common enterprise definition that cuts horizontally across multiple ownership boundaries.

Why the two structures should not be the same

It can be tempting to make the Enterprise Glossary hierarchy simply mirror the Governance Domain hierarchy.

I think that misses an important opportunity.

They answer different questions.

Governance Domains

WHO owns and governs the data?

They represent:

• Ownership
• Accountability
• Organisational responsibility

Enterprise Glossary Terms

WHAT does the data represent?

They represent:

• Business meaning
• Shared concepts
• Enterprise vocabulary

The two structures should connect, but they should not simply duplicate each other.

One Governance Domain can contain many Domains of Data

A Governance Domain may contain many different business concepts.

For example, one Governance Domain might contain:

• PII
• Customer Data
• Location Data
• Financial Data
• Operational Data

The Governance Domain is therefore not necessarily a “type of data”.

It is primarily an ownership and governance boundary.

One Domain of Data can cross many Governance Domains

The reverse is equally important.

A single Domain of Data can exist across many Governance Domains.

For example, PII might appear in:

• Governance Domain 01 – Customer and contact data
• Governance Domain 02 – Complaints and incident data
• Governance Domain 03 – Employee and work force data
• Governance Domain 04 – Regulatory and operational data

This gives us a many-to-many relationship:

One Governance Domain can contain many Domains of Data.
One Domain of Data can exist across many Governance Domains.

That is the part I think is especially powerful.

Where the two structures intersect

This is where the model becomes much more valuable.

Think about it as:

Governance Domain
WHO owns it?

Enterprise Glossary Term
WHAT does it mean?

Governed Business Context

For example:

HR Governance Domain
PII Enterprise Glossary Term

The result is:

The HR-owned instance of an enterprise-wide PII concept.

That intersection gives us both ownership and meaning.

Why this matters for data consumers

Most data consumers do not necessarily know:

• which Governance Domain owns the data;
• which platform contains it;
• which Data Product it belongs to;
• what the database table is called; or
• what the individual column names are.

They may simply know the business question they are trying to answer.

For example:

• Where do we hold PII?
• Which Data Products contain Customer information?
• Where is Location information used?
• Which Data Assets contain Financial information?

This is where the Enterprise Glossary becomes much more than a list of definitions.

It becomes a business discovery layer.

From business concept to technical data

If the relationships are created properly, a user can begin with a business concept and navigate towards the underlying data.

For example:

Enterprise Glossary Term → Data Products → Data Assets → Critical Data Elements → Columns and Attributes

This creates a bridge between:

Business meaning ↔ Technical implementation

That is a much more useful experience than expecting users to understand the technical structure of the data estate before they can discover anything.

Enterprise terms, local terms and CDEs

There is also an important distinction between the different types of business metadata.

Enterprise Glossary Terms

These should represent concepts that have meaning across multiple Governance Domains.

Examples might include:

• PII
• Customer
• Organisation
• Location
• Financial Information

These provide the horizontal enterprise view.

Local Glossary Terms

These are better suited to terminology that is specific to:

• a Governance Domain;
• a business area;
• a Data Product; or
• a specialised process.

They provide local business context without forcing every term into the enterprise vocabulary.

Critical Data Elements

CDEs are different again.

A Domain of Data may represent a broad business concept such as PII, while CDEs represent individual important data elements such as:

• Email Address
• Date of Birth
• Customer Identifier
• Postcode

That gives us another useful relationship:

Enterprise Glossary Term: PII → Critical Data Element: Email Address → Physical Column: customer_email

Now the business concept is connected directly to the technical implementation.

The principle I keep coming back to

The value is not in creating as many glossary terms as possible.

It is in applying:

The right term → at the right level → connected to the right data

That means asking:

• Is this genuinely an enterprise-wide concept?
• Should this be local to one Governance Domain?
• Is this actually a Critical Data Element?
• What Data Products and Data Assets should it connect to?

The quality of those relationships matters far more than the volume of metadata.

The bigger picture

This is ultimately why I think the horizontal and vertical model is useful.

Vertical = Ownership

Governance Domains tell us WHO owns and governs the data.

Horizontal = Meaning

Enterprise Glossary Terms tell us WHAT the data represents across the organisation.

And where they intersect:

Ownership + Meaning = Governed Business Context

That is what allows Microsoft Purview to move beyond simply listing technical assets.

Instead, it starts to create a connected view of:

Ownership → Business Meaning → Discovery → Governance

across the enterprise data estate.

For me, that is where the real value of the catalogue starts to appear.