Dans la présentation de l'alignement métier de services dans les Instructions :
Service, a été évoqué le rapport entre les modèles métier et l'identification de service. En général, cette
approche indique un rapport très étroit entre les intervenants/utilisateurs métier et l'entreprise informatique qui
implémente les services, en rendant possible la prise en charge directe par les opérations de service des tâches
identifiées dans les modèles de processus. Les modèles de processus métier mettent généralement l'accent sur les tâches
réalisées par des rôles et/ou des ressources d'une organisation pour atteindre un objectif, souvent dans le but de
fournir de la valeur (sous la forme d'un produit ou d'un service) à un tiers, par exemple un client ou un associé. Le
processus global consiste donc en un ensemble ordonné de tâches de ce type, éventuellement décomposé en sous-processus.
Une organisation, des ressources et des modèles de données lui sont associés afin d'enregistrer tous les aspects du
processus, à savoir non seulement les rôles d'exécution, mais aussi les ressources requises/utilisées, la propriété des
ressources, la responsabilité, les définitions d'éléments intégrés aux tâches et qui en sont issus, etc. Le Concept : Décomposition de processus métier décrit comment atteindre un niveau
de description d'un modèle de processus métier auquel il est possible d'identifier des services candidats, comme
illustré dans l'exemple ci-dessous. En fonction du niveau de granularité de l'Artefact : modèles de cas d'utilisation métier, il peut être
nécessaire de détailler les cas d'utilisation métier, afin de pouvoir atteindre le niveau de
décomposition auquel un modèle de processus utile peut être produit.
Le diagramme ci-dessous illustre un modèle de processus très simple utilisant IBM WebSphere Business Integration
Modeler.
Chaque couloir d'activité horizontal représente ici un rôle exécutant des tâches du processus. Le processus débute au
niveau du cercle vert et se termine avec le cercle entouré de rouge ; des données circulent entre certaines tâches
(sous la forme d'une demande de crédit). Ce processus, bien que visiblement simplifié et artificiel, illustre le haut
niveau de tâches. D'un point de vue métier, elles peuvent être considérées comme des actions atomiques, mais il est
évident qu'elles nécessiteraient un certain nombre d'étapes si elles étaient décomposées au niveau informatique. En
général, dans le cas du développement orienté objet ou à base de composants, chaque tâche distincte serait ensuite
traitée à partir d'une vue métier comme un cas d'utilisation dans la vue informatique et décomposée en ensembles de
composants et de classes afin de permettre l'implémentation du cas d'utilisation.
Dans le cas d'une solution orientée services, le service est identifié à un niveau de granularité similaire. On
considère généralement que les opérations d'une spécification de service correspondront à 100% aux tâches atomiques
identifiées dans un modèle de processus métier. Bien que cette approche soit intéressante et puisse, si on l'utilise
prudemment, donner les résultats attendus, elle tend à faire penser qu'une fois ce type de services identifiés, ils
peuvent être directement implémentés lorsqu'ils sont décrits dans le modèle de processus. En particulier, chaque rôle
(couloir d'activité) deviendra un service nommé et chaque tâche d'un couloir d'activité sera créée en tant qu'opération
pour le service correspondant, comme illustré dans le diagramme suivant.
Le défaut de cette approche est de ne pas prendre en compte le fait que des exigences non fonctionnelles ont un impact
sur le type de service devant être développé, sur la façon dont les opérations sont identifiées pour les services, etc.
Le niveau de détail généralement enregistré par ce type d'outils n'est pas suffisant pour enregistrer par exemple les
règles de sécurité, de qualité de service ou de gérabilité. La transformation du processus en un ensemble de
spécifications de service potentielles dans un modèle de services permet d'obtenir un point de départ, mais il
doit vraiment être considéré comme un simple point de départ à partir duquel l'analyse doit se poursuivre avant que le
modèle de conception (qui décrit l'implémentation réelle) ne soit développé. Par conséquent, l'état de tous ces
services doit être défini par "candidat", comme illustré dans cette vue de propriété de Rational Software Modeler.
Représentation alternative
Lorsqu'un format plus orienté document pour le modèle de services est utilisé, il peut être plus approprié de capturer
le mappage entre les tâches de processus et le service à l'aide d'un format tabulaire. L'exemple ci-dessous montre ce
format possible.
|