Dans notre précédent article, nous avons décomposé le Data Lineage en présentant les différentes typologies de lineage (couche physique, couche métier et couche sémantique) et les différents niveaux de granularité (valeurs, champs, datasets, application).
Nous allons vous présenter ici notre approche matricielle pour concentrer vos efforts et vos ressources là où la valeur du Data Lineage est la plus forte pour vos différentes équipes (métiers).
Notre matrice centrée sur les métiers
Pour bien appréhender l’approche Zeenea du data lineage centrée sur les métiers au sein de l’entreprise, nous vous invitons au préalable à lire notre article sur la décomposition du data lineage.
Les différents profils métiers dans l’organisation
Nous avons classé les populations qui souhaitent exploiter la valeur du Data Lineage dans une organisation en 4 grandes catégories :
- IT : ce sont les ingénieurs et architectes chargés de développer et de maintenir l’infrastructure, les flux et les applications data.
- Analytique : ce sont les équipes chargées d’analyser les données, de construire des indicateurs, des tableaux de bord, des rapports, etc.
- Métier : ce sont tous les acteurs chargés d’imaginer puis d’opérer les usages et applications fonctionnelles autour des données – chefs de projets, chefs de produits, analystes métier, etc.
- Conformité : ce sont les équipes responsables de la conformité réglementaire, de la sécurité, du contrôle interne, etc.
Valeur ajoutée du Data Lineage en fonction du profil métier
La matrice suivante synthétise la valeur ajoutée apportée par le Data Lineage pour les différentes combinaisons typologie, granularité et profil métier.
À l’observation de cette matrice, et sachant que le lineage de niveau supérieur peut être déterminé à partir de celui du niveau inférieur, il est tentant de se fixer comme objectif de gérer le lineage au niveau champ : c’est à ce niveau que la valeur ajoutée est la plus élevée, et il permet de produire automatiquement le lineage sur les niveaux supérieurs.
Les choses, bien sûr, ne sont pas si simples !
Si le bénéfice du lineage champ à champ est indiscutable, il présente un inconvénient majeur : son coût. Quel que soit la couche de lineage considérée, le coût de production et de maintenance va en effet dépendre principalement de deux variables :a volumétrie (nombre d’objets pris en compte et nombre de liens entre eux), et la capacité à automatiser la récupération et la mise à jour de ces informations.
Sur ces deux aspects, le lineage champ à champ présente clairement le profil le plus défavorable..
Les limites du lineage champ à champs: Une volumétrie gigantesque
Concernant la volumétrie, on comprend facilement que le nombre de champs matérialisés dans un système d’information même de taille modeste atteint facilement plusieurs dizaines de milliers, quand ce n’est pas des centaines de milliers voire des millions. Maintenir l’information de lineage manuellement sur un tel volume d’objets n’est pas raisonnable. La seule voie praticable est donc celle de l’automatisation massive.
Des possibilités d’automatisation limitées
En théorie, le lineage technique champ à champ peut être automatisé en inspectant les différentes étapes du traitement, depuis la capture initiale de la donnée jusqu’à ses usages finaux. En pratique, cette automatisation se heurte à la très grande hétérogénéité des solutions d’intégration et de traitement des données. Certains fournisseurs proposent des solutions pour réaliser ces opérations.
Nous avouons de ne pas y croire, pour deux raisons : d’une part le reverse-engineering est une opération fragile, dont la fiabilité ne peut être garantie à 100% ; d’autre part la panoplie de solutions et de langages utilisés dans les pipelines de données est trop vaste, et l’innovation constante dans ce domaine rend difficile pour une solution commerciale de garantir une couverture intégrale de toutes les technologies mises en œuvre dans un environnement donné.
Une granularité au champ est séduisante, mais hors de portée en pratique.
Notre approche pour une optimisation du Data Lineage
Le pivot : la couche physique au niveau des datasets
Si l’on reprend la matrice présentée plus haut, il apparaît que la valeur du lineage au niveau dataset est très proche de celle du lineage champ à champ.
Pour les profils IT, métier et analytique, elle est dans la plupart des cas équivalente. Le principal écart concerne la conformité. Pour la plupart des normes, l’exigence de documentation du lineage concerne des champs. Mais la conformité ne concerne pas toutes les données de l’organisation, uniquement celles que l’on qualifie de critical data elements (CDE).
Les CDE sont de différentes natures – données personnelles, données sensibles, données de risque, etc. Mais elles possèdent l’intérêt de ne représenter qu’une infirme portion des données totales – souvent quelques dizaines ou quelques centaines de champs dont il faut fournir le lineage aval ou amont.
Partant de là, voici l’approche générale qui a notre préférence pour la couche physique :
- Focaliser l’effort sur le lineage au niveau dataset, en visant l’automatisation la plus poussée possible.
- Associer les datasets (et autres objets physiques de même niveau) aux applications auxquelles ils sont rattachés – cette opération est généralement facile à automatiser, elle est globalement stable dans le temps, et peut au pire être gérée manuellement dans le catalogue.
- Compléter localement par du lineage champ à champ ciblé sur les CDEs – on pourra automatiser quand c’est possible, mais également s’appuyer sur les processus de revue périodique courant dans les dispositifs réglementaires.
Lineage des couches métier et sémantique
Pour ce qui est des autres couches (métier et sémantique), l’approche est sensiblement différente : l’automatisation n’est guère possible. Aucun miracle, donc : le lineage métier et le lineage sémantique devront probablement être gérés à la main.
Pour ce qui est de la couche métier, nous proposons plutôt une approche top-down. Cela signifie que le premier effort devrait être consacré à définir le lineage métier au niveau application. Les datasets et champs contenus dans les applications hériteront de ce lineage métier. On devrait également être en mesure de définir le lineage métier à un niveau plus fin, mais uniquement quand un cas d’utilisation le justifie.
Pour la couche sémantique, les choses sont encore un peu différentes. En effet, un effort spécifique est nécessaire pour construire le glossaire. Cet effort est de l’ordre de la modélisation, et sera plus ou moins considérable selon la taille du corpus de données, et l’existence préalable de modèles pouvant être importés ou intégrés au catalogue.
Le point d’ancrage naturel du modèle sémantique sur la couche physique du lineage se fait au niveau des champs. Or une nouvelle fois, l’automatisation est peu praticable – vous ne possédez probablement pas de système référençant de façon systématique le sens de chacun des champs de tous vos systèmes.
L’association entre les champs de la couche physique et les définitions de la couche sémantique devra donc être faite manuellement, ce qui représente une nouvelle fois une tâche titanesque si l’on cherche à le faire de façon exhaustive.
Conclusion
Le Data Lineage est un sujet complexe, qui peut être décomposé en couches (physique, métier et sémantique) et en plusieurs niveaux de granularité (valeur, champ, dataset, application).
La valeur du lineage peut alors être représentée sous la forme d’une matrice très dépendante des cas d’usage, et des populations qui l’exploitent. Le coût de production et de maintenance de l’information de lineage est alors fonction de la capacité d’automatisation, et de la volumétrie d’objets au niveau considéré.
Pour en savoir plus sur les bonnes pratiques du Data Lineage, téléchargez dès maintenant notre eBook : Tout ce que vous avez toujours voulu savoir sur le Data Lineage !
