The business glossary application should be structured to meet the functional requirements of the three core audiences. The structure of the business glossary application and database should be defined based upon the requirements that are necessary to meet the functional processes for each audience. The three audiences are:
- Business Users – the individuals in all business organizations that will search the business glossary for knowledge and meaning of enterprise terminology. These are the individuals that need to leverage the business glossary knowledge for making business decisions. I include all data analysts, research analysts, management and executive staff in this group.
- Data Stewards – the individuals or groups that will be responsible for managing the lifecycle of the business glossary terms and definitions. Data stewards may additionally increase the enterprise knowledge through the association of other assets with the terms in the glossary. These other assets can be business metrics, associated reports, data quality analysis, and other technology components.
- Technology Users – the individuals in the technology organizations that will leverage the knowledge from the business glossary to make technology architecture, systems design and development decisions, and to conduct information lineage and impact analysis recommendations.
So what functionality should we deliver to this audience? As with most applications, the business glossary application is comprised of data capture and audit functions, governance processes, data management processes, a database, user query/search access, and reporting functions. You should consider all of these capabilities, especially the user query/search access, if you are defining your requirements or conducting an evaluation of software solutions. I cannot over emphasize the importance of the user query and search functionality that should be provided. In fact, when I weight the criticality of application functions, I put a 33% weight on the user query and search functionality. I have seen many organizations spend significant effort on the capture of business terms and do so very successfully. Yet, we are not achieving the maximum value of the business glossary until we can deliver the business terms to the individuals that need to use those terms for decision-making purposes. We cannot build the equivalent of "information roach motels" as my friend Bonnie O'Neil calls them. Data capture and governance is a means to achieving the delivery of this knowledge to the teams that need to use that knowledge. Let’s explore these functions and their relationship to the core audiences.
Data Capture and Audit Functions
Yes, we have to capture our business terminology and definitions of those as a first step. However, this is only the first step in the lifecycle of managing our business glossary terms. This data capture may include recording terminology attributes such as the following:
- Term name
- Term definition
- Term acronyms
- Business unit and or application responsible for managing the data associated
- Name of the person identifying the term
- Date of term definition
- Categorization or taxonomy association for the term (business functional association)
The less mature business glossary applications often focus exclusively on data capture functionality. For example, you can capture these attributes in a spreadsheet or document and present that information on SharePoint or from an internal website as HTML.
There are a plethora of methods that can be used to capture you business glossary terms and associated information. I've seen organizations with business terminology in documents, in training manuals, on websites, in SharePoint or in spreadsheets. We all have heard a coworker say, “Waldo knows all about that stuff. Just find Waldo."
Now I'm not suggesting that harvesting your existing business glossary information is easy. Actually it may be a significant challenge to find it it as the information is spread across applications, business material in different business units and knowledge in people’s heads. Harvesting it all into one place is the first step. You then may have to reconcile conflicting information, discrepancies, out-of-date information, and erroneous information, but that is the function of the governance processes.
Fortunately, today most business people don't run away waving hands in the air and screaming when you mention the word "governance." The governance function and process have been widely discussed in business publications, and most will recognize that some level of governance, even informal by Waldo, is happening today. A critical success factor for the business glossary application will be to organize a governance function and processes that will be acceptable to your organization's culture and funding capabilities.
Let me give you an example of how simple it can be to start a business glossary governance effort. Recently I was with an organization that implemented a business glossary with an informal governance approach. Anyone in the organization could send an email to a special Outlook inbox. This was one of our data capture methods. The architects in data management then took turns being "the governance lead of the month" on a rotating basis. If we had issues, we discussed it as a team, but generally the lead would make the necessary decisions to manage the lifecycle.
I suggest that most organizations determine their specific requirements for the management of the business glossary lifecycle and establish governance processes to enable those requirements. Many require dedicated resources, but not always someone dedicated full-time to governance. If your organization has a data governance
team, you should be able to leverage that team for the business glossary. Your governance team may be responsible for defining the business glossary standards and managing status changes – often with work-flow or collaboration software – and may also be responsible for promotional activities and training development or actual training across the organization.
More rigorous governance will require a business term and its definition to progress through varying status changes or governance gates; for example, from a candidate term, to approved, to published, and to a final point in the lifecycle of replaced or retired. The governance team may also manage business term associations such as related terms, as well as the categorization of and grouping of the terms. The governance team may also be responsible for relating technology assets to the business terms. Technology assets are the alignment of actual technology implementations to the business terms. These may include logical attribute names, physical database column name, managed by application name, physical database and application server names, data lineage, and report column names. This alignment between the business usage and the technology implementation may be the reason why business glossary technologies are generally considered metadata implementations.
The Database Model
The database model for a business glossary is very specific to that lifecycle and associations that you desire to manage. Each technology vendor application will have a specific set of attributes that are managed by their application. Most also allow you to customize and extend the attributes that can be managed. I have had to build a number of business glossary applications rather than purchase an application. While I don't recommend this option, it is often necessary to create a proof-of-concept to demonstrate the value of the business glossary. Obviously, if you need to build a proof-of-concept, then the database model should be kept to the minimum needed to prove out the value proposition. In this case, I suggest only maintaining the basic data for a business glossary.
Every business glossary implementation should have a basic set of reporting to support the governance processes. I always recommend that organizations do not "print the glossary contents." That implies that the business glossary content is static, which should never be true for more than a very short period of time. However, we do require reporting to aid the data stewards to manage the glossary and governance processes. These reports may not need to be printed reports. Generally, the business glossary reports should be more in the nature of status tracking or audit reporting. This could include, for example, new terms and definitions that have not been reviewed yet, those that have been in a "pending" status, and those that are missing definitions or other attributes. These reports should be created as email attachments or work-flow actions to the appropriate data steward.
User Query and Search Functions
Finally we get to why we really care about business glossaries: to leverage the organization’s business and technical knowledge for better business decision making. Everything else is a means to achieve the dissemination of knowledge to the users in the organization, both business and technical. So how can we achieve this dissemination of knowledge?
Let's ignore the promotion and training functions for now. I want to focus on the query and search basics. The best use cases of the business glossary content are at the point in time when users question the understanding of a term. That may be in a document they are reading, it may be a column heading in a spreadsheet, it may be a dimension on a report, it may be a measure in a report, or it may be a term they’ve never heard that is contained in an email from their boss. They really don't want to stop what they are doing to start up and sign into a separate application or even open a browser to enter the term in a search box. Most of us will have to do this, and it is effective but not optimal. I'd rather just highlight the term and depress a "hot key" that does the search of the business glossary for me. There are a few technologies that enable this "hot key" search in the business glossary.
All business glossary vendors provide the ability to search for terms in the glossary; however, the ease of use and functionality can vary widely. Understanding the vendor’s capability here is critical. I've had to build my own search functions too many times. When we have to build our own, I suggest it should be located somewhere that everyone can easily get to, such as the company intranet home page. The simpler and easier we make the business glossary search, the more likely the glossary content will be used. And the business glossary content has to be used to ensure that we don't build "information roach motels."
Recent articles by Lowell Fryman, CBIP-CDMP