Avant tout un problème culturel

S'abonner :

Newsletters

Magazines

01men.

SOA : vers une informatique pilotée par le métier

Avant tout un problème culturel
SOA est moins une révolution technique qu'organisationnelle. Prudence et évolution progressive s'imposent, car l'impact culturel est énorme.

Marie Varandat , 01 Informatique (n° 1746), le 21/11/2003 à 00h00

« Le concept SOA a un fort goût de réchauffé technologique ! La complexité n'est pas là, la productivité non plus, pas plus que le retour sur investissement ! La SOA, ce n'est que de l'urbanisation. » Catégorique, le point de vue de Pierre Pezziardi, directeur technique d'Octo Technology, n'a rien d'isolé. De manière générale, dans les grandes SSII françaises, on souligne à quel point la SOA n'est pas une révolution : « Dans les années 80-90, on concevait déjà des architectures orientées services avec Corba et DCom. La seule différence, c'est qu'avec les plates-formes .Net et J2EE, cela devient plus facile », explique Rémy Poulain, directeur technique de Cross Systems. C'est donc tout naturellement qu'une SOA pose les mêmes problèmes. Ceux-ci sont avant tout d'ordres culturel et organisationnel : il faut penser l'informatique autrement. En effet, on ne s'improvise pas architecte SOA quand on a passé des années à concevoir de l'application monolithique. Le cap est d'autant plus difficile à franchir qu'il s'accompagne en général d'une réorganisation des équipes. « Trois acteurs interviennent dans une architecture SOA : les consommateurs ou utilisateurs, les transporteurs ou responsables des outils pour acheminer les messages entre applications, et les fournisseurs, qui conçoivent les services, explique Didier Girard, directeur technique d'Improve. Et chacun doit se limiter à son domaine. Sinon, apparaissent très vite des luttes de pouvoir, qui débouchent sur des systèmes ne respectant plus le principe de la séparation des couches. »

Une organisation qui suppose un coordinateur

Pour éviter cet écueil, l'organisation des équipes informatiques doit se calquer sur la séparation des couches préconisée par SOA, avec un « couplage lâche » . Chaque équipe a un rôle bien défini et travaille en collaboration avec les autres équipes impliquées dans le développement de l'architecture. Mais elle n'empiète pas sur le domaine de son voisin. Bien entendu, cette organisation suppose un coordinateur capable d'avoir une vision globale de la stratégie et, si nécessaire, de jouer les arbitres. « Il ne faut pas pour autant devenir esclave du concept de la séparation des couches, mais urbaniser au fur et à mesure que les occasions se présentent », explique Pierre Pezziardi. Pas de branle-bas de combat, donc, mais une évolution en douceur, avec de petits projets qui laissent le temps aux équipes de se familiariser avec les concepts, tout en respectant un schéma directeur général à l'entreprise.

Ne pas oublier de référencer les services

En effet, le principal enjeu de la SOA étant la réutilisation des services, ceux-ci doivent être pensés non seulement en fonction d'un projet immédiat, mais aussi sur le long terme pour servir à d'autres applications. Raison pour laquelle il est également indispensable d'adopter très vite une solution de référencement des services développés en vue, par la suite, de faciliter leur gestion. Souvent négligé, ce référencement est d'autant plus critique que, comme le souligne Rémy Poulain, de Cross Systems, « il est facile surtout maintenant de créer des méthodes et des services tous azimuts. Et cela d'autant plus que, souvent, faute d'une véritable formation aux concepts et aux enjeux, on se retrouve très vite avec ce que l'on cherchait précisément à éviter : une usine à gaz ! »

Cinq règles pour réussir une architecture orientée services

Penser dès le départ réutilisation. Une SOA favorise par nature la réutilisation des services. Cette stratégie n'est possible que si le découpage de l'application est conçu dans un cadre plus général que celui du projet immédiat. Le retour sur investissement repose sur la réussite de ce découpage.

Une stratégie d'entreprise, mais pas un projet global. Il faut non seulement cantonner l'application de SOA à de petits projets isolés et maîtrisés localement, mais aussi l'inscrire dans le respect de directives définies à l'échelle de l'entreprise.

Tester le principe de SOA sur des architectures neuves. Découper une ancienne application en services s'avère généralement bien plus complexe que créer une nouvelle application. Il est donc préférable, pour tester les technologies et laisser le temps aux équipes de se familiariser avec les concepts, de commencer par de nouvelles applications.

Privilégier une formation aux concepts plutôt qu'aux technologies. Passer d'un modèle d'application monolithique à une architecture orientée services constitue un vrai choc culturel, difficilement surmontable sans formation aux concepts et aux enjeux. Primordiale, cette formation doit prendre le pas sur la sensibilisation aux nouvelles technologies. Contrairement aux concepts, elles remettent moins en cause les acquis de l'individu et sont plus faciles à appréhender.

Référencer les services et gérer les versions. Les services développés doivent être référencés et gérés de manière rigoureuse. Au risque sinon, pour l'entreprise, de rapidement se retrouver à la tête d'une multitude de composants non documentés, et donc très peu réutilisables. Ou même d'être confrontée à de véritables problèmes, une mauvaise version de service pouvant poser de graves problèmes de compatibilité.

Point de vue « On peut concevoir une SOA sans services web »

Didier Girard, directeur technique d'Improve

« Le concept d'architecture orientée services n'est pas nouveau. Mais depuis que l'on parle de SOA, les technologies ont pris le pas sur un problème, avant tout d'ordres fonctionnel et organisationnel. Dans plus de 70 % des cas, une SOA est associée aux services web. Or, bien avant leur avènement, on savait faire de l'architecture orientée services. Et, aujourd'hui encore, on peut tout à fait s'en passer pour construire une architecture SOA. SOA est un phénomène de mode. J'en veux pour preuve sa visibilité, qui a augmenté de 68 % sur Google au cours de ces six derniers mois. La seule chose à retenir de tout cela et ce n'est d'ailleurs pas une nouveauté , c'est que, pour favoriser la réutilisation et, par là même, optimiser le ROI de ses développements, il faut limiter l'impact d'une réorganisation des données ou des traitements en optant pour une couche d'abstraction, et donc un couplage lâche. Les services web n'ont pas le monopole de ce couplage lâche. Ils présentent même des lacunes importantes, dont la gestion des versions. Rien n'a été prévu dans leurs spécifications. Or, c'est un problème d'autant plus complexe et fondamental que les services se multiplient dans l'entreprise, et que le moindre changement de version peut générer des problèmes de compatibilité très difficiles à résoudre. »