SOA ne s'achète pas, SOA se construit

Voici le contenu d'un interview que j'ai donné au site Silicon.fr sur SOA.

Dans quels contextes SOA incarne-t-elle une démarche pertinente ?

Globalement, je citerai trois raisons qui présentent un intérêt évident pour une approche SOA. En dehors de ces trois situations, l’entreprise peut se passer de la démarche SOA.

• Première motivation : apporter de l’agilité aux processus métier. Dans certains secteurs (finance, services…), ces processus évoluent fortement. Or, s’ils sont “codés en dur” dans les programmes, la rigidité freine fortement l’agilité du système d’information qui ne peut s’adapter souplement pour répondre aux besoins évolutifs de l’entreprise. Avec une architecture SOA, les processus sont décomposés en briques élémentaires appelées services. Cela favorise les évolutions sans remettre en cause l’ensemble du schéma applicatif. Par exemple, une banque propose des services bancaires en marque blanche à d’autres acteurs. Or, chacun souhaite disposer de sa propre variante de processus tels que la souscription de crédit (traitement spécifique en cas de refus, limiter les étapes de validation…). En mode SOA, soit le processus présente une souplesse suffisante, soit la banque peut mettre en place des variantes d’un même processus pour un coût très raisonnable.

• Seconde situation favorable dans laquelle le SOA apporte une solution efficace : l’interopérabilité. Une caractéristique critique pour une entreprise nécessitant de forts échanges entre les briques de son système information, entre ses applications décloisonnées, ou pour communiquer avec les applications de ses partenaires, fournisseuse ou clients. C’est ce que j’appelle la “SOA de surface” : on ne sait pas forcément ce qui se trouve dans l’application, mais on déploie les interfaces nécessaires à la communication (e.g. Services Web). Ainsi, un groupe de transport dont les processus restent identiques doit pourtant se conformer à de nouvelles règlementations. Il ne modifie pas les processus applicatifs, mais uniquement l’interface des échanges.

• Troisième cas, moins fréquent que les deux autres : la rationalisation du SI. L’objectif consiste à réduire les occurrences multiples d’informations et d’applications ou fonctions. Il s’agit alors de travailler sur la qualité des données et des services applicatifs (MDM et autres outils de ce type). Si ce travail permet de réduire les coûts à moyen terme, on ne vise pas le retour sur investissement rapide, mais plutôt la cohérence du SI.

Quels éléments ou infrastructures favorisent l’élaboration d’une approche SOA ?

L’infrastructure ou les logiciels ne sont pas l’essentiel de la démarche, et les questions à leur sujet ne devraient pas se poser au départ. SOA est une philosophie de construction du SI sous forme de briques élémentaires et réutilisables. Or, cette notion de réutilisabilité provient de la qualité de l’interface et passe forcément par des formats pivots (description par message d’un processus métier, qui sera véhiculé lors des appels de services). L’intérêt consiste à mettre sur pied un vocabulaire commun à toute l’entreprise et à détecter les différences. Par exemple, la notion de “client” est différente selon les services, mais certains attributs sont communs. Alors, autant utiliser ce “plus petit dénominateur commun” de façon unique et le stocker dans un référentiel. Ainsi, en cas de modification et d’évolution, l’impact sera moindre et la maintenance des données largement simplifiée. Au final, une meilleure cohérence du SI et une productivité en hausse des informaticiens. On comprend alors pourquoi le référentiel est propre à chaque entreprise, à sa culture et ses métiers, et peut difficilement être vendu “prêt à l’emploi”.

En quoi l’architecture SOA diffère-t-elle de l’architecture applicative classique ?

Dans une architecture traditionnelle, on distingue trois couches : la couche utilisateur (avec le poste de travail et les interfaces homme-machine), les traitements et les données. Avec SOA, les traitements métiers sont séparés en Services élémentaires et en Services d’orchestration. Les premiers sont les briques de base que les seconds viennent compléter pour permettre la communication et les échanges.

À quel moment et où les logiciels peuvent-ils faciliter la démarche ?

Dans les solutions des éditeurs, la couche la plus stratégique reste le transport avec des logiciels comme MQ Series d’IBM ou JMS Sonic MQ de Progress, entre autres. En outre, lorsque les services se multiplient et se comptent par centaines, des suites logicielles deviennent indispensables pour comprendre ce qui se passe et orchestrer l’ensemble. Elles permettent d’industrialiser les tâches. De même, l’entreprise devra en déployer une pour assurer une ouverture contrôlée de ses applications dans des flux B2B. Cependant, SOA ne s’achète pas, mais se construit ! Signer un chèque à un éditeur ne sert à rien au départ du projet. Bien qu’il faille planifier cet investissement pour la suite.