Resurser

Av Cloud Information Model Content Collective · Uppdaterad 23 september 2026

Resurssidan är ingångspunkten för alla som vill förstå, anta eller bidra till Cloud Information Model (CIM). CIM är en öppen källkods- och applikationsagnostisk datamodell – förvaltad under The Linux Foundation – som definierar ett delat vokabulär av affärsenheter så att moln- och lokala system kan utbyta data utan att varje integrationsteam behöver återuppfinna sitt eget schema. Den här sidan samlar de artefakter du behöver för att utvärdera CIM, de format den stöder, de arkiv där modellerna finns och kanalerna för att engagera sig.

Viktiga slutsatser

CIM är en delad, leverantörsneutral datamodell, inte en produkt eller en databas – den beskriver enheter, attribut och relationer som flera applikationer kan mappa till.
De primära tekniska tillgångarna finns i CIM GitHub-organisationen, där modelldefinitionerna och verktygen är versionerade och öppet licensierade.
CIM uttrycks i flera standardformat så att den kan konsumeras av olika verktygskedjor istället för att låsa dig till en specifik serialisering.
Presentationen, FAQ-sidan och nyhetssidorna är det snabbaste sättet att bygga ett affärscase och svara på frågor från intressenter innan en teknisk djupdykning.
Bidrag sker genom GitHub-arkiven och bidragsgivarens webbformulär; modellen utvecklas genom granskning av communityn snarare än en enskild leverantörs färdplan.

Vad Cloud Information Model faktiskt är

CIM förstås bäst som en kanonisk modell: en neutral, överenskommen representation av affärskoncept – kunder, konton, order, produkter, kontakter och relationerna mellan dem – som ligger mellan de system du redan kör. Istället för att tvinga varje applikation att tala varje annan applikations dialekt, mappar du varje system till CIM en gång, och CIM blir utbytespunkten.

Detta är samma arkitektoniska mönster som har dykt upp upprepade gånger i företagsintegration: ett kanoniskt schema med nav-och-eker-struktur (hub-and-spoke) istället för ett nät av punkt-till-punkt-mappningar. Det är begreppsmässigt relaterat till initiativ som OASIS Universal Business Language (UBL) för dokument, Open Applications Group Integration Specification (OAGIS) för affärsmeddelanden och schema.org för vokabulärer i webbskala. CIM:s utmärkande betoning är att den är applikationsagnostisk och designad för den verklighet med både moln och lokala installationer som de flesta företag faktiskt verkar i.

Den praktiska vinsten är minskad “mapping sprawl”. Om du har n system och varje system måste prata med alla andra, står du inför i storleksordningen n² mappningar. Introducerar du en kanonisk modell minskar arbetet till cirka n mappningar – en per system till den delade modellen. Denna minskning är det centrala ekonomiska argumentet för att anta CIM.

CIM-presentation

CIM-presentationen är den rekommenderade startartefakten för alla som bygger ett case internt. Den är utformad för att visas för en blandad publik – arkitekter, ansvariga för datastyrning och affärssponsorer – och täcker motivationen för en delad modell, omfattningen av vad CIM definierar och hur den passar in i ett befintligt integrationslandskap.

Använd den enligt följande:

Relaterat: — Den fullt -pipelinen som bara fortsätter att köras.

För chefer och sponsorer: utgå från problemet med mapping sprawl och argumentet om leverantörsneutralitet. Presentationen ramar in CIM som riskminskning, inte som ett utbyte av befintliga system (rip-and-replace).
För arkitekter och ingenjörer: använd den för att sätta sammanhanget, och gå sedan omedelbart vidare till GitHub-arkiven för de faktiska modelldefinitionerna.
För intressenter inom styrning och efterlevnad: använd den för att öppna konversationen om ägande, versionshantering och hur modelländringar granskas.

En presentation är en konversationsstartare, inte en specifikation. Se den som påfarten och se arkiven som källan till sanning.

CIM-format

CIM stöder medvetet flera standarder och format snarare än en enda proprietär serialisering. Detta är viktigt eftersom företagsverktygskedjor är heterogena: ditt modelleringsverktyg, din ETL-plattform, din API-gateway och din dokumentationsgenerator kan var och en föredra en annan representation.

Vanligtvis relevanta formatfamiljer inom detta område inkluderar:

Om du handlar: — för hybrid moln-till-på-prem-integration.

Entitetsrelations- och konceptuella notationer för mänsklig granskning och designworkshops.
JSON-baserade schemarepresentationer för konsumtion i API:er och applikationer.
RDF- och ontologiliknande representationer för semantiska användningsfall och kunskapsgrafer.
Relationella och tabellformade mappningar för datalager och ETL-pipelines.

Designprincipen är portabilitet: en modell uttryckt i ett öppet format kan transformeras, jämföras (diffas), versionshanteras och valideras med standardverktyg. När du utvärderar CIM för din organisation är frågan inte “vilket format använder den?”, utan “kan jag köra min modell fram och tillbaka genom de format som mina verktyg kräver utan dataförlust?”. Om en formatkonvertering tyst tar bort relationskardinalitet eller attributbegränsningar är det en verklig integrationsrisk som är värd att testa tidigt.

Hur man avgör vilket format som ska användas

Använd detta som en snabb beslutsguide:

Om din primära konsument är…	Föredra en representation som…	Se upp för…
Applikations-/API-utvecklare	JSON-liknande scheman	Förlust av relationssemantik i platt JSON
Datalager / ETL-team	Relationella eller tabellformade mappningar	Många-till-många-relationer som kräver bryggtabeller
Kunskapsgraf / semantiska team	RDF/ontologiska representationer	Verktygsmognad och frågeprestanda
Design- och styrningsworkshops	Konceptuell/ER-notation	Avvikelse mellan diagrammet och den maskinläsbara modellen

Den sista raden är det vanligaste felläget: team underhåller ett vackert diagram som inte längre matchar den versionerade modellen. Se till att diagrammet genereras från, eller åtminstone stäms av mot, artefakterna i arkivet.

CIM i nyheterna

Avsnittet “CIM i nyheterna” samlar extern bevakning – tillkännagivanden, analytikerkommentarer och community-artiklar – så att du kan se hur CIM tas emot utanför själva projektet. Detta är användbart av två skäl.

För det första ger det tredjepartsvalidering. När du föreslår att man ska anta en delad modell är det mer övertygande att citera oberoende bevakning än att citera projektets egen marknadsföring. För det andra lyfter det fram verkliga adoptionshistorier och integrationsmönster som kärndokumentationen kanske inte täcker.

Läs nyhetsbevakningen kritiskt. Meddelanden beskriver ofta avsikt och partnerskap snarare än utrullad användning i produktion. Skilj mellan “organisation X anslöt sig till insatsen” och “organisation X kör CIM i produktion för system Y”. Det förstnämnda är vanligt; det sistnämnda är beviset som är avgörande för ett beslut om att bygga kontra anta.

Relaterat: — Push-down ELT byggd för molndatalager.

CIM GitHub-organisation

GitHub-organisationen är där själva substansen finns. För tekniska läsare är detta den viktigaste destinationen. Räkna med att hitta:

Modelldefinitioner — de entiteter, attribut, relationer och begränsningar som utgör CIM.
Verktyg — skript och verktyg för att validera, transformera och generera artefakter från modellen.
Versionering och historik — commit-historiken som visar hur modellen har utvecklats och varför.
Issues och diskussioner — arbetsprotokollet för förslag, frågor och beslut.

Några praktiska vanor gört arkiven mycket mer användbara:

Lås till en release eller tagg istället för att följa standardgrenen, så att dina mappningar inte ändras mitt i projektet.
Läs commit-historiken för de entiteter du är intresserad av innan du antar dem. Ett fält som ändrats tre gånger på ett år signalerar ett instabilt område.
Kontrollera licensen för varje arkiv. Open source-projekt blandar ibland licenser mellan verktyg och modellinnehåll.
Skapa issues för oklarheter. Om en relations kardinalitet är otydlig kommer den tvetydigheten att påverka alla nedströmsteam; att lyfta det tidigt förbättrar modellen för alla.

För organisationer med strikta krav på försörjningskedja eller härkomst, granska arkiven på samma sätt som du skulle granska vilket tredjepartsberoende som helst: licens, underhållsaktivitet, bidragsgivarnas mångfald och releasekadens. En modell som är beroende av en enskild underhållare har en annan riskprofil än en med brett organisatoriskt stöd.

Vårt val: — som affärsteam faktiskt kan bygga på.

Vanliga frågor

Är Cloud Information Model en produkt jag kan köpa?

Nej. CIM är en datamodell med öppen källkod – en uppsättning definitioner och stödjande artefakter – som förvaltas under The Linux Foundation. Du antar den genom att mappa dina system till den och använda de publicerade modelldefinitionerna; det finns ingen licensavgift för själva modellen. Leverantörer kan bygga produkter som stöder eller bäddar in CIM, men modellen är inte ett kommersiellt erbjudande.

Måste jag byta ut mina befintliga system för att använda CIM?

Nej, och det är just det som är poängen. CIM är designad för att sitta mellan system som en kanonisk utbytesmodell. Du behåller dina applikationer, databaser och datalager, och du bygger mappningar från varje system till CIM. Detta sker inkrementellt: du kan börja med en enda högvärdig integration och utöka täckningen över tid.

Vilket format ska jag använda för att konsumera CIM?

Det beror på konsumenten. API- och applikationsteam föredrar generellt JSON-liknande schemarepresentationer; lager- och ETL-team föredrar relationella eller tabulära mappningar; semantiska team och team för kunskapsgrafer föredrar RDF/ontologirepresentationer. Det avgörande testet är förlustfri tur-och-retur-konvertering – verifiera att konvertering mellan format bevarar relationer och begränsningar innan du committar.

Hur förhåller sig CIM till andra standarder som UBL eller OAGIS?

De upptar närliggande problemområden. UBL och OAGIS fokuserar kraftigt på affärsdokument och meddelanden som utbyts mellan parter, medan CIM betonar en delad entitetsmodell som applikationer mappar till. I praktiken kan de vara komplementära: en kanonisk entitetsmodell kan ligga till grund för hur du fyller i dokumentstandarder. Utvärdera överlappningen för dina specifika användningsfall snarare än att anta att den ena ersätter den andra.

Hur bidrar jag till CIM?

Bidrag sker främst genom CIM GitHub-organisationen – issues, pull requests och diskussioner – tillsammans med bidragsgivarens webbformulär som länkas från denna webbplats. Eftersom modellen är community-styrd granskas förslag öppet. Börja smått: förtydliga en tvetydig definition eller lägg till ett saknat attribut med en tydlig motivering, och engagera dig med underhållarna innan du föreslår stora strukturella ändringar.

Var ska en icke-teknisk intressent börja?

Börja med CIM-presentationen och FAQ, skumma sedan igenom “CIM i nyheterna” för tredjepartskontext. Dessa ger dig motivationen och vokabulären utan att du behöver läsa modelldefinitioner. Ta in det tekniska teamet när du har en kandidatintegration att pilottesta, och låt dem arbeta utifrån GitHub-arkiven.

Att engagera sig och läsa vidare

Att anta en delad modell är lika mycket en organisatorisk insats som en teknisk. De mest framgångsrika CIM-initiativen tenderar att börja med en enda, välavgränsad integration – en där två system för närvarande kräver skör anpassad mappning – bevisa ansatsen med en kanonisk modell, och sedan expandera. Styrning är viktigt: bestäm tidigt vem som äger dina interna CIM-mappningar, hur uppgraderingar av modellversioner hanteras och hur konflikter mellan affärsdefinitioner löses.

För bakgrund om förvaltarskapet och kontexten kring öppen styrning, se Linux Foundation på Wikipedia. För relaterat standardiseringsarbete är OASIS Universal Business Language och schema.org användbara referenspunkter när man jämför ansatser för kanoniska modeller. För att fördjupa dig i semantisk modellering publicerar World Wide Web Consortium (W3C) RDF- och OWL-specifikationerna som utgör grunden för representationer i ontologistil.

Använd navigeringen på denna webbplats för att nå presentationen, FAQ, formatdokumentationen, nyhetssammanfattningen och GitHub-arkiven – och använd bidragsgivarens webbformulär när du är redo att delta i utformningen av modellen.

Bygg ditt första recept gratis – inget kreditkort

Automationsledd iPaaS som affärsteam faktiskt kan bygga på