Miser sur la transformation numérique pilotée par le mainframe pour les services financiers

Ceci est la troisième partie d’une série en cinq volets sur la modernisation des mainframes.

Nous avons déjà abordé le fait que la modernisation des mainframes ne concerne pas uniquement le secteur financier. Par conséquent, pourquoi ne pas aborder le sujet qui préoccupe tout le monde ? Les plus grands défis de modernisation du monde sont concentrés dans le secteur bancaire.

Avant Internet et le cloud computing, et avant les smartphones et les applications mobiles, les banques effectuaient des paiements via d’immenses passerelles électroniques de règlement et exploitaient des mainframes comme systèmes d’enregistrement.

Les sociétés de services financiers sont considérées comme des institutions parce qu’elles gèrent et déplacent les principaux aspects de notre système économique mondial. Et le cœur battant des institutions financières est le mainframe IBM.

Les banques ont tout à gagner (et tout à perdre en cas d’échec) à adapter leurs applications mainframe et leurs actifs de données aux normes modernes de flexibilité, d’agilité et d’innovation cloud pour répondre à la demande des clients.

Nous avons récemment connu des incertitudes économiques mondiales, depuis la crise de 2008 dite « too big to fail » jusqu’aux taux d’intérêt élevés actuels post-pandémie, qui entraînent une surexposition et l’insolvabilité de certaines grandes banques dépositaires.

Bien que les faillites bancaires soient souvent le résultat de mauvaises décisions et politiques de gestion, il y a de bonnes raisons d’attribuer une part de responsabilité à des initiatives et stratégies de modernisation retardées. Les dirigeants n’auraient-ils pas pu effectuer de meilleures analyses pour repérer les risques dans les données ? Pourquoi n’ont-ils pas lancé de nouvelle application mobile ? Est-ce que quelqu’un les a piratés et bloqué les clients ?

Tout le monde sait qu’il y a un coût en termes d’opportunités à remettre à plus tard la modernisation des applications mainframe, mais certains pensent qu’il est risqué de modifier les systèmes qui soutiennent actuellement les opérations.

Les banques communautaires et régionales peuvent manquer de ressources techniques, tandis que les grandes institutions ont une dette technique écrasante, des problèmes de gestion des données à forte gravité ou peinent à gérer le business case.

Les banques, grandes et petites, ont probablement toutes échoué dans une ou plusieurs initiatives de modernisation ou de migration. Au fur et à mesure que les efforts sont gaspillés, les responsables informatiques au sein de ces entreprises avaient l’impression d’avoir plus à mâcher qu’ils ne pouvaient le faire.

La transformation de l’effort de modernisation ne devrait pas nécessiter une réécriture complète du code du mainframe, ni un exercice laborieux et coûteux de lift-and-shift. Les équipes devraient plutôt moderniser ce qui a du sens pour les priorités les plus importantes de l’entreprise.

Voici d’excellents cas d’utilisation des banques qui sont allés au-delà de la simple reprise des initiatives de modernisation pour améliorer significativement la valeur de leurs mainframes dans le contexte d’architectures logicielles hautement distribuées et des attentes élevées en matière d’expérience client.

De nombreuses banques ont peur d’adresse leur dette technique dans le code de leur mainframe existant, qui a peut-être été écrit en COBOL ou dans d’autres langages avant l’avènement des systèmes distribués. Souvent, les ingénieurs qui ont conçu le système original ne sont plus présents et les interruptions d’activité ne sont pas une bonne option. Les décideurs informatiques retardent donc la transformation en travaillant au niveau intermédiaire.

Atruvia AG est l’un des principaux fournisseurs mondiaux de technologies de services bancaires. Plus de 800 banques font appel à ses services innovants pour près de 100 milliards de transactions annuelles, soutenues par huit systèmes IBM z15 fonctionnant dans quatre centres de données.

Au lieu de tout remplacer, ils ont décidé de remanier sur place, en écrivant des services RESTful en Java en parallèle du COBOL existant exécuté sur les mainframes. En remplaçant progressivement 85 % de leurs principales transactions bancaires par du Java moderne, ils ont pu créer de nouvelles fonctionnalités pour les clients des banques, tout en multipliant par 3 la performance des workloads sur les mainframes.

La plupart des banques disposent d’un plan de protection des données qui inclut une certaine forme de redondance pour la reprise après sinistre (DR), telle qu’une copie principale du mainframe de production dans le centre de données et éventuellement une sauvegarde secondaire hors site ou une solution de bande virtuelle qui reçoit un nouveau lot de données tous les quelques mois.

À mesure que les volumes de données augmentent de manière inexorable, avec davantage de transactions et de points de terminaison d’applications, leur copie à l’aide de technologies de sauvegarde traditionnelles devient de plus en plus coûteuse et chronophage, et leur reconstitution est également lente, ce qui peut entraîner un écart en matière de reprise après sinistre. Il existe un besoin critique de sauvegardes et de restaurations plus rapides afin de sécuriser l’environnement informatique des banques modernes, y compris contre les ransomwares.

ANZ, l’une des cinq plus grandes banques d’Australie, souhaitait augmenter sa capacité à effectuer des sauvegardes plus rapides de son mainframe et améliorer les performances de sa reprise après sinistre afin de garantir une haute disponibilité à ses plus de 8,5 millions de clients.

Elle a mis en place une capacité de résilience intersite, en exploitant des serveurs IBM zSystems en miroir à l’aide de leur fonction HyperSwap afin de permettre des échanges de stockage multi-cibles sans interruption de service, car n’importe lequel des serveurs identiques peut prendre en charge les charges de travail de production si l’un d’entre eux est en cours de sauvegarde ou de restauration.

Les responsables informatiques d’ANZ ont désormais l’esprit tranquille grâce à une meilleure disponibilité du système, mais surtout, ils disposent désormais d’une solution moderne de reprise après sinistre certifiée pour assurer la continuité des activités de ses clients.

Les banques s’appuient sur l’analytique pour presque tous les aspects des décisions clés qui influencent la satisfaction client, la performance, l’investissement dans les infrastructures et la gestion des risques.

Les requêtes analytiques complexes sur des ensembles de données volumineux sur le mainframe peuvent épuiser les budgets informatiques et prendre des heures, voire des jours, à s’exécuter. Le transfert des données vers un autre emplacement, tel qu’un entrepôt de données dans le cloud, peut entraîner des délais de transport encore plus importants, ce qui se traduit par des données obsolètes et des décisions de mauvaise qualité.

Garanti BBVA, la deuxième plus grande banque de Turquie, a déployé IBM Db2 Analytics Accelerator pour z/OS, qui accélère les workloads de requêtes tout en réduisant la consommation CPU du mainframe.

La séparation des workloads analytiques des préoccupations et des coûts liés à l’environnement de production mainframe permet à Garanti d’exécuter plus de 300 tâches analytiques par lots chaque nuit, et un rapport de conformité qui prenait auparavant deux jours à générer ne prend désormais qu’une minute.

Les banques rivalisent pour offrir à leurs clients des applications et des services innovants. Par conséquent, des équipes de développement et de test agiles contribuent constamment à l’amélioration des fonctionnalités logicielles. Nous avons naturellement tendance à généraliser ces améliorations en les considérant comme des améliorations front-end des applications pour smartphones et des intégrations basées sur des API avec des services cloud.

Mais attendez, presque toutes ces nouvelles fonctionnalités finiront par toucher le mainframe. Pourquoi ne pas faire de l’équipe mainframe un participant de premier ordre au mouvement DevOps afin qu’elle puisse s’impliquer ?

Danske Bank a décidé d’intégrer près de 1 000 développeurs mainframe internes dans un mouvement de transformation DevOps à l’échelle de l’entreprise, en utilisant IBM Application Delivery Foundation for z/OS (ADFz) comme plateforme pour le développement de fonctionnalités, le débogage, les tests et la gestion des versions.

Même le code COBOL et PL/1 existant pourrait être intégré au pipeline de gestion CI/CD, puis ouvert et modifié intuitivement dans les environnements de développement intégrés (IDE) des développeurs. Fini les écrans verts. La Danske Bank peut désormais commercialiser ses offres en deux fois moins de temps qu’auparavant.

Lisez l’étude de cas de la Danske Bank https://www.ibm.com/fr-fr/case-studies/danske_bank_as

Même les nouvelles sociétés fintech « natives du cloud » auraient tout intérêt à réfléchir à la manière dont leurs propres innovations doivent interagir avec un environnement informatique hybride de contreparties en constante évolution.

Une transaction sur une application mobile finira néanmoins par atteindre les réseaux de paiement mondiaux, les entités de régulation et d’autres banques — chacune avec ses propres ressources de calcul et de stockage sur mainframe derrière chaque traitement de requête.

Il n’y aura jamais de voie à suivre unique, car chaque banque est unique, et de nombreuses transformations possibles pourraient être réalisées dans le cadre du parcours de modernisation des applications mainframe.

Les responsables informatiques doivent commencer quelque part et sélectionner les cas d’utilisation les mieux adaptés à leurs besoins métier et à l’architecture du parc d’applications unique dans lequel évoluera le mainframe.

Pour en savoir plus, consultez les autres articles de cette série :

• Partie 1 : « La modernisation des applications mainframe au-delà du secteur bancaire ».
• Partie 2 : « Utiliser la collaboration (pas la migration) pour moderniser vos applications mainframe avec le cloud »
• Partie 4 : « Mainframe et cloud ? C’est facile avec l’open source. »