|
|
Expert
UML et Génie Logiciel Objet
Direct (Homsys Group) |
|
Grégory
Weinbach
L'urbanisme,
c'est découpler les applications
SSII regroupant 250 personnes à Paris et dans plusieurs
grandes villes françaises, réalisant en
2002 un CA de 18 millions d'euros, Homsys Group se divise
en trois branches, la première - Kedros - centrée
sur les systèmes et réseau, la seconde -
Homsys - ciblant le décisionnel (BI) et les portails,
et la troisième - Object Direct - dont le métier
est d'assurer l'évolution des architectures. Pour
cette dernière structure, 2003 a coïncidé
avec une reprise nette des projets de refonte d'applications
existantes autour de nouvelles plates-formes comme J2EE.
L'occasion pour Grégory Weinbach d'aborder le thème
de l'urbanisation du SI, des processus métiers
à l'EAI.
27 mai
2003 |
|
|
|
JDNet
Solutions. Où s'arrête l'intégration
et où commence l'urbanisme ?
Grégory Weinbach.
Le but d'une démarche d'urbanisme n'est pas d'unifier:
on sait très bien faire dialoguer ensemble des
applications, avec un MOM [NDLR: Message Oriented Middleware]
type MQSeries, mais si on se focalise sur l'intégration
technique, on peut investir beaucoup d'argent dans quelque
chose qui ne répond pas aux besoins de l'entreprise.
L'objectif ultime est de permettre au SI d'évoluer
facilement, de faire migrer une application progicielle
vers du spécifique ou l'inverse, d'intégrer
un nouveau service, etc.
Pour cela, l'essentiel est de pouvoir remplacer une application
par une autre sans toucher au reste: il s'agit de découpler
les applications, s'assurer par exemple qu'un message
est indépendant techniquement de sa source et de
sa destination, ce qu'une approche EAI n'effectue que
vu de l'extérieur.
Quelles
sont les composantes de l'urbanisme des SI ?
Il s'agit d'un projet à
étapes. D'abord, il est nécessaire d'identifier
ce qui constitue la chaîne de valeur ajoutée
de l'entreprise: les processus métier. Comment
interagissent les systèmes, quels sont les flux
qui sont échangés, etc. Ceci permet de bâtir
un référentiel métier qui modélise
une cible proche de l'existant, destinée à
évoluer, dynamique, itérative. Prendre en
compte cette dimension fonctionnelle, c'est garantir la
souplesse de son SI afin de mettre en oeuvre un lien objectif
entre les décisions stratégiques et leurs
projections sur l'infrastructure technique.
Il est important de noter que l'urbanisation est un projet
d'entreprise qui s'inscrit dans la durée, et qui
est impliquant: la décision émane généralement
de la direction générale, nécessite
des budgets importants, la création d'une structure
fonctionnelle de liaison...
La
notion de processus est mise en avant par les acteurs
du monde des progiciels comme SAP, PeopleSoft ou Siebel,
Cela répond-il à la problématique
d'urbanisation ?
L' approche progicielle
n'est pas urbanisée pour la raison suivante: ce
que nous définissons comme des blocs d'urbanisme
découplés sont au contraire fortement couplés
dans un progiciel, où il est difficile de faire
évoluer un module sans faire évoluer le
reste. On ne maîtrise pas ses processus, on ne peut
pas, par exemple, externaliser ce qui correspond à
un bloc d'urbanisme. Par contre, la démarche progicielle
est pertinente si on veut déléguer la gestion
de ses processus, et à l'inverse, il n'est pas
interdit dans une démarche d'urbanisme d'utiliser
des éléments progiciels comme choix d'implémentation
technique.
Comment
s'organise la modélisation et l'évolution
du projet d'urbanisation ?
Prenons
l'exemple de notre client Bouygues Telecom, pour lequel
nous avons mis en place une démarche d'urbanisme
fin 99 début 2000 avec la construction d'un référentiel
métier ciblant le SI commercial, mais ayant un
impact sur l'ensemble du réseau de l'entreprise.
Nous avons procédé par des entretiens avec
les acteurs de la maîtrise d'ouvrage, puis par validation
et prototypage de spécifications formelles: par
le biais d'enchaînement d'écrans, de scénarios
concrets de manipulation de données réelles,
nous avons pu obtenir un retour sur des simulations de
processus. Par ailleurs, il fallait favoriser l'appropriation
du formalisme de notre référentiel par les
acteurs, ce qui est un aspect fondamental: sans un transfert
de compétence et une bonne communication, on court
le risque que les travaux restent lettres mortes faute
d'une maîtrise d'un vocabulaire pivot.
Quels
sont les choix techniques d'Objet Direct pour la modélisation
des processus ?
Nous aimons travailler avec l'UML, qui
est un outil standard bien adapté à la modélisation
de bout en bout, mais n'est pas obligatoire. Les entreprises
ont souvent des outils de BPM avec leur formalisme propriétaire
ou non, qui permettent de faire beaucoup de choses. Cela
dit, le BPM ne permet pas de décrire le contenu
fonctionnel des flux, au contraire d'UML.
|
|
Propos recueillis
par Jérôme Morlon |
|