TÉMOIGNAGE : « Les jobs technologiques dans les banques et le problème du legacy code… »

Si vous êtes un technologiste qui ne veut pas travailler dans une banque d’investissement, je pense savoir pourquoi. C’est parce que vous avez entendu parler des horreurs du code hérité. Beaucoup a été écrit là-dessus, mais tout n'est pas vrai.

J'ai effectué l’intégralité de ma carrière dans la technologie bancaire au sein de grandes banques américaines. La plupart du code que j’ai vu était testé à l'unité, testé par des pairs, et faisait partie d'un mécanisme d'intégration continue et relativement facile à déployer. La qualité des applications individuelles s'améliore. Mais le code hérité n’est jamais bien loin.

Pourquoi le code hérité est-il si problématique pour les banques ?

Pour comprendre pourquoi les banques ont un problème de code hérité, vous devez d’abord comprendre leur structure. Les départements IT des banques sont généralement les plus fournis en termes d’effectifs. Par exemple, 25% des employés de Goldman Sachs sont ingénieurs et JP Morgan emploie 50.000 personnes dans sa division technologique.

Cela signifie que l'équipe IT de JPMorgan est plus importante que celle de Facebook et celle d'Uber réunies. Cependant, il existe une énorme différence entre les problèmes auxquels sont confrontés les technologues travaillant chez Facebook et Uber, et ceux travaillant dans des banques d'investissement.

Chez Facebook ou Uber, vous travaillerez sur des problèmes simples sur le plan fonctionnel mais difficiles sur le plan technique. En comparaison, dans une banque, les problèmes sont plus susceptibles d’être simples sur le plan technique mais extrêmement difficiles sur le plan fonctionnel. Dans la plupart des banques, des milliers de développeurs sont organisés en silos, chacun essayant de résoudre des problèmes difficiles. Historiquement, c'était la recette pour des systèmes disparates et fragiles.

L’un des problèmes majeurs du système hérité dans les banques est qu’il faille suivre une seule transaction enregistrée par grande banque. Le nombre de systèmes et d'applications auxquels ladite transaction est confrontée au cours de son cycle de vie est stupéfiant. Elle sera modélisée d'innombrables fois à des fins différentes, avec des flux allant partout.

Si vous essayez de produire un diagramme pour la représenter, il ressemblera à une œuvre d'art abstraite. L'interconnexion, le couplage et la complexité organisationnelle impliqués dans ces liens et systèmes rendent les choses fragiles et très difficiles à changer. Par conséquent, si vous souhaitez améliorer une application existante, cela peut entraîner par effet papillon des modifications sur l'ensemble de la banque.

L’extension du problème des systèmes hérités dans les banques est illustrée par ce qui s'est passé lorsque la banque britannique TSB a tenté de fusionner des enregistrements et des comptes à partir de systèmes provenant du groupe Lloyds Bank avec les systèmes de leur nouveau propriétaire Sabadell :  le chaos qui en a résulté a entraîné une baisse de 4% du cours de l'action de Sabadell.

Les changements majeurs sont non seulement difficiles, mais ils sont aussi risqués sur le plan financier et opérationnel.

Les banques ne peuvent pas simplement fermer leurs anciennes applications

Les problèmes sont aggravés par le fait que les banques ne peuvent pas simplement fermer ces applications héritées. Google a récemment pris la décision de fermer Google+. Un produit et un écosystème complets sont passés à la trappe - le code ne nécessitant plus de maintenance. C’est le genre de luxe que les équipes techniques bancaires ne peuvent pas s’offrir.

La plupart des systèmes des banques sont conçus pour automatiser certains processus internes, ce qui est généralement une activité de longue durée. Il est très coûteux d'extraire et de retirer des systèmes, et souvent moins difficile de les réparer lorsqu’ils sont endommagés. C'est pourquoi vous voyez des systèmes vieux de plusieurs décennies, COBOL et autres technologies mainframe d’un autre âge.

Cela n’aide pas que les banques soient souvent dirigées par d’anciens traders et banquiers d’investissement qui refusent d’investir dans le renouvellement de la technologie pendant plusieurs années sous prétexte qu’il n’y a pas de retour immédiat sur cet investissement.

Les systèmes hérités sont un problème... politique

Le problème des systèmes hérités n’a pas été résolu par le nombre incalculable de technologues dans les banques. J'ai vu de grandes applications développées par des équipes de front office (traders ou banquiers) à Londres et à New York, avec un déploiement réussi, mais l'équipe a ensuite été réorganisée ou dissoute et l'application a été confiée à une autre équipe de Inde, avec peu ou pas de partage des connaissances.

C'est un problème particulier lorsque les technologues seniors qui ont atteint le rang de managing directors (MDs) technologie quittent la banque. Le nouveau remplaçant a ses propres idées, ce qui conduit les applications ou les plates-formes déjà développées à être laissées pour compte.

Comment les banques tentent de réduire les systèmes hérités (et rendent leurs emplois tech plus intéressants)

Croyez-moi, les banques savent que leur code hérité est un frein à l'embauche de technologues. - Personne ne veut être affecté à un système comportant des centaines de dépendances déconcertantes et datées.

JPMorgan est en avance à cet égard. La banque a participé à un programme relativement réussi et baptisé « Kill the Tail ». Il s'agissait d'un effort à l'échelle de la division technologique pour identifier et supprimer les anciennes applications si elles n'étaient plus nécessaires, ou pour réorganiser leurs fonctionnalités dans de nouvelles plates-formes stratégiques, puis les supprimer.

Deutsche Bank a fait la même chose dans diverses parties de ses implantations et cela porte déjà ses dividendes. C'est la preuve que la rationalisation de votre suite d'applications et de votre infrastructure peut vous faire économiser beaucoup d'argent à long terme.

Personnellement, je pense que la loi de Conway s'applique : « Les organisations qui conçoivent des systèmes ... sont obligées de produire des designs qui sont des copies des structures de communication de ces organisations ». Les dirigeants de banques ont beau dire qu’il s’agit d’entreprises de technologie, mais en attendant que leur organisation et leur fonctionnement soient modifiés en profondeur, ils sont condamnés à continuer de produire des systèmes incroyablement complexes.

Si j'étais patron d'une banque, j'achèterais l'une des banques numériques challenger pour voir comment modéliser et organiser une banque de détail ex-nihilo et l'adapter aux besoins d'une plus grande clientèle et d'une plus grande base de produits.

Sam Garrett est le pseudonyme d'un développeur travaillant pour une banque à Londres.

Vous avez un scoop, une anecdote, un conseil ou bien un commentaire que vous aimeriez partager ? Contact : tiochem@efinancialcareers.com