Accélérer la

sortie de

[DataStage]

DataStage d’IBM, c’est un peu le vieux moteur diesel : puissant, robuste, mais coûteux à entretenir, complexe à régler et pas vraiment conçu pour les architectures Cloud modernes.

Pour compléter le portrait, les jeunes informaticiens n’ont pas vraiment envie de s’y frotter.

L’avenir de cet ETL semble aujourd’hui s’inscrire en pointillé.

Face à cela, l’option la plus couramment mise en œuvre pour les migrations DataStage reste le « copier-coller » (Lift & Shift) vers telle ou telle cible.

Et là, trois problèmes majeurs apparaissent :

Après 10, 15 ou 20 ans de développements, les flux DataStage ressemblent (peut-être ) à un énorme "plat de spaghettis" : dette technique, complexité accumulée… bon courage.
Migrer en mode "T&M", c’est long, c’est cher… et en plus, c’est incertain.
La technologie cible choisie, aussi moderne soit-elle aujourd’hui, finira tôt ou tard lestée de dette, de coûts de licence inflationnistes — en somme, presque un problème en devenir.

C’est là qu’{openAudit} notre logiciel intervient :
pour automatiser la migration vers un socle technique universel, mais aussi pour la faire précéder d’une véritable « cure de détox ».

3 étapes :

1. On allume la lumière !

[Cartographie]

On ne devine pas. On analyse.

{openAudit} scanne :

Les fichiers ISX,
Les Shared Containers,
Et même le fameux RCP (Runtime Column Propagation), etc.

Résultat : un data lineage complet, de la source — et potentiellement jusqu’au dashboard — sans rupture, rejoué en continu.
Un inventaire précis de ce qui se cache réellement dans les soutes, pour comprendre avant d’agir.

Quelques exemples d'output :

1 . Vue "Job Graph" dans DataStage

Comprendre le flux global du job -

Cette vue permet de visualiser le pipeline complet d’un job DataStage sous forme graphique.

Chaque nœud représente une étape du traitement (source, transformation, jointure, agrégation, table cible) et les liens matérialisent les flux de données.

C’est la vue de compréhension globale du job DataStage et de sa logique d’exécution.

2. Vue "Job Lineage" dans DataStage

Tracer chaque champ, de la cible jusqu’aux sources -

Cette vue présente la traçabilité descendante détaillée des données, champ par champ.

Elle permet de suivre l’origine d’un champ depuis la table cible jusqu’aux sources, transformation après transformation, en identifiant précisément les règles appliquées.

C’est la vue d’audit et d’explicabilité fine dans DataStage

3. Vue "Data Lineage multi techno"

Relier les technologies et comprendre les usages de l’information -

Une vue macroscopique et transverse des flux de données, au-delà de DataStage.

Elle relie les différents moteurs de transformation et usages métier au sein d’une interface unique, et met en évidence la consommation réelle de l’information.

C’est la vue holistique des flux et des usages de la donnée.

2. On se sépare d’une large partie des jobs [Rationalisation]

Pourquoi migrer ce qui ne sert plus ?

En croisant le data lineage avec l’usage réel issu des logs, {openAudit} permet d'identifier les « branches mortes », i.e. les flux qui "construisent" des données qui ne sont jamais exploitées.

Le constat : en moyenne, 40 à 60 % d’un patrimoine DataStage peut être supprimé avant même de commencer la migration.

3. On traduit en SQL intelligible, transposable

[Migration]

{openAudit} ne produit pas du code machine illisible.
Il traduit des logiques complexes (CDC, Before/After, Filtres, Transformations…) en un SQL standardisé, factorisé :

Chaque requête est commentée, reliée à son job, à son stage et à son projet DataStage d’origine.
Le code est à plat, lisible, explicable - du coup compréhensible par les équipes.
Quand une logique ne peut pas être traduite en SQL, elle est isolée dans une toolbox ouverte, clairement identifiée.
Même chose pour l’analyse des écarts et le double run : outillé, documenté, donc maîtrisé !