Le modèle d'architecture orientée service (SOA)

Résumé du document

L'objectif de ce mémoire est de présenter une synthèse des informations sur un sujet qui occupe de plus en plus l'actualité des systèmes d'information : Les Architectures Orientées Services (SOA). Le Gartner a lancé ce terme en 2003 et a voulu associer derrière cet acronyme deux mondes qui ont souvent du mal à se comprendre : architecture (qui a une connotation technique), et services (qui a une connotation métier). Pourtant, si ce terme remporte l'adhésion du public, c'est que le mot « Service » a un double emploi : les directions fonctionnelles aident à mieux définir leur besoin, et les directions informatiques permettent de mieux y répondre.

L'absence de connaissance des technologies utilisées par SOA n'est pas forcément un obstacle à la compréhension du concept. D'ailleurs, à l'échelle de l'entreprise, et d'un point de vue complexité, SOA n'est pratiquement pas une question d'informatique. C'est une philosophie, et une nouvelle manière de concevoir une architecture d'entreprise. Avec une SOA, c'est le processus métier qui est prioritaire et non l'application.

L'organisation des services via le tiers d'intermédiation permet de faire muter le SI selon les attentes fonctionnelles en limitant les contraintes liées à la technique. La création d'un référentiel d'entreprise permet une centralisation des données selon des vues pertinentes dans une nomenclature définie.

Très tôt, l'entreprise Amazon a organisé son système autour de services qu'elle a mis à disposition pour ses applications en interne et/ou en externe pour ses partenaires. En voici quelques exemples : renvoi du prix et de la disponibilité d'un article en temps réel, génération à la volée d'une liste des meilleures ventes, génération d'une liste de résultats de recherche, etc.

Cet exemple fournit un bon contexte d'utilisation des services : poussée par la réactivité et le besoin de s'adapter à un environnement changeant, l'entreprise met en place une infrastructure de service qui lui permet notamment d'inclure le temps réel dans bon nombre de ses procédures client.
L'exemple d'Amazon n'est pas isolé, et aujourd'hui tous les grands comptes de l'Internet (Google, Ebay, Microsoft…) ont bien compris l'intérêt d'exposer leurs services au monde extérieur. Certes, nous aurons l'occasion de revenir sur les autres avantages du modèle SOA, mais déjà, on sent bien que la tendance des prochaines années consistera à généraliser cette approche à tous les autres secteurs de l'industrie ou des services.

Extraits

[...] Il est important à ce moment-là d'organiser la prospection des services candidats, et SOMA[17] répond parfaitement à ce besoin. Mais pour être menée dans les meilleures conditions, SOMA nécessite : une bonne description des processus métiers, et une vision détaillée de l'architecture SI existante. Le premier point permet d'avoir une approche par processus qui soit efficace, et le second permet de faire plus facilement le lien avec la réalité du SI, car l'objectif final avec SOMA, ce n'est pas seulement d'avoir la liste des services métiers spécifiés, mais aussi la vue des applications qui pourraient réellement les supporter. [...]

[...] En fait SOMA, n'impose rien, mais aide à séparer ce qui a un sens SOA de ce qui n'en a pas. Pour mieux comprendre, on peut très bien imaginer que du côté de la production informatique, on veuille remonter des informations sur les anomalies, et donc exposer un service web associé, ce qui n'a aucune valeur au sens métier. Cependant, rien n'empêche d'exposer quand même ce service, si on estime qu'il a une vraie utilité. La phase d'identification est cruciale et même assez structurante, mais SOMA est une méthode itérative, ce qui permet par la suite d'y revenir, et d'affiner davantage la liste des candidats. [...]

[...] Nous allons voir que cette approche facilite grandement le travail d'identification des services métiers réutilisables dans l'entreprise que nous verrons dans la partie suivante. Ici, toutes les contraintes géographiques, organisationnelles, ainsi que toutes les notions de produits, bref tout ce qui peut conduire à des considérations en silo est écarté, pour laisser la place à une vision centrée sur les grandes fonctions de l'entreprise. Dans CBM, chaque composant métier est vu comme une partie logique de l'entreprise, supportée par des ressources, des personnes, des technologies, des pratiques et des indicateurs de mesure, délivrant une valeur métier (bien ou service), en échange d'autres biens ou services. [...]

[...] C'est le cas de la liste de recherche ou de l'emplissage du caddie à distance depuis un autre site : on expose des éléments d'une application et non l'application elle-même, en fournissant un accès à certaines fonctionnalités clairement référencées par les services qu'elles rendent. Cette notion de référencement ouvre la voie à celle d'annuaire de services, nœuds centraux qui informent des modes d'accès au service et de ses interfaces d'entrée-sortie. L'idée est ainsi de permettre à tout utilisateur, à toute application d'accéder aux services qui lui sont nécessaires pour bâtir ses propres processus. Amazon devient fournisseur de services pour lui-même, comme pour ses partenaires. [...]

[...] Et les lignes quant à elles représentent les trois niveaux de responsabilités. Les composants sont répartis dans les cases de ce tableau par des boites coloriées : Les trois niveaux de responsabilités (Accountability levels) utilisés dans CBM sont standards à toutes les entreprises : Direct : fixe les règles de fonctionnement, fixe la stratégie, et planifie les grandes décisions ; Control : mesure les résultats, gère les exceptions et les décisions tactiques ; Execute : réalise le travail, gère des opérations, de la production et de la maintenance. [...]