Tous les articles par Thomas Cordival

Concevoir des interfaces inter-applicatives : les formats pivots

Suite au précédent billet sur les interfaces, nous allons ici approfondir les intérêts ainsi que les risques que peuvent présenter la mise en place de formats pivots.

La thèse initiale

La promesse faite par les partisans des formats pivots est que leur utilisation permet de réduire les coûts d’intégration : il est plus intéressant que chacune des applications ayant besoin de s’intégrer fasse la moitié du chemin.

Ainsi, une approche directe (sans format intermédiaire) consiste à ce qu’une application conserve son format et ses contraintes et que les applications avec qui elle doit communiquer s’y adaptent. À l’opposé, la mise en place d’un format pivot consiste à définir un format intermédiaire permettant de tenir compte des différents cas d’usages, puis de développer des traitements d’intégration pour que chacune des applications puissent interagir avec ce format.

Qu’est-ce qu’un format

Lors de la mise en place d’un format pivot ou dans la spécification d’une interface entre deux applications, un format représente le contrat sur les données échangées. Nous parlons ici de contrat car la définition de formats pivots prend toute sa dimension dans une approche service des interfaces entre applications, ce qui fera l’objet d’un prochain billet sur le blog.

Que sa description soit formelle ou implicite, le format porte donc :

  • Le type des données échangées : les entités métier qui transitent dans l’interface
  • Le format technique utilisé dans l’interface, ce qui matérialise le format structurel (arborescence, tabulaire, relationnelle), le format du conteneur technique (XML, CSV, tables) et la manière d’encoder chacun des attributs (encoding des chaînes de caractères, format des dates…)
  • Les codifications ou référentiels associés à chacun des attributs
  • La définition des critères d’unicité des entités : les contraintes d’unicité des entités et les multiplicités des relations des données transitant dans l’interface peuvent être différentes de celles des applications impliquées (par exemple la relation entre un client et un dossier client qui peut faire que les entités sont confondues dans certains systèmes (relations 1-1) et pas dans d’autres)
  • La définition de l’ensemble des objets transitant dans l’interface : le sous-ensemble des entités qui sont concernées par l’interface (par exemple, une application de gestion des ressources humaines qui travaille sur l’ensemble du personnel et une application de gestion des contrats avec les entreprises d’intérim qui ne travaille que sur le personnel intérimaire).

La définition de ces formats est une base de la mise en place d’une démarche d’urbanisme des interfaces d’une DSI. Elle permet en effet de distinguer les éléments communs qui doivent être partagés entre les applications de ceux qui peuvent être spécifiques à une application ou une interface. Pour chacune des caractéristiques du format (type de données, formats technique (structurel, conteneur et encodage des attributs), référentiels et codifications), il faut donc se poser la question de l’intérêt d’une homogénéisation ou d’une spécialisation.

Les intérêts des formats pivots

Le premier gain qui peut être attendu lors de la mise en place d’un format pivot est la diminution du coût de mise en place des interfaces.

La description de formats pivot, et des services associés, place les applications dans une relation client-fournisseur. Cette contractualisation permet de définir de manière nette les frontières de responsabilité entre applications et leurs dépendances. Ce n’est pas un hasard si les formats pivots dont l’usage est le plus généralisé (SWIFT et les formats EDI par exemple) se retrouvent dans les interfaces inter-SI : elles se sont placées sur des interfaces qui étaient déjà des relations clients-fournisseur contractualisées.

La généralisation de formats pivots peut également être l’occasion pour une DSI de spécifier une méthodologie de définition de ses formats, une grammaire commune à toutes les applications pour définir les données qui transitent dans les interfaces. Cette grammaire peut s’exprimer en termes d’entités, de relations et d’attributs, dans un vocabulaire de modélisation objet ou dans tout langage de description de données. Cette démarche peut mener jusqu’à une industrialisation des développements des traitements d’intégration (export et import des données des interfaces par les applications) dans les projets.

Spécifier des formats pivots nécessite d’identifier les différentes entités qui circulent entre les applications. Cette spécification est donc également l’occasion de formaliser le dictionnaire de l’entreprise et de définir un langage commun aux utilisateurs des différents métiers et à la DSI. Ceci facilite la communication dans l’entreprise, entre autre lors des projets informatiques.

Enfin, la mise en place de formats pivots autour d’une application facilite son rôle de fournisseur. Durant un projet, cela permet de limiter la quantité de spécificités des clients à prendre en compte à ce qui a été identifié comme suffisamment commun et donc mis dans le pivot et le service rendu par le fournisseur.

De manière générale, dans une interface, la mise en place d’un format pivot profite à l’application qui est du côté où il est seul (souvent le fournisseur). La limite de sa responsabilité est définie et il sera ainsi souvent plus facile de faire bouger un nouveau tiers pour qu’il se conforme à la règle qui est déjà définie et partagée. Il faut aussi garder à l’esprit que le nombre de clients qui utilisent effectivement un format pivot est en général moins grand que ce qui est espéré lors de sa conception initiale pour deux principales raisons : la partie commune peut se révéler trop faible et la complexité de mise en œuvre trop élevée.

Les coûts de la généralisation

La généralisation nécessaire à la mise en place de formats pivots a un coût, qui doit être rentabilisé par la réduction du coût marginal d’une intégration supplémentaire utilisant ce nouveau pivot. Ceci est généralement démenti lors de la mise en place des interfaces jusqu’au format pivot : elles sont souvent aussi coûteuses à mettre en œuvre que des interfaces directes. Mais la principale difficulté réside dans la généralisation nécessaire à la mise en œuvre d’un format pivot.

La mise en place d’un format pivot demande de prendre en compte les spécificités de toutes les interfaces qui vont l’utiliser, ce qui demande un travail de conception beaucoup plus complexe et risqué que de spécifier les formats unitairement. En effet, la construction d’un format pivot par juxtaposition des besoins des différentes applications ne va faire que concentrer la complexité de toutes les interfaces dans un seul format qui sera de plus rigidifié par le nombre de contraintes qu’il porte.

Un pivot est également supposé être utilisé plus longtemps qu’un format pour une interface point à point, ce qui demande de concevoir dès le premier jour son évolutivité. La construction d’un format pivot pose la question de sa responsabilité et de sa propriété. Il faut en effet à la fois un sponsor qui finance cet effort initial dont les gains à court terme ne sont pas évidents et un responsable qui portera l’effort au-delà de la première mise en place. Ces deux rôles sont complémentaires car ils ont des intérêts différents : l’un voudra que le coût initial soit le plus raisonnable tandis que l’autre cherchera à ce que le pivot soit le plus général possible pour pouvoir le diffuser largement dans le SI.

La tentation d’un urbaniste lors de la définition d’un pivot peut être d’essayer d’englober la totalité des notions qui ressemblent à l’objet visé sous prétexte qu’elles portent le même nom ou partagent une structure commune (par exemple facture client et facture fournisseur ou client et prospect). Plus le format prendra en compte de spécificités, plus il sera compliqué de s’accorder sur son contenu et plus il sera complexe à mettre en œuvre. Il est alors important de se concentrer sur les éléments qui sont réellement communs, ce qui peut rendre le format sans intérêt (par exemple lorsque seuls les identifiants et les libellés sont partagés) ou décevant intellectuellement.

Le rythme de mise en œuvre des évolutions à coordonner entre les différentes applications (client(s) et fournisseur(s)) représente une difficulté supplémentaire, à la fois à la conception (réussir à collecter les besoins de tout le monde pour réaliser une version initiale) et dans le maintien de l’interface et des différents environnements dans lesquels elle peut être exécutée. Ce problème de coordination peut résulter dans une situation ou une application principale impose son format au nom de ses contraintes de planning.

La mise en place de formats pivots permet de maîtriser (ou au moins d’identifier) les points de dépendance avec un tiers (fournisseur) ou une application (par exemple un progiciel). Cependant, la mise en place d’un pivot dans le seul but de se rendre indépendant peut conduire à la superposition de couches d’isolation n’apportant aucune valeur (par exemple en imposant un format technique sous prétexte qu’il est technologiquement neutre). D’autre part, à l’échelle d’un SI, vouloir isoler absolument les applications d’un ERP central qui est mis en place pour rester 5 à 10 ans apporte beaucoup de contraintes et bien peu de gains.  Il n’est pas absurde de conserver des parties du format du fournisseur, mais cela doit relever d’un choix et non être subit. Il peut également être tentant de se réfugier derrière un produit (ETL, EAI, ou ESB) ou une technologie (XML) promettant l’isolation. Or, la valeur et la durabilité du format pivot résident dans le modèle et les codifications, pas dans son format technique.

Faut-il mettre en place des formats pivots ?

S’il peut être bénéfique de mettre en place des formats pivots dans les interfaces de service de son SI, à quelles fins ?

Nous pouvons identifier deux cas d’usage où les formats pivots peuvent apporter de réels gains :

  • La diffusion de données de référentiels
  • Le transport de données opérationnelles fortement partagées qui traversent le SI (stock, ventes…)

Dans ces deux cas, il s’agit de données qui sont déjà largement partagées dans le SI. Il est donc ici possible d’espérer tirer les avantages de la mise en place d’un format pivot :

  • Le partage de la définition des données, ce qui en facilite l’interprétation et la cohérence
  • La réduction des coûts d’intégration des applications (développements et données mieux maîtrisés)
  • Dans certains cas, la réduction du nombre de développements d’intégration

Au contraire, certains objets peuvent se révéler être de mauvais candidats pour l’utilisation d’un format pivot. On peut prendre pour exemple l’entité « client ». C’est une notion dont la définition peut varier très largement entre les différentes utilisations qui en sont faites (de la prospection commerciale à la facturation). Non seulement les attributs nécessaires aux différentes étapes du cycle de vie de l’objet ont peu en commun, mais l’identité même de l’objet peut être différente : il faut parfois faire la distinction entre les filiales et les agences d’une même entreprise (au moment de la livraison par exemple) alors qu’elles peuvent être considérées comme une seule entité pour la facturation ou l’évaluation de la solidité financière. C’est un objet dont une représentation unique servant tous les usages du SI est une illusion, ce qui n’empêche pas d’avoir un pivot plus spécifique pour certains usages clairement définis.

Il faut garder à l’esprit lors de la conception d’un format que sa complétude est moins importante que sa souplesse (capacité à y décrire des données de natures différentes et complexes), sa facilité de mise en œuvre (en tenant compte de l’outillage disponible sur le marché et l’intégration aux méthodes et outils de la DSI) et son évolutivité (capacité à évoluer sans rompre la compatibilité avec les utilisateurs déjà en place).

Au-delà des caractéristiques générales que nous pouvons proposer, la conception de formats pivots demande une grande maturité de la fonction urbanisme dans une DSI au point d’avoir une vision de l’évolution du métier de l’entreprise et du SI qui le sert, pour comprendre quels sont les points d’adhérence justifiés et les éléments qui peuvent être mis en commun entre les applications. Surestimer cette maturité est une erreur fréquente des architectes et des urbanistes.

Conclusion

Nous avons vu ici que la mise en place d’un format pivot représente rarement une réduction des coûts de développement. Elle peut cependant permettre un transfert de coût de l’application fournisseur aux applications clientes et un lissage des dépenses dans le temps.

Sur le plan méthodologique, la mise en place de formats pivots et la définition des niveaux de partage (définition des entités, formats techniques, référentiels), permet de matérialiser la démarche d’urbanisme et de faciliter l’industrialisation de l’intégration des applications.

Ce partage et les normalisations associées imposent des rigidités et des difficultés supplémentaires. Celles-ci doivent donc être équilibrées par les gains apportés par la mutualisation.

Nous avons ici évoqué le contrat passé entre les applications sur les données. Or, cette démarche de contractualisation est bien plus vaste et doit prendre en compte les traitements faits sur les données, les cinématiques de plusieurs interfaces, les volumes de données, les capacités d’annulation ou de réémission d’une interface, l’outillage mis à disposition pour le développement et la disponibilité. En résumé, tout ce qui constitue un service, qui sera détaillé dans un prochain billet.

Problématiques des interfaces entre applications

Ce blog est destiné à traiter de sujets de modélisation, et plus particulièrement de la modélisation de systèmes d’information complexes. Nous commencerons par traiter d’un sujet au coeur de la décomposition de systèmes informatiques complexes : les interfaces.

La première définition que nous pouvons donner est la suivante « Limite commune à deux systèmes, permettant des échanges entre ceux-ci » (Larousse). Cette définition précise qu’il s’agit donc d’éléments communs à deux applications qui permettent des échanges, dans notre cas, principalement d’informations ou de demande d’exécution d’ordre.

Nous limiterons ce billet aux interfaces d’échanges d’information, en opposition aux interfaces d’interrogation (par exemple via des web-services) et aux diffusion large de type publish-and-subscribe.

Les éléments constitutifs d’une interface

Au delà de la définition théorique d’une interface entre deux applications, il nous faut définir sa décomposition en éléments identifiables qui porteront les exigences, et qui auront des représentations physiques tout au long de la vie de l’interface : spécifications, programmes de traitements, fichiers de données.

Un premier niveau d’analyse logique d’une interface dans le contexte d’un SI se focalise principalement sur les données qui y transitent, sur ses dépendances, en terme de données de référentiel ou d’autres données transitant dans des interfaces, ainsi que sur les éléments déclencheurs : critère horaire, déclenchement à la demande d’un utilisateur ou sur l’apparition d’un évènement interne à l’application ou externe.

Au niveau technique, une interface peut se décomposer suivant les éléments suivants :

  • Un ou plusieurs traitements d’extraction qui permettent de transformer les données d’un format propre à l’application émettrice dans un format intelligible
  • Un ou plusieurs mécanismes de transport. Ceux-ci ne modifient pas les données mais sont chargés de déplacer physiquement les données d’une machine (serveur, poste utilisateur …) à un autre.
  • Un ou plusieurs traitements intermédiaire qui sont chargés de transformer le format émit par l’application source dans un format compatible avec les traitements de chargement de l’application destinataire.
  • Des données transportées d’une application à une autre, matérialisées par un format (schéma XML, description de champs pour un fichier plat …)
  • Un ou plusieurs traitements de chargement qui ont pour rôle de charger les données émises afin que les traitements propres à la logique de l’application destinataire puisse les utiliser.

Cette décomposition est évidemment maximaliste et vise à décrire les cas les plus complexes. Nous verrons plus tard les intérêts et les problèmes posés par la mise en place de pivots, mais la mise en place de traitements intermédiaire n’a de sens que dans un tel cas.

Les données de référentiel

Les données de référentiel sont les données auxquels font référence les objets transportés dans une interface. Elles ont en général une durée de vie plus longue et une fréquence de mise à jour plus faible que les données de transaction.

D’un certain point de vue, les données de référentiel sont des données comme les autres et font l’objet d’interface entre les applications maîtresses de leurs mises à jour et les applications qui les utilisent. Cependant, ces données ont un rôle important puisque c’est sur celles-ci que reposent les données de transaction qui portent les informations opérationnelles : factures, écritures comptables, commande d’achat … Cette importance se traduit dans une question qui revient souvent lors de la conception d’interfaces dans un système d’information : doit-on faire transiter les données de référentiel avec les données de transaction ou faire des interfaces séparées ?

Les données de référentiel utilisées par une interface doivent en général faire l’objet d’interfaces à part pour plusieurs raisons :

  • Le cycle de vie des interfaces de référentiel et de transaction n’est pas le même
  • Les interfaces de référentiel sont en général de bons candidats à la réutilisation, surcharger ces interfaces avec des données spécifiques à certaines applications peut nuire à cette réutilisation en augmentant la complexité de l’interface
  • La séparation de ces flux facilite une mise en oeuvre ultérieure d’une concentration des données référentielles dans une application dédiée à leur gestion.

Cependant, certaines situations rendent la séparation en différentes interfaces trop complexe ou coûteuse pour l’intérêt que cela représente :

  • Des interfaces particulièrement simples : le format et les traitements utilisés sont simples et stables. Par exemple, créer une interface supplémentaire uniquement pour transférer les libellés d’objets n’est pas nécessairement judicieux.
  • Un référentiel très lourd dont peu d’objets sont utilisés et qui ne sont pas identifiables à priori.
  • Des besoins de fraîcheur de données très importants : les données de référentiel sont très souvent modifiées et que l’utilisation des données les plus fraîches est indispensable (problèmes en cas de désynchronisation des applications)
  • Un référentiel pauvre ne gérant pas les données à date pour permettre leur accrochage avec les données de transaction.

Ces cas peuvent amener à charger des données de référentiel dans des interfaces initialement prévues pour transférer des transactions. Chaque référence faite par celles-ci est alors remplacées dans le format d’extraction par les informations utiles à l’application cible.

La réutilisation des interfaces : les formats pivots

Lors qu’il est question d’interfaces dans un SI, le terme de format pivot est une question centrale. Le principe de fonctionnement est le suivant : pour chaque interface on fait l’effort d’extraire les données dans un format pivot ou de les y transformer et ensuite de le re-transformer dans le format de chargement dans l’application cible ou de l’y charger directement.

La thèse est que la réutilisation permise par ce mode de fonctionnement est supérieure au surcout engendré par la complexité supplémentaire de chaque interface.

Ce mode de fonctionnement ne peut être indépendant des frontières posées entre les applications : les gains engendrés par une réutilisation sont plus importants si une partie des transformations intermédiaires peut être partagée entre les différentes applications.

Le principal piège tient au fait que la description d’un format pivot ne fait pas tout. En effet, en plus de son format, une interface est décrite par ses dépendances externes (référentiels associées, codifications), son mode de fonctionnement (par exemple transfert de toutes les données ou uniquement des données modifiées) et ses conditions de déclenchement. S’il y a besoin de faire la combinaison de toutes ces possibilités, l’interface pensée comme générique devient vite un cas particulier pour chaque application partenaire.

Dans certains cas, la définition et l’usage d’interfaces standards d’intégration (définies par un format et les caractéristiques mentionnées précédemment) des applications présentent des avantages en terme d’efficacité de travail. Par exemple la diffusion de référentiels et les interfaces proposées par une application proposant des services centraux utilisés par différentes applications (par exemple une application comptable qui recueille l’ensemble de les factures afin de les comptabiliser) sont de bons candidats. La mise en place de ces interfaces standards autour d’applications structurantes dans le SI permet ensuite de cadrer l’intégration de nouvelles applications en offrant un certain nombre de points d’entrée partagés.

Nous ne faisons ici qu’effleurer le sujet des formats pivots, dont les intérêts et inconvénients sont souvent mal compris. Nous l’approfondirons donc dans un prochain billet.

La réutilisation des interfaces : les composants techniques

Dans une même optique que le partage des formats, il est envisageable de partager entre les différentes interfaces et différentes applications un certain nombre de composants techniques.

Les éléments les plus évidents à partager sont les middleware : ils sont par définition agnostiques des données qu’ils manipulent et sont souvent structurés afin de pouvoir gérer des contextes et des projets différents. Il s’agit d’outils de transfert de données (transfert de fichier, middleware orienté message …), de traitement (ETL, EAI/ESB, EDI …) ou de stockage des données (Bases de données …) ou d’outils utilisés par les applications en dehors du strict domaine des interfaces comme un ordonnanceur.

En poussant la réflexion, on se rend compte qu’il est possible de partager à l’intérieur de ces outils des éléments : code source, paramétrage … Ceci permet de constituer un framework autour duquel est capitalisé le travail réalisé sur les différentes interfaces. Dans le cas d’un middleware de traitement de données, on peut donner comme exemple des formats de fichier ou des traitements génériques (changement de codification des données, de format techniques ou d’encodage des fichier).

Enfin, certains services annexes sont utiles pour la plupart des applications mais relèvent presque d’une logique applicative, on peut alors imaginer le développement d’un tel outil partagé. Par exemple, la gestion des rejets dans une interface demande des écrans permettant aux utilisateurs de voir des données, éventuellement les corriger voire de relancer l’interface. L’assemblage des différents services partagés peuvent former un véritable service d’intégration, mais ceci sera le sujet d’une prochaine note sur ce blog.

Cette partie technique est aujourd’hui plus mure et permet ainsi d’espérer des gains de productivité plus importants que la mise en place d’une approche fondée sur des formats pivots.

Les frontières de responsabilités entre les applications

La création d’interfaces entre applications demande de définir la propriété de certaines données, ce qui nécessite de délimiter les périmètres de responsabilité des différentes applications. Il est donc important de faire ces attributions avant de mettre en place les interfaces.

Nous partons ici du principe qu’une interface entre deux applications nécessite forcément des modifications sur les informations transportées, que ce soit des changements sur les données elles-même (transcodification …) ou des traitements techniques (changement d’encodage des caractères, de formats de dates …). En effet, la question de l’adaptation ne se pose pas sinon.

La solution par défaut lors de la mise en place d’une nouvelle application est souvent de dire que toutes les adaptations seront réalisées par celle-ci. Cette position vient du fait que la nouvelle application est en cours de projet et que, par conséquent, elle a un budget alloué et des équipes présentes et qu’il est plus simple de gérer les modifications localisées à un seul projet.

Il convient ainsi de prendre plusieurs facteurs en considération :

  • « La norme » : quelle est l’application qui a le comportement le plus spécifique ? Car si une des applications doit s’adapter à l’autre c’est alors celle-ci.
  • Cycle de vie : si une application est en fin de vie, c’est à elle de s’adapter : ces spécificités disparaîtront alors avec son décomissionnement au lieu de perdurer et de constituer un standard de fait au sein de l’entreprise.
  • Capacité d’adaptation : si une application a des contraintes qui l’empêchent de s’adapter (pauvreté des mécanismes d’intégration disponibles, application hébergée en ASP, indisponibilité des équipes, etc.), le travail devra être fait par l’autre application concernée
  • Les besoins de données externes : si les modifications réalisées ont besoin de données appartenant à une des applications alors les adaptations doivent y être faites.
  • Présence de d’interfaces standard (formalisés ou de fait) : si l’interface qui est mise en place correspond à une interface déjà existante avec une autre application alors c’est la nouvelle application qui doit s’adapter.

Les questions et difficultés que nous avons mentionnées sont également présentes dans l’intégration inter-système d’information (client-fournisseur ou SI partenaires) mais sont rendues plus aiguës par la distance introduite entre les équipes et les différences de conception des interfaces (vocabulaire, principes de partage …).

Conclusion

Cette note de sensibilisation nous a permis d’aborder un certain nombre de problématiques rencontrées dans la mise en place d’interfaces entre les différentes applications d’un système d’information classique. Elle laisse volontairement de côté les aspects de techniques et d’urbanisme qui sont des sujets à part entière et qui mériteront des notes de blog dédiées.

Les différents objets mentionnés ainsi que leurs propriétés constituent une première présentation d’un modèle logique des interfaces entre applications.