One of the major challenges of the glossary is to provide a representation of the data model that
- Makes sense to business users
- Is understandable and valuable to all
There are several constraints to take into account when building the glossary
- Constraints related to your project;
- The use case: modelisation is often different whether you are working on a BI, DataGovernance or even DataHub project
- The maturity of the organization in terms of data management
- Constraints related to the platform: the definitions of objects and their ability to be linked, for example.
There is no perfect modeling solution, but several approaches depending on your needs/use cases.
We present below two approaches: by proximity and by urbanization
The proximity approach
This approach objectives is to make it easy for business users to understande thanks to a modelisation centered around "large objects". The idea is to differentiate the different 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 facilitate 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, others not. You can then identify these specific or common objects thanks to sub-groupings.
The urbanization approach
The idea is to rely on the concepts of urbanization allowing to have a cross domain vision of the company. This way, communication is easier while relying on bases that are often pre-existing.This approach enables to
- Simplify the deployment of the cartography by providing a shared framework and rules
- Identify data redundancies more easily and thus be able to process them
- To initiate or support the constitution of a POS, i.e. a land use plan, allowing to anticipate the evolution of data management
However, the focus is no longer on the data but rather on the business repositories.
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 belongs to one and only one zone and belongs to only one district
- A data is under the responsibility of a single block
- Relations between blocks of the same neighborhood or between different neighborhoods must be made explicit thanks to relationship: is a synonym of, generalizes, specializes, is used by...
This approach can allow business users to get closer to the business repositories used on a daily basis.
- Make, as much as possible, abstraction of the technical implementations during the creation of the glossary: they will be addressed later thanks to the following links
- A for registration system for any type of object
- Concept with the tables of a database
- Business term with the fields of a database
With this suggestion, we only deal with the functional area that corresponds to the functional description of the IS.
As a reminder, an urbanization logic contains 3 other zones
- The business architecture which corresponds to the mapping of the organization's business processes
- The application layer: i.e. the different software bricks that make up the service layer of the IS
- The technical view: i.e., the technical elements that enable the application vision to function, as well as information exchanges
These 3 views are to be described in the other modules of DataGalaxy :
- The business architecture processes as well as the software bricks are to be described in the usage module which has dedicated objects
- The technical view will be transcribed in the catalog module for databases or in the processing module for flows