1. SOA est un style d’architecture de système informatique
Pour élaborer la structure d’un système informatique, nous recourons toujours à une métaphore : fonction, machine, ville, service, événement, agent… La plus traditionnelle et encore la plus ancrée dans les esprits est celle de l’architecture fonctionnelle, par laquelle nous percevons le système comme un ensemble de fonctions. Elle a montré ses limites puisqu’elle est associée à la décomposition hiérarchique et entraîne un fort taux de redondance. La métaphore la plus actuelle est celle du service, caractéristique de l’approche SOA (service oriented architecture). Elle agrège de nombreuses notions connexes telles que le contrat et l’encapsulation.
Aborder un système par le truchement d’une métaphore est un acte propre à l’architecture logique : la conception d’un système artificiel, dans une relative indépendance par rapport aux choix techniques.
Le premier message de Praxeme pour SOA est l’importance des disciplines d’architecture logique et de conception logique pour tirer parti de l’approche SOA.
2. Les promesses de SOA ne se concrétisent que quand on consent un effort de restructuration du système
On oppose ainsi :
- SOA de surface, qui consiste à brancher quelques services sur un système auquel on ne touche pas ;
- SOA de refonte, qui généralise la métaphore à l’ensemble du système et, progressivement, transforme celui-ci significativement.
Évidemment, si on applique la première approche (on pourrait dire : FOA, la fausse SOA), il ne faudra pas s’étonner que les retombées promises (réutilisation, simplification, interopérabilité, agilité…) n’auront pas été tenues.
3. La mise en place d’une SOA prend son sens dans une stratégie d’urbanisation du système informatique
Cette conclusion découle de la précédente : la conversion d’un système en architecture de services est un processus patient, qui exige une continuité de vision et une grande constance sur le long terme. Tout à fait les caractéristiques de l’urbanisation.
Il convient donc d’articuler soigneusement les deux disciplines de l’urbanisation de SI et de l’architecture logique. Ceci réclame des dispositions pratiques, notamment en ce qui concerne les représentations du système mais aussi en termes d’organisation et de gouvernance SI.
4. La bonne volonté et l’intuition sont insuffisantes pour mener à bien la transformation d’un système informatique
Il y faut de la rigueur et des techniques précises, conçues pour affronter la complexité propre aux systèmes d’information. Se lancer dans de tels travaux sans méthode serait naïf et suicidaire. On observe encore trop souvent des équipes qui s’écharpent sur la notion de service, qui s’épuisent en vaines considérations sur la granularité ou la typologie des services, ou qui bricolent de prétendus méta-modèles. Aurait-on accepté un tel gaspillage dans les années 80 ? Non, pas au moment où les managers savaient imposer les méthodes à leurs équipes. Certes, cette attitude était facilitée par l’existence de méthodes de référence largement répandues et appuyées par la Puissance publique. Autre temps, autre mœurs !
Il existe néanmoins une réponse toute prête : Praxeme pour SOA, c’est-à-dire, dans la méthodologie de transformation des entreprises, la partie dévolue à la conception des systèmes informatiques. Élaborée à partir de 2003 et mise au point sur de grands projets, elle a été appliquée de nombreuses fois et a été consolidée. Sa version 2 est diffusée à travers la formation “SOA, conception d’une architecture de services“. Elle sera publiée en fonction des opportunités (guide “Approche de l’aspect logique” et fiches de procédés).
Pour aller plus loin…
Ces quatre messages sont développés dans l’article “Quatre idées fortes de Praxeme pour SOA“.