Ressurser

CIM er en åpen kildekode, applikasjonsagnostisk datamodell – styrt under The Linux Foundation – som definerer et delt vokabular av forretningsenheter slik at sky- og lokale systemer kan utveksle data uten at hvert integrasjonsteam må gjenoppfinne sitt eget skjema. Denne siden samler artefaktene du trenger for å evaluere CIM, formatene den støtter, depotene der modellene ligger, og kanalene for å bli involvert.

Viktige takeaways

• CIM er en delt, leverandørnøytral datamodell, ikke et produkt eller en database – den beskriver enheter, attributter og relasjoner som flere applikasjoner kan kartlegges til.
• De primære tekniske ressursene ligger i CIM GitHub-organisasjonen, hvor modelldefinisjonene og verktøyene er versjonert og åpent lisensiert.
• CIM er uttrykt i flere standardformater, slik at den kan konsumeres av forskjellige verktøykjeder i stedet for å låse deg til én serialisering.
• Presentasjonen, FAQ- og nyhetssidene er den raskeste måten å bygge en business case på og svare på spørsmål fra interessenter før et teknisk dypdykk.
• Bidrag skjer gjennom GitHub-repositoriene og bidragsyter-nettskjemaet; modellen utvikler seg gjennom fellesskapsgjennomgang i stedet for en enkelt leverandørs veikart.

Hva Cloud Information Model faktisk er

CIM forstås best som en kanonisk modell: en nøytral, avtalt representasjon av forretningskonsepter – kunder, kontoer, bestillinger, produkter, kontakter og relasjonene mellom dem – som ligger mellom systemene du allerede kjører. I stedet for å tvinge hver applikasjon til å snakke alle andre applikasjoners dialekt, kartlegger du hvert system til CIM én gang, og CIM blir utvekslingspunktet.

Dette er det samme arkitektoniske mønsteret som har dukket opp gjentatte ganger i bedriftsintegrasjon: et kanonisk hub-and-spoke-skjema i stedet for et nett av punkt-til-punkt-kartlegginger. Det er konseptuelt relatert til tiltak som OASIS Universal Business Language (UBL) for dokumenter, Open Applications Group Integration Specification (OAGIS) for forretningsmeldinger, og schema.org for vokabularer i nettskala. CIMs særpreg er at den er applikasjonsagnostisk og designet for den virkeligheten med både sky og lokale installasjoner (on-premises) som de fleste bedrifter faktisk opererer i.

Den praktiske gevinsten er redusert kartleggingsspredning (mapping sprawl). Hvis du har n systemer og hvert må snakke med alle andre, står du overfor i størrelsesorden n² kartlegginger. Introduser en kanonisk modell, og arbeidet reduseres mot n kartlegginger – én per system til den delte modellen. Denne reduksjonen er det sentrale økonomiske argumentet for å ta i bruk CIM.

CIM-presentasjon

CIM-presentasjonen er den anbefalte startartefakten for alle som bygger en sak internt. Den er designet for å vises til et blandet publikum – arkitekter, ledere for datastyring og forretningssponsorer – og dekker motivasjonen for en delt modell, omfanget av hva CIM definerer, og hvordan den passer inn i et eksisterende integrasjonslandskap.

Bruk den som følger:

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

• For ledere og sponsorer: start med problemet med kartleggingsspredning og argumentet om leverandørnøytralitet. Presentasjonen rammer inn CIM som risikoreduksjon, ikke som en “rip-and-replace”.
• For arkitekter og ingeniører: bruk den til å angi kontekst, og gå deretter umiddelbart til GitHub-repositoriene for de faktiske modelldefinisjonene.
• For interessenter innen styring og etterlevelse: bruk den til å åpne samtalen om eierskap, versjonering og hvordan modellendringer vurderes.

En presentasjon er en samtalestarter, ikke en spesifikasjon. Behandle den som påkjøringsrampen, og behandle repositoriene som kilden til sannhet.

CIM-formater

CIM støtter bevisst flere standarder og formater i stedet for en enkelt proprietær serialisering. Dette er viktig fordi bedriftens verktøykjeder er heterogene: modelleringsverktøyet, ETL-plattformen, API-gatewayen og dokumentasjonsgeneratoren kan hver foretrekke en annen representasjon.

Vanligvis relevante formatfamilier i dette området inkluderer:

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

• Entitetsrelasjons- og konseptuelle notasjoner for menneskelig gjennomgang og designverksteder.
• JSON-baserte skjemarepresentasjoner for API- og applikasjonsforbruk.
• RDF- og ontologi-representasjoner for semantiske brukstilfeller og kunnskapsgrafer.
• Relasjonelle og tabulære kartlegginger for datavarehus og ETL-pipelines.

Designprinsippet er portabilitet: en modell uttrykt i et åpent format kan transformeres, sammenlignes (diffed), versjonskontrolleres og valideres med standardverktøy. Når du evaluerer CIM for organisasjonen din, er ikke spørsmålet “hvilket format bruker den?”, men “kan jeg kjøre modellen min frem og tilbake (round-trip) gjennom formatene verktøyene mine krever uten tap?”. Hvis en formatkonvertering i det stille fjerner relasjonskardinalitet eller attributtbegrensninger, er det en reell integrasjonsrisiko som er verdt å teste tidlig.

Hvordan bestemme hvilket format som skal brukes

Bruk dette som en rask beslutningsguide:

Hvis din primære forbruker er…	Foretrekk en representasjon som…	Se opp for…
Applikasjons-/API-utviklere	JSON-stil skjemaer	Tap av relasjonssemantikk i flat JSON
Datavarehus / ETL-team	Relasjonelle eller tabulære kartlegginger	Mange-til-mange-relasjoner som krever koblingstabeller
Kunnskapsgraf / semantiske team	RDF/ontologiske representasjoner	Verktøymodenhet og spørringsytelse
Design- og styringsverksteder	Konseptuell/ER-notasjon	Avvik mellom diagrammet og den maskinlesbare modellen

Den siste raden er den vanligste feilmodusen: team opprettholder et vakkert diagram som ikke lenger samsvarer med den versjonerte modellen. Sørg for at diagrammet er generert fra, eller i det minste avstemt mot, artefaktene i repositoriet.

CIM i nyhetene

Seksjonen “CIM in the News” samler ekstern dekning – kunngjøringer, analytikerkommentarer og artikler fra fellesskapet – slik at du kan se hvordan CIM blir mottatt utenfor selve prosjektet. Dette er nyttig av to grunner.

For det første gir det tredjepartsvalidering. Når du foreslår å ta i bruk en delt modell, er det mer overbevisende å vise til uavhengig dekning enn å vise til prosjektets egen markedsføring. For det andre bringer det frem adopsjonshistorier og integreringsmønstre fra den virkelige verden som kjernedokumentasjonen kanskje ikke dekker.

Les nyhetsdekning kritisk. Kunngjøringer beskriver ofte intensjoner og partnerskap snarere enn faktisk bruk i produksjon. Skille mellom “organisasjon X ble med i arbeidet” og “organisasjon X kjører CIM i produksjon for system Y”. Sistnevnte er beviset som betyr noe for en beslutning om å bygge selv kontra å adoptere.

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

CIM GitHub-organisasjon

GitHub-organisasjonen er der det faktiske innholdet ligger. For tekniske lesere er dette det viktigste målet. Her kan du forvente å finne:

• Modelldefinisjoner — enhetene, attributtene, relasjonene og begrensningene som utgjør CIM.
• Verktøy — skript og verktøy for å validere, transformere og generere artefakter fra modellen.
• Versjonering og historikk — commit-historikken som viser hvordan modellen har utviklet seg og hvorfor.
• Issues og diskusjoner — arbeidsprotokollen for forslag, spørsmål og beslutninger.

Noen få praktiske vaner gjør repositoriene langt mer nyttige:

• Lås til en utgivelse eller tag i stedet for å følge standardgrenen (default branch), slik at mappingene dine ikke endres midt i prosjektet.
• Les commit-historikken for enhetene du er interessert i før du adopterer dem. Et felt som har endret seg tre ganger på et år, signaliserer et ustabilt område.
• Sjekk lisensen for hvert repositorium. Åpen kildekode-prosjekter blander noen ganger lisenser på tvers av verktøy og modellinnhold.
• Opprett issues for uklarheter. Hvis kardinaliteten til en relasjon er uklar, vil denne tvetydigheten ramme alle nedstrømsteam; å ta det opp tidlig forbedrer modellen for alle.

For organisasjoner med strenge krav til forsyningskjede eller proveniens, bør repositoriene gjennomgås på samme måte som enhver tredjepartsavhengighet: lisens, vedlikeholdsaktivitet, bidragsytermangfold og utgivelsesfrekvens. En modell som er avhengig av en enkelt vedlikeholder, har en annen risikoprofil enn en med bred organisatorisk støtte.

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

Vanlige spørsmål

Er Cloud Information Model et produkt jeg kan kjøpe?

Nei. CIM er en åpen kildekode-datamodell – et sett med definisjoner og støtteartefakter – forvaltet under The Linux Foundation. Du adopterer den ved å mappe systemene dine til den og bruke de publiserte modelldefinisjonene; det er ingen lisensavgift for selve modellen. Leverandører kan bygge produkter som støtter eller inneholder CIM, men modellen er ikke et kommersielt produkt.

Må jeg erstatte eksisterende systemer for å bruke CIM?

Nei, og det er nettopp poenget. CIM er designet for å ligge mellom systemer som en kanonisk utvekslingsmodell. Du beholder applikasjonene, databasene og datavarehusene dine, og du bygger mappinger fra hvert system til CIM. Dette er inkrementelt: du kan starte med én enkelt integrasjon av høy verdi og utvide dekningen over tid.

Hvilket format bør jeg bruke for å konsumere CIM?

Det avhenger av forbrukeren. API- og applikasjonsteam foretrekker generelt skjemarepresentasjoner i JSON-stil; varehus- og ETL-team foretrekker relasjonelle eller tabulære mappinger; semantiske team og kunnskapsgraf-team foretrekker RDF/ontologi-representasjoner. Nøkkeltesten er tapsfri tur-retur (round-tripping) – verifiser at konvertering mellom formater bevarer relasjoner og begrensninger før du forplikter deg.

Hvordan forholder CIM seg til andre standarder som UBL eller OAGIS?

De dekker tilstøtende problemområder. UBL og OAGIS fokuserer sterkt på forretningsmessige dokumenter og meldinger som utveksles mellom parter, mens CIM legger vekt på en delt enhetsmodell som applikasjoner mapper til. I praksis kan de være komplementære: en kanonisk enhetsmodell kan informere hvordan du fyller ut dokumentstandarder. Evaluer overlapping for dine spesifikke brukstilfeller i stedet for å anta at den ene erstatter den andre.

Hvordan bidrar jeg til CIM?

Bidrag flyter primært gjennom CIM GitHub-organisasjonen – via issues, pull-forespørsler og diskusjoner – sammen med bidragsyterskjemaet som er lenket fra dette nettstedet. Fordi modellen er samfunnsstyrt, blir forslag vurdert åpent. Start i det små: avklar en tvetydig definisjon eller legg til et manglende attributt med en klar begrunnelse, og gå i dialog med vedlikeholderne før du foreslår store strukturelle endringer.

Hvor skal en ikke-teknisk interessent starte?

Begynn med CIM-presentasjonen og FAQ, og skum deretter “CIM in the News” for tredjepartskontekst. Disse gir deg motivasjonen og vokabularet uten at du trenger å lese modelldefinisjoner. Involver det tekniske teamet når du har en kandidat til en pilotintegrasjon, og la dem jobbe ut fra GitHub-repositoriene.

Engasjement og videre lesning

Adopsjon av en delt modell er like mye en organisatorisk innsats som en teknisk. De mest vellykkede CIM-initiativene har en tendens til å starte med én enkelt, godt avgrenset integrasjon – der to systemer i dag krever skjør, tilpasset mapping – bevise den kanoniske modelltilnærmingen, og deretter utvide. Styring er viktig: Bestem tidlig hvem som eier dine interne CIM-mappinger, hvordan oppgraderinger av modellversjoner håndteres, og hvordan konflikter mellom forretningsdefinisjoner løses.

For bakgrunn om forvalterskap og åpen styring, se Linux Foundation på Wikipedia. For relatert standardiseringsarbeid er OASIS Universal Business Language og schema.org nyttige referansepunkter når man sammenligner kanoniske modelltilnærminger. For å gå dypere inn i semantisk modellering, publiserer World Wide Web Consortium (W3C) RDF- og OWL-spesifikasjonene som ligger til grunn for representasjoner i ontologistil.

Bruk navigasjonen på dette nettstedet for å finne presentasjonen, FAQ, formatdokumentasjonen, nyhetsoppsummeringen og GitHub-repositoriene – og bruk bidragsyterskjemaet når du er klar til å delta i utformingen av modellen.