Beaucoup de critiques. En cause, le décalage trop criant entre les promesses avancées par les promoteurs des architecture SOA et les résultats «on the field». En effet, qu’ils se soient soldés par des succès ou des échecs, ces projets ne font pas, ou si peu, appel à des «processus transversaux», à des «services métiers réutilisables», encore moins à des «architectures évolutives»…

Déception. Et, parfois, rejet. Résultat: les SOA ne font plus partie des priorités des responsables informatiques, estime Gartner. Début 2009, le cabinet d’analystes les plaçait en dixième position dans ses prévisions de budgets, alors qu’elles font toujours l'objet d'une grande promotion de la part des fournisseurs… Mort annoncée? «Non, fin d’une époque. Et début d’une nouvelle, rectifie Sylvain Bouxin, Partner Integration, Cream. Entrez confiants dans l’ère SOA 2.0!»

On nous avait promis la fin des silos, autrement dit la fin de la logique applicative; on pensait que les processus faisant intervenir des composants métier mutualisés par les différentes divisions de l’entreprise allaient prendre le relais…
Dans les faits, ces architectures répondent la plupart du temps à une logique avant tout technique. Aujourd’hui, très clairement, on exploite davantage les fondements techniques des architectures SOA. «C’est dommage, regrette Sylvain Bouxin. Mais faut-il s’en étonner? Dans les organisations, il y a encore confusion entre SOA ou EAI, même si l’on remplace les connecteurs par des services web. En cause, l’industrie: les SOA ont été prioritairement et largement promues par des fournisseurs de middleware. CQFD!»

Dans cette approche, le business est le parent pauvre, quand il n’est pas carrément absent de la démarche. Le dialogue n’a pas été établi; on n’a pas trouvé de terrain commun d’échange et d’enrichissement. «Pas de succès sans un dialogue direct, sans une communication permanente. C’est de la qualité du dialogue que naît l’alignement de l’informatique avec la stratégie et les objectifs métiers.»

Une gageure pour certains. De fait, pour établir le dialogue, il faut pouvoir transgresser les règles et les frontières traditionnelles. Et comme les projets SOA sont encore sous la responsabilité de l’IT, le premier pas leur revient… Sera-t-il franchi? «Dans certains cas, il s’agit bien de nouer ce dialogue que l’on a tout simplement négligé; dans d’autres, il s’agit de le renouer parce qu’on a commis l’erreur de laisser travailler distinctement les spécialistes de la gouvernance et les spécialistes de la technologie, ce qui n’a pas mené les projets bien loin, sans compter les conflits d’intérêt.»

Dialoguez, répète Cream à ses clients. Les outils ne manquent pas. Exemple, les wikis -ces zones d’échange ouvertes qui jouent le rôle de bouillon de culture. Un de ses plus beaux succès est d’avoir créé le contact entre des juristes sans connaissance aucune de l’informatique et des architectes IT. Les premiers parlent spontanément de leur métier, de leurs contraintes et de leurs espoirs; les seconds, désormais en phase avec leurs réalités, s’estiment plus à même de développer les services attendus.

Autre conseil: ne pas voir trop grand. L’approche «big bang» ne fonctionne pas, ou mal. Place aux approches pragmatiques, à l’échelle d’un département, d’un processus ou d’une petite entreprise. Des projets locaux qui, s'ils connaissent le succès, par exemple à travers un PoC (Proof of Concept) s'étendront naturellement à l'échelle de l'entreprise. «Priorité aux quick wins par opposition aux usines à gaz, résume Sylvain Bouxin. C’est rassurant pour les différentes parties, y compris pour la direction qui sponsorise le projet. Et, surtout, c’est la meilleure garantie pour inscrire le projet dans la continuité.»

Bref, une démarche itérative, progressive. Les promesses d'agilité sont conditionnées à cette politique des «petits pas». Il ne suffit pas d'exposer les applications existantes via des technologies plus récentes, ni de développer de nouveaux services pour garantir leur réutilisabilité, voire l'agilité globale du système d'information. Des principes d'agilité doivent gouverner la conception des architectures SOA.

Visez et faites simple, conseille encore le spécialiste de Cream. Car d'autres risques menacent: prolifération anarchique des services, perte de contrôle sur les interdépendances entre les éléments du système d’information, complexification de celui-ci...

«Les SOA doivent s'inscrire au cœur d'une approche visant à moderniser l'architecture de l'entreprise… et pas seulement sa mécanique informatique. Aussi, ne les considérez pas comme un projet informatique en soi.» A l'évidence, un projet SOA n’est ni vertical, ni horinzontal. Une approche holistique s'impose, couvrant l'ensemble de l'entreprise, de ses métiers à son infrastructure.

«Refusez d’introduire une quelconque ‘black box’ censée tout faire, conseille vivement Sylvain Bouxin. Gardez la maîtrise! Un projet SOA est un moyen, pas une fin en soi. C’est pourquoi, chez Cream, nous insistons tellement sur l’éducation. Investissez-vous, impliquez-vous pour préserver votre indépendance. Trop d’échecs résultent d’une perte de contrôle.»

° Gouvernance forte tout en faisant preuve de flexibilité et de créativité
° Ecoute permanente tant du management que du business
° Education (formation) pour garder la maîtrise dde la démarche
° Pas de théorie, mais concrétisation à travers de petits projets concrets
° Cycles courts (1 semaine) aux objectifs concrets

Avant de s’installer à Bruxelles, Sylvain Bouxin a fait ses armes dans les régions «SOA advanced», essentiellement dans les pays anglo-saxons. Exemple, ce projet en Angleterre. La démarche SOA devait englober 16 projets couvrant des applications administratives diverses (time tracking, single-sign-on, …), les collaborateurs de l’organisation concernée étaient répartis sur une cinquantaine de bureaux et les technologies et fournisseurs associés étaient légion. Qui plus est, à l’instar de nombreux projets en cours en Belgique, l’appréhension du monde SOA y était difficile du fait d’une expérience décousue et d’une forte segmentation de l’informatique qui souffrait par ailleurs d’un manque de stratégie claire.

Un défi qui n’en fut pas un. Sylvain Bouxin a tout simplement appliqué ses «recettes». Concrètement, le projet s’est traduit par une livraison hebdomadaire de modules WPS (WebSphre Process Serveur). Au total, 120! Après avoir été développés, les services -tous réutilisables- ont été implémentés. Par la suite, ils ont été régulièrement optimisés et adaptés sans perturber le confort des utilisateurs, avec l’objectif constant d’améliorer la productivité de l’organisation.

D’une manière générale, le projet a bénéficié tout au long de sa mise en œuvre d’une gouvernance forte qui a néanmoins laissé la place à la flexibilité et à la créativité. Autre focus: installer chez le client une équipe projet pluridisciplinaire capable d’appréhender toutes les questions touchant aussi bien au management qu’au business et à l’informatique. Elle a discuté des stratégies à suivre et a basé ses choix technologiques en se fondant sur de petits projets pilotes plutôt que sur la théorie SOA.

L’équipe projet a également travaillé à l’éducation du client tant sur les aspects méthodologiques que technologiques -formations sur les ESB (Enterprise Service Bus), WPS, les services...

Elle s’est également attachée à analyser l’organisation du travail des 18 développeurs en place chez le client pour, au final, n’en retenir que 5 parmi les meilleurs, que ce soit sur le plan technique (dans le domaine du WPS principalement) ou sur le plan humain. Ces 5 développeurs ont alors été répartis dans de petits groupes communiquant fortement entre eux et collaborant étroitement avec les départements business de l’organisation.

Ils ont travaillé sur des cycles de moins d’une semaine avec en tête des objectifs concrets. Résultat: chaque développeur a livré un, voire plusieurs, modules WPS par semaine alors que dans le passé la communauté des 18 développeurs prenait six mois pour produire seulement un développement… de surcroît moins performant!