Bliv involveret

Grundlagt i 2019 under Linux Foundations paraply er Cloud Information Model (CIM) både en medlemsalliance og et fællesskab. Sammen, i samarbejde i arbejdsgrupper, definerer og bruger medlemmerne en fælles åben datamodel, påvirker eksisterende og fremtidige standarder og bygger åbne løsninger til at løse fælles problemer.

CIM eksisterer, fordi virksomhedsdata er fragmenteret på tværs af snesevis af applikationer, hver med sit eget proprietære skema, navngivningskonventioner og semantik. En kunde i Salesforce, en kunde i SAP og en kunde i et hjemmelavet faktureringssystem er alle “kunder” — men de er sjældent enige om, hvad en kunde er, hvilke attributter der er autoritative, eller hvordan relationer mellem kunder, ordrer og produkter skal udtrykkes. CIM’s svar er en delt, applikations-agnostisk model, som ethvert system kan mappe til, så integrationsarbejde bliver en kortlægningsøvelse snarere end et skræddersyet oversættelsesprojekt.

Key Takeaways

• CIM er et Linux Foundation-projekt (stiftet 2019), der udgiver en åben, standardbaseret datamodel oversat til flere formater, så heterogene systemer kan adoptere den.
• Deltagelse er opdelt i niveauer: Steering Members, Contributor Members og det bredere CIM-fællesskab, med gradvist bredere rettigheder, jo højere man kommer op.
• Den enkelte nuværende arbejdsgruppe definerer nye emneområder (Subject Areas), kortlægninger og API-krav — det er her, det egentlige tekniske arbejde foregår.
• Bidrag er ikke kun kode: At foreslå emneområder, deltage i konsensusafstemninger og deltage i arbejdsgrupper er alle førsteklasses måder at forme standarden på.
• Modellen er bevidst formatneutral, hvilket er det, der lader relationelle, graf- og API-orienterede forbrugere dele én kanonisk definition.

Hvorfor en delt datamodel er vigtig

De fleste integrationsproblemer er semantiske, ikke tekniske. ETL-pipelines, iPaaS-platforme og API-gateways er modne; det, der går i stykker, er meningslaget. Når to systemer er uenige om, hvorvidt “konto” betyder en faktureringsenhed eller et virksomhedshierarki, arver enhver downstream-rapport, join og afstemning denne tvetydighed.

En kanonisk model som CIM adresserer dette ved at give et neutralt referencepunkt. I stedet for at mappe N systemer til hinanden (et N×N-problem), mapper hvert system én gang til den kanoniske model (et N×1-problem). Dette er det samme arkitektoniske princip bag standarder som Common Information Model, der bruges i energisektoren (IEC 61970/61968), og HL7 FHIR-ressourcerne, der bruges i sundhedsvæsenet — domænespecifikke kanoniske modeller, der lader uafhængigt byggede systemer interoperere.

CIM’s omfang er bredere og mere horisontalt: det retter sig mod de almindelige forretningsenheder — kunder, produkter, ordrer, leverandører og relationerne mellem dem — der optræder på tværs af CRM-, ERP-, commerce- og forsyningskædesystemer. Målet er ikke at erstatte nogen af disse systemers oprindelige modeller, men at ligge over dem som et fælles ordforråd.

Arbejdsgruppens omfang

Vi har udviklet Cloud Information Model (CIM) med en standardbaseret tilgang og oversat den til flere formater. Denne tilgang gør det muligt for virksomheder med forskellige teknologier at anvende CIM. Det styrker også bidragydere og fremmer vækst for et større CIM-økosystem.

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

Konkret betyder “flere formater”, at den samme underliggende model kan forbruges af forskellige værktøjskæder —for eksempel som en skemadefinition for relationelle eller dokumentlagre, som en graf over enheder og relationer og som grundlag for API-kontrakter. Et team, der bruger et relationelt warehouse, et team, der bruger en grafdatabase, og et team, der bygger REST- eller GraphQL-tjenester, kan alle arbejde ud fra én kilde til sandhed i stedet for tre divergerende definitioner.

Denne formatneutralitet er et bevidst designvalg med reelle afvejninger:

• Pro: Ingen enkelt leverandørs værktøjer er privilegerede, så adoption er ikke betinget af køb af en bestemt platform.
• Pro: Modellen kan udvikle sig uafhængigt af ethvert serialiseringsformat.
• Con: Bidragydere skal tænke nøje over, hvilke konstruktioner der virkelig er kanoniske, kontra artefakter af et bestemt format.
• Con: Værktøjer til at oversætte mellem formater skal vedligeholdes, og round-tripping er ikke altid tabsfrit.

For arkitekter, der vurderer, om de skal anvende CIM, er det praktiske spørgsmål, om din integrationsflade er domineret af delte forretningsenheder. Hvis de fleste af dine kortlægninger er engangs- og domænespecifikke, tilføjer en kanonisk model overhead. Hvis du gentagne gange mapper den samme håndfuld entiteter på tværs af mange systemer, betaler N×1-reduktionen sig selv.

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

Cloud Information Model Working Group

I øjeblikket har CIM en enkelt arbejdsgruppe, som arbejder med definitionen af nye emneområder (Subject Areas), kortlægninger og API-krav.

Et emneområde (Subject Area) er et sammenhængende udsnit af modellen — for eksempel en gruppering af enheder og relationer omkring et forretningsdomæne. At foreslå et emneområde er et af de mest virkningsfulde bidrag, et medlem kan give, fordi det bestemmer, hvad standarden dækker næste gang. Kortlægninger forbinder emneområder med systemer og formater i den virkelige verden; API-krav fanger, hvad forbrugerne har brug for fra tjenester bygget på modellen.

Hvis du overvejer at blive medlem af arbejdsgruppen, er en nyttig måde at beslutte, hvor du skal bidrage, ved at spørge:

1. Hvilke enheder forårsager mest integrationsomarbejde i din organisation? Disse er kandidater til emneområdeforslag.
2. Hvor er dine systemer allerede enige, og hvor divergerer de stille og roligt? Divergens er der, hvor kortlægninger tilføjer størst værdi.
3. Hvad har dine downstream-forbrugere faktisk brug for fra en API? Det former API-kravene.

Fordi der i øjeblikket kun er én arbejdsgruppe, er den praktiske vej for en ny bidragyder normalt at slutte sig til den og foreslå et emneområde, fremfor at oprette en ny gruppe. At foreslå en ny arbejdsgruppe er en ret forbeholdt højere niveauer og bør primært forbeholdes virkeligt adskilte arbejdsområder, der ellers ville overbelaste den eksisterende gruppe.

Medlemskabsniveauer og fordele

CIM-deltagelse er struktureret i niveauer, hver med gradvist bredere rettigheder. Tabellen nedenfor opsummerer fordelene, som offentliggjort af CIM.

Fordel	Styremedlem	Bidragyder	CIM Community
Brug af CIM Model Releases	✓	✓	✓
Hold dig opdateret om CIM-fremskridt og innovationer	✓	✓	✓
Bidrag med idéer til CIM-konsortiet	✓	✓	✓
Kan foreslå et emneområde	✓	✓	✓
Adgang til begrænsede og private ressourcer	✓	✓
Berettiget til at deltage i en arbejdsgruppe	✓	✓
Bidrage til arbejdsgrupper	✓	✓
Foreslå nye arbejdsgrupper	✓	✓
Tæller med i minimumskvorum for et emneområde	✓	✓
Deltag i konsensusmålinger	✓	✓
Bidrager til CIM-køreplanen	✓	✓
Driver den overordnede strategiske retning for CIM	✓
Berettiget til at deltage i styrekomitéen	✓
Berettiget til en stilling som arbejdsgruppeformand	✓
Berettiget til at stemme for at vedtage indhold som en del af CIM-standarden	✓
Kan appellere tekniske spørgsmål	✓
Kan appellere proceduremæssige spørgsmål	✓

*Ansøgning om styremedlem — Bidragydermedlemmer kan ansøge om et styremedlemskab.

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

Sådan læses niveauerne

Niveauerne følger et velkendt open source-styringsmønster, der bruges i Linux Foundation-projekter: et bredt fællesskab, der kan bruge outputtet og bidrage med idéer, et bidragyderniveau, der udfører det praktiske arbejde, og et styreniveau, der ejer strategien og den formelle vedtagelse. Den sondring, der betyder mest i praksis:

• CIM Community er indgangspunktet. Du kan adoptere frigivne modeller og bidrage med idéer uden en formel arbejdsrolle. Dette er passende, hvis du evaluerer CIM til et projekt eller ønsker at påvirke retningen uformelt.
• Bidragyder er her, den tekniske indflydelse ligger. At slutte sig til en arbejdsgruppe, bidrage til den, foreslå emneområder og deltage i konsensusmålinger hører alle til her. Hvis dit mål er at forme standarden fremfor blot at forbruge den, er dette niveauet, du skal sigte efter.
• Styremedlem har governance-rettigheder: strategisk retning, berettigelse til styrekomitéen, berettigelse til at være arbejdsgruppeformand og den formelle stemme til at vedtage indhold som en del af CIM-standarden. Bidragydermedlemmer kan ansøge om et styremedlemskab.

En subtil, men vigtig detalje: at “tælle med i minimumskvorum for et emneområde” er en rettighed for bidragydere og opefter. Kvorumsregler eksisterer, så et emneområde ikke vedtages på baggrund af en enkelt deltager – en governance-sikring, der er almindelig for konsensusbaserede standardiseringsorganer. Hvis din organisation går op i, at et bestemt emneområde bliver vedtaget, er det deltagelse på bidragyderniveau, der gør det muligt at tælle med mod denne tærskel.

Sådan kommer du i gang: En praktisk vej

Hvis du er ny i CIM, er en fornuftig rækkefølge:

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

1. Start som CIM Community. Gennemgå de frigivne modeller og FAQ’en, og identificer hvor dine systems entiteter overlapper med CIM’s emneområder.
2. Bidrag med idéer. Selv på fællesskabsniveauet kan du foreslå idéer til CIM-konsortiet – en måde med lav forpligtelse til at teste, om din use case giver genklang.
3. Bliv Bidragyder, hvis du vil udføre arbejdet. Dette låser op for deltagelse i arbejdsgrupper, forslag til emneområder og konsensusmålinger.
4. Ansøg om styremedlemskab, hvis din organisation ønsker at hjælpe med at sætte retningen og deltage i formelle vedtagelsesafstemninger.

Specifikt for open source-bidragydere betyder modellens formatneutralitet, at der er plads til at bidrage med værktøjer – formatoversættere, validatorer, mapping-generatorer – sideløbende med selve modelindholdet. For platform- og applikationsleverandører er mapping af dit produkts skema til CIM en måde at reducere integrationsomkostningerne for dine kunder, hvilket ofte er en konkurrencemæssig differentiering.

Governance, standarder og appeller

CIM følger en standardbaseret tilgang, hvilket indebærer en defineret proces for at foreslå, gennemgå og vedtage indhold. Tilstedeværelsen af formelle “appel”-rettigheder – både tekniske og proceduremæssige – på styreniveauet er et kendetegn for moden standard-governance. Det betyder, at tvister har en defineret løsningsvej fremfor at blive afgjort uformelt.

Dette afspejler, hvordan etablerede standardiseringsorganisationer fungerer. Linux Foundation er vært for mange sådanne projekter og leverer det juridiske og governance-mæssige stillads – varemærke-, IP- og antitrustpolitikker – der gør det muligt for konkurrenter at samarbejde om delt infrastruktur. Hvis du evaluerer CIM til virksomhedsadoption, er tilknytningen til Linux Foundation et meningsfuldt signal: det betyder, at modellen styres af en neutral fond fremfor at være ejet af en enkelt leverandør, hvilket reducerer risikoen for fremtidige ændringer i licensering eller retning.

Relateret information

• Ofte stillede spørgsmål
• Medlemskontingenter
• Liste over nuværende SteerCo-medlemmer
• Webformular for bidragydere
• CIM-modelressourcer
• CIM-præsentation
• CIM-formater
• CIM i nyhederne
• GitHub-repositories
• Nyhedsblog
• Kontakt

Ofte stillede spørgsmål

Hvad er Cloud Information Model?

Cloud Information Model (CIM) er en åben datamodel og et medlemsfællesskab grundlagt i 2019 under Linux Foundation. Den definerer en fælles, applikations-agnostisk model for forretningsenheder, så cloud- og on-premises-systemer kan interagere gennem delt semantik snarere end skræddersyede punkt-til-punkt-kortlægninger.

Hvem kan deltage i CIM, og hvad koster det?

CIM har tre deltagelsesniveauer: Steering Member, Contributor og CIM Community. Community-niveauet er det bredeste indgangspunkt, mens Contributor-medlemmer kan ansøge om et Steering Membership. Medlemskontingenter offentliggøres separat af CIM, så se siden for medlemskontingenter for aktuelle tal i stedet for at antage en pris.

Hvad er et Subject Area i CIM?

Et Subject Area er et sammenhængende udsnit af modellen, der dækker et sæt af relaterede enheder og relationer. At foreslå et Subject Area er en rettighed på Contributor-niveau og en af de mest direkte måder at påvirke, hvad standarden dækker. Subject Areas er også underlagt et krav om minimumsstøtte (quorum), hvilket forhindrer vedtagelse på baggrund af en enkelt deltager.

Skal jeg være Steering Member for at bidrage?

Nej. Contributor-medlemmer kan deltage i arbejdsgrupper, bidrage til dem, foreslå Subject Areas og deltage i konsensusafstemninger. Steering Membership tilføjer styringsrettigheder såsom strategisk retning, berettigelse til styrekomitéen og den formelle stemme til at vedtage indhold som en del af CIM-standarden.

Hvordan forholder CIM sig til andre datastandarder?

CIM er en horisontal, tværindustriel model med fokus på fælles forretningsenheder, i modsætning til domænespecifikke kanoniske modeller som energisektorens Common Information Model (IEC 61970/61968) eller sundhedsvæsenets HL7 FHIR. Dens formatneutrale design gør det muligt at komplementere, snarere end at erstatte, de native modeller i de systemer, du allerede kører.

Hvorfor er formatneutralitet vigtig for adoption?

Fordi det gør det muligt for teams med forskellige teknologistakke — relationelle datavarehuse, grafdatabaser og API-tjenester — at bruge én kanonisk definition i stedet for at vedligeholde divergerende skemaer. Afvejningen er, at oversættelsesværktøjer skal vedligeholdes, og at round-tripping mellem formater ikke altid er tabsfrit, så teams bør validere kortlægninger i forhold til deres faktiske integrationsbehov.

Yderligere læsning

• Working group — Wikipedia
• Linux Foundation — Wikipedia