Migration de systèmes et services

La migration des données et des services d’intégration est requise lorsqu’un système ou un service est déplacé vers une nouvelle technologie. La migration des systèmes et des services est une activité dans laquelle toutes les organisations se retrouvent généralement engagées à un moment donné. Cette activité peut être déclenchée par:

L’adoption de systèmes et de technologies SaaS.
Le remplacement et la mise à niveau d’une application fournisseur.
Le développement d’une application sur mesure ou implémentation de microservices.
La consolidation de systèmes par fusion ou acquisition.
Le désinvestissement d’une partie d’une entreprise.
La migration de APIs ou de services d’intégration d’une pile à une autre.

Les activités de migration sont l’occasion d’amplifier la valeur d’une mise en œuvre, soit en termes de coûts opérationnels, soit d’opportunité de valeur que la migration fait surface. La prise de conscience de cette valeur dépend des activités de migration et de l’approche adoptée par une organisation.

Les avantages de bien le faire

Éliminer les limitations ou les défauts existants.

Réduire les temps et les coûts pour réussir la migration.

Maximiser l'opportunité du nouvel état et l'investissement.

Créer une base positive pour l'innovation future.

Comment aborder les projets de migration?

Les activités suivantes sont assez fréquentes parmi les projets de migration:

La migration des données implique de réconcilier les modèles de données et de produire un ensemble de règles de mappage pour les objets métier clés partagés entre les systèmes.
L’audit des caractéristiques et fonctionnalités clés, des règles métier, ou autres. à produire et répliquer dans la nouvelle pile technologique.
La compréhension des limites de l’existant dans les données, l’architecture et les termes fonctionnels et incorporer des améliorations dans les nouveaux services
L’optimisation de la nouvelle mise en œuvre pour tenir compte des leçons tirées de la précédente.
La conception de données et d’architecture pour un nouveau monde.
La production d’un modèle canonique et système d’APIs pour vous assurer de pouvoir brancher et jouer des systèmes dans une architecture en cas de besoin de migrer.

Qu’il s’agisse d’une migration de système ou d’une migration de services d’intégration et APIs, la première étape consiste généralement à auditer ce qui existe en termes de caractéristiques et de fonctionnalités, de règles d’affaire et de données à répliquer dans la nouvelle pile technologique. Il est essentiel de réconcilier les modèles de données entre les systèmes et de produire des règles de mappage pour les objets d’affaire partagés. Nous nous trouvons généralement avec des ensembles de données à migrer avec des règles pour chaque compartiment pour migrer ces données avec différents niveaux d’automatisation. La qualité des données ou leur manque est l’une des principales raisons pour lesquelles nous nous retrouvons avec ces compartiments ou catégories de données. Ils sont souvent motivés par des changements dans les processus d’affaires ou le personnel clé au fil du temps.

Les organisations cherchent généralement à résoudre les problèmes de qualité des données, les limites des données, des fonctionnalités et de l’architecture pendant l’activité de migration. C’est l’occasion d’optimiser la nouvelle mise en œuvre, d’optimiser les modèles de données et l’architecture. Le déploiement d’un modèle de données canonique pendant ces activités ou avant par la ré-implémentation des services d’intégration peut rendre les activités de migration beaucoup plus simples à réaliser.

Des erreurs fréquentes commises dans les projets de migration

La migration des systèmes «tels quels» entraîne souvent une migration des limitations existantes ou des problèmes avec l’ancien système. Dans un effort pour ne pas interrompre un processus d’affaire, les organisations se retrouvent à compromettre la valeur de la nouvelle implémentation. Penser “c’est comme ça que ça marche” au lieu de “c’est comme ça que ça devrait fonctionner”.

Ne pas résoudre les problèmes de qualité des données dans le jeu de les anciennes données parce que nous pensons qu’il représente la vérité peut saper la confiance des utilisateurs dans ce qu’ils voient ou rapportent du nouveau monde. Nous mettons en œuvre une nouvelle lentille à travers laquelle afficher nos données ou y voir la vérité. Si nous avons besoin de l’ancien objectif, il est préférable d’entreposer les données et les anciens rapports plutôt que de compromettre la valeur ou la confiance dans la nouvelle mise en œuvre.

Souvent, les organisations ne prennent pas de dispositions de la bonne façon pour les systèmes et services en aval en fonction de ce qui est migré. Il soit qu’ils anticipent trop, ce qui les amène à ne pas aborder les problèmes du modèle de données sous-jacent. Il existe des voies et moyens en termes d’intégration que nous pouvons prévoir pour les besoins de données ultérieurs sans compromettre la nouvelle implémentation. L’implémentation d’un modèle de données canonique en est un exemple.

Tout à fait, l’absence d’intégration jusqu’à la fin est bien plus fréquente que ce que les gens pourraient imaginer. Si l’intégration atteint le registre des risques d’un projet de migration, elle le fait normalement car elle a été traitée beaucoup trop tard dans le projet. C’est rarement le nouveau système ou l’implémentation de service qui résout le problème d’affaire, c’est la façon dont il est mis en œuvre. Les consultants de l’application que vous engagez pour déployer le nouveau monde ont besoin de consultants en intégration pour les aider à réussir la mise en œuvre.

Comment Chakray peut vous aider?

Chez Chakray, nous nous spécialisons dans les données et l’intégration avec la migration, l’une des initiatives les plus communes et les plus fréquentes que nous devons consulter. Nous aidons les organisations de toutes tailles à réaliser la valeur des migrations de systèmes en prenant en compte dès le début leurs besoins en données et en intégration dans la mise en œuvre.

Contactez-nous