2.5.3 Urbanisation
actuelle de notre SI
Dans la démarche d'urbanisation, l'objectif est de
décrire différentes vues :
q la vue externe ou « vue organisation »
afin de décrire de façon générale l'organisation en
place,
q la vue interne dont le but est de cartographier le
processus métier d'alimentation des tiers en précisant les
aspects non fonctionnels tels que les performances, la sécurité.
Cette vue prend parfois le nom de « vue qualité de services
(QoS) »,
q la « vue informationnelle » pour
décrire l'information manipulée, les objets métiers (ici,
les tiers),
q la vue applicative ou fonctionnelle où le but est de
décrire les fonctionnalités ou autrement dit les
« services » offerts par le système d'information
pour assurer le processus métier. Cette vue inclut la vue informatique
qui décrit l'infrastructure permettant le fonctionnement des briques
logicielles du système informatique. Cette vue est aussi appelée
« vue des services ».
2.5.3.1 La Vue externe ou vue
organisation
L'objectif est de formaliser la mission de l'organisation
constituée des utilisateurs et des agents (fournisseurs, consommateur,
superviseur, observateur) sous l'angle des échanges concernant le
périmètre de l'étude. La question qui est posée
à cette étape est le : « Pourquoi ?».
Pour répondre à cette question, la modélisation par les
cas d'utilisation UML peut servir d'illustration.
Illustration 90 : Cas
d'utilisation UML de la communication actuelle
2.5.3.2 La Vue interne ou vue
qualité de service (QoS)
La vue interne permet de visualiser les agents qui
réalisent un certain nombre d'activités ou d'actions dans
l'objectif de répondre à des sollicitations
(« évènements métiers »). Ils
collaborent à un objectif commun à partir de ces activités
qui constituent le processus métier. Cette vue doit répondre
à la question du « Qui » et du « Comment
». Pour cela le diagramme des processus métier UML (BPMN) peut
servir de support. Le processus vu sous l'angle BPMN met en évidence les
événements déclencheurs du processus. Ici le
déclencheur est la saisie mais aussi l'événement horaire.
Le processus est constitué d'activités (cadres arrondis et
orangés) consommant des entrées et générant des
sorties. Entrées et sorties constituent des objets métiers
appartenant à la vue informationnelle. Ces différentes
activités sont à la charge d'acteurs
référencés par la vue d'organisation. Ces acteurs sont
représentés en « swimlanes » ou en couloirs,
en français.
Illustration 91 : Processus
métier actuel, BPMN réalisé avec Magicdraw
Les termes de Consommateur et de fournisseur sont très
génériques et cela nécessite probablement plus
d'explications. Le fournisseur représente l'application centrale GCAT
qui gère le référentiel Terrena. C'est par cette
application qu'il est possible de créer et de modifier les informations
relatives aux Tiers. Les consommateurs représentent les applications qui
gravitent autour de ce référentiel. Elles sont alimentées
grâce au superviseur Open Process qui transmet ou rejette tout message
lui étant présenté (« message »
étant un terme générique pour nommer les informations
tiers réunies dans un fichier dans un format Csv). La photographie de
l'existant ne serait pas complète, s'il n'était pas
précisé que le message échangé entre fournisseur et
consommateur n'est pas homogène. L'histoire du SI Terrena fait que
cohabitent plusieurs formes d'interfaces de tiers et donc plusieurs structures
de messages.
Arcole Comptabilité
Sipal Agro Fournitures
Reporting
Portail Web Partenaire
Céréales
GCAT Gestion centrale des Tiers
Mémos de Gestion
Distribution spécialisée
Datamart Céréales
Fioul
Semences
Illustration 92 : Les
Consommateurs et le Fournisseur
Les couleurs mettent en évidence la
spécificité de certains flux Tiers (au nombre de 6 sur ce
schéma). De plus, les applications, non dotées d'une alimentation
automatique, n'ont pas été intégrées à cette
illustration (dans ces cas, il s'agit d'un mode dégradé,
totalement manuel).
Deux axes marquent la démarche de construction d'une
architecture SOA : la réutilisation de services (de fonctions) et
l'interopérabilité au sens large. Dès à
présent, il est possible de souligner que réorganiser des
services dans le but de les regrouper et les rendre plus rationnels est
limité lorsqu'il s'agit de s'attaquer à un processus
d'alimentation comme le notre (contrairement à des processus de gestion
où il est plus aisé de trouver des fonctionnalités
multiples et parfois redondantes). L'axe de l'interopérabilité
est quant à lui plus évident pour ce type de
problématique.
Les Consommateurs sont autant de systèmes d'information
hétérogènes qui doivent collaborer entre eux. De
façon générale, il faut bien comprendre qu'une application
est bien souvent à la fois « Consommateur et
Fournisseur » d'information pour le SI tout entier.
| 
