Ofte stilte spørsmål

(CIM) er en åpen, standardbasert datamodell og et konsortium som tar sikte på å gjøre bedriftsapplikasjoner og datakilder interoperable på tvers av sky- og lokale systemer. Denne FAQ-en utvider den opprinnelige CIM-FAQ-en med praktisk kontekst for bedriftsdataarkitekter, integrasjons- og ETL-ingeniører, plattformleverandører og bidragsytere til åpen kildekode. Den bevarer de opprinnelige svarene, samtidig som den gir mer dybde om hvordan modellen fungerer, hvordan den styres, og hvordan man avgjør om og hvordan den skal tas i bruk.

Viktige takeaways

• CIM er en åpen spesifikasjon og et konsortium, ikke et kommersielt produkt; formålet er en delt, applikasjonsagnostisk datamodell som reduserer kostnadene og skjørheten ved punkt-til-punkt-integrasjoner.
• Styringen ligger hos Joint Development Foundation under Linux Foundation, med en styringskomité som historisk har inkludert AWS, Google, Genesys og Salesforce.
• Medlemskapet har to nivåer: et betalt nivå for styringskomiteen og et gratis nivå for bidragsytere; selve modellen er åpen kildekode.
• CIM er uttrykt i flere standardformater slik at organisasjoner med ulike teknologistabler kan ta den i bruk uten å måtte forlate eksisterende verktøy.
• Modellen er mest verdifull når den behandles som et kanonisk vokabular og kartleggingsmål, lagt på toppen av eksisterende registreringssystemer (systems of record) i stedet for å erstatte dem.
• Bidragsytere beholder kontrollen over egne data og IP; IP generert i en arbeidsgruppe eies av den juridiske enheten CIM under hver gruppes policy.

Hva er Cloud Information Model?

Cloud Information Model (CIM) er et åpent konsortium dannet for å levere en standardbasert løsning for å koble sammen bedriftsprodukter. Det uttalte målet er å la organisasjoner skape sømløse, skreddersydde personlige opplevelser på tvers av skybaserte applikasjoner.

I praksis er CIM en delt datamodell – et felles vokabular av enheter, attributter og relasjoner – som ulike applikasjoner kan kartlegges til. I stedet for at hvert integrasjonsteam finner opp sine egne feltkartlegginger mellom for eksempel et CRM-system og en markedsføringsplattform, kartlegger begge sider mot de samme kanoniske definisjonene. Det er selve kjernen i løftet om interoperabilitet.

CIM legger til rette for interoperabilitet på flere konkrete måter:

• Raskere tid til verdi – gjenbrukbare kartlegginger og delt semantikk forkorter hvert nytt integrasjonsprosjekt.
• Sømløse, tilpassede opplevelser på tvers av skybaserte applikasjoner, fordi systemene er enige om hva en “kunde”, “ordre” eller “produkt” faktisk er.
• Et systemoverskridende syn på data, som muliggjør analyser og operasjonelle arbeidsflyter som spenner over flere applikasjoner.
• Redusert tid til å bygge og vedlikeholde integrasjoner, siden endringer gjøres mot en stabil, delt modell i stedet for sprø parvise kontrakter.

Det hjelper å plassere CIM i det bredere landskapet av arbeid med datainteroperabilitet. Der “schema-on-read”-tilnærminger (vanlig i datainnsjøer) utsetter struktur til spørringstidspunktet, og der API-spesifikke skjemaer (som de beskrevet av OpenAPI) beskriver en enkelt tjeneste, beskriver CIM en domenemodell som mange tjenester kan dele. Den ligger i ånden nærmere kanoniske modelleringstradisjoner, som de bak industridatamodeller og semantiske nettvokabularer publisert av W3C, selv om CIM bevisst er pragmatisk og bedriftsorientert snarere enn rent akademisk.

Hvilke utfordringer for skyapplikasjoner løser CIM?

CIM er en moderne, åpen spesifikasjon beregnet på å lette smerten ved integrering av data. Den gir en definert standard for å kommunisere enkelt mellom ulike dataformater.

Relatert: Fivetran — Den fullt administrerte ELT-rørledningen som bare fortsetter å kjøre.

De underliggende problemene den retter seg mot er kjent for alle som har bygget bedriftsintegrasjoner:

• Semantisk mismatch. To systemer har begge et “kundeobjekt”, men det ene behandler en faktureringskonto og en person som det samme, mens det andre skiller dem. Uten en delt modell vil hver integrasjon måtte kjempe om disse definisjonene på nytt.
• N-kvadrat integrasjonsvekst. Å koble N applikasjoner parvis kan kreve i størrelsesorden N² distinkte kartlegginger. En delt kanonisk modell reduserer mye av dette til N kartlegginger mot én modell.
• Leverandørlåsing og utskifting (churn). Når integrasjoner skrives direkte mot en leverandørs proprietære skjema, betyr utskifting av leverandøren at integrasjonene må skrives om. Kartlegging til en nøytral modell reduserer byttekostnadene.
• Analyser på tvers av domener. En konsistent modell gjør det mulig å sammenstille data på tvers av salgs-, service-, markedsførings- og handelsdomener uten skreddersydd avstemmingslogikk i hver rapport.

CIM eliminerer ikke behovet for ETL/ELT-verktøy, meldingsmeglere eller API-gatewayer. Den ligger over disse som det semantiske laget som disse verktøyene kartlegger til og fra.

Hvordan CIM uttrykkes på tvers av standardformater

CIM-arbeidsgrupper utviklet modellen med en standardbasert tilnærming og oversatte den til flere standardformater. Denne tilnærmingen gjør det mulig for bedrifter med ulike teknologier å ta i bruk CIM, styrker bidragsytere og fremmer vekst for et større CIM-økosystem.

Hvis du handler: Boomi AtomSphere — Enterprise iPaaS for hybrid sky-til-på-prem-integrasjon.

Den praktiske implikasjonen er at du ikke blir tvunget inn i en enkelt serialisering eller verktøykjede. En modell uttrykt i mer enn ett format kan konsumeres av:

• Skjema- og API-verktøy som forventer JSON Schema eller lignende strukturelle definisjoner.
• Graf- og semantikkverktøy som jobber med vokabularer og ontologier i RDF-stil.
• Relasjons- og lagerverktøy som krever DDL- eller enhetsrelasjonsdefinisjoner.
• Kodegeneratorer som produserer typede klasser eller dataoverføringsobjekter (DTO-er) for applikasjonsutviklere.

Når man vurderer adopsjon, er et nyttig beslutningskriterium å identifisere hvilke av dine eksisterende verktøy som allerede kan lese et av de publiserte formatene. Hvis integrasjonsplattformen din kan konsumere modellen direkte, unngår du å bygge et oversettelseslag bare for å komme i gang.

Hvem kan bli med, og hvordan styres CIM?

CIM ønsker alle bidragsytere velkommen. Det er åpen kildekode som en del av Joint Development Foundation, som opererer under Linux Foundation. Linux Foundation er et velkjent hjem for samarbeidende åpen kildekode-prosjekter og gir det juridiske og organisatoriske rammeverket som lar konkurrenter samarbeide om delt infrastruktur.

Styring og deltakelse fordeler seg som følger:

• Styringskomité. Historisk har fire selskaper vært representert i styringskomiteen: AWS, Google, Genesys og Salesforce. Styringskomiteen setter retningen for modellen.
• Arbeidsgrupper. Disse produserer modellen og dens oversettelser til standardformater, og opererer under forhåndsdefinerte retningslinjer.
• Bidragsytere. Alle kan samarbeide og bidra til CIM-modellen gjennom “Get Involved”-kanalen.

Hvem eier utdataene til CIM?

Fellesskapets medlemmer beholder full kontroll over sine egne data og IP. IP-en som genereres av CIM-medlemmer mens de jobber i en CIM-arbeidsgruppe, eies av den juridiske enheten CIM og administreres i henhold til hver arbeidsgruppes forhåndsdefinerte policy. Denne separasjonen – dine data og eksisterende IP forblir dine; fellesskapte modellartefakter holdes av enheten — er et vanlig og viktig mønster i åpne standardorganer, og det er verdt å lese den spesifikke arbeidsgruppepolicyen før du bidrar.

Medlemsavgifter og nivåer

CIM har for tiden to medlemsnivåer.

Relatert: Matillion — Push-down ELT bygget for skydatavarehus.

Nivå	Årlig kostnad	Krav	Hva du får
SteerCo	$50 000	Firmaet ditt må være medlem av Linux Foundation	Tilgang til styringskomiteen
Bidragsyter	Gratis	Ingen	Deltakelse som bidragsyter

Bidragsyter-nivået krever ingen betaling. SteerCo-nivået har en avgift og et krav om medlemskap i Linux Foundation, noe som gjenspeiler det ekstra styringsansvaret og innflytelsen det gir. For de fleste integrerings- og plattformteam er bidragsyter-nivået det naturlige utgangspunktet; organisasjoner som ønsker å forme modellens veikart bør veie SteerCo-forpliktelsen opp mot den innflytelsen.

Hvordan bestemme om du skal ta i bruk CIM

Adopsjon er en beslutning om modellering og styring like mye som en teknisk beslutning. Vurder disse kriteriene:

• Har du tilbakevendende integrasjonsarbeid på tvers av leverandører? Hvis du integrerer de samme domenene gjentatte ganger på tvers av skiftende leverandører, lønner det seg med en kanonisk modell. Hvis du har én stabil integrasjon, gjør det kanskje ikke det.
• Kan verktøyene dine bruke et publisert format? Sjekk om ETL-plattformen, API-gatewayen eller grafdatabasen din kan ta inn modellen direkte.
• Har du et domene som CIM dekker? CIM er orientert mot kundesentriske bedriftsdomener (kunde, produkt, ordre og relaterte konsepter). Domener utenfor dette omfanget kan trenge utvidelse.
• Hvem skal eie kartleggingslaget? Noen må vedlikeholde kartleggingene mellom registreringssystemene dine og den kanoniske modellen. Behandle dette som et varig ansvar, ikke en engangsoppgave.
• Hva er exit-strategien din? Fordi CIM er nøytral, bør kartlegging til den gjøre fremtidige leverandørendringer billigere – bekreft at kartleggingene dine virkelig er frikoblet fra en enkelt leverandørs skjema.

Et pragmatisk adopsjonsmønster er å starte med ett domene med høy verdi, kartlegge to eller tre systemer til det, og måle om det delte vokabularet faktisk reduserte integreringsinnsatsen før man utvider.

Leserfavoritt: Airbyte — Åpen kildekode ELT med et administrert skyalternativ.

Praktisk veiledning for bidragsytere og integratorer

For de som blir involvert, er det noen få vaner som gjør arbeidet mer effektivt:

• Les arbeidsgruppepolicyen først. Forstå IP-eierskap og bidragsvilkår før du skriver noe.
• Modell for gjenbruk, ikke for én integrasjon. En kanonisk enhet bør reflektere domenet, ikke særegenhetene til et enkelt kildesystem.
• Dokumenter kartlegginger eksplisitt. Hold en versjonert oversikt over hvordan hvert kildesystem kartlegges til modellen slik at endringer kan spores.
• Foretrekk utvidelse fremfor mutasjon. Hvis domenet ditt trenger noe modellen mangler, utvid den på en måte som ikke ødelegger for eksisterende forbrukere.
• Engasjer deg oppstrøms. Å bidra med forbedringer tilbake til modellen kommer alle til gode og reduserer vedlikeholdsbyrden ved private forgreninger (forks).

Vanlige spørsmål

Hva er Cloud Information Model i én setning?

Cloud Information Model er et åpent konsortium og en delt datamodell, styrt under Joint Development Foundation innenfor Linux Foundation, som gir bedriftsapplikasjoner et felles, applikasjons-agnostisk vokabular slik at de kan samhandle på tvers av sky- og lokale systemer.

Er CIM gratis å bruke og bli med i?

Ja. Bidragsyter-medlemskapsnivået er gratis og krever ingen betaling, og modellen er åpen kildekode. Det betalte SteerCo-nivået, som gir tilgang til styringskomiteen, koster $50 000 årlig og krever at bedriften din er medlem av Linux Foundation.

Hvem sitter i CIM-styringskomiteen?

Fire selskaper er for tiden representert i styringskomiteen: AWS, Google, Genesys og Salesforce. Styringskomiteen veileder retningen til modellen, mens arbeidsgrupper produserer artefaktene.

Hvem eier den intellektuelle eiendommen produsert av CIM?

Fellesskapsmedlemmer beholder full kontroll over sine egne data og IP. IP generert av CIM-medlemmer mens de jobber i en arbeidsgruppe, eies av den juridiske enheten CIM og administreres i henhold til denne arbeidsgruppens forhåndsdefinerte policy.

Hvordan forholder CIM seg til andre interoperabilitetsstandarder?

CIM utfyller, snarere enn å erstatte, API-beskrivelsesformater, meldingsskjemaer og semantiske vokabularer. Den gir den delte domenemodellen som disse formatene og verktøyene kan kartlegges til, med en hensikt som ligner kanoniske industridatamodeller, men fokusert på kundesentriske skyapplikasjonsdomener.

Hvordan kan jeg bli involvert i CIM?

Alle kan samarbeide og bidra til CIM-modellen gjennom «Get Involved»-kanalen. Et fornuftig første skritt er å gjennomgå arbeidsgruppens retningslinjer, for deretter å starte med ett enkelt domene og kartlegge et lite antall systemer for å validere tilnærmingen.

Videre lesing

• Linux Foundation — Wikipedia, for bakgrunn om stiftelsen som er vert for CIM.
• Joint Development Foundation — Wikipedia, for den juridiske enhetsstrukturen bak CIM.
• World Wide Web Consortium (W3C) — for relatert arbeid med web- og semantiske standarder.
• OpenAPI Specification — for hvordan skjemaer på API-nivå skiller seg fra en delt domenemodell.