Échec de la migration des données : une question de méthode? #
La plupart du temps, la migration de grands volumes de données se fait soit au moyen de programmes sur mesure, soit au moyen de solutions ETL (extraction, transformation et chargement), ce qui nécessite toujours un certain travail de développement logiciel. Dans le premier cas, la solution est développée à partir de zéro. Dans le second, il faut créer les interfaces et y ajouter une logique de transformation. Et dans les deux cas, les méthodes informatiques standards sont privilégiées. Malheureusement, ces méthodes échouent trop souvent lorsqu’elles sont appliquées à la migration des données. Pourquoi?
Leur réussite repose sur des exigences système rigides et prédéfinies qui sont inatteignables #
Bien souvent, le système source est vieux, lourd et complexe, et les compétences que demanderait une analyse de la configuration requise sont des denrées rares. D’ailleurs, il arrive souvent que les documents qui accompagnent le système soient médiocres, dépassés ou manquants. Certaines exigences viennent effectivement de personnes compétentes qui ont effectué d’autres projets similaires auparavant, mais comme les migrations de données sont peu fréquentes, les ressources compétentes manquent au moment de définir des exigences pourtant essentielles. Tout cela fait en sorte qu’une bonne partie de la configuration requise doit être revue à mi-parcours.
Il en résulte un cycle de raffinement des exigences qui s’avère imprévisible, ingérable et sans fin #
Le problème de la boucle infinie survient parce qu’avec les méthodes traditionnelles, il est difficile d’intégrer des exigences mises au jour en plein milieu du cycle de vie. Une nouvelle configuration entraîne inévitablement des ajustements de conception et d’implantation. À leur tour, ces changements et les tests supplémentaires qu’ils nécessitent révèlent de nouvelles exigences, ce qui influence encore l’implantation, et ainsi de suite.
Cette boucle sans fin est difficile à gérer par les méthodes traditionnelles, sans compter qu’elle entraîne des coûts.
Elles ne permettent pas l’évolution conjointe des exigences de migration des données avec les modifications fonctionnelles du système cible #
Il existe une codépendance naturelle entre la migration des données et les modifications fonctionnelles du système cible : les vraies données de production, qui ne sont disponibles qu’après migration, entraînent une reconfiguration qui influence ces modifications. Ces dernières entraînent à leur tour une reconfiguration qui influence une fois de plus la migration. Pendant ce temps, chaque équipe fait du sur place en attendant qu’une autre (qu’elle blâme inévitablement) termine son travail.
Elles ne s’accompagnent pas d’outils et de moyens d’évaluation du succès #
Chaque migration de données a ses bons côtés et ses moins bons côtés. Mais dans un grand ensemble de données, sans les bons outils, il est difficile de séparer le grain de l’ivraie.
Les documents de conception liés à la migration de données sont inutilisables dans les pas-à-pas qui font habituellement partie du processus #
Pour mettre à jour manuellement les documents en même temps que les exigences système, il faut beaucoup de main-d’œuvre. C’est pourquoi plus le cycle de vie avance, moins les documents manuels sont à jour. D’un autre côté, les documents générés automatiquement contiennent souvent du code brut ou d’autres types de contenus inutilisables, et ils sont parfois présentés dans un format inexploitable. Or quand les documents sont inexacts ou inutilisables, les pas-à-pas ne sont pas aussi efficaces.
Autres problèmes avec les solutions ETL #
Comme les interfaces ETL sont souvent conçues par les mêmes techniques que les programmes personnalisés, les écueils sont les mêmes. Mais les solutions ETL souffrent de problèmes supplémentaires qui peuvent contribuer à des échecs éventuels. Pourquoi?
Leurs nombreuses interfaces sont développées au moyen des mêmes méthodes prédisposées à l’échec #
Il en est question plus haut. Quand ces techniques sont appliquées à la migration des données, même à l’aide d’outils ETL, elles peuvent échouer.
Elles ne sont pas compatibles avec les technologies héritées #
Les solutions ETL ne sont pas compatibles avec les fonctionnalités patriarcales comme les routines entrées-sorties d’extraction et de chargement de données, ou encore avec les routines de conversion, comme les fonctions sur mesure de calcul de dates. Par ailleurs, ces solutions ne prennent pas en charge les formats de stockage de données patrimoniales ou sur mesure qui sont monnaie courante lorsqu’il s’agit de vieilles applications.
Elles requièrent une infrastructure supplémentaire coûteuse #
Il existe toutes sortes de produits « médians » qui permettent une bonne communication entre un système patriarcal et de nouvelles plateformes. Ces produits ont souvent besoin d’une solution ETL pour accéder aux bases de données et aux dossiers hérités. Mais l’ajout de cette composante au système nécessite une expertise pointue et coûte assez cher, quand on considère que le système risque d’être mis hors service sous peu.
Elles impliquent un mélange de composantes modernes et patriarcales ainsi que des étapes manuelles #
Même quand le bon produit médian est disponible, les vieux fichiers et les formats sur mesure font souvent en sorte qu’il faut aussi développer une composante assimilable à l’ancien système patriarcal au moyen d’un autre langage et d’une autre technologie aux fins de l’extraction des données. Le mélange de technologies est une solution complexe qui requiert un bon ensemble de compétences et d’environnements de développement ainsi qu’un effectif considérable. Tout cela a pour effet de multiplier les canaux de communication, les heures de mise en œuvre, les coûts… et les risques d’échec.
