Vanliga frågor

(CIM) är en öppen, standardbaserad datamodell och ett konsortium som syftar till att göra företagsapplikationer och datakällor interoperabla mellan moln- och lokala system. Denna FAQ utökar den ursprungliga CIM-FAQ:n med praktisk kontext för företagsdataarkitekter, integrations- och ETL-ingenjörer, plattformsleverantörer och bidragsgivare med öppen källkod. Den bevarar de ursprungliga svaren samtidigt som den tillför djup kring hur modellen fungerar, hur den styrs och hur man beslutar om och hur man ska implementera den.

Viktiga slutsatser

• CIM är en öppen specifikation och ett konsortium, inte en kommersiell produkt; dess syfte är en delad, applikationsagnostisk datamodell som minskar kostnaden och bräckligheten vid punkt-till-punkt-integrationer.
• Styrningen ligger hos Joint Development Foundation under Linux Foundation, med en styrkommitté som historiskt inkluderat AWS, Google, Genesys och Salesforce.
• Medlemskapet har två nivåer: en betald nivå för styrkommittén och en gratis nivå för bidragsgivare; själva modellen är öppen källkod.
• CIM uttrycks i flera standardformat så att organisationer med olika teknikstackar kan anta den utan att överge befintliga verktyg.
• Modellen är mest värdefull när den behandlas som ett kanoniskt vokabulär och mappningsmål, skiktat ovanpå befintliga registersystem snarare än att ersätta dem.
• Bidragsgivare behåller kontrollen över sin egen data och IP; IP som genereras inom en arbetsgrupp ägs av den juridiska enheten CIM enligt varje grupps policy.

Vad är Cloud Information Model?

Cloud Information Model (CIM) är ett öppet konsortium bildat för att leverera en standardbaserad lösning för att koppla samman företagsprodukter. Dess uttalade mål är att låta organisationer skapa sömlösa, skräddarsydda personliga upplevelser över molnbaserade applikationer.

I praktiken är CIM en delad datamodell — ett gemensamt vokabulär av entiteter, attribut och relationer — som olika applikationer kan mappa till. Istället för att varje integrationsteam uppfinner sina egna fältmappningar mellan, säg, ett CRM och en marknadsföringsplattform, mappar båda sidorna till samma kanoniska definitioner. Det är det centrala löftet om interoperabilitet.

CIM underlättar interoperabilitet på flera konkreta sätt:

• Snabbare time to value — återanvändbara mappningar och delad semantik förkortar varje nytt integrationsprojekt.
• Sömlösa, anpassade upplevelser över molnbaserade applikationer, eftersom systemen är överens om vad en “kund”, “order” eller “produkt” faktiskt är.
• En systemövergripande vy av data, vilket möjliggör analyser och operativa arbetsflöden som spänner över flera applikationer.
• Minskad tid för att bygga och underhålla integrationer, eftersom ändringar görs mot en stabil delad modell snarare än sköra parvisa kontrakt.

Det hjälper att placera CIM i det bredare landskapet av insatser för datainteroperabilitet. Där schema-on-read-metoder (vanliga i datasjöar) skjuter upp strukturen till frågetillfället, och där API-specifika scheman (som de som beskrivs av OpenAPI) beskriver en enskild tjänst, beskriver CIM en domänmodell som många tjänster kan dela. Den ligger i andan närmare kanoniska modelleringstraditioner, såsom de bakom industridatamodeller och semantiska webbvokabulärer publicerade av W3C, även om CIM är medvetet pragmatisk och företagsinriktad snarare än rent akademisk.

Vilka utmaningar för molnapplikationer hanterar CIM?

CIM är en modern, öppen specifikation avsedd att underlätta integration av data. Den tillhandahåller en definierad standard för att enkelt kommunicera mellan olika dataformat.

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

De underliggande problemen den adresserar är bekanta för alla som har byggt företagsintegrationer:

• Semantisk missmatchning. Två system har båda ett “kund”-objekt, men det ena behandlar ett faktureringskonto och en person som samma sak medan det andra separerar dem. Utan en delad modell omförhandlas dessa definitioner i varje integration.
• N-kvadratisk integrationstillväxt. Att ansluta N applikationer parvis kan kräva i storleksordningen N² distinkta mappningar. En delad kanonisk modell reducerar mycket av detta till N mappningar till en enda modell.
• Leverantörslåsning och churn. När integrationer skrivs direkt mot en leverantörs proprietära schema innebär ett byte av leverantör att integrationerna måste skrivas om. Mappning till en neutral modell minskar byteskostnaden.
• Analys över flera domäner. En konsekvent modell gör det genomförbart att sammanfoga data över försäljnings-, service-, marknadsförings- och handelsdomäner utan skräddarsydd avstämningslogik i varje rapport.

CIM eliminerar inte behovet av ETL/ELT-verktyg, meddelandemäklare eller API-gateways. Den ligger ovanför dem som det semantiska lagret som dessa verktyg mappar till och från.

Hur CIM uttrycks i standardformat

CIM-arbetsgrupper utvecklade modellen med ett standardbaserat tillvägagångssätt och översatte den till flera standardformat. Detta tillvägagångssätt gör det möjligt för företag med varierande teknologier att anta CIM, stärker bidragsgivare och främjar tillväxten av ett större CIM-ekosystem.

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

Den praktiska innebörden är att du inte tvingas in i en enda serialisering eller verktygskedja. En modell uttryckt i mer än ett format kan konsumeras av:

• Schema- och API-verktyg som förväntar sig JSON Schema eller liknande strukturella definitioner.
• Graf- och semantikverktyg som arbetar med RDF-liknande vokabulärer och ontologier.
• Relations- och lagerverktyg som kräver DDL- eller entitetsrelationsdefinitioner.
• Kodgeneratorer som producerar typade klasser eller dataöverföringsobjekt (DTO) för applikationsutvecklare.

Vid utvärdering av implementering är ett användbart beslutskriterium att identifiera vilka av dina befintliga verktyg som redan kan läsa in ett av de publicerade formaten. Om din integrationsplattform kan konsumera modellen direkt undviker du att bygga ett översättningslager bara för att komma igång.

Vem kan gå med, och hur styrs CIM?

CIM välkomnar alla bidragsgivare. Den är öppen källkod som en del av Joint Development Foundation, som verkar under Linux Foundation. Linux Foundation är ett välkänt hem för samarbetsprojekt med öppen källkod och tillhandahåller den juridiska och organisatoriska strukturen som låter konkurrenter samarbeta kring delad infrastruktur.

Styrning och deltagande är uppdelade enligt följande:

• Styrkommitté. Historiskt har fyra företag varit representerade i styrkommittén: AWS, Google, Genesys och Salesforce. Styrkommittén fastställer riktningen för modellen.
• Arbetsgrupper. Dessa producerar modellen och dess översättningar till standardformat, och verkar under fördefinierade policyer.
• Bidragsgivare. Vem som helst kan samarbeta och bidra till CIM-modellen genom kanalen “Get Involved”.

Vem äger resultatet av CIM?

Communitymedlemmarna behåller full kontroll över sin egen data och IP. Den IP som genereras av CIM-medlemmar när de arbetar inom en CIM-arbetsgrupp ägs av den juridiska enheten CIM och hanteras enligt varje arbetsgrupps fördefinierade policy. Denna separation — din data och befintlig IP förblir din; gemensamt skapade modellartefakter innehas av enheten — är ett vanligt och viktigt mönster i öppna standardorgan, och det är värt att läsa den specifika arbetsgruppens policy innan man bidrar.

Medlemsavgifter och nivåer

CIM har för närvarande två medlemsnivåer.

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

Nivå	Årlig kostnad	Krav	Vad du får
SteerCo	50 000 $	Ditt företag måste vara medlem i Linux Foundation	Tillgång till styrkommittén
Bidragsgivare	Gratis	Inga	Deltagande som bidragsgivare

Nivån Bidragsgivare kräver ingen betalning. SteerCo-nivån medför en avgift och ett krav på medlemskap i Linux Foundation, vilket återspeglar det ytterligare styrningsansvar och inflytande som den ger. För de flesta integrations- och plattformsteam är nivån Bidragsgivare den naturliga utgångspunkten; organisationer som vill forma modellens färdplan bör väga SteerCo-åtagandet mot detta inflytande.

Hur man avgör om man ska anta CIM

Att anta modellen är lika mycket ett beslut om modellering och styrning som ett tekniskt beslut. Överväg dessa kriterier:

• Har du återkommande integrationsarbete mellan olika leverantörer? Om du integrerar samma domäner upprepade gånger över växlande leverantörer lönar sig en kanonisk modell. Om du har en enda stabil integration kanske det inte gör det.
• Kan dina verktyg konsumera ett publicerat format? Kontrollera om din ETL-plattform, API-gateway eller grafdatabas kan ta in modellen direkt.
• Har du en domän som CIM täcker? CIM är inriktad på kundcentrerade företagsdomäner (kund, produkt, order och relaterade koncept). Domäner utanför den omfattningen kan behöva utökas.
• Vem kommer att äga mappningslagret? Någon måste underhålla mappningarna mellan dina registreringssystem och den kanoniska modellen. Behandla detta som ett varaktigt ansvar, inte en engångsuppgift.
• Vad är din exitstrategi? Eftersom CIM är neutral bör mappning till den göra framtida leverantörsbyten billigare – verifiera att dina mappningar verkligen är frikopplade från någon enskild leverantörs schema.

Ett pragmatiskt adoptionsmönster är att börja med en domän med högt värde, mappa två eller tre system till den och mäta om det delade ordförrådet faktiskt minskade integrationsarbetet innan man expanderar.

Läsarens favorit: Airbyte — Öppen källkod ELT med ett hanterat molnalternativ.

Praktisk vägledning för bidragsgivare och integratörer

För dem som engagerar sig finns det några vanor som gör arbetet mer effektivt:

• Läs arbetsgruppens policy först. Förstå IP-ägande och villkor för bidrag innan du skriver något.
• Modellera för återanvändning, inte för en enskild integration. En kanonisk enhet bör återspegla domänen, inte särdragen hos ett enskilt källsystem.
• Dokumentera mappningar explicit. För ett versionshanterat register över hur varje källsystem mappas till modellen så att ändringar är spårbara.
• Föredra utökning framför mutation. Om din domän behöver något som modellen saknar, utöka den på ett sätt som inte bryter befintliga konsumenter.
• Engagera dig upstream. Att bidra med förbättringar tillbaka till modellen gynnar alla och minskar underhållsbördan av privata forks.

Vanliga frågor

Vad är Cloud Information Model i en mening?

Cloud Information Model är ett öppet konsortium och en delad datamodell, styrd under Joint Development Foundation inom Linux Foundation, som ger företagsapplikationer ett gemensamt, applikationsagnostiskt ordförråd så att de kan samverka mellan moln- och on-premises-system.

Är CIM gratis att använda och gå med i?

Ja. Medlemsnivån Bidragsgivare är gratis och kräver ingen betalning, och modellen är öppen källkod. Den betalda SteerCo-nivån, som ger tillgång till styrkommittén, kostar 50 000 $ årligen och kräver att ditt företag är medlem i Linux Foundation.

Vem sitter i CIM:s styrkommitté?

Fyra företag är för närvarande representerade i styrkommittén: AWS, Google, Genesys och Salesforce. Styrkommittén vägleder riktningen för modellen medan arbetsgrupper producerar artefakterna.

Vem äger den immateriella egendomen som produceras av CIM?

Communitymedlemmar behåller full kontroll över sin egen data och IP. IP som genereras av CIM-medlemmar när de arbetar inom en arbetsgrupp ägs av den juridiska enheten CIM och hanteras enligt den arbetsgruppens fördefinierade policy.

Hur förhåller sig CIM till andra interoperabilitetsstandarder?

CIM kompletterar snarare än ersätter API-beskrivningsformat, meddelandescheman och semantiska vokabulärer. Den tillhandahåller den delade domänmodell som dessa format och verktyg kan mappas till, liknande avsikten med kanoniska industridatamodeller men fokuserad på kundcentrerade molnapplikationsdomäner.

Hur kan jag engagera mig i CIM?

Vem som helst kan samarbeta och bidra till CIM-modellen genom kanalen “Get Involved”. Ett vettigt första steg är att se över arbetsgruppens policyer, och sedan börja med en enda domän och kartlägga ett litet antal system för att validera tillvägagångssättet.

Ytterligare läsning

• Linux Foundation — Wikipedia, för bakgrund om stiftelsen som är värd för CIM.
• Joint Development Foundation — Wikipedia, för den juridiska enhetsstrukturen bakom CIM.
• World Wide Web Consortium (W3C) — för relaterat arbete med webb- och semantiska standarder.
• OpenAPI Specification — för hur scheman på API-nivå skiljer sig från en delad domänmodell.