L'architecture

1 - La base - Le spaghettiware

Par "solution d'intégration" nous désignons un logiciel qui prend en charge le dialogue inter-applications. Ces plates-formes jouent en quelque sorte le rôle d'ilotier du système d'information. 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 chaîne 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'intégration remplit ce rôle en assumant quatre types de fonctions :

Une plate-forme d'Intégration couvre ces quatre étapes. Par comparaison, un logiciel d'ETL peut extraire et appliquer des transformations à des données, mais n'est nullement conçu pour appliquer des règles de routage complexes. Cela dit, un outil d'ETL peut répondre, dans une certaine mesure, à des besoins d'échanges de données, d'où la confusion.

La gestion des processus métiers (BPM, pour Business Process Management) prolonge assez naturellement les quatre fonctions de l'Intégration. 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. Dans la réalité, ce n'est pas vraiment une surprise, tout n'est pas aussi transparent et automatique. Passer les informations du BPM au serveur d'intégration demande des interventions humaines pour, au minimum, finaliser le paramétrage technique.

Avec l'ouverture croissante du système d'information aux partenaires et clients, les éditeurs d'Intégration ont naturellement étendu le champ d'action de leurs plates-formes à l'intégration B to B. A cette fin, beaucoup de ces éditeurs ont rendu leur plate-forme capable d'interpréter les sémantiques définis par des consortiums tels que RosettaNet. Dans le domaine de l'intégration B to B, deux grandes écoles cohabitent:

• ceux qui, à l'instar de webMethods, estiment que les flux B to B exploitant les technologies Web (de http à XML) ne sont pas de la même nature que les flux internes. Et demandent donc des serveurs d'intégration distincts.
• ceux pour qui, à l'instar de Seebeyond, l'intégration B to B prend la forme d'un connecteur enrichi de fonctionnalités relatives aux problématiques B to B et qui s'adosse au serveur d'intégration également exploité pour les flux internes.

Ce débat ne doit toutefois pas trop monopolisé votre attention. Au moins dans un premier temps. Les points de différenciation critiques des offres d'Itégration sont plutôt à chercher du côté des modèles d'architecture qu'elles implémentent.

2 - Les modèles d'architecture

Au moins deux modèles peuvent correspondre à notre besoin : Le "Hub and spoke" et le 'Network Centric".

• L'architecture "Hub and spoke"
  C'est le modèle centralisé de l'Intégration. 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. "En revanche, prévient Marc Muller, PDG de Dreamsoft, la gestion de la charge s'avère complexe dans ce type d'environnement: la seule solution consiste en effet à multiplier les hubs sur les différents segments du réseau, sachant qu'il faudra veiller à synchroniser les règles stockées sur ces différents nœuds". L'administration devient alors moins aisée.
• L'architecture "Network Centric"
  Il s'agit cette fois de la version décentralisée de l'implémentation de l'Intégration. Des référentiels de règles et des gestionnaires de messages sont distribués sur l'ensemble des nœuds (point de connexion à une application). Quand une application émet un message, ce dernier est traité par le référentiel du nœud 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 nœuds.

Les autres points de différenciation des offres :

• Cohérence de la solution :
  Toutes les briques de la plate-forme (connecteurs, serveur d'intégration, outil de BPM) sont-elles bien intégrées ? Partagent-elles par exemple un même référentiel ?
• Puissance de l'outil de BPM :
  L'outil de BPM est-il capable de gérer les interactions humaines ? Quelle supervision des processus permet-il ?
• Connecteurs :
  La plate-forme dispose-t-elle d'un bon éventail de connecteurs ? Un kit pour développer ses propres connecteurs est-il fourni ? Quels types d'échanges B to B peuvent être gérés (EDI ? Swift ? Rosetanet ? cXML.) ?
• Productivité :
  L'ergonomie des outils garantit-elle une bonne productivité, dans les phases de développement et de déploiement ? Facilite-t-elle la gestion des versions et le travail en groupe ?
• Compétences requises :
  A quelles compétences la plate-forme fait-elle appel ? (Java ? XML ? Autres ?)

Ces points de différenciation permettent de comparer les outils du marché.

3 - Le découpage de son système d'information

L'étape suivante une fois son type d'architecture trouvé est de structurer les accès aux applications de votre système d'information.

Suivant les caractéristiques des accès aux différents modules, vous pouvez avoir besoin d'atteindre différents objectifs : Sécurité, filtrage, isolation, robustesse, etc. Le schéma suivant détaille une technique d'accès aux données répondant à toutes ces contraintes :

Les objectifs recherchés

L'implémentation

Voici l'implémentation correspondant à ces objectifs :

Conclusion

L'architecture d'une solution d'intégration ne se limite pas au produit en lui-même. Il faut bien étudier l'architecture entourant votre Intégration et définir des règles à suivrent impérativement pour éviter d'aboutir à des situations absurdes et de véritables imbroglios.

Un moteur d'intégration ne vous permettra pas d'avoir une boîte "fourre-tout" dans laquelle on ne maîtrise pas ce qui se passe. Un moteur d'Intégration va, au contraire, vous obliger à décrire et structurer vos échanges.

Vous avez maintenant à traiter deux autres sujets avant de passer à la partie, dite "Cyclique" commencant par la gestion du référentiel :

• Organiser vos équipes autour de processus communs
• Comparer les différentes solutions du marché répondant à vos besoins