Cloud Information Model

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

Belangrijkste inzichten

• CIM is een gedeeld, open datamodel, geen product. Het definieert gemeenschappelijke bedrijfsconcepten en hun relaties, zodat verschillende applicaties gegevens kunnen uitwisselen zonder op maat gemaakte, eenmalige mappings.
• Het wordt beheerd als een open standaard. CIM is open source onder de Joint Development Foundation, onderdeel van de Linux Foundation, en verwelkomt bijdragers van leveranciers, ondernemingen en de bredere gemeenschap.
• Inhoud is georganiseerd in onderwerpgebieden (domeinen). Elk domein vertegenwoordigt een belangrijk bedrijfsconcept en wordt gepubliceerd in meerdere formaten, inclusief diagrammen, zodat architecten en engineers het stapsgewijs kunnen adopteren.
• De kernwaarde is het verminderen van de broosheid van integraties. Een canoniek model vervangt point-to-point vertaalcode door een stabiel doel waar veel systemen naar en vanuit kunnen mappen.
• Adoptie is een ontwerpbeslissing, geen schakelaar. U kiest welke domeinen u adopteert, hoe u uw bronsystemen mapt en hoe u extensies in de loop van de tijd beheert.

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 bedrijfsproducten. 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-premise-applicaties. Elk heeft zijn eigen datamodel, waardoor ontwikkelaars aangepaste code moeten 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 broze 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. Als open source project onderdeel van de Joint Development Foundation (onder de Linux Foundation), verwelkomen we alle bijdragers.

Het probleem dat CIM aanpakt is structureel, niet incidenteel. Wanneer elk systeem zijn eigen dialect spreekt – de één noemt een klant een “Contact”, de ander een “Party”, een derde een “Account” – eindigen integratieteams met het onderhouden van een groeiend web van paarsgewijze mappings.

Elke nieuwe applicatie vermenigvuldigt het aantal benodigde vertalingen, en elke schemawijziging in een enkel systeem kan doorwerken en stroomafwaartse pijplijnen breken. Een canoniek model verandert de vorm van dat probleem: in plaats van dat N systemen naar elkaar mappen, mapt elk systeem één keer naar een gedeeld vocabulaire.

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

Waarom point-to-point-integratie tekortschiet

Het helpt om concreet te zijn over de faalmodi die een gedeeld model motiveren.

• Combinatorische groei. Bij point-to-point mappings groeit het aantal vertaalpaden ruwweg met het kwadraat van het aantal systemen. Het toevoegen van een tiende applicatie is veel duurder dan het toevoegen van de tweede.
• Semantische drift. Twee teams kunnen allebei “de klant mappen” en het toch oneens zijn over de vraag of een klant een persoon, een organisatie of een factureringsrelatie is. De gegevens stromen, maar de betekenis divergeert.
• Broos verandermanagement. Een veldhernoeming of een nieuw verplicht attribuut in één bronsysteem dwingt wijzigingen af bij elke consument die ermee in aanraking komt.
• Gedupliceerde logica. Regels voor validatie, deduplicatie en identiteitsresolutie worden in elke integratie opnieuw geïmplementeerd in plaats van één keer gedefinieerd.
• Druk van vendor lock-in. Wanneer de integratielogica verweven is met het schema van een specifieke leverancier, wordt het wisselen of toevoegen van leveranciers een re-platformingproject.

Een canoniek model zoals CIM elimineert het mappingwerk niet — elk bronsysteem heeft nog steeds een mapping naar het model nodig. Wat het elimineert, is de vermenigvuldiging van dat werk. U bouwt één mapping per systeem naar het gedeelde model, en het model zelf biedt het stabiele contract tussen hen.

Hoe CIM is georganiseerd: Onderwerpgebieden

Collaboratief gedefinieerde inhoud is georganiseerd in domeinen, of Onderwerpgebieden. Elk onderwerpgebied vertegenwoordigt een belangrijk bedrijfsconcept. De CIM-ontwerpen zijn voor elk domein beschikbaar in meerdere formaten, inclusief voorbeelddiagrammen. Het aantal en de reikwijdte van de onderwerpgebieden zullen groeien met het consortium en de bijdragen.

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

Deze domeingeoriënteerde structuur is van belang voor de adoptie. U heeft zelden het hele model in één keer nodig. Een typische onderneming begint met de domeinen die de meest pijnlijke integratie raken, bewijst de aanpak en breidt deze vervolgens uit. Veelvoorkomende startpunten zijn doorgaans de concepten die in vrijwel elk systeem voorkomen:

• Party / Customer — de mensen en organisaties waarmee u zaken doet, en de rollen die zij spelen.
• Product — wat u verkoopt, aanbiedt of beheert, inclusief catalogi en classificaties.
• Account and relationship — hoe partijen zich verhouden tot producten, contracten en elkaar.
• Interaction and activity — de gebeurtenissen, transacties en interacties die het bovenstaande met elkaar verbinden.

Omdat elk onderwerpgebied wordt gepubliceerd met diagrammen en meerdere weergaveformaten, kunnen architecten het conceptuele model beoordelen, kunnen engineers een machineleesbare vorm gebruiken en kunnen zakelijke belanghebbenden valideren of de concepten overeenkomen met de werkelijkheid. Die multi-formaat aanpak is een bewuste ontwerpkeuze: een model dat alleen engineers kunnen lezen, heeft de neiging af te wijken van de zakelijke betekenis.

Hoe CIM zich verhoudt tot andere benaderingen

CIM is één van de verschillende opties om interoperabiliteit te bereiken. Een goede keuze maken betekent dat u de afwegingen begrijpt.

Benadering	Wat het is	Sterke punten	Afwegingen
Point-to-point mapping	Directe vertalingen tussen elk paar systemen	Eenvoudig voor twee systemen; geen gedeeld bestuur nodig	Groeit combinatorisch; fragiel; gedupliceerde logica
Canoniek model (CIM-stijl)	Een gedeeld, applicatie-agnostisch vocabulaire waarnaar elk systeem mapt	Lineaire mapping-inspanning; stabiel contract; herbruikbaar over projecten heen	Vereist bestuur en overeenstemming; mapping nog steeds nodig per systeem
Industriële datastandaarden	Verticale standaarden voor een specifieke sector (bijv. gezondheidszorg, financiën)	Diepe domeindekking; afstemming op regelgeving	Smalle reikwijdte; dekt mogelijk geen sectoroverschrijdende enterprise-concepten
Leveranciersdatamodellen	Het native schema van een platform dat als integratiehub fungeert	Nauwe tooling-integratie; snel binnen het ecosysteem van één leverancier	Lock-in-risico; andere leveranciers moeten zich conformeren aan het model van één partij
API-first / schema-on-read	Contracten gedefinieerd per API; betekenis wordt bepaald op het moment van consumptie	Flexibel; snel te starten	Semantische consistentie hangt af van discipline; moeilijker te besturen op schaal

De praktische richtlijn: gebruik een canoniek model wanneer u veel systemen, domeinoverschrijdende concepten en een langlevend integratielandschap heeft. Gebruik point-to-point wanneer de reikwijdte echt uit twee systemen bestaat en van korte duur is. Industriestandaarden en CIM zijn complementair — een verticale standaard kan een domein informeren, terwijl CIM het overkoepelende enterprise-vocabulaire biedt.

Hoe CIM in de praktijk te implementeren

Adoptie is een opeenvolging van weloverwogen beslissingen in plaats van een enkele migratie. Een werkbaar patroon ziet er als volgt uit:

1. Kies een integratie met veel pijnpunten en een goed afgebakend bereik. Kies een domein waar de mapping-pijn reëel is en de reikwijdte klein genoeg is om snel waarde te bewijzen.
2. Inventariseer de bronsystemen en hun schema’s. Documenteer hoe elk systeem de concepten in het gekozen Subject Area noemt, en waar ze van mening verschillen.
3. Map elk systeem naar het CIM-domein. Bouw één mapping per systeem naar het gedeelde model. Behandel deze mappings als versiebeheerde artefacten, niet als wegwerpscripts.
4. Definieer vooraf uw uitbreidingsbeleid. Bepaal hoe u omgaat met concepten die CIM nog niet bestrijkt — uitbreidingen moeten worden gedocumenteerd, consistent benoemd en, indien breed nuttig, worden voorgesteld aan het consortium.
5. Stel governance in. Wijs eigenaarschap toe voor de mappings, een reviewproces voor wijzigingen en een ritme voor synchronisatie met upstream CIM-updates.
6. Breid domein voor domein uit. Hergebruik de mapping-patronen en governance van het eerste domein om de kosten van het volgende te verlagen.

Twee kanttekeningen zijn het vermelden waard. Ten eerste voegt een canoniek model een laag toe — het is niet gratis, en de winst komt voort uit hergebruik over veel integraties heen, niet uit één enkele. Ten tweede is mapping waar het echte werk ligt; het model biedt een stabiel doel, maar iemand moet nog steeds beslissen hoe elk bronveld hiermee correspondeert, en die beslissing is gebaat bij business-input, niet alleen bij engineering.

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

Governance, Licenties en Bijdragen

CIM is open source als onderdeel van de Joint Development Foundation, die opereert onder de Linux Foundation. Die structuur is van belang voor bedrijven die dit evalueren: de Linux Foundation is een gevestigde thuisbasis voor collaboratieve, leveranciersneutrale open source-projecten, en de Joint Development Foundation biedt een juridisch kader dat specifiek is ontworpen voor het ontwikkelen en beheren van standaarden en specificatieprojecten.

Voor een enterprise data-architect zijn de praktische implicaties van dit governancemodel:

• Leveranciersneutraliteit. Geen enkele leverancier controleert de specificatie, wat het risico verkleint dat het model is vormgegeven om één platform te bevoordelen.
• Open bijdragen. Iedereen kan wijzigingen voorstellen, wat betekent dat het model kan evolueren om echte integratiebehoeften te weerspiegelen in plaats van een enkele roadmap.
• Specificatiegericht proces. Het model van de Joint Development Foundation is gebouwd rond het produceren en onderhouden van specificaties, wat aansluit bij de manier waarop standaarden worden aangenomen en gerefereerd in aanbestedingen en architectuurreviews.

Bijdragen worden aangemoedigd en staan open voor iedereen. Bijdragen nemen doorgaans de vorm aan van nieuwe of verfijnde Subject Areas, correcties en verduidelijkingen, voorbeelddiagrammen en feedback uit echte integratieprojecten. De meest waardevolle bijdragen komen vaak van praktijkexperts die tegen een specifiek mappingprobleem zijn aangelopen en het concept kunnen beschrijven dat dit oplost.

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

Betrokken raken

Bent u geïnteresseerd in het deelnemen aan het CIM-initiatief? Geweldig! Neem gerust contact met ons op via e-mail voor meer informatie.

Naast e-mailen zijn de natuurlijke manieren om betrokken te raken: het bekijken van de gepubliceerde Subject Areas voor uw interessegebied, proberen een van uw systemen naar een domein te mappen en de hiaten die u vindt terug te brengen naar de gemeenschap. Omdat het aantal en de reikwijdte van de Subject Areas groeien met het consortium en de bijdragen, verbetert het model in proportie tot het aantal echte integratieproblemen dat gebruikers ermee aan de orde stellen.

Veelgestelde vragen

Wat is het Cloud Information Model precies?

CIM is een applicatie-agnostisch, open datamodel dat gemeenschappelijke bedrijfsconcepten en hun relaties definieert, zodat verschillende applicaties gegevens kunnen uitwisselen via een gedeeld vocabulaire. Het wordt geproduceerd door een open consortium en gepubliceerd als een open specificatie. In plaats van een product dat u installeert, is het een model waarnaar u uw systemen mapt.

Voor wie is CIM bedoeld?

Het is gericht op enterprise data-architecten, integratie- en ETL-engineers, applicatie- en platformleveranciers en open-source bijdragers. Iedereen die meerdere cloud- en on-premise systemen met verschillende schema’s moet verbinden, is een potentiële gebruiker. Leveranciers profiteren omdat een gedeeld model het maatwerk vermindert dat nodig is om met hun producten te integreren.

Hoe wordt CIM beheerd en gelicentieerd?

CIM is open source als onderdeel van de Joint Development Foundation, die opereert onder de Linux Foundation. Dit biedt een leveranciersneutraal, specificatiegericht governanceframework. Die structuur is bedoeld om het model open te houden voor bijdragen en onafhankelijk van de controle van één enkele leverancier.

Hoe verschilt CIM van het eigen datamodel van een leverancier?

Het eigen model van een leverancier is geoptimaliseerd voor het product en ecosysteem van die leverancier; het adopteren hiervan als uw integratiehub heeft de neiging om lock-in te creëren. CIM is ontworpen om applicatie-agnostisch te zijn, zodat geen enkel platform de woordenschat definieert. De trade-off is dat CIM governance en overeenstemming tussen teams vereist, terwijl een leveranciersmodel klaar is voor gebruik binnen de tooling van die leverancier.

Moet ik nog steeds mappings schrijven als ik CIM gebruik?

Ja. Elk bronsysteem heeft nog steeds een mapping naar het gedeelde model nodig. Het voordeel is dat u één mapping per systeem naar CIM schrijft, in plaats van een afzonderlijke vertaling voor elk paar systemen. Dit verandert de combinatorische mapping-inspanning in grofweg lineaire inspanning en geeft u een stabiel contract dat veranderingen in individuele systemen overleeft.

Hoe begin ik met het adopteren van CIM?

Begin met een enkele, problematische en goed begrensde integratie in één Subject Area. Inventariseer de bronschema’s, map elk systeem naar het CIM-domein, definieer een uitbreidings- en governancebeleid, en behandel de mappings als versiebeheerde artefacten. Zodra het eerste domein waarde bewijst, breidt u domein voor domein uit, waarbij u de patronen en governance die u heeft vastgesteld hergebruikt.

Verder lezen

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia