Business Drivers

The need for a clear and unambiguous understanding of the meaning of business terminologies, taxonomies, and other hierarchies, and how they differ across Communities.

Key Questions

The Business Glossary business case envisions a systematic process to reach agreement and alignment between all stakeholders on their Business Assets and how they relate to Data Assets and Technology Assets. It envisions to answer questions such as:

• what is the meaning of a business term, e.g., “Customer”?
• why is there different meanings for this business term across businesses and functions?
• what are the different data attributes/elements/fields for this business term and how are they formatted?
• where – i.e., in which databases and systems – is the age attribute of a customer recorded?
• to whom should I report in case I cannot find a business term in the published glossaries?
• to whom should I request a revision of a business term definition I found to be inconsistent or incomplete?
• to whom should I request the deletion of a term I find redundant or obsolete?
• to whom should I report to promote my term to a global level?

Key business terms mean different things depending on their context. Take the example of the business term “Customer”: a widely used; hence overloaded term, but when you put different people from different business units together to come to a common definition, it turns out one may attribute different meanings to a term to serve various purposes. E.g., a marketing department may categorise a natural person as “Customer” differently from how a sales department does. Hence, they want to retain the freedom to retain their own definitions, while articulating well the difference between each other.

On the contrary, there are other terms that must be universally agreed upon leaving no room for interpretation to anyone in the organization. If your organization does not have a stake in these glossaries, they are adopted from an external (standardization) organization and from the moment a new release is issued, it is imported through the Collibra API and. One can analyse the differences with the previous version using snapshots, and see the impact it may have. Other glossaries that are internally developed may represent the single version of the meaning for the terms it contains. They may be the result of a long search for unification among different business units or -functions.

Traceability Requirements

The business glossary case is usually the starting point in business-driven data governance programs. Starting with a limited list of business terms, a glossary may gradually evolve an extend its population with acronyms. Further, it may develop agreements on other asset types such as report, business process, metrics, key performance indicator and dimension.

The business glossary case aims at a establishing traceability between one or more of the above asset types in different domains, which translates to establishing following relations in the Operating Model:

• Business Term groups Business Term(s)
• Business Term’s synonyms and acronyms;
• Business Term has allowed value Business Term;
• Business Term encoded by Code Value (in case reference data case is in place);
• Business Asset is represented by Data Asset;
• Business Term has system of record/source/use Technology Asset.

The description of these relation types and attribute types is provided in the section Asset Types. Naturally, other relation types may be added to the Operating Model to fit a more specific case sample.

Business Glossary Lifecycle

The business glossary lifecycle is illustrated below. This general view is to be further defines in terms of a Data Governance Operating Model. In Business Semantics Glossary Cookbook INPUT, we provide a cookbook on how to get your implementation started that is based on numerous customer implementations.

Every business asset goes through at least the following phases:

1. Import: the first step is to gather all existing content, analyse it and import relevant parts into the Business Semantics Glossary tool. The import functionality allows to import thousands of assets in one pass. Two other options are the create assets manually, or discover them from unstructured text. The outcome is an initial population of business assets of varying types, assigned the candidate status, and organised in different glossary domains.
2. Improve: the second step involves assigning roles and responsibilities in the respective domains. The steward teams improve the bulk import, and make it ready for review. To ensure the orchestration of improving, reviewing and approving tasks among the team members, the out-of-the-box Operating Model features two approval workflow variants: Approval and Simple Approval. The outcome is a set of business assets with the status “Approved”.
3. Publish: Approved business assets can be provisioned in different ways to the business user. They can be exported in MS Excel spreadsheet format, comma-separated file format or SQL statements. The Collibra API also offers ways to push approved assets to external applications. The latter can be automated in a timely manner through custom workflows. Once published the assets are not assigned another status by default. However, it could be useful to distinguish between “Approved” and “Published”. To achieve, this software can be customised.
4. Use: during the final stage in the lifecycle, the business users consume published assets in their own applications such as reporting. This typically results the identification of inconsistencies or incompleteness in the current glossaries. These issues can be reported triggering the cycle to restart.

[bok-callout]The fourth “Use” phase provides an extension point for the Issue Management business case, the latter involving capacities to report different types of issues, and to handle these issues according to their type and domain context. This will be described further below in Issue Management.[/bok-callout]

Reference Cases

• Business Semantics Glossary for Research Information Systems