Cloud Information Model

In plaats van voor elke integratie een op maat gemaakt datamodel uit te vinden, biedt CIM een gedeeld vocabulaire, zodat een CRM, een ERP, een commerce-platform en een analytics warehouse het eens kunnen worden over wat een “Sales Order” of een “Product Relationship Type” eigenlijk betekent. Dit artikel doorloopt de entiteitsgroepen waaruit het model bestaat en gaat vervolgens in op één representatieve entiteit — ProductRelationshipType — om te laten zien hoe CIM relaties, rollen en sleutels in de praktijk uitdrukt.

Belangrijkste inzichten

• CIM organiseert bedrijfsgegevens in entiteitsgroepen (Party, Product, Sales Order, Payment en andere) die stapsgewijs kunnen worden overgenomen in plaats van allemaal tegelijk.
• Elke entiteit wordt gedefinieerd met een Term URI, een beschrijving, scalaire eigenschappen en linkeigenschappen — een structuur die naadloos kan worden toegewezen aan JSON-LD-, RDF- en property-graph stores.
• Relatie-entiteiten zoals ProductRelationshipType coderen rollen (parent/child), zodat bundels, opties en dekkingen kunnen worden gemodelleerd zonder bedrijfslogica hard te coderen.
• Het model is bewust applicatie-agnostisch: het beschrijft wat gegevens betekenen, niet hoe een specifieke leverancier deze opslaat.
• Het adopteren van CIM is een mapping-oefening, geen rip-and-replace — je stemt bestaande systemen af op gedeelde termen en vult de hiaten in.

Waarom een gedeeld model belangrijk is

Enterprise-integratie kent een bekende faalmodus: elk systeem spreekt zijn eigen dialect. Salesforce noemt het een Account, SAP noemt het een Business Partner, en een eigen factureringsdienst noemt het een Customer. Wanneer u point-to-point mappings tussen elk paar maakt, groeit het aantal vertalingen met het kwadraat van de betrokken systemen, en vermenigvuldigt elk nieuw systeem de onderhoudslast.

Een canoniek model doorbreekt dat kwadratische probleem. U mapt elk systeem één keer naar het gedeelde model, en het gedeelde model wordt de hub. Dit is hetzelfde architecturale instinct achter standaarden als OAGIS (Open Applications Group Integration Specification), het Common Warehouse Metamodel van de OMG en het vocabulaire van schema.org voor commercie.

CIM past in die traditie, maar is gericht op interoperabiliteit in het cloudtijdperk en wordt gepubliceerd als open termen met dereferentiebare URI’s.

De praktische winst is dat een data-architect vragen kan beantwoorden als “welke systemen bevatten het gezaghebbende record voor een Party?” of “hoe representeren we een productbundel consistent in de catalogus en de bestelling?” met behulp van één enkel referentiepunt.

De entiteitsgroepen in één oogopslag

CIM is geen enkel monolithisch schema; het is een reeks losjes gekoppelde groepen. De groepen die in het model worden genoemd, zijn onder meer:

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

• Account — de commerciële relatiecontext voor een partij.
• Contact Point — telefoonnummers, e-mailadressen en soortgelijke bereikbaarheidskanalen.
• Lead — een potentiële partij die nog niet gekwalificeerd is.
• Party en Party Role — het algemene concept van een actor en de rollen die deze speelt (klant, leverancier, werknemer).
• Payment en Payment Method — hoe geld beweegt en welke instrumenten worden gebruikt.
• Product Attribute, Product Catalog en Product — de verkoopbare en omschrijfbare goederen en diensten.
• Sales Order en de grote familie van subentiteiten — het transactionele hart van het model.
• Shipment — fulfillment en logistiek.

De Sales Order-groep is veruit de meest granulaire, en het is de moeite waard om te begrijpen waarom. Een order is de plek waar bedrijfsregels zich concentreren: prijzen, belastingen, aanpassingen, leveringsgroepen en notities per regel zijn er allemaal aan verbonden.

CIM ontleedt de order in vele kleine entiteiten — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log en meer — in plaats van één brede tabel. Die decompositie is een bewuste ontwerpkeuze: het laat elk aspect onafhankelijk evolueren en stelt systemen in staat om zich alleen te abonneren op de segmenten die voor hen relevant zijn.

Anatomie van een CIM-entiteit

Elke entiteit in CIM volgt dezelfde vorm, waardoor het model voorspelbaar is om programmatisch te consumeren. Neem ProductRelationshipType, de entiteit die beschrijft waarom twee producten gerelateerd zijn.

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

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Dit is de wereldwijd unieke identifier voor het concept. Omdat het een URI is, kan deze worden gedereferentieerd en direct worden gebruikt in RDF/JSON-LD-grafieken.
• Beschrijving — “Reasons why products are related such as bundle, option or covering.” Dit vertelt u dat de entiteit een type of classificatie is, niet de relatie-instantie zelf.
• Scalaire eigenschappen — de primitieve velden die gegevens bevatten.
• Link-eigenschappen — verwijzingen naar andere entiteiten. ProductRelationshipType heeft er geen, wat op zichzelf informatief is: het is een bladentiteit, een gecontroleerd vocabulaire in plaats van een hub.

De scalaire eigenschappen zijn:

Property	Term URI	Range	Mandatory	Description
id	.../model/id	guid	yes	Primary key
parentProductRole	.../model/parentProductRole	string	yes	De eerste rol in de relatie, bijv. “Consists of”
childProductRole	.../model/childProductRole	string	yes	De tweede rol in de relatie, bijv. “Component of”

Dat de id een GUID is, is een betekenisvolle conventie: het betekent dat identifiers wereldwijd uniek zijn zonder coördinatie tussen systemen, wat precies is wat u wilt wanneer records in verschillende clouds worden aangemaakt en later worden samengevoegd.

Relaties modelleren met rollen

Het meest leerzame deel van ProductRelationshipType is het paar roleigenschappen. Een productrelatie is directioneel, en CIM legt die richting vast met twee benoemde rollen in plaats van een enkele ondoorzichtige “type”-string.

Denk eens aan een bundel. Een “Starter Kit” bestaat uit een “Router” en een “Kabel”. In CIM-termen:

• Het bovenliggende product speelt de rol die wordt beschreven door parentProductRole — bijvoorbeeld “Bestaat uit”.
• Het kindproduct speelt de rol die wordt beschreven door childProductRole — bijvoorbeeld “Component van”.

Door beide rollen als strings op het type op te slaan, krijgt u een herbruikbare definitie. Een willekeurig aantal daadwerkelijke product-naar-product-links kan verwijzen naar dezelfde ProductRelationshipType-rij, zodat de woordenschat klein en consistent blijft terwijl de relatie-instanties talrijk blijven. Dit is een klassiek normalisatiepatroon: scheid het type relatie van de instanties ervan.

De beschrijving noemt expliciet drie smaken — bundel, optie en covering — wat verwijst naar de reeks commerciële semantiek die het model wil bestrijken:

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

• Bundel — producten die samen als een eenheid worden verkocht (ouder “bestaat uit” kinderen).
• Optie — een keuze of add-on die is gekoppeld aan een basisproduct.
• Covering — een product dat een ander product omhult of beschermt, gebruikelijk in verzekerings- en garantiecontexten.

Hoe u uw rolwoordenschat bepaalt

Omdat parentProductRole en childProductRole strings in vrije vorm zijn, dicteert het model niet uw exacte bewoording. Die flexibiliteit is een kenmerk en een gevaar. Een paar praktische regels:

1. Kies een gecontroleerd vocabulaire en bevries het. Spreek een kleine reeks rolzinnen af (“Bestaat uit” / “Component van”, “Optionele add-on aan” / “Heeft optie”) en documenteer deze. Vrije tekst nodigt uit tot drift.
2. Houd rollen symmetrisch en leesbaar in beide richtingen. Een goede test: kunt u de relatie van beide kanten hardop voorlezen zodat deze logisch klinkt?
3. Overbelast rollen niet met bedrijfslogica. Als een rol voorwaardelijk gedrag vereist, hoort die logica thuis in de consumerende applicatie, niet in de string.
4. Versioneer uw vocabulaire. Wanneer u een rol toevoegt, behandel deze dan als een schemawijziging met een migratiepad, en niet als een ad-hoc invoeging.

CIM in de praktijk toepassen

Het adopteren van een canoniek model is een mapping-discipline, geen migratie. Een werkbare reeks:

• Inventariseer uw registratiesystemen (systems of record). Bepaal voor elke entiteitsgroep welk systeem gezaghebbend is. Party zou in het CRM kunnen leven; Product in het PIM; Sales Order in het ERP.
• Map elke bron naar CIM-termen. Bouw een tabel van bronveld $\rightarrow$ CIM-eigenschap. Waar een bron geen equivalent heeft, noteer dan de leemte; waar CIM geen equivalent heeft, noteer dan de extensie.
• Reconcilieer identifiers. De GUID-conventie van CIM betekent dat u doorgaans een crosswalk onderhoudt tussen native keys en CIM id-waarden.
• Kies een serialisatie. De op URI gebaseerde termen van CIM mappen op natuurlijke wijze naar JSON-LD en RDF; ze vertalen zich ook netjes naar relationele tabellen of een property graph. Het model dwingt geen opslagtechnologie af.
• Beheer de woordenschat. De rolstrings, enumeraties en extensies die u toevoegt, zijn de onderdelen die het meest waarschijnlijk zullen afwijken, dus plaats ze onder wijzigingsbeheer.

Een nuttig mentaal model is om CIM te behandelen als het interchange-schema en uw operationele stores als het system of record. U vraagt niet elke applicatie om zijn native model te verlaten; u vraagt hen om een gedeeld model aan de grenzen te publiceren en te consumeren.

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

Voorbehoud en afwegingen

Geen enkel canoniek model is gratis, en CIM vormt daarop geen uitzondering.

• Abstractie heeft een prijs. Een model dat algemeen genoeg is om industrieën te overspannen, zal niet perfect bij één specifieke sector passen. Verwacht dat u extensies moet toevoegen.
• De Sales Order-groep is zwaar. De fijnmazige decompositie ervan is krachtig, maar betekent meer joins en meer entiteiten om te mappen. Teams met eenvoudige orderstromen kunnen slechts een subset adopteren.
• Rolstrings in vrije vorm hebben governance nodig. Zoals opgemerkt is de flexibiliteit in parentProductRole en childProductRole slechts zo goed als de discipline eromheen.
• Open modellen evolueren. Omdat CIM gemeenschapsgericht is, kunnen termen in de loop van de tijd worden toegevoegd of verfijnd. Pin op een versie en beoordeel wijzigingen bewust.

De afweging is in wezen de klassieke keuze tussen trouw aan een specifiek systeem en portabiliteit over systemen heen. CIM optimaliseert voor portabiliteit, wat de juiste keuze is wanneer interoperabiliteit het doel is.

Veelgestelde vragen

Wat is het Cloud Information Model?

Het Cloud Information Model is een open, applicatie-agnostisch datamodel dat gedeelde entiteiten en termen definieert voor bedrijfsgegevens zoals partijen, producten, orders en betalingen. Het biedt een gemeenschappelijk vocabulaire zodat verschillende cloud- en on-premises-systemen gegevens kunnen uitwisselen zonder op maat gemaakte point-to-point mappings.

Waar wordt ProductRelationshipType voor gebruikt?

ProductRelationshipType definieert de redenen waarom twee producten verwant zijn — bijvoorbeeld een bundel, een optie of een covering. Het slaat een parent-rol en een child-rol op, zodat directionele product-naar-product-links kunnen verwijzen naar een herbruikbare, gedeelde definitie in plaats van de semantiek op elke link te herhalen.

Waarom gebruikt CIM GUID’s voor primaire sleutels?

Het gebruik van een GUID voor de id-eigenschap betekent dat identifiers globaal uniek zijn zonder centrale coördinatie. Dat is van belang in multi-cloud- en multi-vendor-omgevingen waar records in verschillende systemen worden aangemaakt en later worden samengevoegd, omdat collisies effectief worden vermeden.

Is CIM een databaseschema of een formaat voor gegevensuitwisseling?

Het kan het beste worden begrepen als een conceptueel en interchange-model in plaats van een fysiek databaseschema. De op URI gebaseerde termen mappen op natuurlijke wijze naar JSON-LD, RDF, relationele tabellen of property graphs, zodat u het kunt implementeren in welke opslagtechnologie uw architectuur ook al gebruikt.

Hoe verhoudt CIM zich tot andere standaarden zoals OAGIS of schema.org?

CIM deelt het doel van deze inspanningen – een gedeelde woordenschat voor interoperabiliteit – maar is gericht op enterprise-integratie in het cloud-tijdperk en gepubliceerd als open, dereferenceerbare termen. In de praktijk kun je CIM koppelen aan andere standaarden aan de randen waar partners deze vereisen.

Moet ik het hele model in één keer overnemen?

Nee. CIM is georganiseerd in losjes gekoppelde entiteitsgroepen, zodat u de groepen die u nodig heeft kunt overnemen – zeg, Party en Product – en later kunt uitbreiden. De meeste teams beginnen met de entiteiten die de meeste integratieproblemen veroorzaken en groeien van daaruit verder.

Verder lezen

• Sales order — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — gedeelde woordenschat voor gestructureerde gegevens op het web