Avec Internet et les nouvelles technologies, les échanges d’information au sein d’une même entreprise mais aussi avec l’extérieur (partenaires, fournisseurs, clients, etc…) se développent à vitesse grand V. Les entreprises sont alors confrontées à des problématiques complexes d’intégration. La mise en place de formats pivot est une réponse idéale à l’intégration de flux au sein du Système d’Informations de l’entreprise.
Définition
Dans toute problématique informatique, on rencontre la notion d’entité métier. On caractérise cette entité par un ensemble de caractéristiques qui la définissent et qui ont, entre elles, de fortes dépendances. Ainsi, dans le cadre de la facturation, on parlera de clients, de factures, de contrats… Dans le domaine du trading, on parlera de portefeuilles, de passage d’ordres, de ventes, d’achats…
Un format pivot, qu’on peut aussi appeler format d’échange de données, format canonique ou encore objet métier de référence, se définit donc comme une entité métier structurante, pour un domaine métier spécifique. Il a un sens sémantique « fort ». Un modèle de formats pivot définit les relations entre ces formats.
Contexte d’utilisation
Les formats pivot sont utilisés essentiellement pour répondre à des problématiques d’intégration de flux. Ainsi, ces formats peuvent être rattachés à des architectures structurées autour d’outils de type ETL (Extract Transform Load), ou même des environnements SOA (Service Oriented Architecture). Le recensement, la modélisation et l’implémentation de ces formats pivot s’insère aussi parfaitement dans une démarche d’urbanisation du système d’information.
Les formats pivot et Oracle
Oracle propose un outil de type ETL avec ODI (Oracle Data Integrator). ODI est une plateforme complète d’intégration de données, qui couvre un spectre large de besoins sur les données d’intégration : l’implémentation de processus d’intégration, l’intégration de gros volumes, l’implémentation de batchs de haute performance ou orientés évènements, etc… Les échanges de données entre applications se font en général en mode point à point, et les données véhiculées sont représentées sous la forme de formats pivot.
Oracle propose aussi une Suite SOA complète permettant d’implémenter de bout en bout une architecture orientée services. Cette suite dispose d’un bus de service permettant de transformer et router des flux de données. Ces données sont également représentées par des formats pivot.
Intérêts
Un format pivot correctement défini et utilisé, ainsi que le modèle associé, ont une grande valeur ajoutée :
- Il facilite la compréhension commune, du métier et de la direction opérationnelle du SI, de ce qu’est réellement l’entité métier qu’il représente, ainsi que des relations entre ces entités.
- Il minimise les coûts liés à l’intégration des systèmes, ces derniers utilisant les mêmes objets et manipulant les mêmes concepts.
- Il facilite le couplage lâche, c’est-à-dire empêche l’interdépendance entre systèmes définis par des formats spécifiques.
Comment créer son format pivot ?
Plusieurs démarches sont possibles pour créer son modèle de formats pivot.
La démarche « top-down »
La démarche « top-down consiste à conceptualiser l’existant métier. Elle préconise de construire ces formats pivot à partir de la sémantique métier de l’entreprise. A partir de ces formats pivot, dans les systèmes, on modifie les traitements et les structures pour qu’elles tiennent compte des ces nouveaux formats, qui peuvent être loin de la réalité technique.
L’intérêt de cette méthodologie est qu’elle permet de mieux s’aligner aux besoins métiers, et donc de mieux répondre aux nouveaux challenges de l’entreprise. Elle permet aussi de profiter pleinement des mutualisations de formats pivot, qui sous-entend la mutualisation de services, et donc une architecture SOA optimisée. La contrainte est qu’elle demande une somme de travail considérable (besoin de cartographier tout le métier du SI pour ensuite le décliner sur les couches basses de développement), et peut induire un coût certain de refonte d’une partie du SI.
La démarche « bottom-up »
La démarche « bottom-up » re-conceptualise l’existant technique. Elle guide le concepteur vers une rétro-conception de l’existant technique, à partir des formats manipulés dans les applications, pour en déduire des formats pivot.
Son gain principal est de réutiliser l’existant, et donc de capitaliser et de gagner du temps sur les développements. De plus, dans le cas de Systèmes d’Informations dans laquelle une application centrale manipule des données avec plusieurs autres systèmes, en partant de données échangées par cette application, on dispose d’un format unitaire cohérent et surtout exhaustif. L’inconvénient de cette démarche est qu’on ne s’aligne pas sur le métier de l’entreprise, il y a donc un risque de césure entre les besoins que peut exprimer la direction métier et les réponses que peut lui apporter la DOSI.
La démarche « meet in the middle »
Cette démarche préconise de mener en parallèle un chantier « Top Down » et un chantier « Bottom Up ». Une fois ces deux chantiers en phase finale, l’objectif est de trouver une passerelle entre ces deux résultats et donc entre les formats pivot orientés métier et les formats pivot orientés techniques. Elle présente les avantages des deux premières méthodes : alignement parfait sur le métier et réutilisation de l’existant. Son principal inconvénient est le risque d’effet « tunnel » qu’elle engendre : attendre la fin des deux chantiers pour construire des formats pivot alternatifs entre une approche métier et une approche technique. Le risque principal est que durant le temps de construction de la passerelle, les besoins métier ou plus vraisemblablement les formats pivot techniques aient changé : les formats pivot alternatifs deviennent alors obsolètes.
La démarche « middle-out »
Cette démarche préconise de commencer à mi-chemin (« middle ») entre le métier et la direction opérationnelle du SI (DOSI), c’est-à-dire à partir d’un vocabulaire commun aux gens du métier et aux informaticiens. Elle s’attaque au problème principal des projets informatiques actuels : la compréhension des problématiques métier côté IT, et vice-versa. Les deux parties trouvent un consensus par l’intermédiaire d’une base d’entités composants-entités métiers nécessaires, à partir duquel découleront les entités haut niveau côté métier (domaines sémantiques, classes sémantiques…), et les entités bas niveau côté DOSI (objets de type Data Transfert Objects).
Cette démarche peut être complémentaire à la mise en place progressive d’une architecture SOA.
Personnellement, je préfère les deux dernières démarches qui allient pragmatisme et efficacité. La meilleure méthode parmi ces deux dernières est à mon avis de privilégier l’une ou l’autre approche selon les cartes en main de l’entreprise sur ce projet :
- Disponibilités du métier ;
- Degré de compréhension entre la DOSI et le métier ;
- Temps et nombre de ressources allouées à la tâche d’urbanisation…
Comme dans beaucoup de situations, il faut simplement faire preuve de bon sens…
Illustration
Pour finir, quelques conseils…
- Impliquer tous les acteurs ;
- Savoir solliciter suffisamment le métier ou les documentations métier pour ne pas être dans l’interprétation côté DOSI ;
- Ne pas avoir les yeux plus gros que le ventre, savoir délimiter son périmètre d’entités à « pivotiser »,
- Itérer pour progressivement arriver à l’utilisation de formats d’échange de données standards à l’entreprise et à son métier ;
- Utiliser pour cela le contexte de projets concrets pour la mise en place de ces formats pivot ;
- Découper suffisamment ces entités en plusieurs entités, de manière à les rendre lisibles par tout un chacun, et en y associant des espaces de nommage, tout en évitant l’effet « grappe » ;
- Privilégier la communication autour de l’aspect graphique (diagramme de classes) plutôt que l’aspect technique (fichier XSD).
Merci beaucoup aux auteurs des articles suivants, qui m’ont beaucoup inspirés dont je vous recommande la lecture :
