Au cours du temps, chaque groupe a tenté d’imposer sa vision. Les démarches d’analyses purement fonctionnelles ont d’abord été la règle dans l’élaboration des spécifications informatiques. L’idée était que, par une décomposition de plus en plus fine des métiers, on devait aboutir aux fonctions et aux programmes informatiques.

Malheureusement, on obtenait ainsi des applications rigides souvent conçues pour un seul cas d’emploi. A la première demande d’évolution, c’est l’ensemble des dépendances entre programmes qui était impacté. Pour résumer, les approches purement fonctionnelles ne prenaient pas en compte les problématiques d’architecture propres aux systèmes informatiques, comme la limitation des dépendances, la modularité et la réutilisation.

Avec l’apparition des techniques de développement objet, les informaticiens ont mis en place de nouvelles méthodes de conception intégrant les principes qui leur sont chers comme l’isolation des composants (encapsulation), l’indépendance, la réutilisation.

On pensait pouvoir étendre la notion informatique d’objet à l’analyse des entreprises et des organisations. Mais comme les organisations ne sont pas des programmes, ces tentatives n’ont eu qu’un succès limité : UML n’est pas devenu le langage de modélisation universel pour la description des métiers.

Aujourd’hui le fossé entre métier et informatique semble être pour partie comblé par la mise en avant du concept de service. Celui-ci se situe à la charnière entre la vue axée sur les fonctions à fournir, prônée par les départements métiers, et la vue orientée objet prônée par les départements informatiques. Pour mieux le comprendre, il faut préciser à quoi correspond un service.

Le service, une unité autonome
Un service représente une unité autonome de traitement et de gestion de données, communiquant avec son environnement à l’aide de messages ; les échanges de messages sont organisés sous forme de contrats d’échange.

Cette définition emprunte de nombreuses caractéristiques à celle d’un composant objet:
- La combinaison de données et de traitements.
- L’autonomie: un service a sa propre implémentation, son propre déploiement. Il peut être modifié sans que cela affecte les autres services ou partenaires avec lesquels il est en relation.
- Des frontières explicites : on distingue l’intérieur du service, son implémentation, et l’extérieur du service, l’expression sous forme de message de ce qu’il peut échanger et comment il peut être, toujours de l’extérieur, sollicité.

C’est sur ce dernier élément que se joue la différence : par rapport à un composant traditionnel auquel on passe des paramètres, un service échange et fournit de l’information au travers de messages. Chaque service propose un ensemble de messages pouvant être enchaînés pour remplir une fonction déterminée.

Prenons l’exemple d’un service de "formulation des demandes de placement d’ordre de bourse". Ce service propose un ensemble de messages pour formuler un ordre de bourse:
- Envoyer "la demande d’information sur la valeur mobilière X"
- Répondre par "les conditions de marché concernant la valeur mobilière X"
- Envoyer la "Demande de placement d’ordre de bourse pour X"
- Répondre par "Acceptation de la demande de placement" ou par "Les données suivantes doivent être complétées"

On peut donc décrire un service comme un composant informatique délivrant un ensemble cohérent de fonctions sous la forme d’informations échangées via des messages.
Parce qu’ils ne communiquent que par des messages, les services offrent une indépendance par rapport aux technologies d’implémentation.

Un service peut, par exemple, reposer sur un programme cobol par lequel on extrait une donnée ; celle-ci est ensuite mise en forme dans un document XML et envoyée à un autre service qui peut reposer sur un programme Java.
Seules les données sont échangées, sous forme d’informations structurées.

De la même manière, un autre service peut prendre cette information et la présenter sous forme d’une page web à un utilisateur du système.

Sur le plan des spécifications fonctionnelles, les départements métiers peuvent exprimer leur besoin – pour schématiser - sous forme de listes d’informations qu’ils attendent du système. Ce faisant, ils décrivent les fonctions qui doivent à terme être supportées par un système.

Les informaticiens ont pour tâche de grouper sous forme de service les messages délivrant les informations demandées.

Les difficultés de découpage du SI en services
Les services se présentent ainsi comme point d’articulation entre les métiers et l’informatique. Les métiers les voient par le biais des fonctions rendues, les informaticiens les voient en tant qu’élément d’architecture du système. Cependant, une difficulté majeure émerge quant aux critères de découpage du système d’information en services.

Prenons notre exemple de service précédent de "formulation des demandes de placement d’ordre de bourse".
Dans cet exemple, pourtant déjà extrêmement simplifié, on s’aperçoit que l’on a regroupé deux types de fonctions dans le même service : la demande d’information et la demande de placement.
Est-ce légitime ?
Une étude du département bancaire correspondant nous indiquera peut-être que la fonction d’information peut évoluer de manière indépendante de celle de l’ordre de placement lui-même. Il faudra alors prévoir un service d’information indépendant et régler les éventuels messages de communication entre le nouveau service d’information et l’ancien service de formulation de demande.

Si l’architecture de service permet, sur le plan technique, un découpage agile du système, elle ne donne en rien les critères de ce découpage.

Pour télécharger le document complet