One of the major challenges of the glossary is to provide a representation of the data model that makes sense to business users, and that is understandable and valuable to everyone.
There is no perfect modeling solution, but several approaches depending on your needs and use case. Below are two approaches: by proximity and by urbanization.
Which constraints should you take into account?
Several constraints must be taken into account when building the glossary:
- Constraints related to your project:
- The use case: modeling is often different depending on whether you are working on a BI, Data Governance or even DataHub project
- The maturity of the organization in terms of data management
- Constraints related to the platform: for example, the definitions of objects and their ability to be linked.
How to model by proximity
This approach aims to make things easy for business users to understand, through a model centered around "large objects". The idea is to differentiate the levels of proximity that objects can have with each other within a common grouping. This makes it possible to differentiate the different "islands of data" and thus facilitates a very business-oriented representation and governance area.
This approach can of course be deepened, for example by specifying the common groupings: you have customers who are individuals and legal entities; some information is common, some isn't. You can then identify these specific or common objects through sub-groupings.
How to model by urbanization
The idea is to rely on urbanization concepts, which give a cross-domain vision of the company. This makes communication easier while building on foundations that often already exist. This approach lets you:
- Simplify the deployment of the mapping by providing a shared framework and rules
- Identify data redundancies more easily and thus be able to address them
- Initiate or support the creation of a POS (a land-use plan), which lets you anticipate how data management will evolve
One rule is fundamental: the uniqueness of the blocks.
- A block belongs to a single district.
- A district belongs to one and only one zone.
- A block therefore belongs to one and only one zone and to a single district.
- A piece of data is under the responsibility of a single block.
- Relationships between blocks of the same district, or between different districts, must be made explicit through relationships: is a synonym of, generalizes, specializes, is used by...
This approach can help business users get closer to the business repositories they use every day.
- As far as possible, set aside technical implementations when creating the glossary: they are handled later through the following links.
- Has as system of record, for any type of object
- Concept with the tables of a database
- Business term with the fields of a database
With this proposal, we only deal with the functional zone, which corresponds to the functional description of the information system (IS). As a reminder, an urbanization logic contains 3 other zones:
- Business architecture: the mapping of the organization's business processes
- Application view: the different software components that make up the service layer of the IS
- Technical view: the technical elements that make the application view work, as well as information exchanges
These 3 views are described in the other DataGalaxy modules:
- Business-architecture processes and software components are described in the Usages module, which has dedicated objects
- The technical view is transcribed in the Dictionary module for databases, or in the Data Processing module for flows