Ofte stillede spørgsmål

(CIM) er en åben, standardbaseret datamodel og et konsortium, der har til formål at gøre virksomhedsapplikationer og datakilder interoperable på tværs af cloud- og on-premises-systemer. Denne FAQ udvider den originale CIM FAQ med praktisk kontekst for virksomhedsdataarkitekter, integrations- og ETL-ingeniører, platformsleverandører og open source-bidragydere. Den bevarer de originale svar, samtidig med at den tilføjer dybde til, hvordan modellen fungerer, hvordan den styres, og hvordan man beslutter, om og hvordan den skal adopteres.

Key Takeaways

• CIM er en åben specifikation og et konsortium, ikke et kommercielt produkt; dens formål er en delt, applikations-agnostisk datamodel, der reducerer omkostningerne og skrøbeligheden ved punkt-til-punkt-integrationer.
• Governance ligger hos Joint Development Foundation under Linux Foundation, med en styrekomité, der historisk har inkluderet AWS, Google, Genesys og Salesforce.
• Medlemskab har to niveauer: et betalt styrekomité-niveau og et gratis bidragyderniveau; selve modellen er open source.
• CIM er udtrykt i flere standardformater, så organisationer med forskellige teknologistakke kan adoptere den uden at opgive eksisterende værktøjer.
• Modellen er mest værdifuld, når den behandles som et kanonisk ordforråd og kortlægningsmål, lagt oven på eksisterende registreringssystemer (systems of record) i stedet for at erstatte dem.
• Bidragydere bevarer kontrollen over deres egne data og IP; IP genereret i en arbejdsgruppe ejes af den juridiske enhed CIM i henhold til hver gruppes politik.

Hvad er Cloud Information Model?

Cloud Information Model (CIM) er et åbent konsortium dannet for at levere en standardbaseret løsning til at forbinde virksomhedsprodukter. Dets erklærede mål er at lade organisationer skabe sømløse, skræddersyede personlige oplevelser på tværs af cloud-native applikationer.

I praksis er CIM en delt datamodel — et fælles ordforråd af entiteter, attributter og relationer — som forskellige applikationer kan kortlægges til. I stedet for at hvert integrationsteam opfinder sine egne feltkortlægninger mellem f.eks. et CRM og en marketingplatform, mapper begge sider til de samme kanoniske definitioner. Det er det centrale løfte om interoperabilitet.

CIM letter interoperabilitet på flere konkrete måder:

• Hurtigere tid til værdi — genanvendelige kortlægninger og delt semantik forkorter hvert nyt integrationsprojekt.
• Sømløse, tilpassede oplevelser på tværs af cloud-native applikationer, fordi systemerne er enige om, hvad en “kunde”, “ordre” eller “produkt” faktisk er.
• Et på tværs af systemer-visning af data, der muliggør analyse og operationelle arbejdsgange, der spænder over flere applikationer.
• Reduceret tid til at bygge og vedligeholde integrationer, da ændringer foretages mod en stabil delt model i stedet for skrøbelige parvise kontrakter.

Det hjælper at placere CIM i det bredere landskab af datainteroperabilitetsbestræbelser. Hvor schema-on-read-tilgange (almindelige i datasøer) udskyder struktur indtil forespørgselstidspunktet, og hvor API-specifikke skemaer (såsom dem beskrevet af OpenAPI) beskriver en enkelt tjeneste, beskriver CIM en domænemodel, som mange tjenester kan dele. Det er i ånden tættere på kanoniske modelleringstraditioner som dem, der ligger bag industridatamodeller, og på semantiske web-vokabularer som dem, der er udgivet af W3C, selvom CIM er bevidst pragmatisk og virksomhedsorienteret snarere end rent akademisk.

Hvilke udfordringer for cloud-applikationer adresserer CIM?

CIM er en moderne, åben specifikation beregnet til at lette smerten ved at integrere data. Den giver en defineret standard til nemt at kommunikere mellem forskellige dataformater.

Relateret: Fivetran — Den fuldt administrerede ELT-pipeline, der bare bliver ved med at køre.

De underliggende problemer, den retter sig mod, er velkendte for alle, der har bygget virksomhedsintegrationer:

• Semantisk uoverensstemmelse. To systemer har begge et “kunde”-objekt, men det ene behandler en faktureringskonto og en person som det samme, mens det andet adskiller dem. Uden en delt model genforhandles disse definitioner ved hver integration.
• N-kvadratet integrationsvækst. At forbinde N applikationer parvis kan kræve i størrelsesordenen N² distinkte kortlægninger. En delt kanonisk model reducerer meget af dette til N kortlægninger til én model.
• Vendor lock-in og churn. Når integrationer skrives direkte mod en leverandørs proprietære skema, betyder udskiftning af denne leverandør, at integrationerne skal omskrives. Kortlægning til en neutral model reducerer skifteomkostningerne.
• Analyse på tværs af domæner. En konsistent model gør det muligt at sammenføre data på tværs af salgs-, service-, marketing- og handelsdomæner uden skræddersyet afstemningslogik i hver rapport.

CIM eliminerer ikke behovet for ETL/ELT-værktøjer, message brokers eller API-gateways. Den ligger over dem som det semantiske lag, som disse værktøjer mapper til og fra.

Hvordan CIM udtrykkes på tværs af standardformater

CIM-arbejdsgrupper udviklede modellen med en standardbaseret tilgang og oversatte den til flere standardformater. Denne tilgang gør det muligt for virksomheder med forskellige teknologier at adoptere CIM, styrker bidragydere og fremmer væksten af et større CIM-økosystem.

Hvis du handler: Boomi AtomSphere — Enterprise iPaaS til hybrid cloud-to-on-prem integration.

Den praktiske implikation er, at du ikke er tvunget til en enkelt serialisering eller værktøjskæde. En model udtrykt i mere end ét format kan forbruges af:

• Skema- og API-værktøjer, der forventer JSON Schema eller lignende strukturelle definitioner.
• Graf- og semantiske værktøjer, der arbejder med RDF-stil vokabularer og ontologier.
• Relationelle værktøjer og data warehouses, der ønsker DDL- eller entitets-relationsdefinitioner.
• Kodegeneratorer, der producerer typede klasser eller data transfer objects til applikationsudviklere.

Når du evaluerer adoption, er et nyttigt beslutningskriterium at identificere, hvilke af dine eksisterende værktøjer der allerede kan indlæse et af de offentliggjorte formater. Hvis din integrationsplatform kan forbruge modellen direkte, undgår du at bygge et oversættelseslag blot for at komme i gang.

Hvem kan deltage, og hvordan styres CIM?

CIM byder alle bidragydere velkommen. Det er open source som en del af Joint Development Foundation, som opererer under Linux Foundation. Linux Foundation er et velkendt hjem for kollaborative open source-projekter og giver det juridiske og organisatoriske stillads, der lader konkurrenter samarbejde om delt infrastruktur.

Styring og deltagelse fordeler sig som følger:

• Styrekomité. Historisk har fire virksomheder været repræsenteret i styrekomitéen: AWS, Google, Genesys og Salesforce. Styrekomitéen sætter retningen for modellen.
• Arbejdsgrupper. Disse producerer modellen og dens oversættelser til standardformater og opererer under foruddefinerede politikker.
• Bidragydere. Alle kan samarbejde og bidrage til CIM-modellen gennem “Get Involved”-kanalen.

Hvem ejer outputtet af CIM?

Fællesskabsmedlemmerne bevarer fuld kontrol over deres egne data og IP. Den IP, der genereres af CIM-medlemmer, mens de arbejder i en CIM-arbejdsgruppe, ejes af den juridiske enhed CIM og administreres i henhold til hver arbejdsgruppes foruddefinerede politik. Denne adskillelse — dine data og eksisterende IP forbliver dine; fælles oprettede modelartefakter indehaves af enheden — er et almindeligt og vigtigt mønster i åbne standardorganer, og det er værd at læse den specifikke arbejdsgruppepolitik, før du bidrager.

Medlemsgebyrer og niveauer

CIM har i øjeblikket to medlemsniveauer.

Relateret: Matillion — Push-down ELT bygget til cloud-datavarehuse.

Niveau	Årlige omkostninger	Krav	Hvad får du
SteerCo	$50.000	Din virksomhed skal være medlem af Linux Foundation	Adgang til styrekomitéen
Bidragyder	Gratis	Ingen	Deltagelse som bidragyder

Bidragyder-niveauet kræver ingen betaling. SteerCo-niveauet indebærer et gebyr og et forudsætningsvist Linux Foundation-medlemskab, hvilket afspejler det yderligere ledelsesansvar og den indflydelse, det giver. For de fleste integrations- og platformsteams er bidragyder-niveauet det naturlige udgangspunkt; organisationer, der ønsker at forme modellens køreplan, bør afveje SteerCo-forpligtelsen mod denne indflydelse.

Sådan beslutter du, om du vil adoptere CIM

Adoption er lige så meget en beslutning om modellering og styring, som det er en teknisk beslutning. Overvej disse kriterier:

• Har du tilbagevendende integrationsarbejde på tværs af leverandører? Hvis du integrerer de samme domæner gentagne gange på tværs af skiftende leverandører, betaler en kanonisk model sig. Hvis du har én stabil integration, gør den det muligvis ikke.
• Kan dit værktøj forbruge et offentliggjort format? Tjek, om din ETL-platform, API-gateway eller graflager kan indtage modellen direkte.
• Har du et domæne, som CIM dækker? CIM er orienteret mod kundecentrerede virksomhedsdomæner (kunde, produkt, ordre og relaterede koncepter). Domæner uden for dette område skal muligvis udvides.
• Hvem skal eje kortlægningslaget? Nogen skal vedligeholde kortlægningerne mellem dine registreringssystemer og den kanoniske model. Behandl dette som et varigt ansvar, ikke en engangsopgave.
• Hvad er din exit-strategi? Fordi CIM er neutral, bør kortlægning til den gøre fremtidige leverandørændringer billigere — bekræft, at dine kortlægninger reelt er afkoblet fra en enkelt leverandørs skema.

Et pragmatisk adoptionsmønster er at starte med ét højværdidomæne, kortlægge to eller tre systemer til det og måle, om det fælles ordforråd faktisk reducerede integrationsindsatsen, før man udvider.

Læsernes favorit: Airbyte — Open source ELT med en administreret cloud-mulighed.

Praktisk vejledning for bidragydere og integratorer

For dem, der bliver involveret, gør nogle få vaner arbejdet mere effektivt:

• Læs først arbejdsgruppepolitikken. Forstå IP-ejerskab og bidragsvilkår, før du skriver noget.
• Modelér til genbrug, ikke til én integration. En kanonisk enhed skal afspejle domænet, ikke særheder ved et enkelt kildesystem.
• Dokumentér kortlægninger eksplicit. Hold en versionsstyret registrering af, hvordan hvert kildesystem kortlægges til modellen, så ændringer kan spores.
• Foretræk udvidelse frem for mutation. Hvis dit domæne har brug for noget, som modellen mangler, skal du udvide den på en måde, der ikke bryder eksisterende forbrugere.
• Engager dig upstream. At bidrage med forbedringer tilbage til modellen gavner alle og reducerer vedligeholdelsesbyrden ved private forks.

Ofte stillede spørgsmål

Hvad er Cloud Information Model i én sætning?

Cloud Information Model er et åbent konsortium og en delt datamodel, styret under Joint Development Foundation inden for Linux Foundation, der giver virksomhedsapplikationer et fælles, applikations-agnostisk ordforråd, så de kan interagere på tværs af cloud- og on-premises-systemer.

Er CIM gratis at bruge og melde sig ind i?

Ja. Bidragyder-medlemsniveauet er gratis og kræver ingen betaling, og modellen er open source. Det betalte SteerCo-niveau, som giver adgang til styrekomitéen, koster $50.000 årligt og kræver, at din virksomhed er medlem af Linux Foundation.

Hvem sidder i CIM-styrekomitéen?

Fire virksomheder er i øjeblikket repræsenteret i styrekomitéen: AWS, Google, Genesys og Salesforce. Styrekomitéen vejleder modellens retning, mens arbejdsgrupper producerer artefakterne.

Hvem ejer den intellektuelle ejendom produceret af CIM?

Fællesskabsmedlemmer bevarer fuld kontrol over deres egne data og IP. IP genereret af CIM-medlemmer, mens de arbejder i en arbejdsgruppe, ejes af den juridiske CIM-enhed og administreres i henhold til den pågældende arbejdsgruppes foruddefinerede politik.

Hvordan forholder CIM sig til andre interoperabilitetsstandarder?

CIM supplerer snarere end erstatter API-beskrivelsesformater, meddelelsesskemaer og semantiske ordforråd. Det leverer den delte domænemodel, som disse formater og værktøjer kan kortlægges til, svarende i hensigt til kanoniske industridatamodeller, men fokuseret på kundecentrerede cloud-applikationsdomæner.

Hvordan kan jeg blive involveret i CIM?

Alle kan samarbejde og bidrage til CIM-modellen gennem “Get Involved”-kanalen. Et fornuftigt første skridt er at gennemgå arbejdsgruppens politikker, og derefter starte med et enkelt domæne og kortlægge et lille antal systemer for at validere tilgangen.

Yderligere læsning

• Linux Foundation — Wikipedia, for baggrund om fonden, der er vært for CIM.
• Joint Development Foundation — Wikipedia, for den juridiske enhedsstruktur bag CIM.
• World Wide Web Consortium (W3C) — for relateret arbejde med web- og semantiske standarder.
• OpenAPI Specification — for hvordan skemaer på API-niveau adskiller sig fra en delt domænemodel.