SOA pour l'urbanisation du SI

Philippe Noël est consultant spécialisé dans les architectures distribuées (J2EE et .NET), SOA et urbanisation. Il intervient depuis plusieurs années, en tant que architecte,  au sein de projets ou de structures pour proposer et mettre en place une démarche SOA ou d’urbanisation quand une entreprise est convaincue de l’intérêt de cette démarche. De façon plus pragmatique, il présente une approche concrète qui porte sur la mise en place d’une SOA au sein de projets sur mesure développés en régie.

Comment pouvez-vous nous décrire l'approche SOA?

La SOA propose une organisation et le développement de projets recentrés sur le fonctionnel à travers l’offre et la définition de services. Le SOA n’est pas une approche technique, même si on relie souvent le SOA aux services Web. Le SOA est donc une approche d’abord et avant tout organisationnelle de type urbanisation.

Peut-on faire une parallèle avec les approches précédentes?

Les dernières évolutions ont été essentiellement techniques (J2EE, .NET, Web Services, frameworks…). S’il y a eu un gain incontestable en terme de productivité, il y a bien des points qui n’ont pas été réglés : la réutilisabilité de composants, promise par l’objet, est souvent un vœu pieux. C’est vrai au sein d’un même projet, c’est encore plus vrai pour la communication entre projets qui est souvent inexistante et irréalisable pour des raisons autant organisationnelles que techniques. La communication entre le business et les équipes techniques est souvent un point faible qui peut entraîner des inadéquations entre les spécifications et le résultat, ou encore un time-to-market qui peut être amélioré. La complexité croissante des projets rend difficile leur maintenance, leur évolutivité et la rationalisation des outils. L’application des concepts portés par le SOA (couplage faible, définition de services et approche top-down, services sans états…) à différents niveaux (entre projets ou au sein des projets eux-mêmes) permet d’améliorer très fortement ces problématiques. La différence avec les approches précédentes est qu’il ne s’agit pas de l’émergence d’une nouvelle technologie, d’un nouveau protocole ou d’un nouveau standard, mais d’une approche organisationnelle.

Comment réussir à structurer une approche SOA ?

Tout d’abord, il n’est pas nécessaire de faire partie du top 10 du CAC 40 pour mettre en place une architecture orientée services, même si la SOA aujourd’hui s’applique d’abord à des entités qui font du développement sur mesure (les progiciels n’intègrent pas encore vraiment ces concepts, ou de façon limitée). J’ai eu l’occasion de mettre en place de la SOA sur des projets d’une volumétrie de 1.000 Jours/homme avec des gains certains en terme de réutilisabilité, de maintenabilité et de réactivité, ceci rien qu’au sein même du projet.

Deux approches peuvent être envisagées pour mettre en place une SOA : une approche top-down, et dans ce cas la mise en place se fait "par le haut" (par le top management) et une approche bottom-up qui part d’un ou plusieurs projets pilotes. C’est la démarche qui est généralement adoptée pour démarrer une organisation SOA. Cela permet de bien appréhender les concepts à mettre en place et d’adapter la démarche au contexte de l’entreprise. La création d’un premier ensemble de services, publiés selon une forme à définir (un wiki par exemple), permet à chacun de voir une offre de services se développer et au SOA de s’ancrer au sein de l’entreprise.

Quels sont les meilleures pratiques du domaine ?

Il faut penser services encore services et toujours services. Quand on est à un niveau business cela peut paraître simple, mais quand on descend dans les couches d’une application ce n’est pas toujours évident dans la mesure où le développement se pense d’abord en terme d’objets. C’est pourquoi il est nécessaire de développer le travail en amont (de design) en équipe, avec plusieurs acteurs dont l’un au moins a une forte connaissance du métier. Enfin, la définition d’un vocabulaire, de règles de fonctionnement, de contrat et de cycle de vie des services est nécessaire pour tirer une pleine efficacité d’une SOA.

Quelle satisfaction retirez-vous d'une approche SOA ? Et vos clients?

Grâce à des notions et un vocabulaire communs, il y a moins de cloisonnement au sein des différentes équipes. La motivation des équipes est aussi plus forte parce que tout le monde travaille dans un but de réutilisabilité et d’interconnexion. Cela est vrai pour les équipes de développement, mais aussi entre les projets et pour le business. Côté client, le métier apparaît beaucoup plus clairement au travers des services et vise un accroissement de la durée de vie des projets (un des objectifs majeurs du SOA). De plus, cela permet de mieux s’assurer de la validité des spécifications fournies par le business et de leur compréhension par les équipes de développement. Enfin, la définition de services de granularités différentes a des impacts sur les scénarios de tests qui permettent d’accroître la qualité des livrables. Comme c’est souvent le cas dans une démarche d’urbanisation, la complexité du SI est mieux gérée et fait souvent émerger des incohérences et des améliorations possibles à travers, par exemple, de la rationalisation.

Peut-on parler d'effets pour les utilisateurs finaux ? Et pour les équipes clients?

Du côté utilisateurs finaux et équipes clients, les effets se traduisent essentiellement en amélioration de la réactivité des équipes projets ainsi qu’en accroissement de la valeur apportée par les technologies de l’information aux métiers de l’entreprise.

Comment cela contribue-t-il au développement des équipes ?

Dans l’approche traditionnelle, le développeur est l’architecte, souvent solitaire, du cas d’utilisation qui lui est confié. Dans une architecture orientée service, une partie des interfaces qu’il aura à fournir sera définie par un groupe (dont il fait partie) et seront ensuite publiées et offertes aux autres acteurs qui pourraient en avoir besoin. De plus, il aura aussi à se poser la question si les fonctionnalités qu’il a à implémenter ne sont pas déjà fournies par d’autres services. Pour en arriver là, je préconise de distinguer deux niveaux de service : les services de composition (plus business) et les services unitaires (plus techniques), les premiers s’appuyant sur les seconds. Cela est relativement nouveau puisque auparavant la réutilisation n’était pas formellement gérée. Au-delà du fait que cela revalorise l’activité de développeur, cela entraîne un travail d’équipe plus motivant et une prépondérance du modèle des services sur la structure de l’ensemble, ce qui donne un résultat plus propre et plus satisfaisant pour l’ensemble des acteurs. La maintenance et surtout l’évolutivité s’en ressent d’ailleurs considérablement. Enfin, la définition d’un vocabulaire commun améliore la communication et le partage des compétences. Il y a moins de cloisonnement entre le business et le technique.

Pouvez-vous quantifier l'apport / les gains / les économies ?

Comme toute nouvelle technologie ou organisation, il y a un coût de mise en place qui va ralentir le lancement du ou des premiers projets pilotes. Puis l’accoutumance des différents acteurs à la nouvelle organisation, au vocabulaire et aux concepts, l’amélioration de la communication entre les différentes fonctions (business, architecte, développeur) puis la publication, la réutilisabilité et la composition des services va permettre d’augmenter la vitesse des développements techniques ou business. En fait, la mise en place d’une SOA impacte toute la chaîne de développement, depuis le business jusqu’aux tests. Le gain d’une SOA ne doit donc pas se chiffrer en terme de réutilisabilité mais d’abord et surtout en accroissement de la réactivité et d’ouverture du système. Dans un monde où le time-to-market se doit d’être toujours réduit pour faire face à la globalisation ou à la concurrence, on se rend compte de l’intérêt d’avoir de tels gains.

En effet, toutes les grandes banques actuelles ont démarré des processus d’urbanisation basées sur les architectures orientées services (SGCIB, CALYON, BNP…), des assurances aussi ont lancé des démarches, aujourd’hui déjà bien avancées, dans cette direction (comme SMA-BTP…) ou encore les télécoms (comme Bouygues Télécom). En conclusion, la question n’est pas de savoir si l’on doit passer aux architectures orientées services, mais quand et comment.

Y-a-t-il des écueils à éviter ?

D’un point de vue organisationnel, il faut bien voir que l’intérêt d’une SOA ne sera pas immédiat et que c’est un travail qui réclame du temps. C’est pourquoi il faut une volonté forte des sponsors et des leaders pour mettre cette démarche en place.

L’identification et la granularité des services constituent deux des aspects difficiles de cette approche. Si la granularité est trop forte il n’y a pas de réutilisabilité et de lisibilité et si la granularité est trop faible, la réutilisabilité passe par la composition d’une multitude de services qui accroît de façon excessive la complexité du système. De plus, il faut bien distinguer les services business des services techniques. Les deux peuvent être adressés par le SOA, il faut savoir ce que l’on veut exposer et à qui. Il est important aussi de trouver des personnes capables de travailler en équipe, capables de se remettre en cause et d’adopter un vocabulaire et des notions communes. Cela devient même un critère de recrutement en plus des compétences techniques. Enfin, la SOA requiert un effort qui doit porter sur la durée et c’est pourquoi les équipes doivent être motivées et adhérer à cette démarche.

En quelle mesure cela change les relations durant le projet ?

Il va y avoir clairement une meilleure adéquation entre les volontés du business et la réalisation par les équipes projets. Le fait qu’il y ait un décloisonnement entre le business et les équipes projets, ainsi qu’entre les différentes équipes elles-mêmes, change la nature des rapports entre les différents protagonistes. C’est pourquoi, à terme, la réactivité de l’ensemble des équipes s’améliore grâce à une communication plus directe entre les différents acteurs impliqués dans un projet.