The Business Glossary Prime Directive

The Business Glossary Prime Directive

The Business Glossary Prime DirectiveYes, I’m using a line from the Star Trek franchise. We must have a similar concept for data governance and the business glossary. The Star Trek Prime Directive is the single guiding principle of the United Federation of Planets, and has not waivered since the beginning of the franchise. It does not matter what the contents of the directive are; what matters is that there is a directive, that it is understood and communicated, and, when necessary, everyone follows the directive as the single deciding principle for the society. For data governance and the business glossary, a prime directive relates to the naming and definition of our business terms.

We do have a Prime Directive for the business glossary that every program should adapt. Like all prime directives, the business glossary prime directive is simple to state. Therefore, it is simple to remember.  Yet, it is significantly difficult to implement under all situations. Hence, we must remember it and always strive to achieve it.

Simply stated, the Business Glossary Prime Directive is “to eliminate semantic confusion across the enterprise.” What does that statement mean for our governance program? It means that each business term has a unique name, a single definition, a single value set, a single set of business rules, single authoritative source, and accountable party identified. However, there may be multiple usages but those usages do not conflict with the single definition or introduce additional values and or rules.

But Lowell, we don’t have one definition for our business terms; we have multiple. At times, every business unit uses the same term, but the rules and business/reporting usages are all different. However, we want to use the same term. Therefore, my response is NO, don’t do that! You are not eliminating semantic confusion. You are fueling the fire of chaos and your temple of governance will eventually burn down. (I’ll explain later so we can stay with the prime directive concept).

 Perhaps we should consider “the elimination of semantic confusion” as more of a long-term objective. I have not met an organization that begins their data governance program at this level of maturity. Most of us have several definitions and usages for the same business term. This is the governance problem: having multiple definitions for the same concept creating semantic confusion across the enterprise. In fact, it is likely that once you have achieved the elimination of semantic confusion, you have achieved the highest level of governance maturity. So maybe considering it as an objective is a guiding principle that every data governance program must have. From my experience, it should be your first guiding principle. Therefore, I recommend this in all of my business glossary tutorials.

My greater concern is that many governance teams do not yet realize that they must strive for this objective. Maybe we can consider this as lack of maturity in the practices for the data governance industry. However, I’m not suggesting that we stop using the Prime Directive as our guiding principle. Let’s look at some examples in order to further convince you of the need for and the value of our Prime Directive.

Let’s consider an analogy to the concept of Master Data Management (MDM). Many organizations understand the value and benefits of MDM. That is to have “one” definition, one value set, one authoritative source system/column, and one accountable party for that set of data. We agree that this is the objective—a goal that is simple to state but difficult to achieve for many. Consider the situation where we have three different sources for Customer Name, Customer Number, etc. We would then say we have chaos since we do not have a single source of truth. Our business management asks “Which one is right? Which one should we use for analytics? Which one is correct for reporting our financials and to the regulators if we have to?”  If we have multiple MDM sources, then we don’t have a “golden copy” of that data. We have conflict and chaos that wastes money and business opportunity time to resolve. Furthermore, this problem extends to the business glossary. If we don’t have a single business term name, definition and all that comes along with it to manage a source of truth, then we have chaos in our semantics and usages.

When we have multiple definitions, rules etc. for the same business term name, we create additional confusion, which is contrary to our directive and objective of clear semantics and greater governance maturity. We instead have the equivalent of a dictionary.  A dictionary often has many definitions and usages for the same term. One has to first know the intended usage of the term prior to reading the dictionary in order to find the right definition for the term in the context you are using it. This specific confusion is what we are trying to eliminate, not create.

The example I have used for a long time is the term “mole.” When the term mole is used in a business context we, the listeners, must understand the context of the speaker before responding. “How many moles do we have in our brick and mortar retail operations?” Is the requestor asking the question about that small ground animal in the back yard or the skin anomalies of our customers? This example is intended to be silly, but can easily be extrapolated to the complexity of our corporate environments.  Marketing resources do not necessarily understand the context or complexity of customer service business processes and usages. This creates confusion if we use the same business term that has different meaning in each business unit usage of that term.  Information Technology (IT) does not seem to understand the business term context of any business unit, and vise-versa.

Consider another example maybe more relevant: The business term is “Customer Life-time Value”. The definition is “The economic or monetary value to the company for each individual customer.” Sounds like a good definition. Simply, this definition could be used across the enterprise. However, the definition is too general and thus very weak. Consider that different business units may compute the value for this term differently. The usage may also be different. The retail sales brick and mortar units may compute this differently than the on-line sales unit. If anything about that business term differs in definition, value set, authoritative source, security, or computation, then the object (term) may not be the same. You need to uniquely define and name that business term. In this example, Customer Life-Time Value is computed differently between the 2 business units. If we use the same business terms, then what will happen when someone does a comparison of Customer Life-Time Value? Is it a far comparison? No, it is not. With this example, we just created another dictionary entry to increase the semantic confusion. There are a number of issues that lead to the need to modify a business term and its definition. I have those documented in the General Guidelines for authoring a Business Term Name and Definition. Request a copy via email from And if you want to meet with like-minded individuals on this and other pressing data governance topics, join my weekly office hours on Collibra Community.

I know that most data governance programs have multiple definitions of the same term today. The first step is to identify and record those with all the associated metadata. Place them under different domains initially. Over time you will be able to review and harmonize them across the business unit usages. As time allows, you will be able to modify the terms and definitions so that they are unique. Just don’t forget that this maturity step is required before you can achieve the Prime Directive. It is OK, stay calm and allow your business glossary to prosper.

More stories like this one

Mar 17, 2021 - 4 min read

How to build a business glossary

Read more
Mar 3, 2021 - 4 min read

What is a business glossary?

Read more
12 Steps to Data Intelligence
Apr 22, 2020 - 7 min read

12 Steps to Data Intelligence: Part 1

Read more