Conceptual Data Layer Mapping from Collibra to LeanIX

Introduction

The conceptual data layer is the highest level of organization in Collibra's Data Catalog operating model. It consists of Line of Business, Data Domain, and Data Concept. LeanIX Collibra integration allows you to map the conceptual data layer from Collibra to data object fact sheets in LeanIX.

To learn more about the conceptual data layer, see Conceptual data layer.

Configuring Synchronization of Conceptual Data Layer

Before configuring the mapping, ensure that the Maximal Hierarchy Level of your data object fact sheet type is set to an appropriate level. This setting is necessary for creating data object fact sheets through the Collibra integration.

The default setting in meta model configuration is 3, but Collibra hierarchies typically exceed this level. Therefore, it's crucial to adjust it to match the hierarchy level you have for your data in Collibra. If the Maximal Hierarchy Level is set lower than the hierarchy level you have in Collibra, it will read to errors during the synchronization run.

The maximal hierarchy level is configured in the meta model configuration. To learn how, see Meta Model Configuration.

Choosing the Source Communities

To configure synchronization of the conceptual data layer from Collibra to data object fact sheets, begin by selecting the appropriate communities from Collibra.

1. In the Collibra Integration Configuration area, go to the Conceptual Data Layer Mapping tab.

2. Set the mapping to active by selecting the checkbox against Active.

3. Choose the needed communities from the drop-down menu provided.

   

Hierarchy and Naming

The integration will scan the defined communities for all sub-communities, domains, and assets and will create a data object fact sheet for each of them using the following rules:

• The Name of the created fact sheet in LeanIX will match the name of the corresponding object in Collibra.

• The Display Name of the fact sheets will be derived from the following hierarchy:

  • For each sub-community, the corresponding fact sheet is suffixed with "relToParent" relation to its parent community.
  • For each domain, the corresponding fact sheet is suffixed with "relToParent" relation to its community.
  • For each asset, the corresponding fact sheet is suffixed with "relToParent" relation to its domain.

  

Category of the Data Object

The integration will try to match the data object fact sheet’s category with the asset type used in Collibra. If a match is found, the Category field is populated accordingly. Otherwise, it will remain empty.

Filtering Assets by Type and Status

The integration enables filtering for asset types (subtypes of either Business Asset or Data Asset) to be mapped to your LeanIX workspace, as well as specifying which statuses will be considered. Only assets that have at least one of the selected types are mapped. If no status is chosen, all statuses are considered.

Mapping Fields

The integration allows you to map attributes on your assets from Collibra into fields on your data object fact sheets. To learn more about supported attribute types and how they are mapped, see Supported Field Types for Conceptual Data Layer Mapping. If you choose a single or multi select attribute on both ends, you can further specify how values are mapped.

Mapping Responsibilities to Subscriptions

You can map responsibilities from a mapped community, domain, or asset of Collibra to subscription roles in LeanIX. In the Role Mapping field, choose any roles available in Collibra and map them to relevant subscription roles of the type Responsible for the data object fact sheet type.

You can also automatically create users who exist in Collibra but not in LeanIX by selecting the Create Users check box.

The integration will only consider implicit responsibilities and ignore inherited ones. It will also resolve user groups and translate them to the corresponding individuals.

Mapping Relations Between the Assets

If you use the "groups" relation between your assets, you have the option to reflect it as many-to-many relations in data object fact sheets. For instance, you can map it to the requires/required by relation in LeanIX.