Tribunes

SOA : ca se gère ?

PublicitéLe battage fait autour des architectures orientées services (SOA) ne surprendra personne. La floraison d'offres logicielles est à la hauteur des espoirs financiers. Le marketing y montre brillamment sa capacité - dont personne ne doutait - à précéder la technique. Les fruits risquent cependant de ne pas passer la promesse des fleurs si l'on oublie l'objectif principal : contribuer à l'agilité de l'entreprise, donc donner à l'entreprise la maîtrise dans le temps de son système d'information. Passons sur ceux, il en reste, qui réduisent SOA aux Services Web. Ou ceux pour qui tout est service (je me souviens encore d'une époque pas si lointaine où tout était objet). Plus sérieusement, de nombreux éditeurs proposent aujourd'hui des outils non seulement pour créer, tester, déployer et publier des Services Web, mais aussi pour les agencer et les orchestrer afin de créer de nouvelles solutions. Autrement dit, ils offrent les moyens de fabriquer les composants constitutifs d'une SOA. Et après ? L'impression qui ressort généralement, c'est qu'il n'y a pas d'après. Ce qui est sans importance si l'entreprise a approché SOA de manière purement tactique, avec un petit projet amenant au déploiement de quelques services. Mais dès que l'architecture prend de l'ampleur, 100 services, c'est déjà important, il faut poser des questions telles que la modification des processus, la réutilisation ou la modification des services, pour que SOA vive. Car une SOA qui ne suit pas les évolutions du métier est une SOA morte, une SOA qui a échoué dans son but essentiel : aligner système d'information et métier. Retournons le problème : il existe de nombreuses approches techniques à une solution, et souvent plusieurs acceptables. De plus, une solution complète réclame l'utilisation de plusieurs outils. Dans cette diversité, ce qui doit aujourd'hui guider le choix, au-delà de la gestion quotidienne, c'est bien la capacité à maîtriser et anticiper les évolutions, en faisant collaborer les outils mis en oeuvre. En un mot, le point focal, c'est la gouvernance. Gouverner suppose connaître, gérer et anticiper. Gouverner une architecture orientée services, c'est donc : - avoir une visibilité totale sur les actifs constituants de l'architecture, leurs versions disponibles et déployées - maîtriser leurs relations et utilisations (quelle couche utilise quel service, quelle couche génère quel service, dans quelle version, etc.) - prévoir et analyser l'impact sur les couches et les services des évolutions applicatives, pour favoriser une meilleure réutilisation des composants existants. L'outil central de cette gouvernance est le référentiel regroupant toutes les méta-données informatiques de SOA : modèles de processus, modèles d'orchestration, modèles de données et d'information, descriptifs et interfaces des services, etc. L'outil doit aussi permettre l'utilisation des services, donc jouer le rôle de registre UDDI. Mais ce rôle de registre doit être élargi à tous les composants SOA qui sont en relation, pour permettre les analyses d'impact. On peut donc parler de « registre-référentiel SOA ». Ce registre-référentiel doit évidemment être partagé par tous les outils de modélisation et de génération de services pour garantir la continuité, l'unité et la cohérence des processus tout au long du cycle de vie des solutions. Nous avons maintenant la réponse à la question initiale. SOA, ça se gère ? Oui, et le registre-référentiel SOA y joue le rôle central. Dans ce domaine, les offres sont encore rares.