Le département de développement logiciel de mon entreprise est confronté au problème que les migrations de données sont considérées comme potentiellement dangereuses, notamment pour mes managers.
Le contexte est que nos clients utilisent une grande quantité de données de mauvaise qualité . Les raisons de cela ne sont que partiellement liées à la qualité de nos logiciels , mais plutôt à l'historique des données: la plupart d'entre elles ont été migrées à partir des systèmes précédents , certains bogues ont provoqué des incohérences (principalement commerciales) dans les enregistrements de données ou des erreurs de saisie par accident sur le côté client (ce que notre logiciel a permis par erreur).
Les contre-arguments les plus importants de mes gestionnaires sont que les données erronées peuvent se transformer en données encore pires , les problèmes de données peuvent réveiller certains gestionnaires chez le client et certains processus du côté du client peuvent ne plus fonctionner parce que leurs processus sont quelque peu adaptés à notre système.
Personnellement, je considère les migrations de données comme partie intégrante du développement logiciel et que la migration des données peut être vue vers les données ce que le refactoring est un code. Je pense que la migration des données est un élément essentiel pour créer des logiciels qui évoluent . Sans cela, il faudrait créer un logiciel douloureux qui contourne quelque peu une mauvaise structure de données.
Je te demande:
- Que pensez-vous de la migration des données, en particulier pour les cas réels et pas seulement du point de vue d'un développeur?
- Avez-vous des arguments contre les opinions de mes managers?
- Comment votre entreprise gère-t-elle les migrations de données et les difficultés qui en découlent?
- Y a-t-il d'autres pensées intéressantes qui appartiennent à ces sujets?
la source
Réponses:
Les migrations de données sont mon pain et mon beurre et le nettoyage des données est en effet une question extrêmement importante. L'une des stratégies que nous utilisons pour migrer 100% des données de nos clients est les outils de pré-migration de nettoyage asymptotique des données.
Cela signifie développer des dizaines de contrôles d'intégrité des données (principalement des requêtes SQL).
Échange d'outils de nettoyage avec le client (puisque ce sont ses données, nous concevons les utilitaires de patch, il les valide et les exécute).
Affiner l'outil au fil des itérations et atteindre une qualité mesurable soutenue par des KPI dès que possible.
Vérification de la cohérence des données une fois la migration terminée. Cela aide à prendre une décision GO / NOGO le jour J.
Au final, la migration des données est un exercice extrêmement bénéfique qui doit se produire après 3 à 5 ans.
Il permet de renforcer la capacité de la plateforme à soutenir les affaires.
Il permet de rationaliser la base de données.
Il prépare la plate-forme informatique pour les outils commerciaux de prochaine génération (ESB / EAI, portails, plates-formes Self-Care, reporting et data mining, vous l'appelez).
Il réorganise les flux de données de bricolage entre plates-formes qui se sont accumulées au fil des ans d'une manière «temporaire» rapide et sale pour répondre aux «besoins urgents».
Par-dessus tout, cela permet à l'équipe de production informatique de mieux connaître sa plate-forme et de favoriser des attitudes de «pouvoir». Ces types d'avantages sont difficiles à mesurer, mais lorsque vous rencontrez de nombreux clients, cette considération devient évidente. Les entreprises fuyant les migrations restent au niveau suivant, les audacieuses en tête.
C'est un peu comme lorsque le sous-sol de votre maison est encombré de bois. Un matin, vous devez tout retirer, ne remettre que ce dont vous avez besoin et jeter le reste. Après cela, vous pouvez réutiliser votre sous-sol ;-)
Une autre considération fondamentale est que de nos jours, les attentes des clients sont toujours en mouvement, comme dans "les clients sont toujours plus exigeants". De sorte qu'il y aura toujours une proportion importante de concurrents d'une entreprise donnée à l'affût de ces nouvelles tendances avec l'intention évidente d'augmenter leur part de marché. Ils y parviendront en adaptant leur offre pour rester fidèle à la tendance, voire la conduire, ce qui implique une réingénierie métier constante. Si votre plate-forme informatique est trop rigide, ce sera un frein à votre propre aptitude à épouser ou à précéder les tendances du marché de votre propre côté et, finalement, à maintenir votre propre part de marché. En d'autres termes, dans un marché en mouvement, l'inertie est une recette pour la non-pertinence.
En revanche, une migration des données vers un système plus récent déploiera un outil de productivité plus moderne et plus polyvalent, tirant le meilleur des technologies plus récentes, plus attrayantes pour les employés et cela, à son tour, contribuera à soutenir ou même à diriger le processus d'innovation interne de l'entreprise , garantissant ou augmentant ainsi sa part de marché relative.
Les considérations ci-dessus ne répondent en fait qu'à la moitié de la question posée dans le titre "Migration des données - dangereuse ou essentielle". Oui Les migrations de données sont essentielles, mais sont-elles également dangereuses? De ce fait, beaucoup de choses dans l'informatique sont alors dangereuses. Par définition, tout ce dont les enjeux sont élevés est dangereux; surtout si vous ne prenez pas la question au sérieux. Mais c'est en fait le modèle le plus courant en informatique. Ne pas prendre au sérieux les centres de données, la haute disponibilité ou la tolérance aux catastrophes est dangereux.
Cela signifie-t-il que les entreprises d'aujourd'hui devraient se retirer de ces piliers du paysage informatique d'aujourd'hui? Sûrement pas !
Pour faire valoir votre point de vue en plaisantant, vous pourriez affirmer que «voler est dangereux si vous n'utilisez pas un avion fabriqué par des professionnels». C'est la même chose pour les migrations de données. Lorsqu'il est exécuté et conduit par des professionnels, il n'est pas plus dangereux que de voler dans un avion bien conçu et bien exploité. Et le retour sur investissement est dans la même proportion par rapport aux moyens de transport terrestres.
Confiées à des professionnels, la plupart des migrations sont des succès bien maîtrisés et le taux d'échec + abandon est extrêmement faible.
Vos managers devraient être amenés à se demander "Alors que la plupart des entreprises réussissent des projets de migration de données, qu'est-ce qui rendrait notre entreprise si différente qu'elle connaîtrait un échec? Et peut-elle s'en tirer sans?"
la source
Alain a donné une excellente réponse en termes d'importance du nettoyage des données pour le succès du projet de migration de données et la justification de la migration de données. Je voudrais cibler uniquement les préoccupations spécifiques de votre manager.
À mon avis, il ne s'agit pas de savoir s'il faut faire la migration des données ou non, mais de savoir quand le faire. Votre responsable a tout à fait raison de dire que vos données ne sont plus uniquement les vôtres et que les clients finaux ont déjà construit leurs procédures autour de celles-ci. Cependant, cet état ne changera pas à l'avenir . Tôt ou tard, la mauvaise qualité des données deviendra un facteur inévitable de ralentissement de votre entreprise et vous serez obligé de faire la migration. Faire cela sous pression et avec des délais serrés pourrait conduire à des décisions sous-optimales. En outre, pensez à l'expertise que vous avez maintenant et que vous aurez dans 2 à 3 ans. Et si des personnes qui comprennent vos données quittent l'entreprise? Êtes-vous sûr que la documentation que vous avez est adéquate?
Peut-être que la migration n'est pas nécessaire maintenant, mais votre responsable doit au moins avoir une vision du moment exact où la migration sera effectuée.
la source
Je travaillais pour une compagnie d'assurance et je participais à la migration des données pour le système principal. Eh bien, il y en avait au total 4 fois. Alors, voici mes commentaires:
Dans mon cas, la migration des données est un must, car par règlement, nous devons conserver les données pendant au moins 10 ans, et nous ne pouvons pas nous permettre de soutenir un système double à long terme. L'autre raison est que les utilisateurs s'attendent à pouvoir continuer leur travail avec la nouvelle application. S'ils ne peuvent pas trouver l'élément sur lequel ils travaillent, votre application est mauvaise et encore pire lorsque les données ne sont pas correctes.
Eh bien, la migration des données est une horrible bête et elle est réelle, alors avouons-le. Il est risqué mais peut être minimisé en le traitant plus tôt et avec soin. À titre indicatif, quatre grands processus doivent être pris en compte dans la migration des données:
Événement avec un plan minutieux, la merde arrive! Un groupe de travail spécial devrait être prêt à traiter les problèmes liés à la migration.
la source
1) Que pensez-vous de la migration des données, en particulier pour les cas réels et pas seulement du point de vue d'un développeur?:
La migration est une partie essentielle du développement des systèmes. Si vous remplacez partiellement ou entièrement d'anciens systèmes, la migration est une réalité, que la direction le veuille ou non. Si les données existantes sont mauvaises, elles se refléteront mal sur votre nouveau système. Il est donc extrêmement important d'avoir une bonne stratégie de migration.
2) Avez-vous des arguments contre les opinions de mes managers?
Oui, la migration est risquée, mais c'est aussi une réalité de la vie, alors faites-y face. Et traitez-le le plus tôt possible.
3) Comment votre entreprise gère-t-elle les migrations de données et les difficultés qui en découlent?
Mon entreprise a, avec un succès croissant, impliqué activement les clients dans le processus de migration. Nous examinons les données existantes du mieux que nous pouvons au tout début du projet et encourageons le client à améliorer la qualité des données avant de commencer la migration. Parfois, nous l'exigeons.
4: Toute autre pensée intéressante qui appartient à ce sujet
Mon conseil est de diviser le processus de migration en deux étapes: conversion et nettoyage des données. La conversion est assez simple - une question de mappage des anciens objets système au nouveau nouveau système. Le nettoyage des données, d'autre part, peut être une chose très délicate (comme mentionné ci-dessus). Impliquez le client autant que possible et lancez le processus le plus tôt possible. Gardez à l'esprit que les mauvaises données se refléteront mal sur votre nouveau système - parfois complètement sans raison. Lorsqu'un nouveau système ne fonctionne pas, un client blâmera rarement les données qui semblaient bien fonctionner dans l'ancien système.
la source
Si les données que vous prévoyez de migrer sont actuellement incorrectes, elles doivent être corrigées, que vous effectuiez une migration ou non. Mauvaises données = données inutiles.
Les migrations sont risquées, c'est vrai. Mais il en va de même pour tous les grands projets informatiques. Il existe des moyens d'atténuer les risques et ils doivent certainement être planifiés dès le début d'une migration.
Tout d'abord, vous devriez toujours avoir un moyen de revenir au système tel qu'il est actuellement. Les deuxièmes migrations doivent être effectuées sur des serveurs de test configurés uniquement pour la migration. Il est insensé de faire une migration sans avoir la possibilité de la tester d'abord. Troisièmement, tout le code de la migration doit être sous contrôle de code source.
Quatrièmement, vous avez besoin d'exigences et de plans de test avant de commencer la migration. Vous devez savoir que si vous aviez 1 293 687 enregistrements dans l'ancien système, que vous en avez de même dans le nouveau ou que vous savez où ils sont allés (dans une table d'exceptions peut-être). Si vous normalisez un schéma dénormalisé, vous devez calculer le nombre d'enregistrements avec lesquels vous devez vous retrouver avant de commencer, puis vérifier cela. Vous avez besoin d'une documentation qui spécifie les mappages d'un système à l'autre. Cela aidera votre personnel AQ à vérifier que les données sont bien placées.
Vous devez déterminer comment gérer les mauvaises données actuelles. Ce qui peut être nettoyé, ce qui pourrait avoir besoin d'une valeur dans un champ obligatoire qui dit 'Inconnu', ce qui devrait être jeté dans une table d'exceptions, ce qui nécessite une intervention manuelle d'un groupe d'utilisateurs (décider si ces deux personnes sont vraiment un dup ou y a-t-il deux médecins dans cette pratique avec le même nom par exemple et s'il s'agit d'un dup dont les données doivent être choisies lorsque les deux enregistrements diffèrent, etc.).
La clé d'une migration réussie est la planification. J'ai constaté que la planification (qui comprend la rédaction des cas de test et des tests unitaires) prend généralement plus de temps que le développement réel.
La prochaine clé d'une migration de données réussie est le contrôle qualité. Ce n'est pas un projet à lancer à l'équipe QA la veille du lancement. Ce n'est pas un projet à lancer lorsque QA dit qu'il y a un problème.
Une autre clé d'une migration réussie consiste à déployer la majorité des données et à les tester pendant que le système d'origine est toujours en cours d'exécution. Si vous déplacez de nombreux enregistrements, cela peut prendre du temps et de nouveaux changements se produiront. Par conséquent, votre processus doit également pouvoir extraire les modifications des données après le début de la migration. SQL Server, par exemple, a quelque chose appelé Change Data Capture qui peut vous aider. Vous pouvez effectuer une sauvegarde du système d'origine et activer simultanément la capture des données modifiées. Ensuite, vous pouvez réinstaller la sauvegarde sur votre serveur de migration, tester la migration, charger la majorité des données et ensuite il vous suffit de charger les enregistrements qui ont changé. Lorsque vous migrez les enregistrements finaux, désactivez le système source jusqu'à ce que la migration soit terminée. C'est une des raisons de migrer la majorité des enregistrements à l'avance, donc l'application est en panne le moins de temps. Choisissez bien votre heure de migration, ne fermez pas le système de paie le jour où ils devraient traiter la paie ou envoyer des W2. Et faites-le pendant les faibles heures d'utilisation. Si vous avez plusieurs clients, vous pouvez envisager de migrer un premier et de vous assurer que tout va bien avant de faire les autres. Il est beaucoup plus facile de restaurer les données d'un client que 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites. s données supérieures à 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites. s données supérieures à 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites.
Si la migration implique une nouvelle interface utilisateur, veuillez demander aux utilisateurs réels de l'utiliser dans le cadre des tests de migration. Ensuite, formez les autres utilisateurs avant de mettre en ligne (mais moins d'une semaine avant de mettre en ligne ou ils oublieront). Demandez aux utilisateurs impliqués dans les tests d'aider à concevoir la formation, ils savent quelles questions ils ont et ce que les gens doivent savoir dans quel ordre. Obtenez leur entrée, en rendant un champ obligatoire parce que vous pensez que cela devrait être utile si les utilisateurs n'ont généralement pas ces données lorsqu'ils entrent dans les enregistrements. Ils vont simplement mettre du courrier indésirable dans le champ nouvellement requis car ils ne peuvent pas entrer les données autrement.
Regardez ce qui ne va pas avec les données actuelles, pouvez-vous ajouter des clés étrangères, des contraintes, des déclencheurs, des règles métier dans l'application, des valeurs par défaut, etc. afin d'éviter que cela ne soit mauvais à l'avenir? Lorsque vous nettoyez de mauvaises données, vous devez également créer un moyen d'éviter que ces données tout aussi mauvaises ne pénètrent à l'avenir. Analysez pourquoi les mauvaises données ont été allouées et corrigez la conception des trous.
la source
La migration des données est une nécessité. Sans migration de données, vous ne pouvez souvent pas aller de l'avant. De nombreux systèmes sur lesquels j'ai travaillé avec l'historique requis ne sont disponibles que sur les systèmes précédents. La migration est la seule méthode pratique pour y parvenir. La qualité des données est souvent un problème. En règle générale, cela devrait être traité dans le système antérieur. Cela peut nécessiter des modifications des données pour retrouver la qualité.
Les autres systèmes avec lesquels j'ai travaillé dépendent des données d'autres systèmes. Il s'agit d'un problème différent mais important. Dans certains cas, les données peuvent être entièrement remplacées. D'autres cas peuvent être mieux traités en fusionnant les modifications incluses dans les nouvelles données dans l'ensemble existant. Ces types de migrations doivent inclure des vérifications de validité pour le flux entrant.
La possibilité de valider et de nettoyer les données existantes peut être une caractéristique importante d'un système. Ceci est indépendant de la migration. Il existe souvent des mécanismes de modification des données qui échappent au contrôle du système. Cela peut rendre les données invalides. D'autres problèmes de données résultent de bogues dans l'application. L'exécution périodique des routines de validation peut aider à identifier le problème et permettre le nettoyage des données avant l'heure de la migration. Comme il a été noté, le nettoyage précoce des données peut faciliter la migration.
Certaines validations sont sensibles au temps et ne doivent pas être appliquées aux données qui n'ont pas été modifiées. Cela est courant avec les valeurs codées, où les codes ont été supprimés. Il devrait être possible de modifier d'autres champs de l'enregistrement sans déclencher d'erreurs de validation. Cela peut rendre la validation de la mise à jour plus complexe car elle doit identifier les champs modifiés avant la validation. La validation entre champs peut également être plus complexe. La possibilité de traiter certains enregistrements en lecture seule peut être utile dans ce cas, car la validation peut être évitée.
Sur un système I sur lequel j'ai travaillé, le nouveau système a été partiellement rejeté par le client. Ils ont refusé d'autoriser l'utilisation des nouveaux modules de saisie de données. Cependant, ils voulaient le traitement par lots à partir du nouveau système. La solution consistait à migrer les données tous les soirs avant l'exécution par lots.
la source
C'est un mal nécessaire. J'ai été des deux côtés et ce sont quelques-uns des autres problèmes qui aggravent le problème.
Si vos managers peuvent justifier la perte de ventes en ne convertissant pas les données, plus de puissance pour eux. Dire à vos clients que toutes les conversions de données échouent ne fonctionnera pas parce que quelqu'un d'autre leur dira toujours que ce sera le cas (généralement vos concurrents).
la source
le logiciel doit être mis à jour régulièrement. pour vous assurer que la migration est enregistrée, vous avez besoin d'une sauvegarde et de tests.
il a raison de dire que c'est risqué. mais vous pouvez adapter les techniques pour le rendre moins risqué.
nous avons une sauvegarde quotidienne, une sauvegarde incrémentielle, une sauvegarde avant chaque déploiement en production. qui vous permet au moins de revenir en arrière en cas de problème.
nous avons un environnement de test, des tests automatisés et un serveur de build quotidien. également une procédure de test de fumée pour s'assurer que les principales opérations et fonctions fonctionnent correctement. Nous impliquons les développeurs, le contrôle qualité et les utilisateurs pour tester la version (qui a migré les données).
nous utilisons ruby on rails, qui assure le versionnage de la migration, la mise à niveau et la restauration des données. ce qui nous facilite la vie.
nous utilisons capistrano pour exécuter la mise à jour du code et la migration des données. garder la migration automatisée et simple est l'un des éléments clés pour garantir le fonctionnement du système de production.
une autre préoccupation concernant la migration des données pour moi est la cohérence de la mise à niveau du code et de la migration des données. dans mon cas, encore une fois, nous utilisons des moyens automatisés pour gérer cela. et toujours prêt à revenir en arrière.
l'exécution manuelle de la migration des données peut transformer la base de données en statut inconnu. et il est difficile de comparer la version de migration des données entre différents environnements de serveurs.
J'espère que ça aide.
la source
Nous ne perdons pas notre temps à essayer de migrer les données d'anciens systèmes hérités car le temps, l'investissement et les risques sont trop élevés. Nous allons simplement de l'avant avec de nouveaux systèmes et nous intégrons lorsque cela est nécessaire.
Chaque entreprise a une forme de système hérité qu'elle doit prendre en charge, et ce n'est qu'un coût normal de faire des affaires.
La récompense que vos managers espèrent réaliser devrait être extrêmement élevée compte tenu du coût de la migration.
la source
"The reward your managers hope to realize had better be extremely high given the cost of the migration."Si la récompense est élevée - quelle qu'elle soit - alors ça vaut le coup. Sinon, c'est une perte de temps pour tout le monde et un risque inutile. De plus, j'ai mentionné dans ma réponse que l'intégration peut être effectuée pour permettre au nouveau système d'accéder aux anciennes données, dans certains cas. Mais cette décision dépend entièrement du scénario.