Par : Pannerselvam D, AVP, Intellect Design Arena
Les services basés sur l'informatique en nuage tels que SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) et NaaS (Network as a Service) sont devenus des mots à la mode sur le marché. Selon un rapport, le marché mondial de l'informatique en nuage était estimé à 219 milliards de dollars en 2020 et devrait atteindre 791 milliards de dollars d'ici 20281. Si la pandémie a joué un rôle clé dans le passage des entreprises à l'informatique en nuage, d'autres facteurs ont contribué à cette évolution. Certains d'entre eux sont la réduction des coûts de maintenance, l'adoption plus fréquente de technologies telles que l'IA et la ML et l'augmentation du financement de l'informatique dématérialisée par les pays développés.
S'il est logique que les banques passent à l'informatique dématérialisée pour améliorer l'évolutivité, réduire les problèmes de maintenance et les coûts, la simple migration vers l'informatique dématérialisée n'est pas toujours la solution. Au fur et à mesure que la banque se développe, il en va de même pour ses produits et les applications qui les supportent. Il se peut que ces applications continuent à fonctionner en silos. Par défaut, cela signifie que la banque n'a pas une vue d'ensemble. Ce n'est pas tout, il y a plus.
Comment une banque doit-elle se préparer à une montée en puissance continue ? Les API peuvent-elles être la réponse ?
Comme nous l'avons déjà mentionné, l'un des principaux problèmes rencontrés par les banques est la gestion de différents types d'applications dans leur paysage informatique. Lorsqu'il y a un grand nombre d'applications, l'interfaçage de ces applications devient une tâche fastidieuse. Prenons l'exemple d'une grande institution financière diversifiée de la région APAC qui fournit une gamme complète de produits et de services financiers à des clients institutionnels et individuels. La banque disposait de plus de 300 applications mises en œuvre à l'aide de différentes technologies, toutes à des stades différents. De ce fait, la banque a été confrontée à plusieurs difficultés dans l'interfaçage de ces systèmes. En voici quelques-unes :
1. Gestion de plusieurs systèmes d'interface : Chaque système avait besoin de ses propres fonctions d'interface pour se connecter à divers autres systèmes en aval. Cela a conduit à la mise en œuvre de fonctions d'interface similaires dans tous les systèmes.
2. Coût et temps énormes pour toute demande de changement : L'interface du système en aval ayant été modifiée, toutes les fonctions d'interface des applications concernées ont dû être modifiées. Ces changements d'interface étaient coûteux et nécessitaient des périodes de mise en œuvre plus longues.
3. Difficultés à maintenir les documents d'interface : En raison du grand nombre d'applications, la banque a eu du mal à maintenir les documents d'interface pour toutes ces applications.
4. Difficultés dans l'analyse d'impact : La banque a eu du mal à réaliser l'analyse d'impact des changements d'interface et il y a eu des cas d'interruption de la production en raison d'une analyse d'impact incorrecte.
5. Coût élevé des licences : Les fonctions d'interface de certaines applications étaient déployées dans des logiciels intermédiaires spécifiques tels que JBOSS, ce qui a entraîné des coûts de licence supplémentaires pour la banque, en plus des coûts liés à l'application.
Les API peuvent être la réponse à ces problèmes. Une API est un ensemble de règles qui guident les ordinateurs ou les applications pour qu'ils communiquent entre eux. Les API agissent comme une couche intermédiaire entre l'application et le serveur web, traitant le transfert de données entre les systèmes2.
External API hub : Cette couche comprend des conteneurs d'API pour chaque système frontal proposé par la banque, ses filiales et d'autres sociétés Fintech. L'objectif de cette couche est de mettre en œuvre les exigences fonctionnelles du système frontal et d'éviter toute logique dans le système frontal. On peut également l'appeler Backend for Frontend System.
Les fonctions du hub API externe sont les suivantes :
Authorization : Autorisation de l'accès à l'API de chaque système frontal avec Red Hat Single Sign-On.
Agrégation : Invocation de plusieurs API internes et agrégation des résultats pour le système frontal.
Transformation : Transformation des messages de demande et de réponse en fonction des besoins du système frontal, comme le filtrage, le formatage des données, la conversion des messages, etc.
Cache : Servir des paramètres ou des données statiques au système frontal.
2. Centre API interne : Cette couche comprend des conteneurs d'API pour chaque processeur de produit ou système dorsal. L'objectif de cette couche est de servir des API standard par le biais d'une transformation. Par exemple, dans le cas d'un distributeur automatique de billets, les messages sont convertis du format ISO au format JSON à des fins de normalisation.
Cette nouvelle conception du centre API aide la banque à :
Normaliser les interfaces API : API Hub a veillé à ce que toutes les interfaces API soient au format JSON et qu'elles respectent la conception standard de l'API. Cela a permis aux développeurs de comprendre facilement les spécifications et l'utilisation de l'API.
Maintenance des enregistrements : Les spécifications de toutes les API ont été consolidées et conservées dans le cadre d'API Hub et sont facilement accessibles à tous à titre de référence.
Réduction du coût des licences : Les API ont été développées dans le cadre Apache Camel et déployées en tant que microservices dans la plateforme de conteneurs RH OpenShift. Cela a permis de réduire le coût des licences des instances JBOSS individuelles requises pour la fonction d'interface de l'application.
Analyse d'impact et demandes de changement : Conformément à la conception de l'API Hub, les applications ont été connectées à un seul système (API Hub) au lieu d'être connectées à plusieurs systèmes en aval. L'analyse d'impact et les demandes de changement ont donc été gérées en douceur.
Amélioration des performances : La conception de l'API Hub a permis de réduire le temps de réponse des fonctions frontales, au lieu d'invoquer plusieurs API à partir du système frontal. Prenons l'exemple du transfert de fonds : diverses validations, contrôles AML, limites de compte et OTP ont été vérifiés par le biais d'appels d'API parallèles, puis le transfert de fonds proprement dit a été lancé. Les appels d'API parallèles ont permis de réduire le temps de traitement de chaque activité.
Conclusion
Les banques du futur ne se contenteront pas de répondre à nos besoins en matière de banque et d'investissement, mais agiront comme un guichet unique pour tous les besoins liés à l'argent. Tout comme le nuage, une API n'est pas non plus une pilule universelle pour la transformation numérique. Les banques devraient investir dans des plateformes "cloud-natives" qui sont complètes, résistantes à l'avenir, évolutives et agiles.
Sources d'information
1. https://www.fortunebusinessinsights.com/cloud-computing-market-102697
2. https://www.ibm.com/cloud/learn/api