SOA : des architectures pas conçues pour les métiers

Vincent Berdot, Alain Clapaud et Thierry Jacquot

01 Informatique

le 05/12/2007 à 07h00

envoyer
par mail

imprimer
l'article

sommaire

SOA : des architectures pas conçues pour les métiers

Imposer des outils de gouvernance

Découper et calibrer correctement les services

Le long chemin vers la normalisation de larchitecture

Des plates-formes intégrées encore jeunes

Les spécialistes de linfrastructure visent les métiers avec SOA

Les éditeurs de plates-formes cohabitent avec les spécialistes

Yves Caseau (Bouygues Télécom): éditeurs de solutions, adressez-vous mieux au métier

Voir tout sommaire  

Les architectures orientées services (SOA) sont porteuses de la plus belle promesse de l’informatique : aligner le système d’information (SI) sur l’organisation de l’entreprise, et ce par l’entremise de services métier. Leur orchestration est censée traduire les processus de la société. Ces composants métier pilotent et orchestrent à leur tour des applications ou des programmes. Le processus n’est donc plus promu par les applications, mais par cette couche intermédiaire, formée par les services métier. Elle garantit au processus une étanchéité vis-à-vis des modifications effectuées dans le SI. Quels que soient les bouleversements de l’infrastructure technique, les contrats des services restent identiques. Pour parfaire le tout, ces services sont conçus, appelés, et orchestré via des protocoles normalisés.

Dans les faits, les premières mises en œuvre des architectures SOA n’ont toutefois pas cette couleur métier. Ou si peu… Elles ont majoritairement été déployées par les techniciens… pour les techniciens. Principalement à des fins d’intégration de données, notamment pour exploiter les traitements d’un mainframe dans une architecture distribuée, préparer des jeux de données pour une application, ou synchroniser des référentiels. “ Dans la plupart des cas, les architectures SOA répondent aux mêmes problématiques que l’EAI (intégration d’applications d’entreprise – NDLR). A la différence qu’elles ne reposent plus sur des connecteurs propriétaires ”, admet Willy Seymour, en charge du BAM et du management des processus métier (BPM) chez Devoteam.

Est-ce à dire que le modèle SOA ne bénéficie pas aux métiers ? Certainement pas. Mais ces derniers se retrouvent souvent devant le fait accompli, à savoir une architecture orientée services conçue et bâtie par le SI. Les spécialistes de la modélisation de processus reconnaissent d’ailleurs ces approches “ bottom-up ” de la SOA : “ les entreprises viennent nous consulter pour savoir comment exploiter leur existant BPM ou SOA ”, explique Antoine Lonjon, directeur des méthodes chez Mega.

Traduire les processus en métiers est une priorité

Plusieurs raisons expliquent cette relative distance des métiers vis-à-vis des architectures SOA. “ Le principe de cette couche intermédiaire n’a pas été compris, et donc pas mis en œuvre ”, analyse Servais Bonazebi, architecte SOA chez Devoteam. Et pour cause : les fournisseurs de plates-formes SOA (IBM, BEA, Tibco, Webmethods, etc.) ont fourni aux informaticiens tout l’attirail pour déployer leurs services techniques. “ Mais les métiers, eux, n’ont eu que des discours ”, poursuit-il.

Bernard Debauche, spécialiste BPM chez Axway, regrette lui aussi que le centre de gravité des suites SOA soit trop technique. Il stigmatise, par exemple, la notion de gouvernance SOA, pourtant très en vogue chez les éditeurs. “ Limiter la gouvernance aux services constitue une aberration. Par essence, elle s’applique à toutes les strates de l’entreprise. Autant aux couches basses, avec la gestion des flux de données, qu’aux processus et articulations des métiers de l’entreprise. ”

Peut-être aussi que le Big Bang qui devait accompagner le déploiement des architectures SOA était irréalisable. Précisément celui qui imposait à l’entreprise de remplacer ses silos fonctionnels (achat, gestion des stocks, facturation…) par une organisation orientée vers des processus transversaux (prise de commande). “ Cette transversalité s’avère beaucoup plus compliquée à déployer qu’une architecture orientée services ”, ajoute Bernard Debauche.

Aujourd’hui, la priorité porte sur les méthodes de traduction des processus en services (métier et techniques). Nombre d’acteurs travaillent sur cette problématique, à commencer par les sociétés de conseil comme Unilog ou IBM Global Services. Elles s’appuient sur de nouvelles méthodologies (Praxeme ou Soma) pour décliner des vues métier en services. De leur côté, les éditeurs de modélisation de processus tels que Mega, IDS Scheer, ou Casewise tentent de formaliser des cadres théoriques. Même les éditeurs d’infrastructure cherchent, désormais, à flirter avec les couches fonctionnelles, en lançant des packages métier alignés sur des secteurs d’activité.