Les 10 pièges de la SOA : 04 – Mauvaise utilisation des Modèles de Données Canoniques (pivots)

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le septième de ces pièges porte sur la mauvaise utilisation des Modèles de Données Canoniques (CDM : Canonical Data Model) ou format pivot.

La mise en place d’un Modèle de Données Canonique (Pivot) est une pièce maîtresse de la mise en œuvre d’Architectures Orientées Service. Elle est souvent perçue comme l’une des solutions miracles qui vont résoudre les problèmes de communication, faciliter l’intégration et de fait réduire les coûts d’intégration des systèmes.
Ce sont effectivement les objectifs visés par la mise en place d’un Modèle de Données Canonique, mais les choses ne sont pas (une fois de plus) si simples. La négociation du CDM peut rapidement aboutir à une discussion sans fin :

• Parce qu’on cherche à lui faire couvrir un spectre trop large ;
• Par manque d’alignement avec le métier de l’entreprise ;
• A cause de principes de conception mal cadrés.

Les apports d’un Modèle de Données Canonique

Un Modèle de Données Canonique définit les entités métiers pertinentes pour un domaine d’intégration spécifique, leurs relations et de leur sémantique. Un CDM correctement défini et utilisé a une grande valeur ajoutée :

• Tout d’abord, un Modèle de Données Canonique facilite une compréhension commune de ce qu’est réellement une entité métier. Par exemple, l’entité métier « Client » est-elle une personne ou une entreprise ou est-elle un rôle qui peut être endossé par une entité métier « Personne » ou « Entreprise » ? De la même façon, un Modèle de Données Canonique facilite une compréhension commune des relations entre les entités métier.
• Cette compréhension commune facilite la communication entre services d’une même entreprise et plus largement entre entreprises, comme l’illustre le modèle SID (Shared Information/Data) du TM Forum.
• Enfin, les coûts d’intégration peuvent être considérablement réduits si les systèmes à intégrer parlent la même langue et manipulent les mêmes concepts.

Les pièges d’un Modèle de Données Canonique

• Les créateurs du Modèle de Données Canonique ont souvent tendance à vouloir mettre Paris en bouteille : ils cherchent à inclure dans un CDM l’intégralité des éléments d’information utilisés au sein de l’entreprise. Ce travers démultiplie la quantité d’entités à modéliser et transforme la conception du Modèle de données Canonique en éternelle tapisserie de Pénélope.
  Un Modèle de Données Canonique est destiné à être utilisé dans un domaine d’intégration spécifique et ne devrait donc décrire que les entités pertinentes dans ce domaine.
• Un autre écueil renvoie au syndrome NIH, il s’agit de Modèles de Données Canoniques mis en place à partir de zéro. Dans ce cas, leurs concepteurs ignorent totalement les modèles existants qu’ils pourraient réutiliser alors qu’il existe divers modèles potentiellement réutilisables (SID, UDEF, …). Certains visent un secteur d’activité spécifique, mais même dans ce cas, les définitions des clients, des contrats, etc. peuvent souvent être réutilisées.
• La conception d’un Modèle de Données Canonique à plat (sans structuration) est un autre écueil. Cette approche rend le modèle difficile à utiliser et à comprendre, même lorsque vous avez seulement besoin d’interagir avec une petite partie de celui-ci. Cela ralentit de fait son adoption (cette adoption est aussi ralentie par des incohérences dans les conventions de dénomination ou les modes de modélisation utilisés).
• Un des plus grands pièges est de ne pas consulter les experts métier du domaine lors de la définition des entités du Modèle de Données Canonique et de leurs relations. Un CDM, comme tout artefact informatique, est fait pour supporter le métier de l’entreprise. Par conséquent, il est essentiel de faire en sorte que le modèle reflète le métier de l’entreprise et non pas une pure vue de l’IT.

Quelques pistes pour se prémunir de ces écueils

La définition d’un Modèle de Données Canonique est un exercice difficile, mais suivre ces quelques lignes directrices devraient aider à relever le défi :

• La mise en place de Modèles de Données Canoniques doit se faire dans le cadre de projets concrets et inclure les entités qui sont nécessaires pour ces projets. Bien sûr, il faut penser un peu plus loin, mais cela n’implique pas que le modèle doive inclure toutes les entités imaginables. Lorsque l’on anticipe l’avenir du modèle, il faut envisager où le modèle doit être extensible et se concentrer sur les entités qui sont actuellement nécessaires.
• Un Modèle de Données Canonique est destiné à être utilisé pour l’intégration et, par conséquent, ne doit porter que sur les entités qui sont utilisées sur la couche intégration. Les entités qui ne sont pas échangées entre les systèmes ne doivent pas faire partie du CDM.
• Un Modèle de Données Canonique doit être divisé en plusieurs domaines de telle façon que les entités d’un même domaine présentent une forte cohésion entre elles et qu’il soit simple d’assurer un couplage lâche entre ces domaines. Cela facilite la compréhension et l’adoption du modèle parce que les lecteurs peuvent facilement se concentrer sur les éléments qui sont pertinents pour eux.
• Avant de ce lancer, il est profitable de faire un tour des modèles disponibles qui peuvent servir de base. La plupart des modèles disponibles sont spécifiques à des secteurs d’activités, mais ils définissent des concepts génériques tels que les clients, les produits, les marchés, les prix, etc. qui peuvent parfaitement être utilisés en dehors.
• La conception des entités d’un Modèle de Données Canonique doit se faire en collaboration avec les experts métiers. Ils sont ceux qui connaissent le mieux le métier de l’entreprise et sont donc les plus à même de vous assurer que le modèle reflète ce métier.
• Il est souhaitable de définir un ensemble (limité) de principes de conception à utiliser. Cela permet d’aboutir à un modèle plus cohérent et donc plus facile à comprendre (la définition de conventions de nommage claires pour les entités, les attributs et les relations contribue également à la cohérence du modèle).
• Lors de la communication autour du modèle, il est important de s’assurer que les personnes adressées puissent le lire et le comprendre facilement (d’une manière générale, il est préférable d’éviter les XSD en pièce attachée en dehors des cellules de développement).

Traduction libre du billet « Top 10 SOA Pitfalls: #4 – Incorrectly applied Canonical Data Model » publié par Gero Vermaas.