{openAudit}, le data lineage et les usages de l'information pour transformer les SI

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 f...

  Accelerate the exit [  DataStage  ]   IBM's DataStage  is  a bit like an old diesel engine  : powerful, robust, but expensive to maintain, complex to configure  , and not really designed for modern cloud architectures. To complete the picture, young computer scientists don't really want to get involved in it. The future of this ETL seems uncertain at present.   Faced with this, the most commonly implemented option for DataStage migrations  remains "copy-paste" (Lift & Shift) to one target or another.   And here, three major problems arise: After 10, 15 or 20 years of development,  DataStage flows look (perhaps  ) like a huge "plate of spaghetti":  technical debt, accumulated complexity... good luck. Migrating to "T&M" mode is long, it's expensive... and on top of that, it's uncertain. The chosen target technology, however modern it may be today, will sooner or later end up burdened with debt, inflationary li...