Les données utilisées dans le contexte des processus de l'entreprise constituent également des indicateurs pour la détection des services. Dans l'exemple précédent, l'opération "Finaliser la proposition de crédit" met en évidence la nécessité de disposer d'un ou plusieurs services de gestion de l'entité "Offre de crédit". Le crédit est lié lui-même à l'entité client dont on voudra consulter les propriétés.

Les services de lecture, de mise à jour, de création et de destruction de chacune de ces entités peuvent ainsi être définis. Ces quatre services de base sont généralement référencés par l'acronyme CRUD (Create, Retrieve, Update, Delete) et aboutissent le plus souvent à une implémentation dans une base de données relationnelle. De ces services atomiques découlent également les services d'interface homme-machine les mettant en œuvre.

Les services applicatifs encapsulent des algorithmes réalisant des calculs complexes ou mettant en œuvre des règles métiers. Dans l'exemple de crédit, un service de simulation de prêt immobilier est utilisé lors de l'entretien commercial avec le client. Ce service met en œuvre des algorithmes de calculs centralisés et peut-être partagé par d'autres processus.

Les services d'orchestration de processus permettent d'enchaîner des tâches implémentées par des services élémentaires dans le but d'automatiser tout ou partie de la chaîne de valeur d'un processus métier.

Par exemple, un système de réservation de billets d'avion prend en charge la mise en attente d'un client au cas où un vol est complet. Dès qu'un désistement survient, le service gérant le processus prend automatiquement en charge le rappel du client (envoi du courrier électronique) et opère la réservation. Dans ce cas de figure, le service gère l'état courant de la transaction de réservation (en attente, réservé, annulé) pendant une période qui peut aller de quelques heures à plusieurs semaines.

Les moteurs d'exécution de processus du marché (BPMS : Business Process Management System) reposent sur la description formelle des processus par le biais d'un langage. Le plus populaire est BPEL (Business Process Execution Language). Il existe également une notation graphique pour représenter ces définitions de processus : BPMN (Business Process Management Notation).

Voir le guide HOPEX Application Designer pour plus de détails.

Une architecture orientée service est basée sur les services et leurs échanges. La gestion des échanges donne lieu elle-même à la mise en place de services dédiés. Dans une architecture de ce type, il est impératif d'utiliser des protocoles et des services standard capables de transporter les messages entre les différents services fonctionnels. Ces derniers étant de nature hétérogène, le système de communication repose sur des protocoles indépendants des messages transférés. Il est alors nécessaire de disposer de services dédiés à la "traduction" des messages depuis le format natif vers le format indépendant et inversement.

SOAP est un bon exemple de protocole mis en place pour répondre à cette problématique. On trouve bon nombre de services capables de prendre en charge ou de transférer un message SOAP que ce soit sur des plates-formes Unix, Windows ou autres.

Le système d'information est un des leviers majeurs de la mise œuvre des processus. En tant que tel, il nécessite une administration qui doit permettre de prendre des décisions relatives à son évolution. Il est donc opportun de définir une architecture spécifique pour son administration. L'objectif est généralement de déterminer :

Pour répondre à ces problématiques internes, on pourra avoir recours aux services définis ci-dessous (liste non exhaustive) :

Tout comme celle d'administration, la notion de sécurité du système d'information peut être vue en dehors de l'aspect fonctionnel de l'entreprise. C'est une problématique à part entière qui traverse toutes les couches de services quel que soit le métier adressé. Ici, l'objectif est de protéger le système d'information contre toutes sortes d'agressions qu'elles soient logicielles ou matérielles, intentionnelles ou non.

Parmi les services correspondant à cette problématique, on trouve :

Un certain nombre d'organismes se sont donnés pour tâche de recenser les risques envisageables en termes de sécurité afin de mieux les appréhender. On trouve parmi eux les recommandations ITIL (Information Technology Infrastructure Library), ou celle du CERT (Computer Emergency Response Team).

L'identification des échanges est réalisée conjointement à l'identification des services. De la découverte d'un service découlent les échanges qui s'y rattachent. Par exemple, à partir d'un service "Simulateur de crédit" on identifie un message entrant "Demande de simulation crédit" et un message sortant "Simulation crédit".

Cet exemple montre qu'un message seul ne suffit pas à représenter l'ensemble des interactions nécessaires à l'obtention d'un résultat. A cette fin, il est nécessaire de regrouper ces messages au sein d'une interaction.

Une interaction est un contrat d'échange entre deux partenaires.Chaque partenaire est représenté par le rôle qu'il joue dans le contrat d'échange. Chaque échange élémentaire est spécifié par un message.

Les interactions permettent de décrire les interfaces des services, c'est à dire l'ensemble des messages en entrée et en sortie qu'ils doivent prendre en compte. Dans notre exemple l'interaction Simulation Crédit comporte les deux messages Demande de simulation crédit et Simulation crédit.

L'application "Simulation de crédit" offre un service "Simulateur de crédit." Celui-ci joue le rôle de "Fournisseur de simulation". Il doit donc pouvoir répondre au message "Demande de simulation crédit" par le message "Simulation crédit". Le diagramme d'architecture interne de l'application "Simulation de crédit" montre comment le service "Simulateur de crédit" est sollicité au moyen de l'interaction "Simulation crédit". Ce même service doit lui-même collaborer avec les services "Consultation situation client" et "Evaluation risques immobiliers" afin de pouvoir effectuer ses traitements.