Le monde évolue rapidement vers la numérisation avec une approche cloud-native. La première étape vers ce voyage consiste à migrer les applications vers le cloud, de préférence avec une disposition de ré-hébergement et de re-plateforme. Alors que les applications personnalisées sont relativement plus faciles à migrer, un défi, une analyse et une décision plus importants se posent en ce qui concerne les applications COTS (commerciales prêtes à l’emploi). Ce blog traite des défis critiques et d’une approche de liste de contrôle avant de commencer la migration COTS. Le terme « modernisation » utilisé ici fait référence au remplacement et à l’activation du produit hérité par une version compatible avec le cloud.
Défis et listes de contrôle
- Feuille de route pour conserver/remplacer/retirer le produit — Les réponses aux questions suivantes peuvent conduire à conserver/remplacer/retirer le produit et la consolidation et la rationalisation potentielles des applications (à exécuter en tant que programme d’entreprise distinct, migration externe)
- Les utilisateurs professionnels/finaux utilisent-ils fréquemment ce produit en tant qu’application stratégique ?
- Ce produit/application est-il utilisé localement ou globalement (le même produit/application est configuré dans différentes régions/pays et est utilisé presque de la même manière) ?
- Les fonctionnalités peuvent-elles être adressées par une autre application (existante) avec une personnalisation améliorée ?
- Remarque : il est préférable de répondre aux questions ci-dessus par l’équipe commerciale du client et la PME du domaine industriel du client.
- Compatibilité des versions — Vérifiez la matrice de compatibilité des produits et la documentation par rapport à la pile technologique, la conformité avec la plate-forme cloud et assurez-vous qu’elles peuvent être prises en charge dans l’architecture cloud cible. Chaque cloud suit un ensemble de normes de sécurité et de politiques prises en charge au niveau des logiciels/technologies. De même, le cloud doit également prendre en charge diverses conformités réglementaires avec le domaine industriel du client. En général, le système d’exploitation, le middleware, etc. sont pris en charge jusqu’au niveau N-1, où N est la dernière version GA (disponibilité générale) du composant système/logiciel.
- Assistance fournisseur du produit — Vérifiez si le fournisseur dispose d’une feuille de route pour prendre en charge la version du produit hébergé sur site. Il doit également être vérifié si les exigences système existantes du produit sont prises en charge dans le cloud cible. Cela peut conduire à une mise à niveau avant la migration. Certains fournisseurs, dans le cadre de la transformation numérique, adoptent des approches multi-locataires et de logiciel en tant que service et peuvent forcer les clients à adopter la même chose pour le produit.
- Adoption SaaS — Le produit a-t-il un SaaS, et si oui, est-ce acceptable pour le client en ce qui concerne la confidentialité et la sécurité des données ? En outre, il convient de faire une évaluation des coûts par rapport à une solution hébergée. Vérifiez que l’offre SaaS prend en charge l’intégration requise avec les interfaces existantes ainsi que l’accessibilité des utilisateurs (authentification/autorisation) et la sécurité.
- Paysage d’intégration de système — Le produit actuel peut utiliser un style/protocole/port d’intégration avec des systèmes internes/externes. Comme le produit est désormais prévu pour être sur le cloud, le même protocole/port peut ne pas être pris en charge conformément aux normes de sécurité et peut nécessiter un port distinct spécifique au cloud. Parfois, cela peut conduire à une refonte du produit lui-même, ce qui est rare à réaliser dans les délais. La plupart du temps, dans ce scénario, une approbation exceptionnelle a été obtenue du CSO (chef de la sécurité) pour que les ports existants soient autorisés sur le cloud.
- Optimisation des ressources — Pour les applications stratégiques, il est important d’adopter une approche rentable en matière d’évolutivité, de disponibilité, d’amélioration de la tolérance aux pannes et de déploiement plus rapide. Le passage au conteneur aidera dans tous ces aspects ; cependant, l’image du produit COTS doit être « légère » et sécurisée. Il faut donc vérifier si le produit peut être hébergé sur un conteneur et s’il a une image sécurisée enregistré dans un registre officiel approuvé par le vendeur du produit. La migration vers une approche basée sur les conteneurs nécessite un effort d’intégration et des tests de sécurité/d’intrusion importants.
- Intégration basée sur des fichiers — La configuration existante et cible du partage de fichiers dépend du protocole pris en charge (SMB, NFS, DFS, etc.) et du fait que les deux systèmes (éditeur et consommateur de fichiers) se trouvent dans le même domaine réseau. Dans la cible, le domaine des systèmes participants sera différents réseaux par l’hyperviseur sous-jacent. Cela nécessite également l’ouverture de ports de communication spécifiques entre le cloud et sur site.
- Chemin de migration — Toute migration de produit peut choisir l’une des deux voies suivantes : 1) Migrer le nouveau produit directement vers le cloud, 2) Mettre à niveau le produit sur site, puis migrer vers le cloud. La première option présente un risque plus élevé en termes de performances et d’intégration, car la version la plus récente/mise à niveau est susceptible d’avoir une interface, un port et une technologie différents. La mise à niveau initiale, le système, l’intégration, les tests requis et la compatibilité doivent être effectués sur site avec tous les écosystèmes et obtenir l’approbation de l’entreprise. Cela réduira considérablement les efforts de test et d’intégration des produits lors de la migration vers le cloud.
- Mise en œuvre RACI — Une fois que la version cible du produit est décidée pour la migration, il devient essentiel d’obtenir la bonne PME et d’établir une matrice RACI (Responsible, Accountable, Accountable, Informed). Bien que la configuration de l’infrastructure et du réseau requis puisse être effectuée par SI (intégrateur de services) et l’équipe cloud, l’installation, la mise à niveau, la configuration de l’installation du produit et l’intégration doivent être effectuées par le produit/COTS SME, qui doit provenir du l’équipe du fournisseur de produits. Généralement, le SME doit être engagé dès la conversation initiale du chemin de mise à niveau-migration et continuer à faire partie de l’équipe de mise en œuvre principale. L’IS, par l’intermédiaire du client, doit soulever un risque de disponibilité et de calendrier de la PME et l’atténuer par la confirmation de l’équipe produit à ce sujet. Pour l’adoption SaaS du produit, le produit SME doit être inclus pour l’intégration ainsi que l’architecture/conception de sécurité.
- Mécanisme d’accès des utilisateurs — La version héritée de nombreux produits COTS nécessite une ancienne méthode d’accès au produit – via un logiciel de sécurité supplémentaire comme Citrix, F5, Array Network, FortiClients, etc. (une URL distincte est utilisée pour accéder à l’application/au produit). Cela nécessite les ordinateurs portables/appareils des utilisateurs pour installer et maintenir des logiciels, une configuration et une distribution distincts chaque fois que nécessaire. Nous devrions chercher à adopter la version moderne du COTS qui prend désormais en charge https/WebAPI, qui est sécurisé et ne nécessite pas de couche supplémentaire.
- Observabilité et aperçu — Lorsque nous déplaçons une application vers le cloud, il est essentiel que l’application génère le bon niveau de traces, de journaux et de métriques afin que les outils de surveillance natifs du cloud puissent capturer et utiliser pour la gestion des alertes et des incidents. Le produit doit être configurable pour générer les bonnes données, ce qui aidera à créer des algorithmes prédictifs (en utilisant AI/ML). Cela peut fournir une observabilité exploitable et aidera à prendre des mesures proactives pour réduire les temps d’arrêt et garantir la santé et la disponibilité du système. Il est donc important d’adopter la version de produit appropriée (facilement configurable pour envoyer des journaux, définir des traces, des niveaux, etc.) pour l’architecture cible de migration/modernisation.