|
Par "plate-forme-EAI" nous désignons un logiciel qui prend en charge le dialogue inter-applications..
Sans elles, quand les applications d'une entreprise sont nombreuses et doivent échanger beaucoup de données, c'est "l'effet spaghetti" assuré: les applications se parlent en face à face (on dit encore en "point à point") via des interfaces qui doivent être paramétrées et maintenues une à une... Or, dans la vie d'une grande entreprise, les occasions d'arriver à cet "effet spaghetti" sont de plus en plus nombreuses: que l'on parle gestion de la relation client, optimisation de la chaine logistique ou encore échanges de données avec les fournisseurs, il s'agit bien souvent de faire parler entre elles des applications qui n'ont pas été conçues pour cela à l'origine. D'où le besoin de déployer dans l'entreprise un logiciel qui va permettre d'industrialiser et de rationaliser ces échanges d'informations. Une plate-forme d'EAI remplit ce rôle en assumant quatre types de fonctions:
-Routage
-Transformation
-Connecteurs (aux applications)
-Transport
Autrement dit, en fonction d'événements préalablement définis, un logiciel d'EAI récupère les données d'une application, puis les "route" vers leur destination (une autre application), non sans les avoir préalablement converties dans un format adéquat. A cette fin, il met en oeuvre:
- un serveur d'intégration qui comprend un moteur de règles et un gestionnaire de messages (pour le routage et la transformation)
- des connecteurs (pour dialoguer avec les applications)
- et un MOM (middleware orienté messages) pour transporter les messages. Quasiment tous les fournisseurs d'EAI disposent de leur propre MOM même si la plupart du temps les plates-formes d'EAI sont déployées sur des MOM déjà installés dans l'entreprise.
La gestion des processus métiers (BPM, pour Business Process Management) prolonge assez naturellement les quatre fonctions de l'EAI. Le BPM ajoute une couche d'abstraction où l'information manipulée n'est plus une donnée ou un flux technique d'une application vers une autre mais un processus métier. A travers le logiciel de BPM, un architecte métier défini un processus (par exemple le circuit de validation des informations concernant un nouveau client) qui sera traduit en flux techniques, lesquels sont transmis au serveur d'intégration à des fins de paramétrage.
Les architectures en concurrence
Deux modèle d'architecture EAI en concurrence : "Hub and spoke" et 'Network Centric".
L'architecture "Hub and spoke"
C'est le modèle centralisé de l'EAI. Ici, tout passe par un "hub" central. Aucun flux n'est possible sans l'entremise de ce hub. Quand une application envoie un message, ce dernier est expédié à destination du hub. Le référentiel (la base où sont stockées les règles de routage et de transformation) est donc lui aussi centralisé. L'avantage d'une telle architecture saute aux yeux: l'administration est grandement facilitée. "
L'architecture "Network Centric"
Il s'agit cette fois de la version décentralisée de l'implémentation de l'EAI. Des référentiels de règles et des gestionnaires de messages sont distribués sur l'ensemble des noeuds (point de connexion à une application). Quand une application émet un message, ce dernier est traité par le référentiel du noeud correspondant afin que les applications abonnés à ce type de messages le reçoivent. Avec ce type d'architecture, la charge est donc naturellement répartie sur l'ensemble des noeuds.
Une différence pas uniquement technique
Une plate-forme de type "Network Centric" est facturée en premier lieu en fonction du nombre de noeuds; résultat, le client doit d'embler payer pour le périmètre des applications qu'il souhaite couvrir. En revanche, avec le modèle "hub and spoke", un client a la possibilité de n'utiliser qu'un seul hub dans un premier temps pour couvrir un large éventail d'applications. Autrement dit, l'architecture "hub and spoke" donne plus de souplesse que sa concurrente pour acheter des hubs au fur et à mesure de la montée en charge.
|
