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 partagé et ouvert, pas un produit. Il définit des concepts métier communs et leurs relations afin que différentes applications puissent échanger des données sans mappages ponctuels et sur mesure.
• Il est régi comme un standard ouvert. CIM est open source sous la Joint Development Foundation, qui fait partie de la Linux Foundation, et accueille les contributeurs des fournisseurs, des entreprises et de la communauté au sens large.
• Le contenu est organisé en domaines thématiques (Subject Areas). Chaque domaine représente un concept métier majeur et est publié dans plusieurs formats, y compris des diagrammes, afin que les architectes et les ingénieurs puissent l’adopter progressivement.
• La valeur fondamentale est de réduire la fragilité de l’intégration. Un modèle canonique remplace le code de traduction point à point par une cible stable vers laquelle et depuis laquelle de nombreux systèmes peuvent être mappés.
• L’adoption est une décision de conception, pas un interrupteur. Vous choisissez les domaines à adopter, comment mapper vos systèmes sources et comment gérer les extensions au fil du temps.

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 facilite 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.

Le problème résolu par CIM est structurel et non accidentel. Lorsque chaque système parle son propre dialecte — l’un appelle un client un « Contact », un autre une « Partie », un troisième un « Compte » — les équipes d’intégration finissent par maintenir un réseau croissant de mappages par paires.

Chaque nouvelle application multiplie le nombre de traductions requises, et chaque changement de schéma dans un seul système peut se répercuter et rompre les pipelines en aval. Un modèle canonique change la nature de ce problème : au lieu que N systèmes soient mappés les uns aux autres, chaque système est mappé une seule fois vers un vocabulaire partagé.

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

Pourquoi l’intégration point à point échoue

Il est utile d’être concret sur les modes de défaillance qui motivent l’utilisation d’un modèle partagé.

• Croissance combinatoire. Avec les mappages point à point, le nombre de chemins de traduction augmente approximativement avec le carré du nombre de systèmes. L’ajout d’une dixième application coûte bien plus cher que l’ajout d’une seconde.
• Dérive sémantique. Deux équipes peuvent toutes deux « mapper le client » et être pourtant en désaccord sur la question de savoir si un client est une personne, une organisation ou une relation de facturation. Les données circulent, mais le sens diverge.
• Gestion fragile des changements. Un renommage de champ ou un nouvel attribut obligatoire dans un système source force des modifications chez chaque consommateur qui l’utilise.
• Logique dupliquée. Les règles de validation, de déduplication et de résolution d’identité sont réimplémentées dans chaque intégration plutôt que d’être définies une seule fois.
• Pression du verrouillage fournisseur. Lorsque la logique d’intégration est entrelacée avec le schéma d’un fournisseur spécifique, changer ou ajouter des fournisseurs devient un projet de refonte de plateforme.

Un modèle canonique tel que CIM n’élimine pas le travail de mappage — chaque système source a toujours besoin d’un mappage vers le modèle. Ce qu’il élimine, c’est la multiplication de ce travail. Vous créez un seul mappage par système vers le modèle partagé, et le modèle lui-même fournit le contrat stable entre eux.

Comment CIM est organisé : domaines thématiques

Le contenu défini de manière collaborative est organisé en domaines, ou Subject Areas. Chaque domaine 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 domaines thématiques augmenteront avec le consortium et les contributions.

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

Cette structure orientée domaine est importante pour l’adoption. Vous avez rarement besoin du modèle entier d’un coup. Une entreprise typique commence par les domaines qui touchent à son intégration la plus problématique, prouve l’approche, puis s’étend. Les points de départ courants sont généralement les concepts qui apparaissent dans presque tous les systèmes :

• Partie / Client — les personnes et les organisations avec lesquelles vous faites affaire, et les rôles qu’elles jouent.
• Produit — ce que vous vendez, proposez ou gérez, y compris les catalogues et les classifications.
• Compte et relation — comment les parties se rapportent aux produits, aux contrats et entre elles.
• Interaction et activité — les événements, transactions et engagements qui relient les éléments précédents.

Étant donné que chaque domaine thématique est publié avec des diagrammes et plusieurs formats de représentation, les architectes peuvent examiner le modèle conceptuel, les ingénieurs peuvent utiliser une forme lisible par machine et les parties prenantes métier peuvent valider que les concepts correspondent à la réalité. Cette approche multiformat est un choix de conception délibéré : un modèle que seuls les ingénieurs peuvent lire a tendance à s’écarter du sens métier.

Comment CIM se compare aux autres approches

CIM est une option parmi d’autres pour parvenir à l’interopérabilité. Bien choisir signifie comprendre les compromis.

Approche	Qu’est-ce que c’est	Points forts	Compromis
Cartographie point à point	Traductions directes entre chaque paire de systèmes	Simple pour deux systèmes ; aucune gouvernance partagée n’est nécessaire	Croissance combinatoire ; fragile ; logique dupliquée
Modèle canonique (style CIM)	Un vocabulaire partagé et indépendant des applications auquel chaque système est mappé	Effort de cartographie linéaire ; contrat stable ; réutilisable dans tous les projets	Nécessite une gouvernance et un accord ; cartographie encore nécessaire par système
Normes de données de l’industrie	Normes verticales pour un secteur spécifique (par exemple, santé, finance)	Couverture approfondie du domaine ; alignement réglementaire	Portée étroite ; peut ne pas couvrir les concepts d’entreprise intersectoriels
Modèles de données des fournisseurs	Le schéma natif d’une plateforme exposé en tant que hub d’intégration	Intégration étroite des outils ; rapide au sein de l’écosystème d’un seul fournisseur	Risque de verrouillage ; les autres fournisseurs doivent se conformer au modèle d’une seule partie
API-first / schéma à la lecture	Contrats définis par API ; sens résolu au moment de la consommation	Flexible ; rapide à démarrer	La cohérence sémantique dépend de la discipline ; plus difficile à gouverner à grande échelle

Les conseils pratiques : utilisez un modèle canonique lorsque vous disposez de nombreux systèmes, de concepts inter-domaines et d’un paysage d’intégration pérenne. Utilisez le point à point lorsque la portée se limite réellement à deux systèmes et est de courte durée. Les normes industrielles et le CIM sont complémentaires — une norme verticale peut éclairer un domaine, tandis que le CIM fournit le vocabulaire transversal de l’entreprise.

Comment adopter le CIM en pratique

L’adoption est une séquence de décisions délibérées plutôt qu’une seule migration. Un modèle viable ressemble à ceci :

1. Choisissez une intégration à forte douleur et bien délimitée. Choisissez un domaine où la difficulté de cartographie est réelle et où la portée est suffisamment petite pour prouver rapidement la valeur.
2. Inventoriez les systèmes sources et leurs schémas. Documentez comment chaque système nomme les concepts de votre domaine choisi (Subject Area), et là où ils divergent.
3. Mappez chaque système au domaine CIM. Créez un mappage par système vers le modèle partagé. Traitez ces mappages comme des artefacts versionnés, et non comme des scripts jetables.
4. Définissez dès le départ votre politique d’extension. Décidez comment vous gérerez les concepts que le CIM ne couvre pas encore — les extensions doivent être documentées, nommées de manière cohérente et proposées au consortium lorsqu’elles sont largement utiles.
5. Établissez une gouvernance. Attribuez la propriété des mappages, un processus de révision des modifications et une cadence de synchronisation avec les mises à jour CIM en amont.
6. Développez domaine par domaine. Réutilisez les modèles de mappage et la gouvernance du premier domaine pour réduire le coût du suivant.

Deux mises en garde méritent d’être formulées clairement. Premièrement, un modèle canonique ajoute une couche — ce n’est pas gratuit, et le gain provient de la réutilisation à travers de nombreuses intégrations, et non d’une seule. Deuxièmement, la cartographie est là où se situe le véritable travail ; le modèle vous donne une cible stable, mais quelqu’un doit toujours décider comment chaque champ source lui correspond, et cette décision bénéficie d’un apport métier, et pas seulement technique.

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

Gouvernance, licences et contribution

Le CIM est open source dans le cadre de la Joint Development Foundation, qui opère sous la Linux Foundation. Cette structure est importante pour les entreprises qui l’évaluent : la Linux Foundation est un foyer bien établi pour les projets open source collaboratifs et neutres vis-à-vis des fournisseurs, et la Joint Development Foundation fournit un cadre juridique spécifiquement conçu pour développer et exploiter des projets de normes et de spécifications.

Pour un architecte de données d’entreprise, les implications pratiques de ce modèle de gouvernance sont les suivantes :

• Neutralité du fournisseur. Aucun fournisseur ne contrôle seul la spécification, ce qui réduit le risque que le modèle soit façonné pour favoriser une plateforme.
• Contribution ouverte. N’importe qui peut proposer des changements, ce qui signifie que le modèle peut évoluer pour refléter les besoins d’intégration du monde réel plutôt qu’une feuille de route unique.
• Processus axé sur les spécifications. Le modèle de la Joint Development Foundation est construit autour de la production et de la maintenance de spécifications, ce qui s’aligne sur la manière dont les normes sont adoptées et référencées dans les revues d’approvisionnement et d’architecture.

La contribution est encouragée et ouverte à tous. Les contributions prennent généralement la forme de domaines (Subject Areas) nouveaux ou affinés, de corrections et de clarifications, de diagrammes d’exemple et de retours d’expérience de projets d’intégration réels. Les contributions les plus précieuses proviennent souvent de praticiens ayant rencontré un problème de cartographie spécifique et pouvant décrire le concept qui le résout.

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

S’impliquer

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

Au-delà de l’e-mail, les moyens naturels de s’engager sont d’examiner les domaines publiés pour votre domaine d’intérêt, d’essayer de mapper l’un de vos systèmes à un domaine et de rapporter les lacunes que vous trouvez à la communauté. Parce que le nombre et la portée des domaines croissent avec le consortium et les contributions, le modèle s’améliore proportionnellement au nombre de problèmes d’intégration réels que ses utilisateurs lui soumettent.

Questions fréquemment posées

Qu’est-ce que le Cloud Information Model exactement ?

Le CIM est un modèle de données ouvert et indépendant des applications qui définit des concepts métier communs et leurs relations afin que différentes applications puissent échanger des données via un vocabulaire partagé. Il est produit par un consortium ouvert et publié sous forme de spécification ouverte. Plutôt que d’être un produit que vous installez, c’est un modèle vers lequel vous mappez vos systèmes.

À qui s’adresse le CIM ?

Il s’adresse aux architectes de données d’entreprise, aux ingénieurs d’intégration et ETL, aux fournisseurs d’applications et de plateformes, ainsi qu’aux contributeurs open source. Toute personne devant connecter plusieurs systèmes cloud et sur site avec des schémas différents est un utilisateur potentiel. Les fournisseurs en bénéficient car un modèle partagé réduit le travail personnalisé requis pour l’intégration avec leurs produits.

Comment le CIM est-il régi et sous quelle licence ?

CIM est open source dans le cadre de la Joint Development Foundation, qui opère sous l’égide de la Linux Foundation. Cela fournit un cadre de gouvernance neutre vis-à-vis des fournisseurs et orienté vers les spécifications. Cette structure vise à maintenir le modèle ouvert aux contributions et indépendant du contrôle d’un fournisseur unique.

En quoi le CIM diffère-t-il du modèle de données natif d’un fournisseur ?

Le modèle natif d’un fournisseur est optimisé pour le produit et l’écosystème de ce fournisseur ; l’adopter comme hub d’intégration a tendance à créer un verrouillage propriétaire. CIM est conçu pour être indépendant des applications, de sorte qu’aucune plate-forme ne définit le vocabulaire à elle seule. Le compromis est que CIM nécessite une gouvernance et un accord entre les équipes, alors qu’un modèle de fournisseur est prêt à l’emploi avec les outils de ce fournisseur.

Dois-je toujours écrire des mappages si j’utilise CIM ?

Oui. Chaque système source a toujours besoin d’un mappage vers le modèle partagé. L’avantage est que vous écrivez un seul mappage par système vers CIM plutôt qu’une traduction distincte pour chaque paire de systèmes. Cela transforme l’effort de mappage combinatoire en un effort approximativement linéaire et vous donne un contrat stable qui survit aux changements dans les systèmes individuels.

Comment commencer à adopter le CIM ?

Commencez par une seule intégration critique (« high-pain ») et bien délimitée dans une seule zone thématique (Subject Area). Inventoriez les schémas sources, mappez chaque système au domaine CIM, définissez une politique d’extension et de gouvernance, et traitez les mappages comme des artefacts versionnés. Une fois que le premier domaine a prouvé sa valeur, étendez-le domaine par domaine, en réutilisant les modèles et la gouvernance que vous avez établis.

Lectures complémentaires

• Linux Foundation — Wikipédia
• Linux Foundation — Wikipédia