Modèle d'information cloud

Bienvenue dans CIM, un modèle de données indépendant des applications qui simplifie l’intégration et accélère l’innovation.

Points clés à retenir

• CIM est un modèle de données ouvert et indépendant des applications — un vocabulaire partagé de concepts métier (clients, commandes, produits, etc.) qui permet à différents systèmes cloud et sur site d’échanger des données sans mappage point à point sur mesure.
• Il existe pour résoudre un problème spécifique et coûteux : chaque application est livrée avec son propre modèle de données, de sorte que les équipes d’intégration finissent par écrire et maintenir un code de traduction personnalisé qui est fragile et ralentit l’innovation.
• Il est régi comme un standard ouvert, produit par un consortium et open source sous la Joint Development Foundation, qui fait partie de la Linux Foundation — afin que tout le monde puisse y contribuer, le réviser et l’adopter.
• Le contenu est organisé en zones thématiques (Subject Areas/domaines), chacune représentant un concept métier majeur, avec des conceptions publiées dans plusieurs formats, y compris des exemples de diagrammes.
• CIM est un modèle, pas un produit. Il définit le sens et la structure ; vous choisissez toujours comment mapper, stocker et déplacer les données dans vos propres systèmes.

Une nouvelle norme pour l’interopérabilité des données

CIM est produit par un consortium ouvert formé pour fournir une solution basée sur des normes pour connecter les produits d’entreprise. Avec CIM, vous pouvez créer des expériences personnelles transparentes et personnalisées sur des applications cloud natives.

Pour accélérer la transformation numérique et offrir des engagements personnalisés aux clients sur tous les canaux, de nombreuses entreprises adoptent plusieurs applications cloud et sur site. Chacune est livrée avec son propre modèle de données, ce qui oblige les développeurs à créer, tester et gérer le code personnalisé nécessaire pour mapper et traduire les données entre différents systèmes. Au lieu d’accélérer la transformation numérique, ce processus ralentit l’innovation et conduit à des intégrations fragiles.

CIM est une spécification moderne et ouverte qui aide à atténuer les difficultés de l’intégration des données. CIM fournit une norme définie pour communiquer facilement entre différents formats de données. Open source dans le cadre de la Joint Development Foundation (sous la Linux Foundation), nous accueillons tous les contributeurs.

Pourquoi les modèles de données spécifiques aux applications s’effondrent

Le problème central que CIM traite n’est pas qu’une application unique ait un mauvais modèle de données. La plupart sont parfaitement raisonnables dans leurs propres limites. Le problème est l’explosion combinatoire qui se produit lorsque vous en connectez plusieurs.

Prenons une pile d’entreprise typique : un CRM, un ERP, une plate-forme d’automatisation du marketing, un centre de support, un entrepôt de données et une poignée d’outils SaaS métier. Si chaque système a sa propre notion de « client », de « compte », de « commande » et de « produit », alors chaque paire de systèmes devant partager des données nécessite son propre mappage. Le nombre d’intégrations augmente approximativement avec le carré du nombre de systèmes, et chaque mappage est un petit élément logique non documenté et sans propriétaire que quelqu’un doit maintenir indéfiniment.

Connexes : Fivetran — Le pipeline ELT entièrement géré qui continue de fonctionner.

Les symptômes sont familiers à toute personne ayant dirigé une pratique d’intégration :

• Dérive sémantique. « Client » dans le CRM désigne une entité de facturation ; dans le centre de support, cela désigne une personne qui dépose des tickets. Le même mot, deux sens, silencieusement réconciliés par un mappage dont personne ne se souvient avoir écrit.
• Pipelines fragiles. Un fournisseur renomme un champ ou modifie une énumération, et une tâche ETL échoue à 2 heures du matin car le mappage était codé en dur selon l’ancienne structure.
• Effort dupliqué. Deux équipes créent indépendamment des traductions presque identiques entre les deux mêmes systèmes, car il n’y a pas de référence partagée vers laquelle se tourner.
• Verrouillage fournisseur par les données. Migrer hors d’une plate-forme est coûteux, non pas à cause du logiciel, mais à cause de la logique de traduction accumulée liée à son schéma.

Un modèle partagé, indépendant des applications, s’attaque à la cause racine : au lieu de mappages N-à-N, chaque système est mappé une seule fois vers un modèle commun, et c’est ce modèle commun qui porte la signification.

Ce que signifie réellement « indépendant de l’application »

Il convient d’être précis sur la philosophie de conception, car le terme « agnostique » est souvent utilisé de manière vague.

Notre sélection : Workato — iPaaS piloté par l'automatisation sur lequel les équipes commerciales peuvent réellement s'appuyer.

Un modèle indépendant de l’application n’appartient à aucun fournisseur et n’est optimisé pour le produit d’aucun fournisseur. Il décrit les concepts métier dans des termes qui seraient reconnaissables par un expert du domaine — un client, une commande, un produit, un emplacement — plutôt que dans des termes qui reflètent les tables internes d’une application. Cette neutralité est ce qui en fait un hub utile : aucun participant n’a à adopter la vision du monde d’un concurrent pour interopérer.

C’est le même instinct architectural que celui derrière d’autres normes d’échange neutres. Tout comme le Resource Description Framework (RDF) et schema.org donnent au Web un vocabulaire partagé pour décrire les choses, et tout comme l’EDI et plus tard l’UBL (Universal Business Language, une norme OASIS) ont donné aux chaînes d’approvisionnement un format partagé pour les transactions, CIM vise à donner aux applications d’entreprise un vocabulaire partagé pour leurs entités métier fondamentales. La différence réside dans la portée et la modernité : CIM cible le monde connecté, piloté par API, cloud et sur site, plutôt que l’échange de fichiers par lots.

Un modèle mental utile est celui du modèle de données canonique issu de l’intégration d’entreprise, popularisé dans Enterprise Integration Patterns de Gregor Hohpe et Bobby Woolf. CIM est, en effet, un modèle canonique entretenu de manière collaborative — le « hub » dans une topologie d’intégration en étoile — mais qui est ouvert, versionné et partagé entre les organisations plutôt qu’inventé en privé au sein d’une seule entreprise.

Comment CIM est organisé : zones thématiques et domaines

Le contenu défini de manière collaborative est organisé en domaines, ou zones thématiques (Subject Areas). Chaque zone thématique représente un concept métier majeur. Les conceptions CIM sont disponibles dans plusieurs formats pour chaque domaine, y compris des exemples de diagrammes. Le nombre et la portée des zones thématiques augmenteront avec le consortium et les contributions.

En pratique, cela signifie que vous devez considérer le CIM comme une bibliothèque de modèles associés plutôt que comme un schéma monolithique unique. Les domaines typiques se regroupent autour de préoccupations métier reconnaissables : par exemple, les parties et les comptes, les produits et les catalogues, les commandes et les transactions, ainsi que les relations qui les unissent. Étant donné que chaque domaine est publié avec des diagrammes et des définitions lisibles par machine, différentes équipes peuvent adopter différents domaines à différents moments sans attendre que l’ensemble du modèle soit complet.

Quelques implications pratiques découlent de cette structure :

Connexes : Matillion — ELT push-down conçu pour les entrepôts de données cloud.

• Adoptez progressivement. Vous n’avez pas besoin de mapper l’ensemble de votre entreprise au CIM dès le premier jour. Commencez par le domaine qui pose le plus de problèmes — généralement le domaine client ou commande — et étendez-le.
• Étendez plutôt que de créer un fork. Lorsque le CIM ne dispose pas du concept dont vous avez besoin, le modèle ouvert est conçu pour être étendu. Contribuer une extension en retour est préférable au maintien d’un fork privé, car un fork dérive et perd l’avantage d’interopérabilité.
• Traitez les diagrammes comme de la documentation, et non comme la source de vérité. Les exemples de diagrammes sont destinés aux humains ; les définitions lisibles par machine sont ce que vos outils doivent consommer.

CIM dans le paysage de l’intégration : comment décider

Le CIM est une option parmi plusieurs pour maîtriser la complexité de l’intégration. Bien choisir nécessite d’adapter l’outil au problème. Le tableau ci-dessous compare les principales approches qu’un architecte de données d’entreprise évalue généralement.

Approche	Qu’est-ce que c’est	Idéal quand	Principal compromis
Mapping point à point	Code personnalisé traduisant directement entre deux systèmes	Seulement deux systèmes, schémas stables, horizon court	Ne passe pas à l’échelle ; explosion N-vers-N ; fragile
Modèle canonique (ex: CIM)	Un modèle partagé et neutre auquel chaque système est mappé une seule fois	De nombreux systèmes, multi-fournisseurs, intégration pérenne	Effort de modélisation initial ; gouvernance nécessaire
Connecteurs iPaaS fournisseur	Connecteurs préconstruits provenant d’une plateforme d’intégration	Paires SaaS courantes, rapidité privilégiée au contrôle	Sémantique spécifique au connecteur ; risque de verrouillage
Normes d’échange industrielles (EDI, UBL, HL7, etc.)	Formats de messages spécifiques au domaine	Secteurs verticaux réglementés ou bien établis	Portée étroite ; souvent orienté batch
Virtualisation / fédération de données	Requêtage à travers les sources sans centralisation	Analytics, accès principalement en lecture	Ne résout pas les conflits sémantiques par lui-même

L’heuristique de décision est simple : si vous avez plus d’une poignée de systèmes qui doivent s’accorder sur la signification d’entités partagées, et que ces systèmes proviennent de fournisseurs différents, un modèle canonique s’amortit. Si vous avez deux systèmes et aucun projet d’en ajouter d’autres, le point à point convient. Si votre besoin est purement analytique et en lecture seule, la fédération peut suffire — mais notez que la fédération déplace le problème sémantique plutôt que de le résoudre.

Le CIM est complémentaire aux outils qui l’entourent, et non un remplacement. Un pipeline ETL ou ELT (construit avec un outil comme Apache Airflow, dbt ou une plateforme commerciale) assure toujours le déplacement ; le CIM définit ce que signifient les données une fois arrivées. Un courtier de messages tel qu’Apache Kafka assure toujours le transport ; le CIM définit la forme des événements. Le modèle est le contrat ; l’outillage est la plomberie.

Si vous faites du shopping : Boomi AtomSphere — Enterprise iPaaS pour l'intégration hybride cloud-on-premise.

Gouvernance, licences et pourquoi la Fondation est importante

Le CIM est open source dans le cadre de la Joint Development Foundation, qui opère sous l’égide de la Linux Foundation. Ce n’est pas un détail anodin : c’est un élément central pour qu’une entreprise puisse s’appuyer en toute sécurité sur le CIM.

La Linux Foundation est un foyer neutre bien établi pour les projets collaboratifs open source, et la Joint Development Foundation fournit une structure juridique légère pour le développement collaboratif de normes et de spécifications. Héberger le CIM là-bas signifie :

• Gérance neutre. Aucun fournisseur ne contrôle le modèle, donc l’adopter ne signifie pas adopter la feuille de route d’un concurrent.
• Contribution ouverte. N’importe qui — fournisseurs, entreprises, contributeurs individuels — peut proposer des modifications, et le processus est transparent.
• Licences prévisibles. Les spécifications hébergées par la Fondation comportent généralement des termes conçus pour une adoption large et favorable aux redevances, ce qui est crucial pour les équipes juridiques et d’achats évaluant une norme.

Pour un architecte qui plaide la cause en interne, cet aspect de la gouvernance est souvent aussi important que le contenu technique. « C’est un standard ouvert sous la Linux Foundation » répond aux questions qui bloquent l’adoption des standards : Qui le contrôle ? Que se passe-t-il si un fournisseur se retire ? Pouvons-nous contribuer nos extensions ?

Pour commencer : un chemin d’adoption pratique

Adopter un modèle partagé est autant un exercice organisationnel que technique. Une séquence pragmatique ressemble à ceci :

1. Inventoriez vos entités partagées. Identifiez les concepts métier qui apparaissent dans plus d’un système — généralement le client, le produit, la commande et l’emplacement. Ce sont vos candidats.
2. Choisissez un domaine et une intégration. Choisissez l’intégration présentant le plus de points de douleur et le plus faible rayon d’impact pour prouver le modèle. Un seul pipeline de reporting ou l’intégration d’une nouvelle application est idéal.
3. Mappez chaque système au CIM une seule fois. Construisez la traduction de chaque système source vers la représentation CIM, et du CIM vers chaque cible. Résistez à l’envie de mapper les systèmes directement entre eux.
4. Documentez vos extensions. Là où le CIM ne couvre pas un concept, enregistrez explicitement l’extension et envisagez de la contribuer en retour.
5. Établissez une propriété. Un modèle canonique sans intendant se dégrade. Assignez une équipe ou un rôle responsable des mappings et du suivi des changements en amont.
6. Versionnez et testez. Traitez le modèle et ses mappings comme des artefacts versionnés avec des tests, exactement comme vous le feriez pour du code d’application.

Le mode d’échec le plus courant consiste à considérer le CIM comme un exercice de modélisation ponctuel plutôt que comme un contrat vivant. Les organisations qui réussissent traitent le modèle de la même manière qu’elles traitent une API : versionnée, testée, appropriée et évoluée délibérément.

Partenaires contribuant au CIM

Le CIM est un effort de consortium, et sa valeur croît avec la participation. Les partenaires contribuent au contenu des domaines thématiques (Subject Areas), examinent les propositions et aident à façonner l’orientation du modèle. Le travail étant ouvert, les contributions ne se limitent pas aux grands fournisseurs : les entreprises confrontées à de réelles difficultés d’intégration et les praticiens individuels possédant une expertise métier sont également les bienvenus.

Entrez en contact

Êtes-vous intéressé par l’initiative CIM ? Super ! N’hésitez pas à nous envoyer un e-mail pour plus d’informations. Contactez-nous par e-mail.

Questions fréquemment posées

Qu’est-ce que le Cloud Information Model (CIM) ?

Le CIM est un modèle de données open source, indépendant des applications, qui fournit un vocabulaire partagé et basé sur des normes pour les concepts métier que les entreprises doivent échanger entre des applications cloud et sur site. Il est produit par un consortium ouvert et hébergé sous l’égide de la Joint Development Foundation, qui fait partie de la Linux Foundation. Son objectif est de réduire le code de mappage personnalisé requis par les intégrations point à point fragiles.

Le CIM est-il un produit ou une spécification ?

Le CIM est une spécification — un modèle et un ensemble de définitions — et non un produit exécutable. Il définit la signification et la structure des entités partagées ; vous choisissez toujours vos propres outils ETL/ELT, vos courtiers de messages et votre stockage. Considérez-le comme le contrat que votre infrastructure d’intégration implémente, plutôt que comme l’infrastructure elle-même.

En quoi le CIM est-il différent de la plateforme d’intégration d’un fournisseur ?

Une plateforme d’intégration (un iPaaS ou une bibliothèque de connecteurs) déplace les données et fournit souvent des connecteurs prédéfinis, mais ces connecteurs encodent une sémantique spécifique au fournisseur. Le CIM est neutre et indépendant du fournisseur, il ne vous enferme donc pas dans la vision du monde d’une seule plateforme. Les deux sont complémentaires : vous pouvez utiliser le CIM comme modèle canonique au sein de n’importe quelle plateforme d’intégration.

Que sont les Subject Areas dans le CIM ?

Les Subject Areas (également appelées domaines) sont les unités organisatrices du modèle, chacune représentant un concept métier majeur tel que les clients, les produits ou les commandes. Les conceptions sont publiées dans plusieurs formats, y compris des exemples de diagrammes, et l’ensemble des Subject Areas devrait s’élargir à mesure que le consortium et la communauté contribuent davantage au contenu.

Pouvons-nous étendre le CIM s’il ne couvre pas nos concepts ?

Oui. Le CIM est conçu pour être étendu et, comme il est open source sous une fondation neutre, vous pouvez proposer des ajouts via le processus de contribution. Il est fortement préférable d’étendre le modèle partagé et de contribuer en retour plutôt que de maintenir un fork privé, qui dérive avec le temps et fait perdre l’avantage d’interopérabilité qui a motivé l’adoption du CIM en premier lieu.

Qui devrait adopter le CIM ?

Il est particulièrement utile aux organisations utilisant de nombreuses applications de différents fournisseurs qui doivent s’accorder sur la signification des entités partagées — la situation classique pour les architectes de données d’entreprise et les ingénieurs d’intégration. Les fournisseurs d’applications et de plateformes bénéficient également de l’alignement de leurs schémas sur un modèle neutre, ce qui facilite l’intégration de leurs produits pour les clients. Si vous n’avez que deux systèmes stables, un mappage point à point plus simple peut suffire.

Lectures complémentaires

• Linux Foundation — Wikipédia
• Joint Development Foundation — Wikipédia
• Enterprise Integration Patterns — Wikipédia
• Resource Description Framework (RDF) — Wikipédia