Hero UCT why data migration fails 1200x628

Pourquoi la migration de données échoue-t-elle si souvent?

Article

É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?

Elles sont mises en œuvre par des gens qui manquent de connaissances sur les systèmes et les affaires Les analystes d’affaires connaissent les systèmes, mais dans un modèle de développement classique, c’est le fournisseur ou les programmeurs internes qui mènent la barque; or ils n’ont pas les connaissances nécessaires.

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.

Les exigences système sont souvent vagues ou incomplètes Normalement, les exigences système liées à la migration des données sont répertoriées dans un dictionnaire de données, sous forme de tableau ou de feuille de calcul. Il est rare que des normes strictes soient en place pour éviter les ambiguïtés et contrôler l’exhaustivité et la clarté du code. Malheureusement, quand les exigences sont vagues et incomplètes, les erreurs d’implantation se multiplient.

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.

Articles associés

Data Migration Route 1200x630

Migration de données

Comment un assureur de premier plan a su migrer plus de 400 000 polices d’assurance vers un système central moderne

Cette étude de cas révèle comment Universal Conversion Technologies (UCT), filiale d'Equisoft, a réussi à migrer les données héritées d'un assureur vers un nouveau système cible.
Lire l' Étude de cas
Hero UCT why data migration fails 1200x628

Migration de données

Pourquoi la migration de données échoue-t-elle si souvent?

Les migrations de données échouent souvent parce qu'elles sont réalisées avec des méthodes traditionnelles. Découvrez les défis auxquels sont confrontés les assureurs lorsqu'ils migrent leurs données vers un système central moderne.
Lire l' Article

Migration de données

Libérer le plein potentiel de votre transformation numérique grâce à la migration des données

Animée par des spécialistes de la conversion de données de Celent et d’UTC, cette séance est une mine d’or d’information sur les pièges à éviter et les moyens de maximiser le RCI de votre parcours de modernisation.
Voir la Webdiffusion