Cloud Information Model

Welkom bij CIM, een applicatie-agnostisch datamodel dat integratie vereenvoudigt en innovatie versnelt.

Belangrijkste inzichten

• CIM is een open, applicatie-agnostisch datamodel — een gedeeld vocabulaire van bedrijfsconcepten (klanten, bestellingen, producten, enzovoort) waarmee verschillende cloud- en on-premises-systemen gegevens kunnen uitwisselen zonder op maat gemaakte point-to-point mapping.
• Het bestaat om een specifiek, kostbaar probleem op te lossen: elke applicatie levert zijn eigen datamodel, waardoor integratieteams uiteindelijk aangepaste vertaalcode schrijven en onderhouden die fragiel is en innovatie vertraagt.
• Het wordt beheerd als een open standaard, geproduceerd door een consortium en open source onder de Joint Development Foundation, onderdeel van de Linux Foundation — zodat iedereen kan bijdragen, beoordelen en het kan adopteren.
• Inhoud is georganiseerd in Subject Areas (domeinen), die elk een belangrijk bedrijfsconcept vertegenwoordigen, met ontwerpen gepubliceerd in meerdere formaten, inclusief voorbeelddiagrammen.
• CIM is een model, geen product. Het definieert betekenis en structuur; u kiest nog steeds zelf hoe u gegevens in uw eigen systemen mapt, opslaat en verplaatst.

Een nieuwe standaard voor data-interoperabiliteit

CIM wordt geproduceerd door een open consortium dat is opgericht om een op standaarden gebaseerde oplossing te leveren voor het verbinden van enterprise-producten. Met CIM kunt u naadloze en op maat gemaakte persoonlijke ervaringen creëren over cloud-native applicaties heen.

Om de digitale transformatie te versnellen en gepersonaliseerde interacties aan klanten via elk kanaal te bieden, maken veel bedrijven gebruik van meerdere cloud- en on-premises-applicaties. Elk daarvan komt met zijn eigen datamodel, wat ontwikkelaars dwingt om aangepaste code te bouwen, testen en beheren die nodig is om gegevens tussen verschillende systemen te mappen en te vertalen. In plaats van de digitale transformatie te versnellen, vertraagt dit proces de innovatie en leidt het tot fragiele integraties.

CIM is een moderne, open specificatie om de pijn van het integreren van gegevens te verlichten. CIM biedt een gedefinieerde standaard om eenvoudig te communiceren tussen verschillende dataformaten. Open source als onderdeel van de Joint Development Foundation (onder de Linux Foundation), verwelkomen wij alle bijdragers.

Waarom applicatiespecifieke datamodellen tekortschieten

Het kernprobleem dat CIM aanpakt, is niet dat een enkele applicatie een slecht datamodel heeft. De meeste zijn volkomen redelijk binnen hun eigen grenzen. Het probleem is de combinatorische explosie die optreedt wanneer u er veel met elkaar verbindt.

Overweeg een typische enterprise-stack: een CRM, een ERP, een marketingautomatiseringsplatform, een supportdesk, een datawarehouse en een handvol line-of-business SaaS-tools. Als elk systeem zijn eigen notie van ‘klant’, ‘account’, ‘bestelling’ en ‘product’ heeft, dan heeft elk paar systemen dat gegevens moet delen zijn eigen mapping nodig. Het aantal integraties groeit grofweg met het kwadraat van het aantal systemen, en elke mapping is een klein, ongedocumenteerd stukje logica zonder eigenaar dat iemand voor altijd moet onderhouden.

Gerelateerd: Fivetran — De volledig beheerde ELT-pijplijn die gewoon blijft draaien.

De symptomen zijn herkenbaar voor iedereen die een integratiepraktijk heeft geleid:

• Semantische drift. ‘Klant’ in het CRM betekent een facturatie-entiteit; in de supportdesk betekent het een persoon die tickets indient. Hetzelfde woord, twee betekenissen, stilletjes verzoend door een mapping die niemand zich herinnert te hebben geschreven.
• Fragiele pijpleidingen. Een leverancier hernoemt een veld of wijzigt een enum, en een ETL-job faalt om 2 uur ‘s nachts omdat de mapping hardgecodeerd was tegen de oude structuur.
• Dubbele inspanning. Twee teams bouwen onafhankelijk van elkaar vrijwel identieke vertalingen tussen dezelfde twee systemen omdat er geen gedeelde referentie is om naar te verwijzen.
• Vendor lock-in door data. Migreren van een platform is duur, niet vanwege de software, maar vanwege de opgehoopte vertaallogica die aan het schema is gekoppeld.

Een gedeeld, applicatie-agnostisch model pakt de hoofdoorzaak aan: in plaats van N-naar-N-mappings mapt elk systeem één keer naar een gemeenschappelijk model, en het gemeenschappelijke model draagt de betekenis.

Wat “applicatie-agnostisch” eigenlijk betekent

Het is de moeite waard om precies te zijn over de ontwerpfilosofie, omdat ‘agnostisch’ vaak losjes wordt gebruikt.

Als u aan het winkelen bent: Boomi AtomSphere — Enterprise iPaaS voor hybride cloud-naar-on-prem-integratie.

Een applicatie-agnostisch model is niet eigendom van, of geoptimaliseerd voor, het product van één enkele leverancier. Het beschrijft bedrijfsconcepten in termen die herkenbaar zouden zijn voor een domeinexpert — een klant, een bestelling, een product, een locatie — in plaats van in termen die de interne tabellen van één applicatie weerspiegelen. Die neutraliteit is wat het tot een nuttige hub maakt: geen enkele deelnemer hoeft het wereldbeeld van een concurrent over te nemen om te kunnen interopereren.

Dit is hetzelfde architecturale instinct achter andere neutrale uitwisselingsstandaarden. Net zoals het Resource Description Framework (RDF) en schema.org het web een gedeeld vocabulaire geven om dingen te beschrijven, en net zoals EDI en later UBL (Universal Business Language, een OASIS-standaard) toeleveringsketens een gedeeld formaat voor transacties gaven, streeft CIM ernaar enterprise-applicaties een gedeeld vocabulaire te geven voor hun kernbedrijfsentiteiten. Het verschil is de reikwijdte en moderniteit: CIM richt zich op de verbonden, API-gestuurde, cloud-en-on-premises wereld in plaats van op batchbestandsuitwisseling.

Een nuttig mentaal model is het canonical data model-patroon uit enterprise-integratie, gepopulariseerd in Enterprise Integration Patterns van Gregor Hohpe en Bobby Woolf. CIM is in feite een gezamenlijk onderhouden canoniek model — de ‘hub’ in een hub-and-spoke-integratietopologie — maar dan een model dat open is, geversioneerd en gedeeld over organisaties heen, in plaats van privé uitgevonden binnen één bedrijf.

Hoe CIM is georganiseerd: Subject Areas en domeinen

Gezamenlijk gedefinieerde inhoud is georganiseerd in domeinen, of Subject Areas. Elke Subject Area vertegenwoordigt een belangrijk bedrijfsconcept. De CIM-ontwerpen zijn voor elk domein beschikbaar in meerdere formaten, inclusief voorbeelddiagrammen. Het aantal en de reikwijdte van de Subject Areas zullen groeien met het consortium en de bijdragen.

In de praktijk betekent dit dat je CIM moet zien als een bibliotheek van gerelateerde modellen in plaats van als een enkel monolithisch schema. Typische Subject Areas clusteren rond herkenbare zakelijke belangen — bijvoorbeeld partijen en accounts, producten en catalogi, bestellingen en transacties, en de relaties die deze met elkaar verbinden. Omdat elk gebied wordt gepubliceerd met diagrammen en machinaal leesbare definities, kunnen verschillende teams op verschillende tijdstippen verschillende gebieden adopteren zonder te wachten tot het hele model compleet is.

Uit deze structuur volgen enkele praktische implicaties:

Gerelateerd: Matillion — Push-down ELT gebouwd voor clouddatawarehouses.

• Stapsgewijs adopteren. Je hoeft niet vanaf dag één je hele onderneming naar CIM te mappen. Begin met het Subject Area dat de meeste pijn veroorzaakt — meestal het klant- of besteldomein — en breid dit uit.
• Uitbreiden in plaats van forken. Wanneer CIM een concept mist dat je nodig hebt, is het open model ontworpen om te worden uitgebreid. Het terugbijdragen van een extensie verdient de voorkeur boven het onderhouden van een private fork, omdat een fork afwijkt en het interoperabiliteitsvoordeel verliest.
• Behandel diagrammen als documentatie, niet als de bron van waarheid. De voorbeelddiagrammen zijn voor mensen; de machinaal leesbare definities zijn wat je tooling zou moeten consumeren.

CIM in het integratielandschap: hoe te beslissen

CIM is één optie van de vele om integratiecomplexiteit te beheersen. Een goede keuze vereist dat de tool wordt afgestemd op het probleem. De onderstaande tabel contrasteert de belangrijkste benaderingen die een enterprise data-architect doorgaans afweegt.

Benadering	Wat het is	Beste wanneer	Belangrijkste afweging
Point-to-point mapping	Aangepaste code die rechtstreeks tussen twee systemen vertaalt	Slechts twee systemen, stabiele schema’s, korte horizon	Schaalt niet; N-naar-N-explosie; fragiel
Canoniek model (bijv. CIM)	Een gedeeld, neutraal model waar elk systeem één keer naar mapt	Veel systemen, cross-vendor, langdurige integratie	Voorafgaande modelleringsinspanning; governance nodig
Vendor iPaaS-connectoren	Vooraf gebouwde connectoren van een integratieplatform	Veelvoorkomende SaaS-paren, snelheid boven controle	Connector-specifieke semantiek; potentiële lock-in
Industriële uitwisselingsstandaarden (EDI, UBL, HL7, etc.)	Domeinspecifieke berichtformaten	Gereguleerde of goed gevestigde verticalen	Smalle reikwijdte; vaak batch-georiënteerd
Datavirtualisatie / federatie	Query’s over bronnen heen zonder centralisatie	Analytics, voornamelijk leesacties	Lost semantische conflicten niet zelfstandig op

De beslissingsheuristiek is eenvoudig: als je meer dan een handvol systemen hebt die het eens moeten worden over de betekenis van gedeelde entiteiten, en die systemen van verschillende leveranciers komen, dan betaalt een canoniek model zichzelf terug. Als je twee systemen hebt en geen plannen om er meer toe te voegen, is point-to-point prima. Als je behoefte puur analytisch en read-only is, kan federatie volstaan — maar let op dat federatie het semantische probleem verplaatst in plaats van oplost.

CIM is complementair aan, en geen vervanging voor, de tools eromheen. Een ETL- of ELT-pijplijn (gebouwd met iets als Apache Airflow, dbt of een commercieel platform) doet nog steeds het verplaatsen; CIM definieert wat de data betekent zodra deze arriveert. Een message broker zoals Apache Kafka doet nog steeds het transport; CIM definieert de vorm van de events. Het model is het contract; de tooling is het leidingwerk.

Lezersfavoriet: Airbyte — Open-source ELT met een beheerde cloudoptie.

Governance, licentieverlening en waarom de stichting ertoe doet

CIM is open source als onderdeel van de Joint Development Foundation, die opereert onder de Linux Foundation. Dit is geen triviaal detail — het is centraal aan de reden waarom een onderneming veilig op CIM kan bouwen.

De Linux Foundation is een gevestigde, neutrale thuisbasis voor collaboratieve open-sourceprojecten, en de Joint Development Foundation biedt een lichtgewicht juridische structuur voor het gezamenlijk ontwikkelen van standaarden en specificaties. Het hosten van CIM daar betekent:

• Neutraal rentmeesterschap. Geen enkele leverancier controleert het model, dus het adopteren ervan betekent niet dat je de roadmap van een concurrent overneemt.
• Open bijdrage. Iedereen — leveranciers, ondernemingen, individuele bijdragers — kan wijzigingen voorstellen, en het proces is transparant.
• Voorspelbare licentieverlening. Door de Foundation gehoste specificaties bevatten doorgaans voorwaarden die zijn ontworpen voor brede, royalty-vriendelijke adoptie, wat enorm belangrijk is voor juridische en inkoopteams die een standaard evalueren.

Voor een architect die intern de zaak bepleit, is dit governance-verhaal vaak net zo belangrijk als de technische inhoud. “Het is een open standaard onder de Linux Foundation” beantwoordt de vragen die de adoptie van standaarden vaak dwarsbomen: Wie controleert het? Wat gebeurt er als een leverancier stopt? Kunnen we onze extensies bijdragen?

Aan de slag: een praktisch adoptiepad

Het adopteren van een gedeeld model is evenzeer een organisatorische als een technische oefening. Een pragmatische volgorde ziet er als volgt uit:

1. Inventariseer je gedeelde entiteiten. Identificeer de businessconcepten die in meer dan één systeem voorkomen — meestal klant, product, order en locatie. Dit zijn je kandidaten.
2. Kies één Subject Area en één integratie. Kies de integratie met de meeste pijn en de kleinste impactradius om het model te bewijzen. Een enkele rapportagepijplijn of het onboarden van één nieuwe applicatie is ideaal.
3. Map elk systeem één keer naar CIM. Bouw de vertaling van elk bronsysteem naar de CIM-representatie, en van CIM naar elk doel. Weersta de drang om systemen direct naar elkaar te mappen.
4. Documenteer je extensies. Waar CIM een concept niet dekt, leg de extensie expliciet vast en overweeg deze terug te bijdragen.
5. Stel eigenaarschap vast. Een canoniek model zonder rentmeester vervalt. Wijs een team of rol aan die verantwoordelijk is voor de mappings en voor het bijhouden van upstream-wijzigingen.
6. Versioneer en test. Behandel het model en de mappings als geversioneerde artefacten met tests, precies zoals je dat met applicatiecode zou doen.

De meest voorkomende faalwijze is het behandelen van CIM als een eenmalige modelleringsoefening in plaats van als een levend contract. De organisaties die succesvol zijn, behandelen het model op dezelfde manier als zij een API behandelen: met versiebeheer, testen, eigenaarschap en doelbewuste evolutie.

Partners die bijdragen aan CIM

CIM is een initiatief van een consortium en de waarde ervan groeit met deelname. Partners dragen bij aan de inhoud van Subject Areas, beoordelen voorstellen en helpen de richting van het model vorm te geven. Omdat het werk open is, zijn bijdragen niet beperkt tot grote leveranciers — ondernemingen met echte integratieproblemen en individuele praktijkmensen met domeinexpertise zijn evenzeer welkom.

Neem contact op

Bent u geïnteresseerd om deel te nemen aan het CIM-initiatief? Geweldig! Neem gerust contact met ons op via e-mail voor meer informatie. E-mail ons.

Veelgestelde vragen

Wat is het Cloud Information Model (CIM)?

CIM is een applicatie-agnostisch, open-source datamodel dat een gedeeld, op standaarden gebaseerd vocabulaire biedt voor de bedrijfsconcepten die ondernemingen moeten uitwisselen tussen cloud- en on-premises-applicaties. Het wordt geproduceerd door een open consortium en gehost onder de Joint Development Foundation, onderdeel van de Linux Foundation. Het doel ervan is om de aangepaste mappingcode te verminderen die broze point-to-point-integraties vereisen.

Is CIM een product of een specificatie?

CIM is een specificatie — een model en een reeks definities — en geen uitvoerbaar product. Het definieert de betekenis en structuur van gedeelde entiteiten; u kiest nog steeds uw eigen ETL/ELT-tooling, message brokers en opslag. Zie het als het contract dat uw integratie-infrastructuur implementeert, in plaats van de infrastructuur zelf.

Waarin verschilt CIM van het integratieplatform van een leverancier?

Een integratieplatform (een iPaaS of connectorbibliotheek) verplaatst gegevens en levert vaak vooraf gebouwde connectoren, maar die connectoren coderen leverancierspecifieke semantiek. CIM is neutraal en leveranciersonafhankelijk, waardoor u niet vastzit aan het wereldbeeld van één platform. De twee zijn complementair: u kunt CIM gebruiken als het canonieke model binnen elk integratieplatform.

Wat zijn Subject Areas in CIM?

Subject Areas (ook wel domeinen genoemd) zijn de organiserende eenheden van het model, waarbij elk een belangrijk bedrijfsconcept vertegenwoordigt, zoals klanten, producten of bestellingen. Ontwerpen worden in meerdere formaten gepubliceerd, inclusief voorbeelddiagrammen, en de reeks Subject Areas zal naar verwachting groeien naarmate het consortium en de gemeenschap meer inhoud bijdragen.

Kunnen we CIM uitbreiden als het onze concepten niet dekt?

Ja. CIM is ontworpen om uitgebreid te worden, en omdat het open source is onder een neutrale stichting, kunt u via het contributieproces aanvullingen voorstellen. Het uitbreiden van het gedeelde model en het teruggeven van bijdragen heeft sterk de voorkeur boven het onderhouden van een private fork, die in de loop van de tijd afwijkt en het interoperabiliteitsvoordeel verspeelt dat de invoering van CIM in de eerste plaats motiveerde.

Wie moet CIM adopteren?

Het is het meest waardevol voor organisaties die veel applicaties van verschillende leveranciers draaien die het eens moeten worden over de betekenis van gedeelde entiteiten — de klassieke situatie voor enterprise data-architecten en integratie-engineers. Applicatie- en platformleveranciers profiteren ook van het afstemmen van hun schema’s op een neutraal model, waardoor hun producten gemakkelijker voor klanten te integreren zijn. Als u slechts twee stabiele systemen heeft, kan een eenvoudigere point-to-point mapping voldoende zijn.

Verder lezen

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia