Devoxx : ESB in Financial Application

Cette année j’ai eu l’occasion de présenter un sujet sous la forme d’un Quickie à Devoxx. Il s’agit d’une mini-présentation limitée à 15 minutes, à l’heure du déjeuner. Au final j’ai bien aimé cette première expérience, en anglais et devant pas mal de monde mine de rien. Voici la présentation en français.

1. ESB in Financial Application

2. Objectif de la présentation

En quinze minutes, l’idée de cette présentation est d’expliquer les besoins rencontrés dans le monde de la finance en terme d’architecture. Où en sommes-nous aujourd’hui et quels outils pouvons-nous utiliser afin de réduire les coûts et améliorer nos architectures ?

3. Speaker’s Qualifications

Après 5 ans 1/2 chez Reuters, j’ai débuté une nouvelle activité en tant qu’indépendant. Je travaille actuellement chez BNP-Paribas sur une mission d’architecture. Je suis membre du Paris Java User Group.

4. ESB

ESB. Ce mot est à la mode. A Devoxx j’ai compté 4 conférences cette année. Mule est traité 3 fois par Antoine Borg avec qui j’ai eu le plaisir de discuter la veille, bref il se passe quelque chose. A noter qu’aucune conférence ne nous parle de téléphone portable, les thèmes cette année tournent autour de l’intégration, de la sécurité ou de SOA. Voyons un peu « dans la vraie vie » où nous en sommes aujourd’hui, car moi, plutôt que de parler de SOA ou d’ESB, j’aime bien parler du terrain avant tout.

5. A legacy application

Ce que l’on constate c’est que les applications vieillissantes dans le monde Java des applications de gestion et de la finance, se présentent avec un socle d’architecture bien connu. Autour d’une architecture trois-tiers, nous retrouvons souvent du Struts pour la partie Web, un serveur d’application avec encore beaucoup d’EJB 2.1, et les innovations des dernières années que sont Hibernate, Spring et JMS. Et il est clair que ce type d’architecture aujourd’hui en production est encore amené à perdurer pour quelques années.
Votre travail sera donc de faire vivre, d’améliorer ou de transformer ce type d’architecture.

6. A legacy application (cont.)

Dans la finance, une application web communique et échange des ressources avec le monde extérieur en utilisant un certain nombre de connecteurs techniques (boîtes vertes). Ce code est bien souvent du code développé au fur et à mesure des besoins. Il peut s’agir de lire un fichier, d’échanger via JMS avec une autre application, de faire appel à un web service, ou d’envoyer un email. Bref, du code massivement technique. Ce code est le socle de communication de chaque application de gestion.

7. Connect

Connecter.
Le besoin de Connecter différents systèmes. Ce besoin entraine un travail de médiation, de transformation et d’interconnexion entre systèmes. Je veux montrer ici qu’il y a forcément un besoin de connexion, au minimum avec une base de données relationnelles, mais bien souvent avec d’autres systèmes informatiques ou techniques. C’est une composante fondamentale de nos solutions, de ce que nous sommes appelés à développer.

8. Ecosystem

J’ai représenté sur ce slide une application financière typique de création de rapports, utilisé sur une plateforme de Prime Brokerage. Ce que nous voyons tout d’abord, c’est que cette application a besoin d’un environnement pour fonctionner, un écosystème. Cet écosystème est composé d’un grand nombre d’applications, maintenu par d’autres équipes que la mienne.
Mon application est représentée au milieu avec ses 3 services internes.

9. Ecosystem 2

Cette application utilise les données du marché ainsi qu’un service de tenue de Position. Aujourd’hui les échanges entre les systèmes s’effectuent avec des fichiers plats via des répertoires partagés ou via JMS. Dans le livre Enterprise Integration Pattern, une excellente présentation explique les avantages et les inconvénients de ces 2 types d’échange.

10. Ecosystem 3

Au delà des échanges de mon application, ce qui est encore plus intéressant c’est de constater que les autres applications échangent elles-aussi des informations entre elles. Il faut donc bien voir que nous sommes là face à un vrai réseau de communication, de médiation et d’échanges. C’est le coeur d’une architecture financière.

11. Ecosystem 4

Au final je dois prendre en compte que mon application cohabite, échange et transfert ses données avec un nombre assez important d’applications. Je ne rentre pas dans les détails de la partie métier, car l’idée ici n’est pas de vous donner un cours de finance des marchés, simplement d’expliquer que les systèmes sont massivement connectés en un réseau.

12. Ecosystem 5

… En forçant un peu le trait, je peux faire une analogie avec un réseau social comme FaceBook : mon application fait partie d’un réseau, d’autres applications m’envoient des messages, observent même les données que je produis sans que je ne le sache, il y a donc clairement un besoin important à résoudre : ce besoin de communication et d’échanges avec mes « amis ».

13. Collaborate

Collaborate en anglais, difficile à traduire avec le même sens en français.
Collaborer c’est apprendre à se connaître : lorsque mon application échange avec d’autres systèmes financiers, au delà du problème technique à résoudre il y aura une interaction humaine. Et donc, ESB ou non, SOA ou non, ce projet d’inter-communication doit s’accompagner de la définition d’une langue pour se comprendre, d’un média pour discuter et d’un contenu pour s’entendre.
Revenons un peu à notre application financière type pour parler d’un facteur très important : le temps.

14. Timebox and Adaptive

J’ai sélectionné ces deux photos du métro afin d’illustrer un facteur important dans les applications financières : l’importance de l’heure de la journée. Prenons le métro de Paris : le matin entre 07h00 et 09h00 il y a un métro chaque minute. A 14h il y a un métro toutes les 6 minutes. A 23h00 il y a une rame toutes les 15 minutes.
Le nombre de rame de métro par heure s’adapte selon les heures d’affluence.
Qu’en est-il de mon application financière ?
Chaque matin celle-ci a besoin de 10 fois plus de puissance qu’en pleine journée, car la génération des rapports doit s’effectuer à la fermeture du marché boursier, dans un intervalle de temps limité. Il n’est pas possible de lancer la génération tant que le marché est ouvert. D’autre part celle-ci doit s’effectuer avant l’ouverture du marché suivant, en Asie. De fait, nous nous retrouvons avec une architecture qui doit répondre à des demandes fluctuantes selon l’heure de la journée.
Mais le plus important est que notre application n’a pas le droit à une deuxième chance. Lorsqu’un bug survient, il faut que l’erreur soit corrigée avant l’ouverture du marché, et ce phénomène n’est pas contrôlable.
Enfin on constate que passé les quelques heures d’activité, la plateforme est ensuite peu sollicité en cours de journée.
Or le souci, c’est qu’aujourd’hui mon architecture n’est pas écologique : 16 serveurs de calcul de risk tournent en permanence, 4 serveurs d’applications sont sollicités pendant la journée mais l’utilisation des ressources est assez inégale durant la journée.
Il faut donc retenir que dans la finance, l’utilisation des ressources et la quantité des échanges avec les autres systèmes varient au cours de la journée. Cependant nous savons à l’avance nos besoins, et donc idéalement notre système devrait pouvoir s’adapter et se programmer comme le réseau de transport parisien.
Un site internet qui vend des ordinateurs pourrait être surpris de l’affluence de visiteur. Pas une application financière : il est possible de connaître à l’avance les besoins en énergie. Mais pourtant, il est difficile aujourd’hui de régler et d’adapter cette énergie.

15. Crisis

2008 marque le début d’une crise financière, qui aura un impact dès demain sur les budgets des projets dans le monde de la banque et de la finance. Nos besoins de connexions avec les autres applications financières demeurent. Je pense même qu’il y aura de nouvelles réglementations pour éviter certains dérapages de 2008. Vu la nervosité des marchés financiers, les calculs de VaR, de risque, d’appel de marge, de collatéral sur notre application de Prime Brokerage vont aussi certainement être plus intensif… Bref il va y avoir du sport en 2009.

16. Predictions for 2009

ll est donc facile d’imaginer ce qui nous attend : avec moins de budget, moins de liberté et plus de pressions, il va falloir trouver des solutions rapides, économiques et capables de faire réaliser des économies. Pour ma part, un calcul de risque c’est un appel de marge pour un client. Si la plate-forme sur laquelle je travaille peut traiter 50 000 calculs au lieu de 10 000 car mon architecture évolue, alors je ferai gagner de l’argent à mon client.
D’autre part, vu la morosité et la crise du secteur de la finance, je pense que les solutions pragmatiques seront les gagnantes de 2009. J’ai peur que de gros projets basés sur les ESB des constructeurs souffrent du même phénomène que les constructeurs automobiles. Les gens veulent une voiture ? ils achètent une Logan et pas le dernier 4×4 à la mode.
Votre application a besoin d’un ESB ? Peut-être que Spring Integration, Mule ou Apache ServiceMix seront suffisants pour vos besoins, que les gros projets sur 6 mois auront plus de mal en 2009 à être validé par les DSI. Il est temps d’être pragmatique et d’arrêter de rêver sur des besoins que les grands éditeurs d’ESB nous ont peut-être inventé, comme les éditeurs de serveur d’app en 2000… Etre pragmatique, économe, écologique, réaliste.

17. Toolbox

En 2009 je pense que vous lirez des articles, que vous testerez, que vous entendrez parler de ces produits : Mule, Apache Service Mix, Apache Camel, Spring Integration, OpenESB project Fuji, Apache Synapse, Apache CXF, Jboss ESB… car ce sont des solutions qui répondent à un besoin : l’intégration légère en entreprise.
Après la guerre des serveurs d’application il y a quelques années, je pense que la prochaine grande bataille sera sur ce front. Les éditeurs du monde open-source savent que la demande va exploser, car lorsque la crise est là comme en 2001, le monde open-source tire son épingle du jeu. En 2002 personne ne se souvient mais c’était la grande époque des articles sur Linux dans 01 informatique, le Monde informatique ect. L’administration français a alors fait un grand pas en sélectionnant des solutions comme JBoss Application Server pour traiter… nos déclarations de revenus.
Economies, pragmatismes, simplifications, réductions des coûts…

18. A New Approach

Alors si nous repensons à notre application de gestion du début, voici comment je la vois en 2009. Tout d’abord le Web tiers a été déporté de mon architecture. Je ne fais pas une application Web, je fais d’abord l’architecture d’une application de gestion. Le web ne me coûte pas cher, j’utilise des frameworks légers sur une recopie en lecture seule de ma base de données. Seule une petite partie du code métier est partagée avec mon espace de données principal.
Ensuite on voit que j’ai cassé ce gros rectangle : je pense que des services sans états et légers sont suffisants pour effectuer les traitements de mon application. Là où auparavant j’utilisais la base de données pour stocker des données de travail, j’utilise désormais un espace mémoire en cluster afin de répliquer les données nécessaires à mes traitements de calculs. Cela demande plus de mémoire physique mais quintuple les performances de traitements. La base de données relationnelle n’intervient que via un service d’historisation qui effectue des captures de données afin de sauvegarder les données les plus sensibles, essentiellement pour un problème légal. Notez que la base est un petit carré bleu, car finalement elle ne me sert plus à grand chose.
Ces services reprennent la boîte à outil dont nous avons parlé tout à l’heure. Plutôt que de chercher à faire une grosse boite qui fait tout (un ESB au sens de certains) je crée un ensemble de services qui discutent et s’échangent des données. Et plutôt que de tenter de résoudre les problèmes de communication avec les applications extérieurs, de tenter de mettre en place un gros chantier afin de mettre tout le monde sur la même plateforme, je conserve et respecte les systèmes extérieurs, je m’adapte à eux, eux ne s’adaptent pas à moi. Et là je sais que mon application pour 2009 pourra continuer à exister sans couter une fortune.
Il faut donc oublier ce rêve qui serait de migrer toutes les applications de mon réseau vers un seul et même système. Ce serait un risque si l’éditeur disparaît (ce qui n’est pas exclu en ce moment). Ce serait la plus belle décision pour dégrader massivement les performances : pourquoi un système extérieure serait plus rapide que ce que mes équipes ont développé ? Ce serait un risque technique, un risque en terme de sécurité, et finalement, il faudrait attendre 6 mois avant de voir ce type de projet de gouvernance sur les rails.

Pour revenir à l’image du métro parisien, je rêve aussi de louer de la puissance machine plutôt que de l’acheter en utilisant par exemple Amazon EC2 et une solution comme Elastic Grid pour piloter mon parc informatique. Pour cette raison mon nouveau système est découpé en services sans état afin de faciliter une migration partielle et rapide de certains services vers ces nouvelles plate-formes de calculs et d’hébergement. La première banque qui aura déployé une plateforme de calcul de risque hostée comme un service sur internet gagnera certainement beaucoup d’argent.
Economies, pragmatismes, simples, réduire les coûts, arrêter de croire au père noël, pensez sur 6 mois…

Code code code
Ensuite j’ai un slide technique pour montrer un exemple d’utilisation d’Apache Camel. Lors de la conférence je n’ai pas eu assez de temps pour les présenter. Je vous ferrai un article complet sur Camel prochainement, donc revenez en janvier pour voir la suite.

Keep it simple

Pour connecter plusieurs systèmes il est tentant de faire n’importe quoi, de faire au plus vite ou de chercher une solution chère et trop complexe pour un problème. Soyez simple et vous réussirez à développer une architecture qui fonctionne.

Ne pas faire de l’intégration pour en faire…
Comme ces messieurs dans la piscine : ne cherchez pas à faire de l’ESB pour en faire, et faites attention à votre environnement. Un ESB ne remplace pas une réunion de pilotage avec l’autre équipe en face qui fait « l’autre » produit.

Don’t buy a solution

N’achetez pas les yeux fermés une solution. Au contraire, il faut que vos équipes retroussent leurs manches, repensez à des solutions simples. Dans le monde des applications de gestion, et de la Finance, le temps est certes à l’économie, mais aussi à un pragmatisme souvent contraire à nos envies d’architectes et de consultants.

The End

En conclusion : nous avons discuté des besoins en architecture dans le monde de la finance : connecter, échanger et collaborer, inter-agir avec d’autres systèmes. Les solutions d’intégrations légères seront en 2009 un moyen de réduire les coûts en évitant d’écrire à la main du code technique sans valeur ajoutée. Je souhaite dépiler un message JMS et envoyer un email, Mule m’aide à le faire en quelques heures au lieu de perdre mon temps avec du code sans valeur. Face aux réductions de budgets, il est logique de penser que les solutions d’intégration dans la finance auront le vent en poupe en 2009. Et face à cette crise, il y aura encore plus de travail pour nous, avec encore moins de budgets, d’où la nécessité de s’outiller enfin correctement.

Fin de la présentation
————————————————

Articles similaires:

Construire une application d'entreprise nouvelle génération avec AJAX en utilisant echo2, EJB et ServiceMix ESB JSR-296 Swing Application Framework Déployer une application Play! Framework sur Heroku Présentation de la JSR-296, Swing Application Framework