Architecture

Interopérabilité fonctionnelle

Publié le : Auteur: Anteo Consulting 2 commentaires
architecture

L’interopérabilité est la motivation première qui vise à améliorer la cohérence des systèmes d’information. La gestion des points de vue fonctionnels ne trouve cependant pas de résolution immédiate et évidente. Au contraire, la mise en œuvre de solutions d’échange de données par entité, risquent souvent d’alourdir les structures d’échange et de finalement introduire plus d’immobilisme que d’agilité dans l’évolution du système.

L’interopérabilité se définit par la facilité avec laquelle les systèmes peuvent échanger. On peut projeter cette propriété sur 3 couches distinctes :

  1. l’interopérabilité technique qui consiste à s’assurer que les encodages des contenus sont exploitables de la part des clients et des fournisseurs de services
  2. l’interopérabilité des protocoles qui permet de garantir l’usage et le fonctionnement cohérent de mécanismes transverses tels que la sécurité ou les transactions
  3. l’interopérabilité fonctionnelle qui s’occupe de l’interprétation cohérente, de l’exhaustivité et de l’utilisabilité de l’information transmise par les services.

S’il est certain que la technologie Web-Services de deuxième génération (spécifications WS-*) apporte des réponses à l’interopérabilité technique et l’interopérabilité des protocoles, résoudre l’interopérabilité fonctionnelle requiert des approches méthodologiques spécifiques.

Prenons par exemple le cas d’un constructeur automobile, le point de vue sur une voiture est très différent selon l’application métier qui l’exploite :

  • pour l’application du concessionnaire, une voiture c’est : des options, un prix de vente, des délais, etc.
  • pour celle de l’usine, une voiture c’est : des approvisionnements, des pièces, un coût de production, etc.
  • pour le contrôle de gestion, une voiture c’est : un BFR, une immobilisation, un coefficient d’absorption des frais généraux, etc.
  • etc.

Pour les objets métier au cœur de l’activité d’entreprise, le nombre de points de vue différents peut ainsi varier de 3 à plus de 10. La question de l’interopérabilité fonctionnelle est donc celle d’un référentiel inter-métiers qui permet d’assurer la cohérence de l’entreprise et celle de la formalisation des services qui viennent autour.

Cette problématique n’est pas nouvelle, et les projets SI n’apportent aujourd’hui que des solutions partielles.

Une première approche prône les données structurées selon les formes normales, sans changer les usages couramment pratiqués pour le développement d’applications . Dans cette vision, l’information est préliminairement structurée selon un point de vue unique qui correspond à l’application en cours de développement. Dans ce ce cas, la première application (ou bien l’ERP) qui prend en charge un objet métier particulier, impose son point de vue aux autres. On crée ainsi des solutions mal adaptées aux points de vue des différents métiers de l’entreprise.

Dans une seconde approche, un format pivot minimaliste est défini pour assurer la cohérence d’information entre les silos applicatifs. Dans ce modèle, chacun a sa définition de l’information mais ils se tiennent au courant des événements survenus dans le cycle de vie de l’objet métier. L’avantage d’une telle approche est que les silos applicatifs gardent une autonomie relative qui correspond bien aux contraintes d’organisation en projets. Elle impose cependant d’administrer les événements afin de compléter l’information pour intégration dans chaque contexte applicatif.

Dans une troisième approche, un format pivot maximaliste est défini pour publier exhaustivement tout ce qui concerne l’objet métier. La philosophie d’une telle approche est que chacun pioche l’information qui le concerne. On réduit certes le besoin d’administrer les événements, mais on introduit en revanche un couplage entre l’évolution de chaque application et la définition du format pivot, qui lui même implique une redéfinition des services associés.

Aucun de ces 3 scénarios n’est donc entièrement satisfaisant. La structuration stricte de la donnée introduit en fait une contrainte de couplage fonctionnel dont on hérite au travers des structures relationnelles (type MCD MERISE) et des interfaces formelles à la CORBA/RPC.

UML permet de modéliser l’information selon une vision un peu plus abstraite que sa stricte mise en œuvre relationnelle et XML introduit des possibilités d’extension dynamique de la donnée avec la déclaration de données optionnelles. Pour autant les possibilités technologiques évoluent actuellement vers plus de souplesse dans la structuration des données : la mise en œuvre de JSON et des bases de données NOSQL faciliteront peut être la mise en œuvre de l’interopérabilité fonctionnelle.

Au-delà des aspects techniques, la construction d’une vision transverse des informations d’entreprise, et notamment de l’urbanisation des données, apparaissent également comme un impératif méthodologique qui ne peut être laissé dans les mains d’un DBA. Dans ce contexte, il faut savoir maintenir la définition sémantique des objets métier de l’entreprise et de leurs règles de gestion, en se gardant de rentrer dans la structuration fine qui ne peut correspondre au mieux qu’à un point de vue instantané, orienté et impermanente de l’information.

 

 

 

  • Splendide! A ce que je comprend, l’interopérabilité fonctionnelle aide ainsi à exploiter les différentes informations disponibles sur différents les pour une application située dans l’une d’eux. Ainsi il y aura ainsi une corrélation et échange d’info.

  • Il est vrai qu’instaurer une interopérabilité au sein d’une entreprise ne se fait pas par déclic ou en un jour d’où l’utilité d’un schéma précis. En fonction des interactions entre les services, il est nécessaire de lui apporter « un langage propre ».