La modernisation des applications mainframe au-delà du secteur bancaire

Voici la première partie d’une série en cinq parties sur la modernisation du mainframe. Lorsque l’on évoque les plus grands défis mondiaux en matière de modernisation, on pense immédiatement au secteur bancaire, et ce pour de bonnes raisons. Les banques ont été parmi les premières à déployer des applications mobiles avancées il y a environ 15 ans, et elles avaient déjà commencé à proposer des services en ligne au milieu des années 1990. Bien avant cela, les banques interagissaient par le biais de passerelles de paiement électronique massives et exploitaient des services mainframe, dont beaucoup restent au cœur de leurs activités aujourd’hui, même si les plateformes elles-mêmes ont considérablement évolué depuis lors. Même si les systèmes transactionnels qui se connectent à une banque constituent une grande partie de l’environnement mainframe, ils font partie d’une vague de transformation plus large qui ne concerne pas seulement les banques. Les mainframes constituent toujours un élément essentiel du système numérique de nombreux autres secteurs, et il reste encore beaucoup d’autres récits de transformation numérique à raconter qui ne sont pas exclusivement motivées par des considérations financières. Découvrons quelques points forts de la modernisation du mainframe dans d’autres secteurs, notamment l’assurance, l’automobile et la vente au détail.

S’il existe un modèle commun à tous les secteurs pour la modernisation de mainframe, c’est que les entreprises tentent d’améliorer l’expérience en ligne de leurs clients sans risquer d’interrompre les systèmes critiques de base. Le client peut être un utilisateur final d’une application ou d’un site Web ou un employé/partenaire dans un bureau ou sur le terrain. Les clients évaluent l’entreprise en fonction de la manière dont la logique commerciale et les données de l’entreprise répondent à leur expérience. Les clients ne se soucient pas de savoir si le back-end est un site mainframe communiquant avec un fournisseur SaaS qui propose une interface utilisateur mobile. Ils veulent simplement que l’ensemble du système réponde à leurs besoins commerciaux de manière efficace et précise. Même dans un scénario de machine learning, où les données du mainframe peuvent alimenter un modèle d’intelligence artificielle (IA) plutôt qu’une personne, il y a toujours un client qui voudra que le modèle d’IA qui en résulte prenne en charge un processus métier.

 Il n’y a pas de raison pour laquelle les pratiques DevOps devraient être réservées aux applications distribuées et au cloud. L'histoire de la transformation de State Farm, l'un des plus grands assureurs mutuels au monde, offre un excellent exemple d'agilité. Dans un secteur mature, l'avenir des assureurs reste très incertain. De nouvelles start-ups apparaissent chaque jour, stimulant la demande des clients pour des fonctionnalités telles que les devis en ligne et les applications mobiles de traitement des demandes d'indemnisation. L'équipe de développement de State Farm était en pleine transformation DevOps. Elle a développé une combinaison de ses propres outils d'automatisation et de test avec Jenkins CI/CD et Git pour la diffusion et le déploiement de nouvelles applications. Ces systèmes exploitent les données des serveurs centraux IBM Z , véritables bêtes de somme, dont certains fonctionnent sans interruption depuis 50 ans. Une fois que les changements apportés aux applications orientées client et aux services compatibles avec les API ont commencé à s'accélérer, un goulot d'étranglement a été détecté. Les services back-end ne pouvaient pas être modifiés avec suffisamment d'agilité pour suivre le rythme ; de plus, il y avait une pénurie de développeurs expérimentés de mainframe pour effectuer les changements. Grâce à l’environnement de développement et de débogage d’IBM® Developer for z/OS, qui s’intègre directement à Git pour le contrôle de versions et les check-ins, même les nouveaux membres de l’équipe de développement ont pu tirer parti et mettre à jour les applications mainframe sur IBM Z grâce à un workflow intuitif et familier. « Nos systèmes IBM Z offrent une base solide, sécurisée et fiable pour la croissance. Nous voulions soutenir les développeurs Z dans l’atteinte d’une plus grande efficacité et rapidité, mais aussi aider les nouvelles recrues à se sentir à l’aise sur la plateforme, afin que nous puissions tous travailler ensemble sur différentes plateformes pour livrer une innovation rapide », a déclaré Krupal Swami, directeur de la technologie et de l'architecture pour State Farm.

Une grande entreprise automobile s’appuie sur des systèmes centraux pour alimenter les nouvelles applications et les nouveaux services embarqués avec des données actualisées. Leur système interne de gestion du code source existant commençait à affecter la stabilité des applications mainframe critiques, et les nouveaux développeurs avaient du mal à obtenir une visibilité sur les dépendances que chaque changement pouvait affecter. L’entreprise a fait passer ses équipes de mainframe au développement sur IBM IDZ (IBM Developer for z/OS) avec IBM DBB (qui améliore la visibilité des constructions basées sur les dépendances), et a ensuite utilisé IBM UrbanCode Deploy pour fournir des mises à jour agiles aux systèmes cibles hautement distribués.

Une grande entreprise de vente au détail accumule naturellement de nombreuses applications mainframe afin de créer de nouvelles fonctionnalités prêtes à être utilisées par les clients. Au bout de quelques années, la rationalisation de ce vaste parc d’applications devient un travail à plein temps pour un trop grand nombre de personnes qualifiées, car les interdépendances entre les applications et les ordinateurs centraux sont difficiles à déceler. Pour compliquer encore les choses, les nouveaux employés du développement ont très peu de visibilité sur les décisions architecturales et logicielles prises par les générations précédentes de développeurs et de responsables informatiques, ce qui nuit à la productivité. En utilisant IBM ADDI (Application Discovery and Delivery Intelligence), les développeurs seniors et juniors peuvent analyser toutes les applications mainframe ainsi que les applications et services plus récents. La découverte et la documentation rapides des interdépendances aident désormais leurs équipes ITOps et de livraison de logiciels à comprendre l’impact de tout changement.

Il est intéressant de noter que si ces transformations se sont produites en dehors des secteurs financiers, presque chacune d’entre elles repose sur un ou plusieurs processus de transactions critiques qui se déroulent probablement sur un mainframe, ce qui ramène en quelque sorte l’histoire de la modernisation aux banques. De nouveaux cas d’utilisation du cloud hybride apparaissent, offrant des performances supérieures et une meilleure protection des données grâce à la colocalisation sélective de certaines charges de travail d’inférence, de traitement des données et de sécurité sur des mainframes, permettant aux équipes de bénéficier de l’élasticité du cloud et de la puissance toujours disponible du mainframe. Dans tous ces cas, déverrouiller la prochaine frontière de la productivité nécessitera de moderniser l’expérience de travail du développeur humain avec le mainframe, de sorte que les développeurs commerciaux expérimentés et les nouveaux talents puissent rejoindre l’effort de modernisation. Pour en savoir plus, consultez les autres articles de cette série :

• Partie 2 : « Utiliser la collaboration (et non la migration) pour moderniser vos applications mainframe avec le cloud »
• Partie 3 : « Miser sur la transformation numérique pilotée par le mainframe pour les services financiers »
• Partie 4 : « Le mainframe et le cloud ? C'est simple avec l'open source »

©2023 Intellyx LLC. Intellyx est responsable du contenu éditorial de ce document. Aucun bot d’IA n’a été utilisé pour générer une quelconque partie de ce contenu. Au moment de la rédaction du présent document, IBM est un client d’Intellyx.