Sortir de [DataStage] - et conserver ses processus métier

Sortir de [DataStage] - et conserver ses processus métier Quand on parle de quitter DataStage (ou autre ETL), on pense souvent "migration technique". C’est certes un sujet épineux (!), mais il est réducteur. En réalité, le véritable enjeu est (surtout) ailleurs.   Schématiquement, DataStage (ou autre ETL) contient deux choses essentielles au cœur de l’intelligence collective d’une entreprise  : Des données qu’on appellera « patrimoine informationnel », Des flux de transformations qui portent les règles métier et transforment ces données, qu'on appellera « patrimoine fonctionnel ».   Le risque d’une migration mal préparée est simple : On va changer d’outil… mais on va perdre ou dégrader toute l’intelligence construite de longue date dans les processus métier. Cartographier les données et les transformations La première étape consiste donc à proposer à tous d’appréhender ces deux patrimoines (informationnel et fonctionnel) avant tout projet de migration. 1- Comprendre les données : le « patrimoine informationnel » Nous proposons pour cela une cartographie des flux et des dépendances, à partir d’un point de donnée, pour visualiser les sources amont, les tables intermédiaires et les usages aval - toutes technologies confondues (DataStage, autres ETL /ELT, langages procéduraux, etc.). Cette vue d’ensemble permet de reconstituer le patrimoine informationnel réel, au-delà d’un outil particulier.   2- Comprendre les transformations : le « patrimoine fonctionnel »  Nous proposons pour cela une cartographie des transformations et des règles métier qui permet de naviguer dans les processus et de zoomer dans un nœud de transformation (ici dans un job DataStage) afin de visualiser les paramètres, les règles appliquées, les dépendances, etc. Les règles sont ainsi inventoriées, documentées et reliées aux flux de données qui les portent.  Sortir de DataStage, pour aller vers quoi ? Une fois ces processus identifiés, il paraît pertinent de les traduire dans un langage ouvert, lisible par les équipes : le choix du SQL s’impose. Pourquoi ? C’est un langage universel - compris par la plupart des équipes data, C’est un langage pérenne - présent dans toutes les plateformes modernes avec quelques adaptations mineures, C’est un langage portable - les processus ne sont du coup plus enfermés dans un outil. En ces temps de tension géostratégiques, ça a du sens (« interopérabilité »).           Avec le SQL, on peut reproduire fidèlement les logiques DataStage : filtres, transformations, jointures, CDC, gestion des before/after, contrôles…sans perte de règles métier, du 1 pour 1. film démo (5') : cartographier ses flux, sortir de DataStage  Un ROI rapide et concret Mettre en lumière les flux et les processus DataStage ne sert pas seulement à préparer une migration. Les bénéfices sont immédiats : Suppression des traitements devenus inutiles, Simplification de l’architecture data, Diminution des coûts d’exploitation et…. de licences 😊.   Si l’objectif est de sortir de DataStage, alors le ROI devient considérable : suppression partielle ou totale d'une dépendance technologique, des processus plus lisibles et un socle ouvert pour les architectures data modernes d’aujourd’hui et de demain.   Migrer efficacement : Plan de Projet sur 28 semaines (indicatif)  Avant de parler migration, il faut d’abord rendre visible ce que DataStage contient réellement : Les données sources sollicitées, les données cibles alimentées (patrimoine informationnel),  les flux et processus métier qui les transforment. Une fois révélés, ces processus peuvent être pérennisés (s’ils ont de la valeur) et portés vers des architectures plus ouvertes pour libérer l’intelligence qui s’y trouve enfermée. Nous pensons que le SQL est une cible particulièrement adaptée. PS : idem pour Genio, Talend, BODS, Informatica, etc. Voir aussi - article de blog  Migrer de SAP BO vers GCP Looker - Garder ses données en source ? Possible ?