We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

What is a Business Glossary?

Originally published September 13, 2012

Welcome to my Business Glossary Expert Channel on the BeyeNETWORK and my first article for this channel.

I envision that this is just the first of many articles and discussions that we will have about the challenges, governance, and implementation issues surrounding a business glossary. I know that there are a few different understandings and definitions for a business glossary. Given that a core objective of a business glossary is to minimize the misunderstanding and confusion of business terminology and communications, it is incumbent upon me to start with a definition of the business glossary.

In its most basic form, a business glossary is a software application used to communicate and govern the organization’s business concepts and terminology along with the associated definitions and relationships between those terms. Sounds simple, but we all know it is more complex than can be described in one sentence. As with all data-oriented applications, there is an architecture, hardware, software, database, processes, and human resources with differing roles and responsibilities. The resources should support different user roles: design and development practices, process and workflow management, technical support, program management, training, help desk support and so on.

One of the complexities of communications in the global enterprise is that each individual can have different experiences and training that equate to a different context for the meaning and definition of the terminology used in the business. This differing context is one of the critical reasons for creating a business glossary. Many of us will have a different context, different understanding, different organizational filter, different cultural or regional semantics, different country regulations that define terminology and processes differently, and other differences. Thus, it may be more effective to discuss the objectives of a business glossary as a means of understanding what one is.

Objectives and Benefits of a Business Glossary

I'm sure I'll never identify all of the objectives and benefits that an organization can achieve through a business glossary implementation.  The list will hopefully grow as we mature our understanding and technology. This is a great topic for my first blog. I hope you can contribute to my blog. Refer to the tab “Blogs,” and find my name, Lowell Fryman, or click on "Read My Blog" on my channel homepage.

The core objective of a business glossary is to improve our understanding of business terminology so we can communicate more effectively across the enterprise. The following are my top 4 objectives.
  1. To maximize the understanding of the core business concepts and terminology of the organization.

    To achieve this, we must manage the concepts or business terms, the definition of each, and associated knowledge such as who is responsible for the term, what metrics might be associated, how the term should be used or not used, what other terms are related, or which have been replaced by this term. We all have experiences where organizations have spent significant effort, and money, resolving terminology differences between different lines of business.  This is one reason why the CEO gets 3 different reports with different metrics for sales volume; we don't agree on what constitutes a sale, or what is a month, or what is a customer, or what is a region, etc.

  2. To minimize the misuse of data due to inaccurate understanding of the business concepts and terms.

    Related to this is the goal to maximize our decision-making processes through better access to knowledge of our business terms. One survey done in 2007 identified that 42% of the managers in the survey acknowledged that they had recently make erroneous business decisions due to misunderstanding of terminology and data usage.

  3. To improve the alignment of the business organizations with the technology assets and organization.

    This is a very important objective that is achievable. The terminology of the business can be aligned with the technology implementations and assets. We can identify the BI metrics, the applications, processes, databases, and data stewards that are associated with business glossary terms. Yes, to achieve this objective will require more than just the business glossary application. Processes and people (governance) are also necessary, but the business glossary provides an enabling platform.

  4. To maximize the accuracy of the results to "searches" for business concepts, and associated knowledge. 

    It is critical for people to find information associated with the key business terms of the organization. We all have done an Internet search for something only find nothing of actual value from the 300 or more returned values.  The business glossary application should support the ability to “gain access to knowledge of the enterprise.” This often begins with a “search” for a term or list of terms.

I will discuss the objectives, benefits and ROI in greater detail in future articles.

A Business Glossary is Not a Dictionary

I have seen ineffective results with all the implementations that have attempted to provide a “dictionary-like solution.” By a dictionary-like solution, I mean having more than one definition for a given business term. I’ve established that an objective of a business glossary is to maximize understanding, and that cannot be accomplished well by providing alternative understandings.  However, having multiple definitions recorded and communicated is far better than having nothing defined. In fact, I consider having a dictionary style with multiple definitions for business terms to be a first level of maturity. Capturing knowledge is the first step.

Have you ever been in a meeting and heard a term discussed but it seemed to you to be out of context from your understanding? Not wanting to interrupt or sound like you did not understand, you said nothing.

Okay, I'm taking liberty with the example to make a point. 

The point is that having multiple definitions of a business term is inadequate to maximize understanding and exact communications.  I recently met with a team in the railroad industry that had inherited 23 different dictionaries of business terms.  The definitions of a “train” and a “track” were often misleading, inaccurate and contradictory.  Train and track are business objects that are made from iron, and we all can see and touch them. There is nothing abstract about trains or tracks. Yet there are business nuances that create complexity in the context of a business term. Eliminating the potential for misunderstanding is critical to the success of a business glossary.

Let's look at a real example that I have from a previous client. This client had revenues of $1.5 billion per year from sales of advertising products in 14 western U.S. states. They had a significant and long-term challenge in defining the processes and metrics around "customer." They were under the impression that one definition of a “customer” was necessary. Most business units had different needs and processes to manage their responsibilities in the customer management lifecycle. A cross-functional committee spent years, meeting each quarter, trying to come to one definition. In the meantime, each business unit reported its own metrics and wanted their own data warehousing and BI application to manage their specific analytics. For example, the following are definitions for a customer from just 2 business units.
  1. "A Customer is a business that has purchased any product from us." Research into this yielded that this definition was needed since the salesperson was given commissions for a new customer for 10 years from the first sale, even if the salesperson was not directly involved with any future sales to the customer. Many companies have similar "sales royalties" rules in place.

  2. "A Customer is a business or individual that we must provide support under a current customer support contract." All advertising products (these were physical books) were under the support contract for the duration of the advertising product, by city, which ended in a specific month each year. Thus, a customer could be under support for 12 months or until the book published expired.
Both definitions are valid definitions of a Customer within the context and business processes of those business units. Yet there was a great deal of wasted productivity and resources just to resolve the metric Count of Customers, or any metric that involved Customer.  The other major business units also had differing definitions.  Multiple definitions for a business term do not allow us to align the specific term to the processes, governance, applications and metrics specific to that term.

Experience has proven that it is best to have business concepts named consistent with the definition of the business term. It just makes sense. We have taken the same approach with data management and modeling standards for a few decades. Refer to the ISO standard 11179.  I now demand that each business term definition is a different business term name.  If you can define the business object differently from other, then it is different and needs to have a different name.  From the above two definitions, I would suggest that the business terms are "Sold to Customer" and "Supported Customer." 

Tightly coupled to the definition challenges are the business glossary governance challenges. We will have additional articles that discuss how to create and manage good definitions for business terms. I will also cover the governance challenges and styles of governance, as well as roles and responsibilities. It is a governance responsibility to maintain business term relationships, such as related terms, term synonyms, term replacements, term activation and retirement, and term associations to the organizational taxonomy. Then we have to manage changes to the definitions of those terms.  We also  have to consider adding value to the business glossary usage by associating lots of technical assets such as what metrics, databases columns, and reports are associated with each term and, yes, the data lineage and where used for reporting as well.

A business glossary is not a dictionary!  Have I convinced you yet?

I am really keen to hear your interests on the business glossary topics and challenges that you are interested in reading about. My current thoughts for the future articles, in no specific order, are as follows:
  • Why do we need a business glossary (BG) and how does the BG add value to the organization?
  • Can the BG program be cost justified? How do we start a BG program? 
  • What is the structure of the BG both conceptually and physically? 
  • How do we define a hierarchy for our business terms? How is the BG aligned with our organizational or product taxonomy?
  • Where does a BG fit in the enterprise architecture of my organization? 
  • How does a BG add value to our data warehousing/BI program?
  • Who should lead the BG program?
  • What are the implementation steps for a BG?
  • What techniques can be used to promote the BG?
  • Who are the users of a BG?
  • What is a "good" definition? How do we name a business term?
  • What are the alternatives for sustaining the BG and keeping the value high?
  • What BG software vendor solutions should we consider and why?
  • What are the maturity levels of the BG? How can we improve our maturity? 
  • How does a BG aid in the alignment of IT and the business?
  • How can we align business terms to technology implementations?
  • Data governance options for the BG
  • Managing temporality in the BG
  • Alternatives for searching the BG
I hope I've piqued your interest in the business glossary. Look for additional articles soon, and please follow my blog. Lastly do not hesitate to email me your questions and burning topics that you would like to understand more about. Let's have a great journey!

  • Lowell Fryman, CBIP-CDMPLowell Fryman, CBIP-CDMP
    Lowell, Senior Principal Consultant at Aspen Information Solutions Inc., is recognized as a thought leader in data warehousing, enterprise data management, and metadata management. He has more than 25 years experience in data management and hands-on experience with over 80 data warehousing implementations. Lowell has authored articles, white papers, and is a co-author of the book Business Metadata: Capturing Enterprise Knowledge. Lowell has developed technology courses and trained thousands of professionals in data warehousing, master data management (MDM), data quality, data management and business glossary topics. Recently he has led teams in the implementation of business glossary, enterprise data management, and business intelligence applications in the healthcare and financial services industries. He is a past adjunct professor at Daniels College of Business, Denver University. He is also the past President of DAMA-I Rocky Mountain Chapter (RMC) and an active speaker at international conferences. He currently leads the LinkedIn groups for Business Glossary and Unstructured Data Warehousing. Lowell can be reached at lowell.fryman@aspensolutionsgroup.com.

Recent articles by Lowell Fryman, CBIP-CDMP



Want to post a comment? Login or become a member today!

Be the first to comment!