De la source à la cellule du dashboard : Cartographier le SI pour le reconstruire intelligemment

 

De la source à la cellule du dashboard :     Cartographier le SI pour le reconstruire intelligemment

Dans les projets de transformation du SI, il y a une injonction qui revient sans cesse : « Il faut migrer ! » … vers le Cloud, vers des architectures modernes, vers des solutions plus agiles, etc.    On a vu éclore ces dernières années de nouvelles solutions data qui sont en train de tout balayer sur leur passage : on pense par exemple à Power BI pour la dataviz, à dbt pour la gestion des transformations ou à Snowflake pour le stockage : simples, efficaces, scalables, Cloud natives, souvent bon marché, etc. Quand on a décidé de passer à l’action,  quelques questions viennent à l’esprit : « qu'est-ce qu'il faudrait migrer au juste » ? « Et donc, qu’est-ce qu’on peut jeter  ? »  « Et comment reconstruire ce qui a de la valeur dans la cible sans tout casser ? » Ci-après, une approche basée en 1er lieu sur l'analyse en temps réel de tous les processus internes d'une entreprise.

Pour moderniser, pour migrer, il faudra nécessairement comprendre comment l’information circule, depuis les sources opérationnelles jusqu’à son exposition finale, colonne par colonne, jusqu’à la cellule du dashboard à laquelle accède le métier.   Et savoir à quoi sert (concrètement) l’information produite  ! Le constat est souvent assez étonnant...

Action #1 :  Inventorier tous les flux en continu, des sources jusqu’à la cellule du dashboard, avec un reverse engineering complet du SI

Dans les couches d’alimentation Il s’agira d’analyser les procédures stockées, les jobs ETL/ELT, les vues imbriquées, les transformations SQL encapsulées, les transferts FTP, les subqueries, les curseurs, etc.

Output ;  À chaque étape, le data lineage technique mettra en évidence les outils de transformation utilisés (comme des ETL, scripts, requêtes SQL…), la nature des traitements appliqués (filtres, agrégations, jointures, etc.) ainsi que l’enchaînement des opérations ou des flux (via des ordonnanceurs, scripts d'exécution, etc.) :

Dans la couche de data visualisation Il s’agira de pousser l’analyse jusqu’à la cellule d’un dashboard, même dans les environnements complexes multi-techno : analyse des règles de gestion embarquées dans les objets de dataviz, la couche sémantique intermédiaire, les expressions, les filtres, etc.

Output : Un data lineage dans la couche de data visualisation, qui permet de zoomer d’un champ source du DWH, jusqu’à la cellule à laquelle accède le métier. Ce data lineage est raccordé au data lineage dans les sources, pour avoir une vision complète d'un flux de données.

Action #2 :  Définir les degrés d’usage : savoir à quoi sert chaque flux d'alimentation, des sources opérationnelles, à la cellule du dashboard.

Il faudra analyser le stack technique principal pour connaître toutes les données consommées dans et en dehors des chaînes batch.

Les données consommées par des satellites (applications non « parsées ») seront également analysées pour identifier l'exhaustivité de l'information utile.

Cette double analyse sera paramétrée pour prendre en considération la cible métier : une information réglementaire peut être consommée de façon très périodique, tout en ayant une valeur ajoutée importante.

Combiner action #1 et action #2 :  Combiner le data lineage et l'analyse des usages, le combo gagnant pour transformer un système !

Remonter les flux pour isoler les chaînes inutiles : Le data lineage permet de remonter le pipeline depuis la donnée inutilisée jusqu'à la première table à l'origine d'une information consommée dans une autre branche. À partir de cet embranchement, il sera possible de supprimer la fraction de chaîne inutile sans incidence : nos différentes missions nous permettent d’avancer que 50 % des tables et traitements peuvent être éliminés en moyenne. Il en est de même (souvent bien au-delà) des dashboards… Go ! Dans le « reste à migrer », chaque flux, chaque dashboard peut être scoré en fonction de considérations internes. Cela permettra de hiérarchiser la migration de façon précise.

Migration automatisée vers le Cloud :  Le reverse engineering technique (continu) permettra de mettre à nu les chaînes de traitement (Jobs ETL/ELT, procédures dans les couches d’alimentation, règles de gestion dans la couche de data visualisation). Cette connaissance ultra-granulaire de la source, sa rationalisation en amont, permettront de reconstruire les flux intelligemment dans les technos cibles, dans les alimentations et dans la dataviz (en plus du template et de l'éventuelle couche sémantique).  Le pivot sera largement opéré via du SQL. Ce sera une vraie porte ouverte à la transformation du SI.

Migrer les alimentations :  Scope technologique adressé par {openAudit} :  Migrer la couche de dataviz :  Scope technologique adressé par {openAudit} :

Comprendre pour mieux transformer : c’est tout le rôle du data lineage et de l’analyse des usages. Avec {openAudit}, il est possible de disposer d’une solution robuste et automatisée pour cartographier, rationaliser et sécuriser les projets de modernisation SI — de la première colonne jusqu’à la dernière cellule du dashboard. Nos projets de diagnostic et de migration sont proposés au forfait.