Modernisation mainframe et midrange avec Azure Logic Apps
Ce guide explique comment votre organisation peut augmenter la valeur commerciale et l’agilité en modernisant vos environnements système mainframe et midrange à l’aide d’Azure Logic Apps. Le monde des affaires actuel connaît une ère d’hyper innovation et est à la recherche permanente d’efficacité, de réduction des coûts, de croissance et d’alignement de l’entreprise. Les organisations cherchent des moyens de moderniser, et une stratégie efficace consiste à augmenter la valeur par l’utilisation de ressources héritées existantes de l’entreprise.
Pour les organisations ayant des investissements dans les systèmes mainframe et midrange, cela signifie qu’il faut utiliser aux mieux les plateformes qui ont aidé à envoyer des hommes sur la lune ou à construire des marchés financiers actuels et étendre leur valeur grâce au cloud et à l’intelligence artificielle (IA). C’est dans ce scénario qu’Azure Logic Apps et ses fonctionnalités natives pour l’intégration avec les systèmes mainframe et midrange entrent en jeu, en ouvrant la porte du monde de l’IA aux investissements hérités. Entre autres fonctionnalités, Azure Logic Apps intègre les principales fonctionnalités de Host Integration Server (HIS), qui a été utilisé pour l’intégration mainframe and midrange au cœur des clients les plus stratégiques de Microsoft depuis plus de 20 ans. Par conséquent, Azure Logic Apps est devenue une plateforme d’intégration en tant que service (iPaaS) pour les systèmes mainframe et midrange.
Lorsque les développeurs d’entreprise créent des flux de travail d’intégration avec Azure Logic Apps, ils peuvent fournir plus rapidement de nouvelles applications à l’aide de peu à aucun code ou code moins personnalisé. Les développeurs qui utilisent Visual Studio Code et Visual Studio peuvent être plus productifs que ceux qui utilisent des outils et technologies de développement mainframe IBM, car ils ne nécessitent pas de connaissances sur les systèmes et l’infrastructure mainframe. Azure Logic Apps permet aux analystes d’entreprise et aux décisionnaires d’analyser et de signaler plus rapidement les informations vitales héritées. Ils peuvent accéder directement aux données dans des sources de données mainframe, ce qui supprime la nécessité pour les développeurs mainframe de créer des programmes qui extraient et convertissent des structures mainframe complexes.
Fonctionnalités natives cloud pour l’intégration du système mainframe et midrange
Depuis 1990, Microsoft a fourni une intégration avec les systèmes mainframe et midrange via Microsoft Communications Server. Une évolution supplémentaire de Microsoft Communications Server a créé Host Integration Server (HIS) en 2000. Alors que HIS était à l’origine une passerelle SNA (System Network Architecture), HIS a été développé pour inclure les magasins de données IBM (DB2, VSAM et Informix), les systèmes de transactions IBM (CICS, IMS et IBM i) et la messagerie IBM (série MQ). Les clients stratégiques de Microsoft ont utilisé ces technologies depuis plus de 20 ans.
Pour permettre aux clients qui exécutent des applications et des données sur Azure de continuer à utiliser ces technologies, Azure Logic Apps et Visual Studio ont progressivement intégré ces fonctionnalités. Par exemple, le concepteur HIS pour Logic Apps qui s’exécute sur Visual Studio et l’outil de conception 3270 vous aident à créer des artefacts de métadonnées requis par les connecteurs intégrés que vous utilisez pour l’intégration mainframe et midrange dans Azure Logic Apps. Ces connecteurs intégrés s’exécutent à l’aide des mêmes ressources de calcul que les flux de travail de l’application logique Standard. Cette conception vous permet non seulement d’obtenir des scénarios à faible latence, mais également d’étendre votre portée pour répondre à davantage de besoins en matière de récupération d’urgence et de haute disponibilité.
Pour plus d’informations sur les fonctionnalités de Microsoft pour l’intégration mainframe et midrange, passez aux sections suivantes.
Concepteur HIS Microsoft pour Logic Apps
Cet outil crée des artefacts de métadonnées système mainframe et midrange pour Azure Logic Apps et fonctionne avec Microsoft Visual Studio en fournissant un concepteur graphique pour pouvoir créer, afficher, modifier et mapper des objets de métadonnées à des artefacts mainframe. Azure Logic Apps utilise ces cartes pour mettre en miroir les programmes et les données dans les systèmes mainframe et midrange. Pour plus d’informations, consultez Concepteur HIS pour Logic Apps.
Outil de conception Microsoft 3270
Cet outil enregistre les écrans, les chemins de navigation, les méthodes et les paramètres des tâches de votre application afin de pouvoir ajouter et exécuter ces tâches en tant qu’actions de connecteur 3270. Alors que le concepteur HIS pour Logic Apps cible les systèmes transactionnels et les données, l’outil de conception 3270 cible les applications 3270. Pour plus d’informations, consultez l’outil de conception 3270.
Connecteurs Azure Logic Apps pour les systèmes mainframe et midrange IBM
Les sections suivantes décrivent les connecteurs intégrés, basés sur un fournisseur de services, que vous pouvez utiliser pour accéder aux systèmes mainframe et midrange IBM lorsque vous créez des flux de travail Standard dans Azure Logic Apps.
Remarque
Bien que certains des connecteurs suivants soient disponibles en tant que connecteurs « partagés » qui s’exécutent dans Azure global, ce guide est axé sur les connecteurs intégrés, basés sur un fournisseur de services, qui sont disponibles uniquement lorsque vous créez des flux de travail Standard dans Azure Logic Apps.
IBM 3270
Ce connecteur Azure Logic Apps pour 3270 permet aux flux de travail Standard d’accéder et d’exécuter des applications mainframe IBM que vous pilotez habituellement en naviguant dans des écrans de l’émulateur 3270. Le connecteur utilise le flux TN3270. Pour en savoir plus, consultez Intégrer des applications sur écran 3270 à des mainframes IBM avec Azure à l’aide d’Azure Logic Apps et du connecteur IBM 3270.
IBM Customer Information Control System (CICS)
Ce connecteur Azure Logic Apps pour CICS fournit des flux de travail Standard qui peuvent interagir et s’intégrer aux programmes CICS à l’aide de plusieurs protocoles, notamment TCP/IP et HTTP. Si vous devez accéder aux environnements CICS à l’aide de LU6.2, vous devez utiliser Host Integration Server (HIS). Pour plus d’informations, consultez Intégrer des programmes CICS sur des mainframes IBM à des flux de travail Standard dans Azure Logic Apps à l’aide du connecteur IBM CICS.
IBM DB2
Ce connecteur Azure Logic Apps pour DB2 active les connexions entre les flux de travail Standard et les bases de données DB2 locales ou dans Azure. Le connecteur offre aux professionnels de l’informatique dans les entreprises et aux développeurs un accès direct aux informations vitales stockées dans les systèmes de gestion de base de données DB2. Pour plus d’informations, consultez Accéder et gérer les ressources IBM DB2 à l’aide d’Azure Logic Apps.
Fichiers hôte IBM
Ce « connecteur » Azure Logic Apps pour les fichiers hôtes fournit un léger wrapper autour de la fonctionnalité « Analyseur de fichiers plats » dans Host Integration Server. Ce « connecteur » hors connexion fournit des opérations qui analysent ou génèrent des données binaires vers et depuis des fichiers hôtes. Ces opérations nécessitent que ces données proviennent de tout déclencheur ou d’une autre action qui produit des données binaires. Pour plus d’informations, consultez Analyser et générer des fichiers hôtes IBM à l’aide d’Azure Logic Apps.
IBM i
Ce connecteur Azure Logic Apps pour IBM i permet aux flux de travail Standard d’interagir et d’intégrer des programmes COBOL et RPG s’exécutant sur des systèmes IBM i à l’aide de TCP/IP. Si vous souhaitez accéder aux environnements IBM i à l’aide de LU6.2, vous devez utiliser Host Integration Server (HIS). Pour plus d’informations, consultez Intégrez des programmes COBOL et RPG sur IBM midrange avec des flux de travail Standard dans Azure Logic Apps à l’aide du connecteur IBM i.
IBM Information Management System (IMS)
Ce connecteur Azure Logic Apps pour IMS utilise le composant IBM IMS Connect, qui fournit un accès haute performance des flux de travail Standard aux transactions IMS à l’aide de TCP/IP. Ce modèle utilise la file d’attente de messages IMS pour le traitement des données. Pour plus d’informations, consultez Intégrer des programmes IMS sur des mainframes IBM à des flux de travail Standard dans Azure Logic Apps à l’aide du connecteur IBM IMS.
IBM MQ
Ce connecteur Azure Logic Apps pour MQ active les connexions entre les flux de travail Standard et des serveurs IBM MQ locaux ou dans Azure. Microsoft fournit également des fonctionnalités d’intégration IBM MQ avec Host Integration Server et BizTalk Server. Pour plus d’informations, consultez Se connecter à un serveur IBM MQ à partir d’un flux de travail dans Azure Logic Apps.
Défis pour la modernisation des systèmes mainframe et midrange
Les systèmes mainframe et midrange peuvent héberger plusieurs environnements qui contiennent des programmes, des données, des fichiers et des outils. Au fil des années, ces environnements n’ont peut-être pas été refactorisés ou ont été laissés pour croître et atteindre leurs limites, malgré les mises à niveau matérielles. Ces environnements peuvent également avoir été entretenus par plusieurs développeurs et administrateurs informatiques, qui suivent différents modèles de programmation et techniques, ou ont recruté d’autres tiers pour aider à des tâches qui nécessitent une expertise rare sur le marché. En plus d’un pool réduit de professionnels expérimentés, tous ces facteurs créent un travail complexe et ambitieux de modernisation des environnements mainframe et midrange.
Bien que la liste suivante ne soit pas exhaustive, la définition d’une stratégie de modernisation réussie inclut au minimum des façons de gérer les tâches suivantes :
- Conserver les indicateurs et objectifs actuels du niveau de service pour vos environnements.
- Gérer la coexistence entre les données héritées et les données migrées.
- Procédez au DevOps entre les environnements pendant la coexistence.
- Gérer les interdépendances des applications.
- Définir l’avenir du planificateur et des travaux mainframe.
- Définir une stratégie pour remplacer les produits du commerce (COTS).
- Effectuer des activités de test fonctionnels et non fonctionnels hybrides.
- Gérer les dépendances externes ou les interfaces.
Avec ces tâches à l’esprit, les clients choisissent généralement l’un des chemins suivants pour mener à bien la modernisation des systèmes mainframe et midrange :
Big Bang
Cette approche est largement basée sur le modèle de livraison de logiciels en cascade, mais avec des itérations en phases. L’approche big bang est davantage adoptée par les clients avec des systèmes mainframe ou midrange de petite taille et des environnements de faible complexité en raison d’un petit nombre de lignes de code, d’une faible densité d’application et de systèmes hérités connus ou de langages de programmation.
Vagues agiles
Cette approche suit les principes agiles du génie logiciel. L’approche des vagues Agile est davantage adoptée par les clients disposant de systèmes mainframe ou midrange plus volumineux et d’environnements complexes en raison d’un grand nombre de lignes de code, d’une densité d’application élevée, de systèmes ou de langages de programmation moins connus et d’un grand nombre de dépendances et d’interfaces.
Le choix entre ces chemins dépend des besoins et des scénarios de votre organisation. Chaque chemin présente des avantages et des inconvénients à prendre en compte. Les sections suivantes fournissent plus d’informations sur ces approches de modernisation.
Big bang ou cascade
Une migration big bang a généralement les phases suivantes :
Conception : lancement
Planification : identifier et préparer les livrables de planification, tels que l’étendue, le temps et les ressources.
Génération : démarre après l’approbation des livrables de planification
Cette phase s’attend également à ce que tous les travaux pour les dépendances ont été identifiés, puis que les activités de migration puissent commencer. Plusieurs itérations se produisent pour terminer le travail de migration.
Stabilisation ou test: démarre lorsque l’environnement migré, les dépendances et les applications sont testés sur les régions de test dans l’environnement mainframe.
Déployer: une fois que tout est approuvé, la migration passe en production.
Les organisations qui choisissent généralement cette approche se concentrent sur le verrouillage du temps, l’étendue de migration et les ressources. Ce chemin d’accès ressemble à un choix positif, mais inclut les risques suivants :
Les migrations peuvent prendre des mois ou même des années.
Les déploiements en production sont plus risqués.
L’analyse que vous effectuez au début du parcours de migration ou pendant la planification n’est plus précise, car ces informations sont généralement obsolètes.
Les organisations s'attachent généralement à disposer d'une documentation complète afin de réduire les risques liés à la livraison.
Toutefois, le temps passé à fournir des artefacts de planification provoque justement l’effet inverse. Le fait de se concentrer sur la planification plutôt que sur l’exécution tend à créer des retards de mise en œuvre, ce qui entraîne une augmentation des coûts à long terme.
Vagues agiles
Une approche agile est orientée vers les résultats et axée sur la création de logiciels et non sur la planification des livrables. Les premières étapes d’une livraison Agile peuvent être chaotiques et complexes pour les barrières organisationnelles qui doivent être levées et pour aligner l’équipe en charge de la migration. Toutefois, lorsque l’équipe de migration arrive à maturité après plusieurs sprints d’exécution, le parcours devient plus fluide. L’objectif de cette approche est de publier fréquemment des fonctionnalités en production et de fournir une valeur commerciale plutôt que choisir d’employer une approche big bang.
Une migration de vagues Agile a généralement les sprints suivants :
Sprint zéro (0)
- Définir l’équipe, un backlog de travail initial et les dépendances principales.
- Identifier les fonctionnalités et un produit minimum viable (MVP) à livrer.
- Lancez la préparation du mainframe avec un ensemble sélectionné d’éléments de travail ou d’histoires utilisateur pour commencer le travail.
Sprint 1, 2, ..., N
Chaque sprint a un objectif où l’équipe maintient un état d’esprit d’expédition, ce qui signifie qu’elle se concentre sur l’achèvement des objectifs de migration et libère les livrables en production. L’équipe peut utiliser un groupe de sprints pour fournir une fonctionnalité spécifique ou une vague de fonctionnalités. Chaque fonctionnalité inclut des tranches de charges de travail d’intégration.
Les éléments partagés, tels que les emplois et les interdépendances, existent et ont un impact sur l’ensemble de l’environnement. Une stratégie réussie se concentre sur l’activation partielle des emplois, la refonte des applications pour la modernisation et le fait de laisser les systèmes avec la plupart des interdépendances jusqu’à la fin pour réduire d’abord la quantité de travail de migration, puis terminer l’étendue de l’effort de modernisation.
Microsoft recommande de moderniser les charges de travail du système mainframe et midrange en suivant un modèle itératif et Agile par vagues en mettant l’accent sur les investissements dans la nouvelle plateforme, tout en limitant la croissance des systèmes hérités. Cette approche réduit considérablement les risques d’implémentation en préservant la valeur métier existante, tout en introduisant l’environnement modernisé. De cette façon, votre équipe peut également tirer parti des compétences technologiques qui aident votre entreprise à être plus compétitive. Ce scénario illustre parfaitement la situation où Azure Logic Apps peut vous aider dans votre parcours de modernisation.
Modèles de modernisation
Une bonne conception comprend des facteurs tels que la cohérence et la cohérence dans la conception de composants et de déploiements, la facilité de gestion pour simplifier l’administration et le développement, et la réutilisation qui permet à d’autres applications et scénarios de réutiliser des composants et des sous-systèmes. En ce qui concerne les services et les applications hébergés dans le cloud, des décisions prises pendant la phase de conception et d’implémentation ont un impact important sur la qualité et le coût total de possession.
Le Centre des architectures Azure fournit des modèles de conception et d’implémentation qui décrivent le problème auquel ils répondent, les considérations relatives à l’application du modèle et un exemple basé sur Microsoft Azure. Bien que plusieurs modèles de conception et d’implémentation existent, certains modèles les plus pertinents pour la modernisation du mainframe incluent les modèles « Couche anti-corruption » « Figuier étrangleur », « Saga » et « Chorégraphie ».
Modèle de couche de lutte contre la corruption
Quelle que soit l’approche de modernisation que vous sélectionnez, vous devez implémenter une « couche anti-corruption » à l’aide d’Azure Logic Apps. Ce service devient la façade ou la couche d’adaptation entre le système hérité mainframe et Azure. Pour une approche efficace, identifiez les charges de travail mainframe à intégrer ou à coexister en tant que charges de travail d’intégration mainframe. Créez une stratégie pour chaque charge de travail d’intégration, qui est l’ensemble d’interfaces que vous devez activer pour la migration d’une application mainframe.
Pour plus d’informations, consultez Couche anti-corruption.
Modèle Figuier étrangleur
Après avoir implémenté la couche anti-corruption, la modernisation se produit progressivement. Pour cette phase, vous devez utiliser le modèle « Strangler Fig » dans lequel vous identifiez les charges de travail ou fonctionnalités mainframe que vous pouvez moderniser de manière incrémentielle. Par exemple, si vous choisissez de moderniser une application CICS, vous devez moderniser non seulement les programmes CICS, mais probablement les applications 3270 ainsi que leurs dépendances externes, données et travaux correspondants.
Finalement, après avoir remplacé toutes les charges de travail ou fonctionnalités du système mainframe par votre nouveau système, vous terminerez le processus de migration, ce qui signifie que vous pouvez désactiver votre système hérité.
Pour plus d’informations, consultez Modèle Fig Strangler.
Modèle Saga et Chorégraphie
Des transactions distribuées, telles que le protocole de validation en deux phases (2PC) requièrent que tous les participants à une transaction valident ou annulent la transaction avant qu’elle se poursuive. Les architectures hybrides cloud fonctionnent mieux en suivant un paradigme de cohérence éventuel plutôt qu’un modèle de transaction distribuée.
Le modèle de conception Saga est un moyen de gérer la cohérence entre les services dans des scénarios de transaction distribuée. Un saga est une séquence de transactions qui met à jour chaque service et publie un message ou un événement pour déclencher l’étape suivante de la transaction. Si une étape échoue, la saga exécute des transactions de compensation qui contrent les transactions précédentes. Pour plus d’informations, consultez Modèle de transactions distribuées Saga.
Dans Azure Logic Apps, les flux de travail peuvent agir en tant que chorégraphes pour coordonner les sagas. Les actions de flux de travail sont atomiques. Vous pouvez donc les réexécuter individuellement. Le type d’action Étendue offre la possibilité d’exécuter un groupe d’actions uniquement une fois qu’un autre groupe d’actions réussit ou échoue. Azure Logic Apps effectue des transactions de compensation au niveau de l’étendue, tandis qu’Azure Event Grid et Azure Service Bus fournissent la gestion des événements requise pour des domaines spécifiques. Tous ces services, qui composent les Services d’intégration Azure, fournissent le support requis par les clients lorsqu’ils ont besoin d’une plateforme d’intégration fiable pour les scénarios stratégiques. Pour plus d’informations, consultez Modèle Chorégraphie.
Bien que cet article couvre plusieurs modèles de modernisation, les solutions complexes nécessitent beaucoup plus de modèles et une compréhension claire des objectifs de modernisation de votre organisation. Bien que la tâche d’étendre la valeur des actifs historiques soit difficile, cette option est la meilleure pour préserver l’investissement dans ces actifs et leur valeur métier.