Veille technologique #5 : SOA, urbanisation et agilité

Quelques notes que j'avais prise lors des remarquables Valtech Days des 23 et 24 octobre 2007.

Comment aborder la SOA dans son SI ?

Session présentée par Philippe Richard, architecte SI à la CDC et Yann LeTanon, consultant senior chez Valtech.

J’ai noté deux idées générales dans cette session :

– L’interaction SOA et urbanisation du SI
– L’approche agile, pour commencer rapidement en allant étape par étape dans la mise en oeuvre

Le concept d’urbanisation (rationalisation et alignement du SI sur les processus métiers), né dans les banques il y a une douzaine d’années, fait peur, car on lui attache en général l’idée d’une reconstruction complète du système d’information. Le concept de SOA (architecture de services), comme beaucoup de mot à la mode, a donné naissance à beaucoup d’outils, mais n’a pas vraiment abouti sur une démarche.

Ce que propose Valtech, c’est l’urbanisation comme démarche pour la SOA, et la SOA comme levier pour l’urbanisation.

Alors, comment ça marche ? Comment la démarche a-t-elle été mise en œuvre à la CDC ?

Première phase : le découpage par métier, sans du tout tenir compte de l’organisation :

– Banque
– Retraite
– Investissement
– Prêts
– Etc, mon but n’étant pas d’être exhaustif, mais de ressortir l’essentiel de ce séminaire.

Ensuite, une analyse du SI, fortement morcelé, avec par exemple :

– J2EE et IIS pour le Web
– PowerBuilder, Citrix, NSDk pour l’architecture client/serveur
– BO, Oracle, SAS pour le décisionnel
– Domino côté processus
– Excel, access, Interdev, forms pour les applications hétérogènes

Un SI comme une penderie dans laquelle on retrouverait toutes les modes. En bref, un SI comme tous les autres !

Troisième phase : la route vers la rationalisation.

On réduit le nombre de composants. On abandonne les technologies devenues obsolètes dans un temps fixé. On fixe un plan d’urbanisation. Et surtout, on généralise l’EAI.

Un nouveau palier :

– Un système d’information plus agile
– Un système modulaire, avec des couplages faibles entre les modules
– Des échanges normalisés, et réduits

Dans la stratégie à trois ans, deux grands objectifs :

– Une architecture technique orientée service pour l’infrastructure
– Une architecture applicative orientée service pour les métiers

Ces objectifs se déclinent dans la construction d’un SI en quatre couches :

– Niveau 1 / couche applicative : ressources applicatives, données et traitements, mainframe, progiciel, référentiel, bases de données
– Niveau 2 / couche de services : exposition du modèle pivot, langage commun du SI, web services, grammaire XML. Les composants services (par exemple, service virement, titre, compte) sont autonomes, et encapsulent toutes les règles métier et les règles d’intégrité. La façade des services permet de rationaliser l’accès au SI, de manière propre, et surtout indépendante de la couche applicative
– Niveau 3 / processus métier, orchestration (pas encore mis en place à la CDC)
– Niveau 4 / interaction avec les acteurs internes et/ou externes : web, portail, qui interagissent actuellement avec la couche 2.

Les étapes de la démarche, baptisée « Think Service » par Valtech :

– Construction de la cartographie du SI, partage de cette cartographie avec l’ensemble des acteurs et liste des échanges points à points
– Définition des règles d’architecture cible et passage des échanges point à point vers un échange de formats pivots
– Mise en place d’un réseau de référents applicatifs chargés de l’évangélisation SOA
– Montée en compétence de tous les collaborateurs de la DSI sur l’urbanisation et la SOA

L’application de la démarche suit ensuite la voie du pragmatisme : on prend les projets au fur et à mesure de leur apparition et on « Think Service ».

J’ai aimé ce retour d’expérience : ne pas mener une SOA en Big Bang, mais y aller étape par étape, et dans la partage. C’est un projet d’entreprise, un projet stratégique, que tous doivent s’approprier :

– Démarche : refuser la mise en place de tours d’ivoire, l’information doit redescendre, il faut fonctionner en réseau.
– Architecture : exploiter au mieux l’existant par la mise en place de façades par les services et utiliser une typologie de services simples.
– Organisation : la démarche SOA doit être portée par la direction et descendue vers le plus grand nombre, et non ps par quelques architectes experts en leur domaine.

La clé du succès : communiquer au plus tôt et concrétiser au plus vite.

A mon avis, bon nombre de projets ambitieux de refonte de SI et d’urbanisation se sont plantés pour ne pas avoir su suivre cette voie.