Comment éviter que votre SI migre… pour mieux se complexifier ?

Dans les projets de transformation du SI, une injonction revient en boucle : « Il faut migrer ! » Vers le Cloud, vers des architectures modernes, vers des solutions plus agiles, plus simples, plus scalables… bref, vers mieux !  Ces dernières années, on a vu apparaître des outils qui ont rebattu les cartes de la data : Power BI, Looker, Strategy pour la dataviz, dbt pour les transformations, Snowflake ou BigQuery pour le stockage. Liste non exhaustive... : des solutions cloud-native, légères, efficaces, accessibles (souvent) - et qui accélèrent l'obsolescence des anciennes architectures.    {openAudit}, notre logiciel, permet d'opérer ces migrations de façon ultra-efficace en automatisant l'essentiel des tâches.    Mais sur le temps long, chaque migration est en réalité un point d'étape. La pire des choses serait de laisser dériver d'emblée le système cible, ce qui réduirait à néant rapidement des années de travail !  Il conviendra donc d'opérer une série d'actions qui permettront aux équipes IT et métiers de conserver à long terme un système cible optimal et interopérable.

Action #1 : Utiliser le SQL comme point de pivot lors des migrations, et le pérenniser !

L'ensemble des migrations automatisées que nous conduisons avec {openAudit} repose sur un reverse engineering technique continu qui permet 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 permettra de reconstruire les chaînes de traitement intelligemment dans les technos cibles, avec nos différents moteurs de migration, en utilisant massivement le SQL comme output. C'est le cas dans les alimentations, mais aussi pour la couche de dataviz pour laquelle {openAudit}  permettra par ailleurs de factoriser l'intelligence et de la concentrer dans les bases. Les réponses seront ajustées pour permettre une opérabilité avec les technos cibles.    Pourquoi nous paraît-il capital d'avoir recours au SQL dans ce cadre ?  Le SQL offrira une efficience maximale du système cible en profitant de la puissance des bases de données modernes. Le SQL garantira une maintenabilité optimale : la majorité des ingénieurs data connaissent le SQL, d'autant que nos moteurs de migration génèrent du SQL à plat, très intelligible.

Surtout, le SQL, qui sert de point de pivot dans la migration, permettra de garantir une interopérabilité technique future, quasi native en lien avec la faible dépendance aux technologies propriétaires. Cela évitera un "mariage forcé" ad vitam aeternam avec telle ou telle techno...

Action #2 : Construire aussitôt après migration une cartographie dynamique des flux

Pour contrôler le déploiement d'un système, il faudra immédiatement qu'{openAudit} analyse en continu toutes les couches techniques du système cible. Cela permettra de délivrer une cartographie intelligible et de partager la compréhension du Système cible à tous.   Côté alimentation : procédures stockées, jobs ETL / ELT, pipelines SQL, transferts de fichiers, scripts, batchs, etc. ; Côté restitution : requêtes, couche sémantique, intelligence (expressions calculées dans les outils BI).    On identifiera les flux, les transformations, les outils… jusqu’à la cellule visible dans le dashboard final !

Le métier et les équipes IT auront ainsi d'emblée les outils pour partager la compréhension fine et continue du système cible, sans avoir à s'en remettre à tel ou tel expert.

Action #3 : Se mettre immédiatement à rationnaliser (en continue) le système cible en écartant les objets inutiles.

On va adjoindre à ce data lineage l'analyse des usages dans le système cible : Quels objets (dashboards, tables) sont réellement exploités dans le système cible, quand ? Par qui ? À quelle fréquence ? Dans quels contextes ? Quelle est la valeur métier de chaque chaîne de traitement (réglementaire, pilotage…) ?   Cela inclut : L’identification des données utilisées dans les chaînes critiques, mais aussi des flux consommés par des applications satellites ou rarement exploités ; La prise en compte des usages faibles mais stratégiques (ex : données peu consultées mais réglementaires).   En combinant lineage + usage, on obtiendra une vision claire de : Ce qu’il faudra conserver sur un temps long : les flux essentiels, les "autoroutes de l'information", les dashboards clés ; Ce qui pourra être supprimé au fil de l'eau : "branches mortes", traitements inutiles, tables orphelines, dashboards jamais consultés.

Ainsi on permettra au système cible de rester aussi simple que possible, ce dans le temps. Cela aura des incidences positives à de nombreux égards : maintenance, qualité de l'information, coûts contenus.  .

En résumé : notre idée est de permettre la mise en œuvre d'un système cible simple, rationalisé, documenté, piloté et nativement interopérable. En automatisant tout le processus.    La migration deviendra un levier de simplification, autant qu’un projet technique à très long terme, visant à reprendre réellement le contrôle de sa data stack !

Contact