Doe mee

Het Cloud Information Model (CIM), opgericht in 2019 onder de paraplu van de Linux Foundation, is zowel een ledenalliantie als een gemeenschap. Samen, door samen te werken in werkgroepen, definiëren en gebruiken de leden een gemeenschappelijk open datamodel, beïnvloeden ze bestaande en toekomstige standaarden en bouwen ze open oplossingen om gemeenschappelijke problemen op te lossen.

CIM bestaat omdat bedrijfsgegevens gefragmenteerd zijn over tientallen applicaties, elk met hun eigen propriëtaire schema, naamgevingsconventies en semantiek. Een klant in Salesforce, een klant in SAP en een klant in een eigen facturatiesysteem zijn allemaal “klanten” — maar ze zijn het zelden eens over wat een klant is, welke attributen gezaghebbend zijn, of hoe relaties tussen klanten, bestellingen en producten tot uitdrukking moeten worden gebracht. Het antwoord van CIM is een gedeeld, applicatie-agnostisch model waar elk systeem naar kan mappen, zodat integratiewerk een mapping-oefening wordt in plaats van een op maat gemaakt vertaalproject.

Belangrijkste inzichten

• CIM is een project van de Linux Foundation (opgericht in 2019) dat een open, op standaarden gebaseerd datamodel publiceert, vertaald in meerdere formaten, zodat heterogene systemen het kunnen adopteren.
• Deelname is gelaagd: Steering Members, Contributor Members en de bredere CIM-gemeenschap, met progressief uitgebreidere rechten naarmate u hogerop komt.
• De enige huidige werkgroep definieert nieuwe Subject Areas, mappings en API-vereisten — dit is waar het inhoudelijke technische werk plaatsvindt.
• Bijdragen is niet alleen code: het voorstellen van Subject Areas, deelnemen aan consensuspolls en lid worden van werkgroepen zijn allemaal volwaardige manieren om de standaard vorm te geven.
• Het model is bewust formaatneutraal, waardoor relationele, grafische en API-georiënteerde consumenten één canonieke definitie kunnen delen.

Waarom een gedeeld datamodel belangrijk is

De meeste integratiepijn is semantisch, niet technisch. ETL-pijplijnen, iPaaS-platforms en API-gateways zijn volwassen; wat breekt is de betekenislaag. Wanneer twee systemen het oneens zijn over de vraag of “account” een factureringsentiteit of een bedrijfshiërarchie betekent, erft elke downstream rapportage, join en reconciliatie die dubbelzinnigheid.

Een canoniek model als CIM pakt dit aan door een neutraal referentiepunt te bieden. In plaats van N systemen aan elkaar te mappen (een N×N probleem), mapt elk systeem één keer naar het canonieke model (een N×1 probleem). Dit is hetzelfde architecturale principe achter standaarden zoals het Common Information Model dat in de energiesector wordt gebruikt (IEC 61970/61968) en de HL7 FHIR-resources die in de gezondheidszorg worden gebruikt — domeinspecifieke canonieke modellen die onafhankelijk gebouwde systemen interoperabel maken.

De reikwijdte van CIM is breder en meer horizontaal: het richt zich op de gemeenschappelijke bedrijfsentiteiten — klanten, producten, bestellingen, leveranciers en de relaties daartussen — die voorkomen in CRM-, ERP-, commerce- en supply chain-systemen. Het doel is niet om de native modellen van die systemen te vervangen, maar om er als een gedeeld vocabulaire boven te staan.

Reikwijdte van de werkgroep

Wij hebben het Cloud Information Model (CIM) ontwikkeld met een op standaarden gebaseerde aanpak en het vertaald naar meerdere formaten. Deze aanpak stelt bedrijven met verschillende technologieën in staat om CIM te adopteren. Het stelt bijdragers ook in staat en bevordert de groei van een groter CIM-ecosysteem.

Gerelateerd: Boomi AtomSphere — Enterprise iPaaS voor hybride cloud-naar-on-prem-integratie.

Concreet betekent “meerdere formaten” dat hetzelfde onderliggende model door verschillende toolchains kan worden gebruikt — bijvoorbeeld als schemadefinitie voor relationele of document stores, als een graaf van entiteiten en relaties, en als de basis voor API-contracten. Een team dat een relationeel warehouse gebruikt, een team dat een graafdatabase gebruikt en een team dat REST- of GraphQL-services bouwt, kunnen allemaal werken vanuit één bron van waarheid in plaats van vanuit drie uiteenlopende definities.

Deze formaatneutraliteit is een bewuste ontwerpkeuze met reële afwegingen:

• Pro: Geen enkele tooling van een specifieke leverancier wordt bevoorrecht, dus adoptie is niet afhankelijk van de aankoop van een bepaald platform.
• Pro: Het model kan onafhankelijk van elk serialisatieformaat evolueren.
• Con: Bijdragers moeten zorgvuldig nadenken over welke constructies echt canoniek zijn versus artefacten van een bepaald formaat.
• Con: Tooling om tussen formaten te vertalen moet worden onderhouden, en round-tripping is niet altijd verliesvrij.

Voor architecten die beoordelen of ze CIM moeten adopteren, is de praktische vraag of uw integratieoppervlak wordt gedomineerd door gedeelde bedrijfsentiteiten. Als de meeste van uw mappings eenmalig en domeinspecifiek zijn, voegt een canoniek model overhead toe. Als u herhaaldelijk hetzelfde handjevol entiteiten over veel systemen heen mapt, betaalt de N×1-reductie zichzelf terug.

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

Cloud Information Model Werkgroep

Momenteel heeft CIM één werkgroep die werkt aan de definitie van nieuwe Subject Areas, mappings en API-vereisten.

Een Subject Area is een samenhangend deel van het model — bijvoorbeeld een groepering van entiteiten en relaties rond een bedrijfsdomein. Het voorstellen van een Subject Area is een van de meest impactvolle bijdragen die een lid kan leveren, omdat het bepaalt wat de standaard vervolgens bestrijkt. Mappings verbinden Subject Areas met systemen en formaten uit de echte wereld; API-vereisten leggen vast wat consumenten nodig hebben van services die op het model zijn gebouwd.

Als u overweegt om lid te worden van de werkgroep, is een handige manier om te beslissen waar u wilt bijdragen door uzelf het volgende te vragen:

1. Welke entiteiten veroorzaken de meeste integratie-herwerkzaamheden in uw organisatie? Dat zijn kandidaten voor Subject Area-voorstellen.
2. Waar zijn uw systemen het al over eens, en waar lopen ze stilletjes uiteen? Divergentie is waar mappings de meeste waarde toevoegen.
3. Wat hebben uw downstream-consumenten daadwerkelijk nodig van een API? Dat vormt de API-vereisten.

Omdat er momenteel één werkgroep is, is het praktische pad voor een nieuwe bijdrager meestal om zich bij deze aan te sluiten en een onderwerpgebied voor te stellen, in plaats van een nieuwe groep op te richten. Het voorstellen van een nieuwe werkgroep is een recht dat is voorbehouden aan hogere niveaus en is het beste voorbehouden voor werkelijk onderscheidende werkgebieden die anders de bestaande groep zouden overbelasten.

Lidmaatschapsniveaus en voordelen

De CIM-deelname is gestructureerd in niveaus, elk met progressief bredere rechten. Onderstaande tabel vat de voordelen samen zoals gepubliceerd door CIM.

Voordeel	Stuurlid	Bijdrager	CIM-gemeenschap
Gebruik CIM-modelreleases	✓	✓	✓
Blijf op de hoogte van de voortgang en innovaties van CIM	✓	✓	✓
Ideeën bijdragen aan het CIM Consortium	✓	✓	✓
Kan een onderwerpgebied voorstellen	✓	✓	✓
Toegang tot beperkte en private bronnen	✓	✓
Komt in aanmerking om lid te worden van een werkgroep	✓	✓
Bijdragen aan werkgroepen	✓	✓
Nieuwe werkgroepen voorstellen	✓	✓
Meetelt voor het minimale ondersteuningsquorum van een onderwerpgebied	✓	✓
Neem deel aan consensuspeilingen	✓	✓
Draagt bij aan de CIM Roadmap	✓	✓
Bepaalt de algemene strategische richting voor CIM	✓
Komt in aanmerking om lid te worden van de stuurgroep	✓
Komt in aanmerking voor een functie van werkgroepvoorzitter	✓
Komt in aanmerking om te stemmen om inhoud te adopteren als onderdeel van de CIM-standaard	✓
Kan in beroep gaan bij technische kwesties	✓
Kan in beroep gaan over procedurele kwesties	✓

*Aanvraag stuurlid — Bijdragende leden kunnen een stuurlidmaatschap aanvragen.

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

Hoe de niveaus te lezen

De niveaus komen overeen met een bekend open-source governancepatroon dat wordt gebruikt in projecten van de Linux Foundation: een brede gemeenschap die de output kan gebruiken en ideeën kan bijdragen, een bijdragersniveau dat het praktische werk doet, en een sturend niveau dat eigenaar is van de strategie en formele adoptie. Het onderscheid dat er in de praktijk het meest toe doet:

• CIM Community is het toegangspunt. U kunt vrijgegeven modellen adopteren en ideeën aandragen zonder een formele werkrol. Dit is geschikt als u CIM voor een project evalueert of de richting informeel wilt beïnvloeden.
• Bijdrager is waar de technische invloed ligt. Lid worden van een werkgroep, eraan bijdragen, onderwerpgebieden voorstellen en deelnemen aan consensuspeilingen vallen hieronder. Als uw doel is om de standaard vorm te geven in plaats van deze alleen maar te consumeren, dan is dit het niveau waarop u zich moet richten.
• Stuurlid beschikt over governance-rechten: strategische richting, geschiktheid voor de stuurgroep, geschiktheid voor voorzitter van de werkgroep en de formele stem om inhoud te adopteren als onderdeel van de CIM-standaard. Bijdragende leden kunnen een stuurlidmaatschap aanvragen.

Een subtiel maar belangrijk detail: ‘meetellen voor het minimale ondersteuningsquorum van een onderwerpgebied’ is een recht voor Bijdragers en hoger. Quorumregels bestaan zodat een onderwerpgebied niet wordt geadopteerd op basis van de kracht van één enkele deelnemer – een governance-waarborg die gebruikelijk is bij op consensus gebaseerde standaardisatie-organen. Als uw organisatie er belang bij heeft dat een bepaald onderwerpgebied wordt geadopteerd, is deelname op bijdragerniveau wat u in staat stelt om mee te tellen voor die drempel.

Hoe u betrokken kunt raken: een praktisch pad

Als u nieuw bent bij CIM, is een verstandige volgorde:

Waar we zouden beginnen: Fivetran — De volledig beheerde ELT-pijplijn die gewoon blijft draaien.

1. Start als CIM Community. Bekijk de vrijgegeven modellen en de FAQ, en identificeer waar de entiteiten van uw systemen overlappen met de onderwerpgebieden van CIM.
2. Ideeën bijdragen. Zelfs op gemeenschapsniveau kunt u ideeën voorstellen aan het CIM Consortium – een manier met weinig verplichtingen om te testen of uw use case resoneert.
3. Ga naar Bijdrager als u het werk wilt doen. Dit ontsluit deelname aan werkgroepen, voorstellen voor onderwerpgebieden en consensuspeilingen.
4. Vraag een stuurlidmaatschap aan als uw organisatie wil helpen de richting te bepalen en formele adoptiestemmingen wil houden.

Specifiek voor open-source bijdragers betekent de formaatneutraliteit van het model dat er ruimte is om tooling bij te dragen — formaatvertalers, validators, mappinggenerators — naast de modelinhoud zelf. Voor platform- en applicatieleveranciers is het mappen van het schema van uw product naar CIM een manier om de integratiekosten die uw klanten betalen te verlagen, wat vaak een concurrentievoordeel is.

Governance, standaarden en beroepen

CIM volgt een op standaarden gebaseerde aanpak, wat een gedefinieerd proces impliceert voor het voorstellen, beoordelen en adopteren van inhoud. De aanwezigheid van formele ‘beroepsrechten’ — technisch en procedureel — op het sturende niveau is een kenmerk van volwassen standaard-governance. Het betekent dat geschillen een gedefinieerd oplossingspad hebben in plaats van informeel te worden beslecht.

Dit weerspiegelt de manier waarop gevestigde standaardisatieorganisaties opereren. De Linux Foundation host veel van dit soort projecten en biedt het juridische en bestuurlijke raamwerk — handelsmerk-, IP- en antitrustbeleid — waarmee concurrenten kunnen samenwerken aan een gedeelde infrastructuur. Als u CIM evalueert voor adoptie door bedrijven, is de affiliatie met de Linux Foundation een betekenisvol signaal: het betekent dat het model wordt beheerd door een neutrale stichting in plaats van eigendom te zijn van één enkele leverancier, wat het risico op een toekomstige wijziging van licenties of richting verkleint.

Gerelateerde informatie

• Veelgestelde vragen
• Lidmaatschapskosten
• Lijst met huidige SteerCo-leden
• Webformulier voor bijdragers
• CIM-modelbronnen
• CIM-presentatie
• CIM-formaten
• CIM in het nieuws
• GitHub-repositories
• Nieuwsblog
• Contact

Veelgestelde vragen

Wat is het Cloud Information Model?

Het Cloud Information Model (CIM) is een open datamodel en ledengemeenschap, opgericht in 2019 onder de Linux Foundation. Het definieert een gemeenschappelijk, applicatie-agnostisch model van bedrijfsentiteiten, zodat cloud- en on-premises-systemen kunnen interopereren via gedeelde semantiek in plaats van op maat gemaakte point-to-point mappings.

Wie kan lid worden van CIM en wat kost het?

CIM heeft drie participatieniveaus: Steering Member, Contributor en CIM Community. Het community-niveau is het breedste instappunt, terwijl Contributor-leden een Steering Membership kunnen aanvragen. Lidmaatschapskosten worden afzonderlijk gepubliceerd door CIM; raadpleeg daarom de pagina Lidmaatschapskosten voor actuele bedragen in plaats van uit te gaan van een bepaalde kostprijs.

Wat is een Subject Area in CIM?

Een Subject Area is een samenhangend deel van het model dat een reeks gerelateerde entiteiten en relaties omvat. Het voorstellen van een Subject Area is een recht op Contributor-niveau en een van de meest directe manieren om invloed uit te oefenen op wat de standaard omvat. Subject Areas zijn ook onderhevig aan een minimaal steunquorum, wat voorkomt dat adoptie plaatsvindt op basis van een enkele deelnemer.

Moet ik een Steering Member zijn om een bijdrage te leveren?

Nee. Contributor-leden kunnen lid worden van werkgroepen, hieraan bijdragen, Subject Areas voorstellen en deelnemen aan consensuspeilingen. Een Steering Membership voegt bestuursrechten toe, zoals strategische richting, geschiktheid voor het Steering Committee en de formele stem om inhoud te adopteren als onderdeel van de CIM-standaard.

Hoe verhoudt CIM zich tot andere datastandaarden?

CIM is een horizontaal, sectoroverschrijdend model dat zich richt op gemeenschappelijke bedrijfsentiteiten, in tegenstelling tot domeinspecifieke canonieke modellen zoals het Common Information Model van de energiesector (IEC 61970/61968) of HL7 FHIR in de gezondheidszorg. Dankzij het formaatneutrale ontwerp kan het de native modellen van de systemen die u al gebruikt aanvullen in plaats van vervangen.

Waarom is formaatneutraliteit belangrijk voor adoptie?

Omdat het teams met verschillende technologiestacks — relationele warehouses, graph-databases en API-services — in staat stelt één canonieke definitie te consumeren in plaats van uiteenlopende schema’s te onderhouden. De trade-off is dat vertaaltools moeten worden onderhouden en dat round-tripping tussen formaten niet altijd verliesvrij is, waardoor teams de mappings moeten valideren aan de hand van hun daadwerkelijke integratiebehoeften.

Verder lezen

• Working group — Wikipedia
• Linux Foundation — Wikipedia