Open XML et les schémas métier - Première partie - Interopérabilité horizontale ou verticale ?
Il semble qu’une certaine confusion règne autour de la notion de « schémas métier ». On entend ainsi parler du fait que l’objectif des schémas métier serait de créer de nouveaux formats de fichiers propriétaires. Il n’en est rien bien sur et la notion de schéma métier et la manière dont ils sont supportés par Open XML méritent d’être développée. Le sujet étant riche il sera développé en plusieurs parties. Le contenu de cette série d’article est largement inspiré des explications données par Doug Mahugh et Brian Jones sur leurs blogs respectifs.
L’un des objectifs d’Open XML est de passer d’un format de fichier binaire (l’ancien format de fichiers d’Office), plat et centré sur le document à un format riche, ouvert et centré sur les données. Autrement dit, en dehors de la nécessité impérieuse de documenter les formats de fichier afin d’en permettre la conservation sur le moyen et long terme dans un environnement où de plus en plus de contenu informationnel est accessible sous forme numérique, une des raisons essentielles qui a poussé Microsoft à l’adoption de XML comme base de son format de documents est précisément de permettre de centrer le format sur les données qui sont, elles, au cœur de tous les processus métier de l’entreprise.
L’unique raison de définir des schémas métier est donc, dans un contexte centré sur les données, de donner du sens à ces données et de faire en sorte que lorsque l’on échange, par exemple, des données entre deux banques, le sens des informations liées à la description d’un compte client soit la même ; de même entre deux administrations, le fait que les coordonnées d’un assuré social ou d’un contribuable aient le même sens au sein des systèmes d’information de différents ministères. Car l’objectif ici est d’aller au-delà de l’interopérabilité technique et de permettre l’interopérabilité sémantique sans laquelle aucune interopérabilité réelle n’est possible. Autrement dit, les schémas métiers ne permettent pas – contrairement à ce qui a pu être dit ici ou là – de définir des formats propriétaires mais tout au contraire de faciliter l’échange des données contenues dans les formats de fichier en leur donnant du sens. Tout leur sens.
Ici, l’approche unique d’Open XML est de permettre ce que l’on pourrait appeler « l’interopérabilité verticale », c'est-à-dire la possibilité d’intégrer d’autres types de systèmes et de données avec des documents Open XML tout en maintenant une séparation nette et simple entre la présentation (Open XML markup) et les données (les schémas métiers, que l’on appelle aussi schémas customisés, et les instances afférentes).
Mais revenons un cours instant sur l’interopérabilité. L’interopérabilité est l’un de ces mots polysémiques qui peuvent vouloir dire des choses différentes pour chacun d’entre-nous. Nous sommes tous d’accord sur le fait que l’interopérabilité signifie quelque chose comme « la possibilité pour des systèmes de travailler efficacement ensemble » mais, comme souvent, dès que l’on rentre dans les détails, les choses se compliquent. Considérons, par exemple, la répartition suivante de produits et de services métier sous la forme d’une classification en domaines « horizontaux » et « verticaux » ainsi qu’indiqué sur le graphique suivant :
Le concept fondamental sous-jacent à un domaine vertical consiste tout simplement dans le fait qu’il représente l’ensemble des activités métiers au sein d’une industrie donnée (la finance ou la construction manufacturière par exemple) sans se préoccuper en aucune façon des types de systèmes ou de logiciels qui y sont utilisés, alors qu’un domaine horizontal pour l’informatique (le marché du traitement de texte, par exemple) correspond à un ensemble de fonctionnalités utilisé par plusieurs industries. Bien entendu, le graphique ci-dessus est très simplificateur et ne saurait prétendre à l’exhaustivité.
Ceci dit, quand on utilise le mot interopérabilité, que peut bien représenter ce mot dans un tel contexte ? Parle-t-on d’interopérabilité horizontale – par exemple d’interopérabilité entre différents tableurs – ou d’interopérabilité verticale, telle que l’interopérabilité entre tous les systèmes utilisés au sein d’une banque, voire même de l’ensemble des systèmes utilisés au sein de la communauté bancaire ?
Bien entendu la réponse à une telle question dépend de sa perspective personnelle, en particulier du milieu professionnel qui est le sien. Pour ceux qui travaillent dans le métier du logiciel, il est tentant de voir le monde en termes de type d’applications : traitement de texte, tableur, messagerie, etc. Et l’on tend alors à un certain strabisme qui conduit à penser l’interopérabilité en des termes horizontaux : deux programmes de traitement de texte peuvent-ils partager des documents ? Deux bases de données peuvent-elles partager des données ?
De même, si l’on travaille dans une entreprise où la technologie informatique ne représente qu’un outil et non l’essentiel de son métier (on est donc dans un domaine vertical), sa vue de l’interopérabilité présente probablement un autre type de strabisme. Par exemple, si l’on travaille dans une entreprise manufacturière, on perçoit probablement l’interopérabilité en termes de capacité pour des systèmes différents – ERP, comptabilité, distribution, logistique – à communiquer efficacement entre eux.
De même, il peut y avoir des besoins d’interopérabilité horizontale au sein d’un domaine vertical. Par exemple, si l’on a mis à jour une version d’un traitement de texte donné, on veut être certain que l’on pourra ouvrir sans surprise les anciens documents avec le nouveau logiciel. Par contre, il est rare que l’on utilise deux programmes de traitement de texte sur le même poste de travail car, dans la majorité des entreprises, quel que soit leur métier, on essaye de standardiser les applications horizontales à chaque fois que c’est possible afin de réduire les coûts de support et de maintenance.
Prochain épisode : Formats de documents et interopérabilité
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
