CIM-model

Het Cloud Information Model (CIM) is een open, applicatie-agnostisch datamodel dat bedoeld is om bedrijven een gedeeld vocabulaire te geven voor de entiteiten die voorkomen in CRM-, ERP-, marketing-, service- en analysesystemen. In plaats van dat elke leverancier zijn eigen objectnamen en relaties bedenkt, definieert CIM een gemeenschappelijke reeks onderwerpgebieden, entiteiten en attributen waaraan elk systeem kan worden toegewezen. Het model wordt beheerd als een open-sourceproject onder The Linux Foundation, die een breed portfolio van collaboratieve data- en infrastructuurprojecten host.

In dit artikel wordt uitgelegd hoe het CIM is gestructureerd, hoe de componenten zich tot elkaar verhouden, hoe supertypes en subtypes werken en hoe de onderwerpgebieden zijn georganiseerd. Het behandelt ook de praktische beslissingen waarmee een architect wordt geconfronteerd bij het adopteren van CIM — mapping, governance, versiebeheer en uitbreiding — en waar het model past ten opzichte van andere industriestandaarden.

Belangrijkste inzichten

• CIM organiseert bedrijfsconcepten in Onderwerpgebieden, die elk Entiteitsgroepen, Entiteiten en Attributen bevatten — een hiërarchie die overzichtelijk is gekoppeld aan schema’s, tabellen en kolommen.
• Supertypes en subtypes laten het model gedeelde kenmerken uitdrukken (een Party die een persoon of een organisatie is) terwijl specialisatie nog steeds mogelijk is.
• Het model is bewust applicatie-agnostisch: het beschrijft bedrijfsconcepten, niet de implementatie van één enkele leverancier.
• CIM wordt gepubliceerd in meerdere formaten met voorbeelddiagrammen, zodat het kan worden gebruikt door modelleringstools, codegeneratoren en documentatie.
• Het aantal en de reikwijdte van de onderwerpgebieden groeit met de bijdragen van het consortium en de gemeenschap, dus bij adoptie moet rekening worden gehouden met versiebeheer en wijzigingsbeheer.
• CIM is één optie van de vele; de juiste keuze hangt af van de vraag of u een breed domeinoverschrijdend model nodig heeft of een smalle, diepe standaard voor één branche.

Hoe het CIM is gestructureerd

Het CIM is georganiseerd in componenten, zodat de inhoud gemakkelijker kan worden genavigeerd en geconsumeerd. Elk niveau van de hiërarchie beantwoordt een andere vraag, en het begrijpen van die hiërarchie is de eerste stap om het model goed te gebruiken.

• Onderwerpgebied (Subject Area) — Een belangrijk zakelijk concept geïdentificeerd door het CIM-consortium, zoals Party. Elk onderwerpgebied bevat een of meer entiteitsgroepen. Beschouw een onderwerpgebied als een afgebakende context: het groepeert alles wat het bedrijf moet weten over één breed thema.
• Entiteitsgroep (Entity Group) — Een logische groepering van gerelateerde entiteiten binnen een onderwerpgebied, zoals Account. Entiteitsgroepen houden grote onderwerpgebieden navigeerbaar en geven teams een natuurlijke eenheid voor het toewijzen van eigenaarschap.
• Entiteit (Entity) — Een uniek object waarover een organisatie informatie verzamelt, zoals een Account Contact. Een entiteit is analoog aan een standaard databasetabel.
• Attribuut (Attribute) — Een uniek kenmerk van een entiteit, zoals Account Id of Contact Email. Een attribuut is analoog aan een standaard databaseveld binnen een tabel.

Deze hiërarchie met vier niveaus is opzettelijk bekend. Data-architecten die hebben gewerkt met relationele modellering, dimensionale modellering of entiteit-relatiediagrammen zullen het patroon onmiddellijk herkennen. De waarde die CIM toevoegt is niet een nieuwe modelleringstechniek, maar een gedeelde, vooraf onderhandelde reeks namen en relaties waarover meerdere organisaties en leveranciers het eens kunnen worden.

Een nuttig mentaal model: een onderwerpgebied is grofweg een schema of een domein; een entiteitsgroep is grofweg een naamruimte of module; een entiteit is een tabel; een attribuut is een kolom. Die mapping is bij benadering — CIM is een conceptueel en logisch model, geen fysiek model — maar het helpt als je CIM vertaalt naar een fysieke implementatie.

Supertypes en subtypes

Naast de vier kerncomponenten past het CIM-ontwerp entiteiten aan en breidt deze uit naar verdere groeperingen met behulp van supertypes en subtypes. Dit is waar het model veel van zijn expressieve kracht krijgt.

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

• Supertype — Een entiteit die wordt uitgebreid door subtype-entiteiten, en die gemeenschappelijke attributen definieert voor vergelijkbare concepten.
• Subtype — Een entiteit die een andere entiteit uitbreidt en de attributen overneemt van zijn supertype-entiteit.

Het klassieke voorbeeld is Party. Een party is iedereen of alles waarmee het bedrijf te maken heeft. Een persoon en een organisatie zijn beide parties, en ze delen attributen — een naam, identificatiegegevens, contactpunten — maar elk heeft attributen die de ander niet heeft.

Door Party te modelleren als een supertype met Person en Organization als subtypes wordt vermeden dat de gedeelde attributen worden gedupliceerd en blijven de relaties (bijvoorbeeld “deze kans behoort toe aan deze party”) consistent, ongeacht om welk subtype het gaat.

Overerving als deze is een beproefd concept in datamodellering en komt voor in standaarden zoals de UML van de Object Management Group en in de entiteitsrelatieconventies die in de hele sector worden gebruikt. Wanneer u CIM fysiek implementeert, moet u beslissen hoe u overerving wilt weergeven:

Onze keuze: Workato — Op automatisering gebaseerde iPaaS waar bedrijfsteams daadwerkelijk op kunnen voortbouwen.

• Enkele tabel (Single table) — sla alle subtypen op in één tabel met een discriminatorkolom. Eenvoudig op te vragen, maar kan veel nullable kolommen opleveren.
• Class table inheritance — één tabel voor het supertype en één per subtype, samengevoegd op een gedeelde sleutel. Genormaliseerd en schoon, maar vereist joins.
• Concrete table inheritance — een afzonderlijke, op zichzelf staande tabel per subtype. Snel voor subtypespecifieke zoekopdrachten, maar dupliceert gedeelde attributen.

Er bestaat geen universeel correct antwoord. De juiste keuze hangt af van de querypatronen, het aantal subtypen en hoe vaak de gedeelde attributen samen worden gelezen. Documenteer de beslissing, omdat deze elke downstream-integratie zal beïnvloeden.

De CIM-onderwerpgebieden

De vakgebieden vertegenwoordigen de belangrijkste bedrijfsconcepten die het consortium tot nu toe heeft gemodelleerd. Elk vakgebied wordt gepubliceerd met eigen diagrammen en formaten, en verschillende hebben expliciete versiemarkeringen (bijvoorbeeld v1.0 of v0.1.1), wat weerspiegelt dat sommige gebieden volwassener zijn dan andere.

Setup — Definieert met wie u te maken heeft, bijvoorbeeld klant, leverancier en verkoper. Het behandelt ook de software- en infrastructuurconcepten die een organisatie exploiteert: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job en IoT Device.

Data Model — De fundamentele modelleringsconcepten zelf.

Hire — Activiteiten die verband houden met het opzetten van uw bedrijf, bijvoorbeeld interne bedrijfseenheid en werknemer. Entiteitsgroepen omvatten Job Application, Employee, Compensation, Training, Location, Work Territory en Work Report.

Biz Process — Concepten voor bedrijfsprocessen en bedrijfscontinuïteit.

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

Produce — Behandeling van materiaal dat u gaat kopen, verplaatsen en verkopen, bijvoorbeeld product en voorraadproduct. Entiteitsgroepen omvatten Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order en Sales Agreement.

Market — Activiteiten die worden gebruikt om uw product te promoten, bijvoorbeeld marketingcampagne en webwinkel. Entiteitsgroepen omvatten Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy en Web Site.

Sell — Activiteiten die worden gebruikt om uw product te verkopen, bijvoorbeeld het maken van offertes en kansen. Entiteitsgroepen omvatten Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program en Competitor.

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

Service — Activiteiten om ondersteuning te bieden voor een verkocht of onderhouden product, bijvoorbeeld een case of een enquête. Entiteitsgroepen omvatten AI Assistant, Asset, Asset Subscription, Web Content, Case, Task en Event.

Fulfill — Activiteiten die u uitvoert om een bestelling aan een klant te leveren, bijvoorbeeld verzending en retourorder. Entiteitsgroepen omvatten Fulfillment Order, Shipment, Return Order, Work Order, Work Resource en Work Forecast.

Interact — Activiteiten om de interactie met eindgebruikers of andere systemen bij te houden. Entiteitsgroepen omvatten Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey en Loyalty.

Finance — Activiteiten om financiële informatie in het bedrijf te traceren, bijvoorbeeld betaling, factuur en onkostendeclaratie. Entiteitsgroepen omvatten Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar en Tax Policy.

Analyze — Activiteiten gerelateerd aan het analyseren van gegevens, bijvoorbeeld het analyseren van patronen, productgebruik, gegevensverplaatsing, gegevenswijzigingen en klanttevredenheid. Entiteitsgroepen omvatten AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty en Journal.

Merk op hoe de vakgebieden zowel operationele zaken (Sell, Fulfill, Service) als analytische zaken (Analyze, Finance) omvatten. Die breedte is precies het punt: een gedeeld model is het meest waardevol als het dezelfde klant, product of bestelling consistent kan beschrijven, ongeacht of de gegevens zich in een transactiesysteem of een datawarehouse bevinden.

Kiezen tussen CIM en andere standaarden

CIM is niet het enige gedeelde model in de onderneming. Verschillende gevestigde standaarden overlappen delen van de reikwijdte ervan, en een volwassen architectuur gebruikt er vaak meer dan één. De beslissing gaat minder over het kiezen van een winnaar en meer over het afstemmen van de breedte en het bestuur van het model op uw probleem.

Standaard	Primaire focus	Typische kracht	Waar CIM verschilt
CIM	Domeinoverschrijdende bedrijfsconcepten	Brede, applicatie-onafhankelijke dekking van CRM/ERP/marketing/service	Ontworpen als een gedeelde paraplu over domeinen heen
OMG Common Core Ontologieën / UML-gebaseerde modellen	Conceptuele modelleringsnotatie en upper ontologieën	Rigoureuze formele semantiek	CIM is directer bedrijfsgericht
Sectorspecifieke modellen (bijv. retail, gezondheidszorg, financiële verticalen)	Diepgaande dekking van één sector	Precisie binnen de verticale	CIM ruilt diepte in voor breedte
Leveranciersdatamodellen (CRM/ERP-platforms)	Objecten van één product	Nauwe integratie met dat product	CIM is van nature leveranciersneutraal

Een praktische vuistregel:

• Als u een gedeelde woordenschat nodig heeft over veel systemen en leveranciers heen, is een breed model als CIM een sterke keuze.
• Als u diepgaande, gereguleerde, sectorspecifieke semantiek nodig heeft, zal een verticale standaard doorgaans nauwkeuriger zijn, en kunt u deze aan de grenzen mappen naar CIM.
• Als u integreert binnen het ecosysteem van één leverancier, kan het eigen model van die leverancier voldoende zijn — maar het zal u niet helpen verbinding te maken met de volgende leverancier.

Het meest voorkomende patroon in de praktijk is een hub-and-spoke-benadering: CIM (of een ander canoniek model) bevindt zich in het midden, en elk bronsysteem mapt hiernaar. Dit is hetzelfde principe achter canonieke datamodellen in master data management en achter het idee van de “conformed dimension” dat in dimensionale modellering werd gepopulariseerd door Ralph Kimball.

Praktische richtlijnen voor het adopteren van CIM

Het adopteren van een gedeeld model is evenzeer een organisatorische als een technische oefening. Een paar beslissingen bepalen of de inspanning loont.

Begin met een begrensd bereik. Probeer niet elk systeem in één keer aan elk vakgebied te mappen. Kies één hoogwaardig domein — Party en Sell zijn gebruikelijke startpunten omdat klant- en opportunitygegevens op grote schaal worden gedupliceerd — en bewijs de mapping van begin tot eind.

Beslis vroeg over uw uitbreidingsbeleid. CIM is ontworpen om mee te groeien met het consortium en bijdragen, maar uw organisatie zal onvermijdelijk attributen nodig hebben die het model nog niet definieert. Stel een conventie vast voor lokale extensies (bijvoorbeeld een namespaced prefix), zodat aangepaste attributen duidelijk te onderscheiden zijn van standaardattributen en later kunnen worden gesynchroniseerd.

Beschouw versiebeheer als een eersteklas prioriteit. De subjectgebieden bevatten versiemarkeringen zoals v1.0 en v0.1.1, wat aangeeft dat het model evolueert. Zet de versie vast waarop u bouwt, houd wijzigingen bij en plan de migratie. Dit is dezelfde discipline die u op elke afhankelijkheid zou toepassen.

Map, kopieer niet. CIM is een conceptueel en logisch model. Weersta de verleiding om er rechtstreeks fysieke schema’s uit te genereren zonder rekening te houden met prestaties, indexering en de toegangspatronen van de systemen die de gegevens verbruiken. Gebruik het model om de betekenis op één lijn te brengen en ontwerp vervolgens de fysieke opslag voor uw werklast.

Beheer de mapping. De mapping tussen een bronsysteem en CIM is op zichzelf al een asset. Maak er een versie van, beoordeel deze en wijs eigenaarschap toe. Tools in het domein van dataintegratie — ETL- en ELT-platforms, datacatalogi en lineage-tools — kunnen u helpen bij te houden waar elk attribuut vandaan komt en hoe het stroomt, wat precies het soort metadata is dat het subjectgebied Analyze verwacht met entiteiten als Data Lineage.

Betrek de gemeenschap. Omdat CIM open source is en door een consortium wordt aangestuurd, zijn de hiaten die u vindt vaak hiaten die anderen ook hebben gevonden. Het bijdragen van een voorgestelde entiteit of attribuut aan het project is zowel goed burgerschap als een manier om uw onderhoudslast op de lange termijn te verminderen.

Formaten, diagrammen en consumptie

De CIM-ontwerpen zijn per domein in meerdere formaten beschikbaar, inclusief voorbeelddiagrammen. Dit is van belang omdat verschillende doelgroepen een datamodel op verschillende manieren consumeren:

• Architecten willen diagrammen en relatieoverzichten om over de structuur te redeneren.
• Engineers willen machinaal leesbare definities die ze kunnen invoeren in code-generatie, schemavalidatie of mappingtools.
• Analisten en stewards willen documentatie die uitlegt wat elke entiteit en elk attribuut in zakelijke termen betekent.

Publiceren in meerdere formaten is een bewuste ontwerpkeuze die de drempel voor adoptie verlaagt. Controleer bij het evalueren van elk gedeeld model of het wordt geleverd in formaten die uw toolchain daadwerkelijk kan verwerken — een model dat alleen als PDF bestaat, is veel minder nuttig dan een model met gestructureerde definities.

Veelgestelde vragen

Wat is het Cloud Information Model (CIM)?

Het Cloud Information Model is een open, applicatie-agnostisch datamodel dat gedeelde zakelijke concepten definieert — zoals Party, Account en Sales Order — zodat verschillende cloud- en on-premises-systemen gegevens kunnen uitwisselen met behulp van een gemeenschappelijk vocabulaire. Het is georganiseerd in subjectgebieden, entiteitsgroepen, entiteiten en attributen, en wordt beheerd als een open-sourceproject onder The Linux Foundation.

Wat is het verschil tussen een supertype en een subtype in CIM?

Een supertype is een entiteit die wordt uitgebreid door subtype-entiteiten en de attributen definieert die gemeenschappelijk zijn voor vergelijkbare concepten. Een subtype breidt een andere entiteit uit en erft de attributen van zijn supertype. Party kan bijvoorbeeld fungeren als een supertype met Person en Organization als subtypes, zodat gedeelde attributen één keer worden gedefinieerd en gespecialiseerde attributen in het subtype staan.

Hoe verhoudt CIM zich tot een databaseschema?

CIM is een conceptueel en logisch model, geen fysiek schema. De entiteiten ervan zijn analoog aan databasetabellen en de attributen aan velden, wat de vertaling intuïtief maakt, maar u moet de fysieke opslag — indexering, partitionering, denormalisatie — nog steeds ontwerpen rond uw eigen querypatronen in plaats van het model letterlijk te kopiëren.

Is CIM een vervanging voor branchespecifieke datastandaarden?

Nee. CIM is breed en domeinoverschrijdend, terwijl verticale standaarden diepgaand en sectorspecifiek zijn. Veel organisaties gebruiken een hub-and-spoke-aanpak waarbij CIM fungeert als het canonieke model in het centrum en industriestandaarden of leveranciersmodellen aan de randen erop worden gemapt.

Waarom hebben CIM-subjectgebieden versienummers?

Versiemarkeringen zoals v1.0 en v0.1.1 geven aan dat het model evolueert en dat sommige subjectgebieden volwassener zijn dan andere. Het vastzetten van een versie, het bijhouden van wijzigingen en het plannen van migraties is dezelfde discipline voor afhankelijkheidsbeheer die u zou toepassen op elke gedeelde bibliotheek of schema.

Hoe ga ik om met attributen die CIM niet definieert?

Stel een gedocumenteerde extensieconventie vast, zoals een namespaced prefix, zodat aangepaste attributen duidelijk te onderscheiden zijn van standaardattributen. Overweeg vervolgens om het hiaat terug te brengen naar het project, aangezien het model is ontworpen om te groeien door bijdragen van het consortium en de gemeenschap.