Les systèmes distribués

La finance de marché utilise depuis plusieurs années les systèmes distribués pour répondre à ses besoins de calcul ou de stockage. Ainsi, la taille des grilles de calcul utilisées aujourd’hui en finance rendrait jaloux bon nombre de laboratoire de recherche. Or dans un environnement distribué, le développement applicatif change totalement. Il faut programmer pour la distribution.



Défis techniques


Que ce soit pour le calcul ou le stockage, faire du distribué n’est pas simplement une tâche technique. Cela nécessite très souvent une compréhension profonde de la nature des calculs ou de la structure des données stockées.

L’expérience a montré que malgré une puissance nominale très grande, un système distribué peut devenir moins performant qu’une machine simple si les applications ne sont pas adaptées.

Ces sujets touchent donc au cœur du métier de l’ingénieur. Il faut comprendre la finalité de l’application, le fonctionnel et comprendre l’architecture, la technique et ses impacts sur le code, pour optimiser le tout.



Missions


Les projets types qui mettent en jeu un environnement distribué sont :
  • Utilisation d’une grille de calcul pour des simulations de Monte-Carlo
  • Utilisation d’une grille pour d’autres calculs parallélisables
  • Optimisation de l’utilisation de la grille pour réduire les temps de calcul
  • Optimisation des données transitant entre les serveurs pour réduire le besoin en bande passante
  • Mise en place d’un cache distribué



Avenir


Pour le calcul, les systèmes ne grossissent plus en machines mais en cœurs. L’avenir court terme, c’est l’utilisation de ces cœurs. Dans le domaine du calcul de risques par exemple, la puissance de calcul des grilles va permettre d’affiner les indicateurs et de mieux  maitriser les risques de marché ou de contrepartie. C’est évidemment un sujet sur lequel les banques comptent dans les prochaines années.

Pour le stockage, les volumes vont très certainement continuer d’augmenter. La finance de marché n’est pas encore rassasiée en données et elle génère chaque jour des milliers de téraoctets venant s’ajouter à un historique déjà grand. L’utilisation de ce volume de données est clairement identifiée par les acteurs de la finance comme un enjeu majeur pour rester concurrentiel.

La gestion des données en temps réel

Les systèmes temps-réel sont des programmes qui doivent garantir un temps de réponse très court, de l’ordre de la milliseconde. En finance de marché, les activités telles que le market making ou l’arbitrage nécessite un traitement en « temps-réel » des données reçues du marché. En effet, le moindre décalage par rapport au prix du marché entraîne des pertes et les meilleurs acteurs sur ces activités sont souvent les plus rapides.



Défis techniques


Le “temps-réel” est un domaine à part entière de la programmation. Cette contrainte nécessite des techniques particulières qui diffèrent de la programmation classique. C’est toute la chaîne de traitement des données qui nécessite d’être conçue pour le temps-réel, il ne suffit pas d’adapter une partie du code.

Avec le temps-réel, on touche également aux problématiques d’infrastructure et de réseau. Il faut connaitre et comprendre ces contraintes pour concevoir un système temps-réel performant.



Missions


La finance de marché exige souvent des applications rapides. Nos consultants interviennent donc très souvent sur des applications dites haute-performance qu’il faut optimiser en permanence.

Les véritables systèmes temps-réel vont un cran plus loin. En général la donnée perd de son utilité à mesure que le temps de traitement se rallonge. La mission de nos consultants est donc de garantir un temps de traitement court dans toutes les situations.



Avenir


La finance s’automatise de plus en plus. Cette automatisation s’accompagne d’une course à la performance. Les missions de conception et d’optimisation de systèmes temps-réels vont donc continuer.

L’étape suivante pourra être d’intégrer des traitements de plus en plus complexes dans la chaine temps-réel, comme des calculs de risques temps-réels ou des algorithmes d’arbitrage de plus en plus sophistiqués.

La diminution de la dette technique

La dette technique est un concept économique appliqué à l’informatique. Elle correspond à une dette néfaste car elle ne produit aucun bénéfice. Elle s’installe notamment à cause du manque de temps consacré à la conception et du non-respect des règles de codage, etc.

Dans un projet informatique, la qualité s'oppose au respect des délais et des coûts de réalisation. Lors de la construction d’une application et de l’ajout de nouvelles fonctionnalités, il faut faire un choix : qualité, coût ou délai ? Le délai l’emporte souvent !  La qualité est sacrifiée à long terme pour atteindre l'objectif prioritaire à court terme : sortir une nouvelle version rapidement. Ainsi on contracte une dette pour en retirer un bénéfice immédiat. Négliger la conception, c’est comme emprunter de l’argent et rembourser sur le long terme.



Défis technique et économique


La dette qui s’accumule épuise les ressources projets et démotive les équipes. Des applications construites sans plan deviennent chères à maintenir et difficiles à faire évoluer. Tout au long de la vie d’une application, les équipes IT remboursent cette dette presque inconsciemment. 

Les architectes sont devenus des experts de travaux « sans plans », occasionnant de nombreux coûts cachés : lenteur des nouveaux développements et perte d’agilité au changement, augmentation des coûts de support et de maintenance, baisse de la satisfaction des utilisateurs, projets qui glissent et TTM qui s’envolent…

Des solutions existent pour éviter la dette :
  • Construire le plan de l’application pour connaître l’existant et maîtriser les développements futurs
  • Refactorer l’application



Missions


Nous sommes convaincus que la phase de conception et de compréhension de l’existant est la condition sine qua non préalable à toute décision stratégique et la base de travail indispensable à tout projet de développement. Par ailleurs, nous savons que la migration et le refactoring automatisés sont des procédés efficaces et réducteurs de dette technique.

Pour réduire la dette technique des SI, nous :
  • Auditons des S.I. à dette technique importante : l’outil interprète des SI complexes et volumineux
  • Transformons un existant en un S.I. à faible dette technique : la technologie, la méthodologie, les coûts et les délais sont maîtrisés.
  • Maintenons la faible dette technique des S.I. en production : grande agilité au changement et coûts de maintenance faibles
  • Construisons des S.I. à faible dette technique
     
Pour transformer les S.I. nous avons créé CodeCaseSoftware (Cf. lien du site)



Avenir


Dans l’IT en finance de marché, la tendance est plutôt au décommissionnement et au re développement from scratch des applications… Pourtant, de tels projets coûtent cher !

À l’heure où les SI vieillissent et où les budgets se réduisent, comment allier baisse des coûts et optimisation des performances des SI vieillissants ?

La dette technique est donc plus que jamais un sujet d’actualité qui ne va cesser de prendre de la place dans les réflexions stratégiques des décideurs IT. Comment la combattre quand elle est déjà installée dans un projet ? Comment l’éviter à la construction d’un projet ?
Aujourd’hui, optimiser l’efficacité des méthodes de développement et capitaliser sur l’existant est en parfaite adéquation avec les exigences de réduction budgétaires en vigueur.

Les créateurs de CODE CASE sont convaincus que l’industrialisation et l’automatisation des développements est l’avenir de l’IT.

Nous faisons le pari que pour réduire la dette technique, l’automatisation est la clé !