Article écrit par Laurent Henriet et Sylvain Fagnent, paru dans la "Revue Banque" n°679 en avril 2006

Contexte

L'histoire se déroule dans un grand groupe bancaire français au sein d'une entité dédiée à la gestion et au pilotage d'une trentaine de filiales à l'étranger. Celle-ci a initié une démarche qui a pour objectif d'harmoniser les SI des filiales à l'étranger en proposant un ensemble de solutions progiciel et d'infrastructure standardisées. Pour des raisons de confidentialité nous nommerons Bank-ML le projet qui s'inscrit dans cette démarche en proposant un dictionnaire d'interopérabilité bancaire pour standardiser les échanges applicatifs.

Standardiser, pour quoi faire ?

Les Systèmes d'Information sont sujets à une évolution inexorable, l'entropie. De part le caractère évolutif des SI - évolutions métier, réactivité vis-à-vis de la concurrence, obsolescences technologiques - il est impératif d'adopter une attitude d'anticipation.

Les deux questions primordiales auxquelles sont confrontées les DSI sont :

· Comment développer plus efficacement mes applications ? Dans ce cadre, les leitmotivs sont d'éviter de réinventer la roue, de capitaliser sur l'existant et de disposer des solutions prêtes à l'emploi.

· Comment faire évoluer sereinement mes applications ? Il s'agit alors d'avoir prévu un couplage faible entre les applications ainsi qu'une manière homogène d'échanger des données.

Derrière ces deux questions, des gains de productivité sont bien évidement attendus.

La standardisation des échanges apparaît alors comme salutaire en apportant des solutions prêtes à l'emploi aux nouveaux projets et en anticipant les évolutions applicatives. Dans notre contexte, elle trouve un écho supplémentaire dans la prise en compte d'une multitude de SI disséminés au sein d'une trentaine de filiales.

La standardisation des échanges n'est donc pas un objectif, mais un moyen pour obtenir ces gains de productivité et contrer l'entropie naturelle des SI.

La standardisation peut être vue selon deux angles qui correspondent généralement aux entités commanditaires. Du point de vue des Référentiels Métier d'entreprise la standardisation consiste souvent à mettre en oeuvre un référentiel d'entreprise des données métier, une sorte de dictionnaire universel à utiliser : " le dictionnaire c'est la loi ". Au contraire, du point de vue des architectes techniques, la standardisation consiste généralement à mettre en oeuvre un outil informatique généralisé dédié aux échanges : " prenez un EAI et c'est gagné ".

Au confluent de ces 2 approches souvent antagonistes, le projet Bank-ML trouve son caractère novateur et son intérêt dans la conjonction du meilleur de ces 2 approches :

· Une standardisation métier centrée sur les échanges

· Une standardisation technique simple, facile d'accès basés sur des standards technologiques pérennes

Construire un seul dictionnaire bancaire pour tous nos échanges : standardisation métier

Le dictionnaire bancaire Bank-ML est constitué de mots (ex. CustomerName) associé à des définitions. Comme son utilisation est dédiée à la construction des flux applicatifs, les données présentes correspondent aux données publiques (i.e. échangées entre les applications contrairement aux données privées qui correspondent à des données utilisées uniquement en interne des applications).

Le périmètre volontairement réduit aux échanges de Bank-ML est un facteur de succès du projet. En effet, cela présente les 2 avantages suivants :

• Adhésion aisée par les projets : pas d'ingérence sur les modèles de données interne des applications,
• Maintenance facilitée : il permet aux équipes transverses en charge de la maintenance et de l'évolution de Bank-ML de maitriser plus facilement le dictionnaire.

Par ailleurs, Bank-ML est également un facilitateur de communication, il est partagé à la fois par les acteurs d'obédiences diverses et par les applications autour d'un unique support décliné en N formats documentaires[1] :

• MS Word pour les fonctionnels,
• Format technique pour les informaticiens,
• Intranet pour les maîtrises d'ouvrage.

L'expérience a montré que permettre à la fois aux équipe fonctionnelles, maitrise d'ouvrage et techniques de se réunir autour d'une même table en parlant un langage commun est un facteur essentiel permettant d'augmenter l'efficacité des développements applicatifs en amenuisant les incompréhensions et les divergences. Ainsi sans même passer à l'étape de standardisation des flux, Bank-ML est déjà un succès.

Implémenter les échanges dans un langage informatique commun XML : standardisation technique

Par respect de standard et de préconisations internes à notre groupe bancaire, le dictionnaire est implémenté au format XML (schémas XSD).

La description des flux, au même format XML (schémas XSD), se construit par assemblage des mots (champs) du dictionnaire. Les applications qui s'inscrivent dans le cadre de la normalisation Bank-ML, implémentent, comme elles le désirent, en tant que consommateur/producteur de données, les flux décrits par leurs schémas XML associés. En opération, ces mêmes applications échangent des données au format XML conformément à leurs descriptions préalablement conçues.

L'utilisation du dictionnaire pour modéliser les échanges présente alors des avantages :

• Au niveau des développements des projets : l'utilisation du dictionnaire réduit l'ambigüité par l'obligation de se référer à une définition unique des données. Les applications impliquées dans un échange convergent ainsi plus rapidement vers une spécification commune des échanges. Par ailleurs, l'échange de données fondées uniquement sur des échanges de fichiers XML facilite les tests de bout en bout. Il n'est pas nécessaire de " brancher directement les deux applications impliquée dans un échange " pour effectuer un premier niveau de test. Chaque application émettrice de données peut autovalider le format des fichiers de données XML produites et ensuite les proposer à l'application cible afin que celle-ci effectue un premier niveau de test d'intégration. L'offre d'outillages légers autour de XML disponible souvent en open source facilite grandement ces premières phases de validation. Lorsque arrive la recette de bout en bout, celle-ci s'en trouve sécurisée.
• Au niveau de l'évolutivité du SI : le remplacement d'une application par une nouvelle application est monnaie courante dans la vie des SI. L'objectif est alors de minimiser les impacts sur les autres applications susceptibles d'échanger des données avec la nouvelle. Nous sommes alors confrontés à une problématique d'évolution des flux de données. L'utilisation de Bank-ML pour la définition des flux dicte à la nouvelle application d'utiliser l'interface XML précédemment définie pour l'application remplacée. Ainsi même si une recette de bout en bout va toujours être nécessaire, la charge d'évolution ne concerne que la nouvelle application et pas celles concernées par les échanges. Bank-ML facilite ainsi la migration des applications.

Adopter une méthodologie de construction incrémentale du dictionnaire orchestrée par le gouverneur du dictionnaire

D'un côté, Bank-ML témoigne d'une approche formelle (démarche top-down), fruit de réflexions internes à l'entreprise sur son coeur de métier bancaire, de la capitalisation d'autres dictionnaires existant ou encore de normes bancaires internationales (ex. ISO, FP-ML, Fix-ML). Cette démarche est une approche " a priori " du dictionnaire, Bank-ML est construit en amont des projets. Si elle permet une capitalisation forte, elle ne doit pas être menée de manière dogmatique car cela présente le risque d'aboutir à un dictionnaire trop théorique et complètement décorrélé des projets et, donc, au final inutilisable.

D'un autre côté, la construction de Bank-ML est pilotée par les besoins d'échanges des projets (démarche bottom-up) répondant ainsi directement à un besoin concret. Il s'agit dans ce cas d'enrichir le dictionnaire par les nouvelles données nécessaires aux échanges des projets. Tout comme l'approche précédente, l'approche bottom-up ne doit pas non plus être menée de manière exclusive. Dans ce cas, elle aboutirait à une spécialisation du dictionnaire en divers branches correspondant aux applications dominantes et donc in fine à plusieurs dictionnaires ; ce qui est l'inverse de l'objectif recherché.

La réconciliation de ces deux approches trouve son salut dans l'organisation à mettre en oeuvre. Il est nécessaire de faire piloter la production du dictionnaire par une équipe transverse Bank-ML en relation avec les projets pour l'implémentation des échanges. Celle-ci va assister les projets dans la bonne utilisation et la compréhension du dictionnaire et faire bénéficier le dictionnaire de la capitalisation projet pour le faire évoluer. Elle intègre donc une activité de veille bancaire sur les normalisations en cours et une activité d'assistance projets sur la spécification des échanges.

Le succès de la démarche repose sur les épaules d'un véritable " Gouverneur du dictionnaire " ayant pour tache d'assurer la cohérence entre les normes et référentiels de la banque et les besoins des projets.

[1] L'outil de modélisation utilisé, XML Spy 2006 d'Altova, permet nativement la génération des différents formats documentaires cités.