De la réussite durable d’une démarche SOA

Trop souvent les démarches SOA adressent uniquement les problématiques d'architectures techniques et fonctionnelles, au dépend des enjeux humains et organisationnels inhérents à la transformation qu'impose la SOA au SI.

La SOA doit aider à fédérer une communauté de partenaires et à maintenir l'adaptabilité du SI

Dans les échanges qu'a l'entreprise avec ses partenaires extérieurs divers, la nécessité de mettre en place et d'utiliser des services ne se discute plus. L'entreprise s'ouvre, s'interconnecte, fournit et consomme de l'information, participe à des chaînes de valeur : cherche à fédérer autour de sa plateforme. Dans l'extension de cette approche vers l'intérieur, l'entreprise cherche à maitriser les processus métier et à répondre à des enjeux tels que le cross-selling, le respect du time-to-market de nouveaux produits, la possibilité d'absorber des reconfigurations sectorielles...
La DSI occupe une place prépondérante dans cette transformation et les enjeux invoqués se déclinent alors essentiellement dans la mutualisation des règles métiers, la gouvernance et la qualité de la donnée, la gestion des échanges inter/intra entreprise, la recherche de l'efficacité des projets informatiques (en favorisant par exemple l'interopérabilité des applications de générations ou de technologies différentes) et l'adaptabilité du SI aux évolutions métiers.

Le SI " mute " d'un SI en silos vers un SI proposant des services partagés

Un consensus semble établi sur le fait que la SOA est un des meilleurs candidats pour adresser l'ensemble de ces enjeux. Mais les SI d'aujourd'hui sont constitués d'applications et de sources de données variées, basées sur des technologies hétérogènes et souvent gérées par des organisations cloisonnées. La SOA tire ses gênes de cette complexité et propose une architecture qui présente fonctions et informations du SI sous forme de "services" interopérables et faiblement couplés. L'architecture du SI s'organise alors à travers la factorisation des éléments communs, l'élimination des redondances, la réutilisation de services avec comme conséquence la "mutation" d'un SI en silo vers un SI proposant des services partagés

Reste qu'une telle mise en oeuvre est souvent synonyme de désillusions voire de douleurs...

• une augmentation drastique des dépendances entre les applications et les équipes avec des difficultés lors de la planification des développements, lors de la définition et la mise à disposition des contrats de services, des impacts sur les processus de gestion des évolutions ou de correction des anomalies qui doit prendre en compte les divers consommateurs, un " run " qui peut avoir à assurer la disponibilité de multiples versions de services, la promesse de découplage qui fait oublier que l'ensemble des applications mises à contribution risquent de devoir s'aligner sur le SLA le plus exigeant

• une mise en oeuvre prématurée d'outils comme les ESB ou les BPM. Utiliser à bon escient et dans des organisations suffisamment matures, ces outils permettent d'optimiser certains comportements (sécurité, routage, administration...). A l'inverse, ils peuvent devenir une contrainte et une source de complexité

• une approche uniquement " bottom-up " qui mène à des échanges points à points non maitrisés et une très faible réutilisabilité

• une approche uniquement " top-down " qui imagine des SI " tout services " ; créant des formats pivots " a priori " alors que beaucoup d'applications ne sont pas prêtes ou normalisant " à tout va " les référentiels au risque de limiter la performance générale des services

Une démarche SOA doit se décliner sur trois axes : les technologies, l'architecture du SI et les aspects organisationnels et humains

La mise en oeuvre d'une architecture SOA doit être pragmatique et dimensionnée en fonction de la complexité de l'architecture cible et de la maturité de l'organisation pour supporter humainement, techniquement et financièrement cette architecture.

Mais quelque soit le niveau de complexité et de maturité, la réalisation d'une architecture SOA se décline sur trois axes: les technologies, l'architecture du SI et les aspects organisationnels et humains.

L'axe technologique embrasse l'ensemble des aspects de l'architecture applicative et de l'expertise technique et vise à plus de simplicité. L'émergence d'architectures dites "orientées ressources" (ROA) et plus légères que les approches dites "classiques" (SOAP) rebattent les cartes et promettent de meilleures interopérabilité et productivité mais cela nécessite d'appliquer des principes d'architecture différents et potentiellement complémentaires. Parallèlement, la sécurisation des services doit privilégier une approche pilotée par les risques plutôt qu'une approche totalement sécuritaire et permettre l'utilisation de moyens techniques adaptés en termes de propriétés et de coûts. Enfin, les différentes plateformes de développement sont relativement matures mais reste à maîtriser leur déploiement (contract-first, code-first), industrialiser leur utilisation afin que leur usage dans le flux de développement ne soit un frein ni à la productivité, ni à la testabilité.

Le second axe regroupe les disciplines de l'architecture de SI, la modélisation des processus métier et promeut des architectures simples et évolutives, des standards opérationnels. Il est aujourd'hui nécessaire de mixer approche organique et approche légaliste. L'approche organique, permet de faire " émerger " des services au sein de projets et facilite la découverte d'une direction opérable à coûts et risques optimisés à partir d'un existant en terme de code, de compétences techniques et fonctionnelles. Mais cette approche sera cadrée par l'approche légaliste permettant d'aligner les différents acteurs sur une intention commune, une vision partagée. De ce mélange des deux approches apparaît une direction unique et utile : des modèles et des standards applicables rapidement par les projets et améliorés de façon continue grâce au "retour terrain".

Enfin l'organisation et les dynamiques d'équipes devront évoluer pour "s'aligner" sur ces notions de "services" et intégrer un mode de développement lui aussi distribué. Des aspects souvent oubliés mais qui imposent à l'organisation de se transformer pour faire émerger des équipes responsables (c'est à dire garantes de la sémantique, de l'intéropérabilité, de la non régression, du SLA...) des services. Cette mise en oeuvre du changement, passera par l'adaptation des processus de développement, de l'organisation du travail et par la remise en cause de la classique contractualisation entre équipes. Cette transformation se traduira par une spécialisation des équipes par " bouquet de services ", une diminution des chaines de responsabilités afin de polariser les équipes sur un unique but qu'est le "service", une évolution des processus de développement vers du plus "itératif-incrémental".

Quant à la Gouvernance, cette dernière aura à charge de préciser les standards à appliquer sur chacun des ces trois axes.

Ainsi, pour que l'augmentation des dépendances entre services et équipes n'aboutisse pas à une paralysie générale lors de la transformation du SI vers une architecture de services, les équipes devront maîtriser les outils et méthodes de l'amélioration continue : développement incrémental et itératif, testabilité du SI, architecture organique, standards émergeants, responsabilisation des hommes

Issu de discussions " endiablées " avec Damien Joguet, Dominique Jocal, Eric Biernat et Pierre Pezziardi ;o)