My last article presented an overview of the Business Glossary and its potential contents. While there may be 100 attributes in your Business Glossary, there are two attributes that function as cornerstones in the foundation. These are the Business Term Name and the Business Term Definition. The content of your Business Term Names and the Business Term Definition are related. Let me explain.
Which came first, Term Name or Term Definition?
This is not really a “chicken or egg” debate. The Business Term Name comes first. Why? Well, we have likely used the term name in the physical operations of the business even before we recorded the definition, and certainly long before we had data modelers that started asking for the business to give them a definition. I started asking that question as a data modeler nearly three decades ago. Yet, our objective for the artifacts of data models is much different than that of the Business Glossary. Hence, our need to be precise in our definitions is far greater.
In the Business Glossary, the Business Term Name and the Business Term Definition must be aligned and specific. The objective is to clearly communicate the language of the business. Now the “business” can be from a unit like Sales, corporate functions like Finance or a technology group like Data Warehousing. We should not settle with a Term Name that is generic and a Term Definition that is not specific to a business activity. Lets’ look at an example such as the Term Name “Status Code”.
“Status Code” is likely a term in every Business Glossary until we resolve the Term Name to the Term Definition. The Status Code may have 20 different definitions and the value set identified may be vastly different. I’m using “Status Code” as a simple example to make a point. I’ve found it typical that the Term Definitions for Status Code may read something like the following:
- Status Code of the Loan Application that identifies the application progress toward approval or denial.
- Status Code of the Loan progress in the provisioning process prior to servicing.
- Status Code of the Mortgage foreclosure process prior to final foreclosure or write-off.
- Status code of the Finance credit approval process.
- Status code of the ETL staging load for Trade transactions.
The above definitions are describing very different business objects or processes. Not having the Term Name appropriate to the Term Definition should not be accepted. An inaccurate Term Name leads to semantic confusion when we communicate across business teams and defeats the purpose of the Business Glossary. Thus, I suggest that once you agree on a great Term Definition you must consider if the Term Name is appropriate based upon the definition.
Based upon the above examples, I suggest that we have 5 different Business Terms, not just one. Those Term Names may be Loan Application Status, Loan Provisioning Status, Mortgage Foreclosure Status, Finance Credit Approval Status, and ETL Trade Transaction Load Status.
There should be no question that the Business Term comes first and may have evolved from a purchased application, a data model, or an industry business concept. The source of the Term Name is not the real concern. I suggest that the concern should be that the Term Name can communicate the concept as we have defined it and both are in alignment. Does this mean we will have a higher number of Business Terms in the Business Glossary? Maybe. But the objective is not to have a limited number of terms, is it? The objective is to have our business language described in a manner that facilitates our communications across the enterprise.
Term Definition – Why is it so hard?
The true intent of this article is to tell you that I have found it is very hard for many of us to create great business term definitions that can be harmonized or used across the enterprise. I have not found anyone that says it is an easy task. Maybe that is why we are not so great at it. There are likely many reasons as to why we do not accomplish the task well. We should always ask questions like:
- Do we have the subject matter experts on the team from the right units to aid in the definition?
- Have we allocated the time to accomplish the desired outcome given the input needed?
- Is our scope of effort local to a limited number of business units or global to the full enterprise?
- Why are we here?
I venture to suggest that few of us have ever been tasked with the objective to “just work on fixing our Business Term Definitions”- most often a perceived data quality issue is why we have to look at the definition. Something such as “The Commission reports from Sales and Finance do not agree, this must be a quality problem, fix it”. I’ve learned to first start the research with the question of “do we agree on the definition and calculation of Commission?” Since mathematics work consistently across technologies and time-zones, I’ve always found the root cause to be some, generally unstated, difference in the definition that created a filtering or computational difference. Please remember that if the Business Term Definition is different, then the Business Term Name must be different. Eliminate the semantic challenges and keep your Term Names aligned to the Term Definitions.
Business Definition Guidelines
There are industry guidelines that you can follow when creating your Business Term Definitions. You may have seen these before. I suggest that you create a guidelines document in your Glossary standards for definitions. Most organizations start with the ISO/IEC 11179 standard for data modeling as a guide. ISO/IEC has 6 sections and it is likely your Data Architecture or modeling team already has a copy. While this is a general guide for data modeling, section 4 of the stand, i.e.,11179-4, presents 13 guidelines for creating great definitions. I have pulled the most critical and combined a few as a summary below. If you have access to 11179 please refer to it for your guidelines. ISO/IEC 11179-4 also has examples, explanations and reasons for each of the guidelines.
The following is my summary of the guidelines for Business Term Definitions.
| # | Rule | Explanation |
| 1 | A data definition should be stated in the singular | The concept expressed by the data definition shall be expressed in the singular. (An exception is made if the concept itself is plural.)”Active Client not Active Clients” |
| 2 | A definition should state what the concept is, not what it is not | When constructing definitions, the concept cannot be defined exclusively by stating what the concept is not. |
| 3 | A definition should be stated as a descriptive phrase or sentence(s) | A phrase is necessary to form a precise definition that includes the essential characteristics of the concept. Simply restating the words of the name in a different order is insufficient. If more than a descriptive phrase is needed, use complete, grammatically correct sentences. |
| 4 | A definition should avoid the use of abbreviations | Understanding the meaning of an abbreviation or acronyms is usually confined to a certain environment. In other environments the same abbreviation can cause misinterpretation or confusion. Therefore, to avoid ambiguity, full words shall always be used. |
| 5 | A definition should be expressed without embedding definitions of other data or underlying concepts | The definition of a second data element or related concept should not appear in the definition of the primary data element. If the second definition is necessary, it may be attached by a note at the end of the primary definition’s main text. |
| 6 | A definition should be concise, precise and unambiguous | The exact meaning and interpretation of the defined concept should be apparent from the definition. A definition should be clear enough to allow only one possible interpretation. The definition should be brief and comprehensive. Extraneous qualifying phrases shall be avoided. |
| 7 | The data values (domain) intended to be used must be aligned with the definition | A definition cannot include language such as “type”, “code”, “name”, etc. when the intended physical data values will not support that definition. Data values used in the physical implementation and the Term Definition should be in agreement and aligned. |
| 8 | A definition should use proper capitalization rules | Every organization should have a writing “Style Guide” that should be used when authoring a definition. The Style Guide should have rules around capitalization and the use of correct wording. |
I hope this article has provided you with guidelines for Term Names and Term Definitions. To summarize, I have suggested:
- Creating great Business Term Definitions are not easy. Set resource expectations accordingly.
- Business Term Names and Business Term Definitions must be aligned to communicate effectively.
- The Term Definition must align with the physical data values or domain that will be implemented. Be careful when you use phrases such as “type of, code for, or name of” in your definitions. Data profiling can be a useful tool when creating Term Definitions.
- It is often necessary to revise the Business Term Name once you have agreement on the enterprise level definition. The Term Name must be reflective of the intent of the object as it has been defined. This may increase the number of Business Terms in your Business Glossary but improves the global communications. Numbers do not matter, clear language and semantic understanding does. It is okay, stay calm and allow your Business Glossary to prosper.
