Skip to main content

15.3 Business Glossary & Classification

1. The semantic problem​

Different teams can use the same word differently.

For example:

Revenue

Could mean:

  • gross sales,
  • net sales,
  • recognized revenue,
  • invoiced revenue,
  • revenue excluding intercompany transactions.

A technical model cannot solve this ambiguity by itself.

The glossary provides shared business meaning.

2. Glossary mental model​

Business Concept
      |
      v
Glossary Term
      |
      +-- Definition
      +-- Synonyms
      +-- Domain
      +-- Owner
      +-- Related Terms
      +-- KPI relationships
      |
      v
Catalog Assets
      |
      v
Models / Analytics / Data Products

3. Good glossary term​

A strong term definition is:

  • business-oriented,
  • unambiguous,
  • concise,
  • testable,
  • owned,
  • version-aware where necessary.

Weak:

"Customer revenue."

Strong:

"Net recognized revenue attributable to external customers after approved returns and commercial adjustments, measured according to the Finance revenue policy."

The second definition gives a modeler something actionable.

4. Term lifecycle​

Proposed
   |
   v
Reviewed
   |
   v
Approved
   |
   v
Published
   |
   +--> Deprecated
           |
           v
         Retired

Do not allow informal definitions to become de facto enterprise definitions without review.

5. Classification​

Classification answers:

"How should this data be treated?"

Typical enterprise classes:

  • Public,
  • Internal,
  • Confidential,
  • Restricted.

Actual classification names must follow the organization's policy.

Classification should influence:

  • access,
  • sharing,
  • handling,
  • monitoring,
  • retention,
  • incident response.

6. Tags versus glossary terms​

They are not equivalent.

Tags​

Useful for flexible classification and filtering.

Examples:

  • Tier-1,
  • Finance,
  • certified,
  • regional.

Glossary terms​

Represent business meaning.

Examples:

  • Customer,
  • Net Revenue,
  • Purchase Order,
  • On-Time Delivery.

Use tags to classify.

Use terms to define.

7. KPI governance​

A KPI should have:

  • business name,
  • definition,
  • formula,
  • grain,
  • time semantics,
  • source,
  • owner,
  • exclusions,
  • aggregation rule,
  • refresh expectation.

For example:

On-Time Delivery %
= deliveries meeting agreed date
  / eligible deliveries

Grain:
delivery line

Exclusions:
cancelled deliveries

Owner:
Supply Chain

The exact formula belongs to the business definition, not to the visualization layer.

8. Glossary-to-model bridge​

A mature architecture connects:

Glossary Term
     |
     +--> governed asset
     |
     +--> KPI
     |
     +--> semantic model
     |
     +--> data product
     |
     +--> analytics content

This creates semantic consistency across consumers.

9. Avoid glossary explosion​

Do not create a term for every technical field.

Create terms for:

  • important business concepts,
  • ambiguous concepts,
  • regulated concepts,
  • critical KPIs,
  • cross-domain concepts.

Architect exercise​

Take these terms:

  • Customer
  • Supplier
  • Revenue
  • Purchase Order
  • Net Price

For each, design:

  1. definition,
  2. owner,
  3. domain,
  4. synonyms,
  5. related terms,
  6. KPI relationships,
  7. example governed assets.