Tâche: Analyse de processus métier
Cette tâche identifie les éléments de conception d'une solution orientée services en termes de services et de partitions et documente la spécification initiale de ces services.
Disciplines: Analyse et conception
Objet
  • Identifier les éléments de conception d'une solution orientée services en termes de services et de partitions.
  • Documenter la spécification initiale des services.
  • Déterminer les dépendances initiales et la communication entre les services.
Relations
Description principale

Cette tâche utilise des modèles de processus métier en tant qu'entrée et identifie un ensemble de services candidats qui sont inclus dans le portefeuille de services du projet. Ces services candidats peuvent toutefois nécessiter une amélioration supplémentaire, néanmoins, les étapes incluses dans le présent document fournissent une méthode efficace pour produire un ensemble initial d'Artefact : Spécifications de service.

Etapes
Identifier des services candidats à partir de processus métier

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.

Diagramme décrit dans le contenu textuel.

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.

 Illustration du format tabulaire



Plus d'informations