Cloud Information Model

Velkommen til CIM, en applikasjonsagnostisk datamodell som forenkler integrasjon og akselererer innovasjon.

Viktige takeaways

• CIM er en delt, åpen datamodell, ikke et produkt. Den definerer felles forretningskonsepter og deres relasjoner slik at ulike applikasjoner kan utveksle data uten skreddersydde engangskartlegginger.
• Den styres som en åpen standard. CIM er åpen kildekode under Joint Development Foundation, en del av Linux Foundation, og ønsker bidragsytere velkommen fra leverandører, bedrifter og det bredere miljøet.
• Innholdet er organisert i emneområder (domener). Hvert domene representerer et sentralt forretningskonsept og publiseres i flere formater, inkludert diagrammer, slik at arkitekter og ingeniører kan ta det i bruk trinnvis.
• Kjerneverdien er å redusere integrasjonsskjørhet. En kanonisk modell erstatter punkt-til-punkt-oversettelseskode med et stabilt mål som mange systemer kan kartlegges til og fra.
• Adopsjon er en designbeslutning, ikke en bryter. Du velger hvilke domener du vil ta i bruk, hvordan du skal kartlegge kildesystemene dine, og hvordan du skal styre utvidelser over tid.

En ny standard for datainteroperabilitet

CIM er produsert av et åpent konsortium dannet for å levere en standardbasert løsning for å koble sammen bedriftsprodukter. Med CIM kan du skape sømløse og skreddersydde personlige opplevelser på tvers av skybaserte applikasjoner.

For å akselerere digital transformasjon og levere personlige engasjementer til kunder på tvers av alle kanaler, tar mange selskaper i bruk flere sky- og lokale applikasjoner. Hver av disse kommer med sin egen datamodell, noe som tvinger utviklere til å bygge, teste og administrere tilpasset kode som er nødvendig for å kartlegge og oversette data på tvers av ulike systemer. I stedet for å akselerere digital transformasjon, bremser denne prosessen innovasjon og fører til skjøre integrasjoner.

CIM er en moderne, åpen spesifikasjon for å lette smerten ved å integrere data. CIM gir en definert standard for å kommunisere enkelt mellom ulike dataformater. Som åpen kildekode under Joint Development Foundation (under Linux Foundation), ønsker vi alle bidragsytere velkommen.

Problemet CIM adresserer er strukturelt, ikke tilfeldig. Når hvert system snakker sin egen dialekt – ett kaller en kunde en «Contact», et annet en «Party», et tredje en «Account» – ender integrasjonsteamene opp med å vedlikeholde et voksende nett av parvise kartlegginger.

Hver ny applikasjon multipliserer antall oversettelser som kreves, og hver skjemaendring i et enkelt system kan forplante seg og bryte nedstrøms rørledninger. En kanonisk modell endrer formen på dette problemet: i stedet for at N systemer kartlegges mot hverandre, kartlegges hvert system én gang til et delt vokabular.

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

Hvorfor punkt-til-punkt-integrasjon bryter sammen

Det hjelper å være konkret om feilmodusene som motiverer en delt modell.

• Kombinatorisk vekst. Med punkt-til-punkt-kartlegginger vokser antallet oversettelsesveier omtrent med kvadratet av antall systemer. Å legge til en tiende applikasjon er langt dyrere enn å legge til den andre.
• Semantisk drift. To team kan begge «kartlegge kunden» og fortsatt være uenige om en kunde er en person, en organisasjon eller et faktureringsforhold. Dataene flyter, men betydningen divergerer.
• Skjør endringsadministrasjon. En navneendring av et felt eller en ny obligatorisk attributt i ett kildesystem tvinger frem endringer hos alle forbrukere som berører det.
• Duplisert logikk. Regler for validering, deduplisering og identitetsoppløsning implementeres på nytt i hver integrasjon i stedet for å defineres én gang.
• Press om leverandørlåsing. Når integrasjonslogikken er sammenvevd med en spesifikk leverandørs skjema, blir bytte av eller tilføying av leverandører et re-plattformprosjekt.

En kanonisk modell som CIM eliminerer ikke kartleggingsarbeid – hvert kildesystem trenger fortsatt en kartlegging til modellen. Det den eliminerer, er multiplikasjonen av dette arbeidet. Du bygger én kartlegging per system til den delte modellen, og modellen selv utgjør den stabile kontrakten mellom dem.

Hvordan CIM er organisert: Emneområder

Samarbeidsdefinert innhold er organisert i domener, eller emneområder. Hvert emneområde representerer et sentralt forretningskonsept. CIM-designene er tilgjengelige i flere formater for hvert domene, inkludert eksempeldiagrammer. Antallet og omfanget av emneområdene vil vokse i takt med konsortiet og bidragene.

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

Denne domeneorienterte strukturen er viktig for adopsjon. Du trenger sjelden hele modellen på en gang. En typisk bedrift starter med domenene som berører dens mest problematiske integrasjon, beviser tilnærmingen og utvider deretter. Vanlige utgangspunkt er ofte konseptene som forekommer i nesten alle systemer:

• Party / Kunde — menneskene og organisasjonene du gjør forretninger med, og rollene de spiller.
• Produkt — hva du selger, tilbyr eller administrerer, inkludert kataloger og klassifiseringer.
• Konto og relasjon — hvordan parter forholder seg til produkter, kontrakter og hverandre.
• Interaksjon og aktivitet — hendelsene, transaksjonene og engasjementene som forbinder ovennevnte.

Fordi hvert emneområde publiseres med diagrammer og flere representasjonsformater, kan arkitekter gjennomgå den konseptuelle modellen, ingeniører kan bruke en maskinlesbar form, og forretningsinteressenter kan validere at konseptene samsvarer med virkeligheten. Denne multiformattilnærmingen er et bevisst designvalg: en modell som bare ingeniører kan lese, har en tendens til å avvike fra den forretningsmessige betydningen.

Hvordan CIM sammenlignes med andre tilnærminger

CIM er ett alternativ blant flere for å oppnå interoperabilitet. Å velge riktig betyr å forstå avveiningene.

Tilnærming	Hva det er	Styrker	Avveininger
Punkt-til-punkt-kartlegging	Direkte oversettelser mellom hvert par av systemer	Enkelt for to systemer; ingen delt styring nødvendig	Vokser kombinatorisk; skjør; duplisert logikk
Kanonisk modell (CIM-stil)	Et delt, applikasjonsagnostisk vokabular som hvert system kartlegges til	Lineær kartleggingsinnsats; stabil kontrakt; gjenbrukbar på tvers av prosjekter	Krever styring og enighet; kartlegging fortsatt nødvendig per system
Bransjedatastandarder	Vertikale standarder for en spesifikk sektor (f.eks. helsevesen, finans)	Dyp domenedekning; regulatorisk samsvar	Smalt omfang; dekker kanskje ikke tverrbransjebaserte bedriftskonsepter
Leverandørdatamodeller	En plattforms native skjema eksponert som integrasjonshub	Tett verktøyintegrasjon; raskt innenfor én leverandørs økosystem	Innlåsningsrisiko; andre leverandører må rette seg etter én parts modell
API-først / schema-on-read	Kontrakter definert per API; betydning avklares ved forbrukstidspunkt	Fleksibel; rask å starte	Semantisk konsistens avhenger av disiplin; vanskeligere å styre i stor skala

Den praktiske veiledningen: bruk en kanonisk modell når du har mange systemer, konsepter på tvers av domener og et langvarig integrasjonslandskap. Bruk punkt-til-punkt når omfanget genuint er to systemer og kortvarig. Bransjestandarder og CIM er komplementære – en vertikal standard kan informere et domene, mens CIM gir det tverrgående bedriftsvokabularet.

Hvordan ta i bruk CIM i praksis

Adopsjon er en sekvens av bevisste beslutninger snarere enn en enkelt migrasjon. Et fungerende mønster ser slik ut:

1. Velg en smertefull, godt avgrenset integrasjon. Velg et domene der kartleggingssmerten er reell og omfanget er lite nok til å bevise verdien raskt.
2. Kartlegg kildesystemene og deres skjemaer. Dokumenter hva hvert system kaller konseptene i ditt valgte fagområde, og hvor de er uenige.
3. Kartlegg hvert system til CIM-domenet. Bygg én kartlegging per system til den delte modellen. Behandle disse kartleggingene som versjonerte artefakter, ikke engangsskript.
4. Definer utvidelsespolicyen din på forhånd. Bestem hvordan du vil håndtere konsepter som CIM ikke dekker ennå – utvidelser bør dokumenteres, navngis konsekvent og foreslås tilbake til konsortiet der de er bredt nyttige.
5. Etabler styring. Tildel eierskap for kartleggingene, en gjennomgangsprosess for endringer og en kadens for synkronisering med oppstrøms CIM-oppdateringer.
6. Utvid domene for domene. Gjenbruk kartleggingsmønstrene og styringen fra det første domenet for å redusere kostnadene for det neste.

To forbehold er verdt å nevne tydelig. For det første legger en kanonisk modell til et lag – det er ikke gratis, og gevinsten kommer fra gjenbruk på tvers av mange integrasjoner, ikke fra en enkelt. For det andre er kartlegging der det virkelige arbeidet ligger; modellen gir deg et stabilt mål, men noen må fortsatt bestemme hvordan hvert kildefelt tilsvarer det, og den beslutningen drar nytte av forretningsmessig input, ikke bare ingeniørarbeid.

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

Styring, lisensiering og bidrag

CIM er åpen kildekode som en del av Joint Development Foundation, som opererer under Linux Foundation. Denne strukturen er viktig for bedrifter som evaluerer den: Linux Foundation er et veletablert hjem for samarbeidende, leverandørnøytrale åpen kildekode-prosjekter, og Joint Development Foundation gir et juridisk rammeverk spesielt utviklet for å utvikle og drive standarder og spesifikasjonsprosjekter.

For en bedriftsdataarkitekt er de praktiske implikasjonene av denne styringsmodellen:

• Leverandørnøytralitet. Ingen enkeltleverandør kontrollerer spesifikasjonen, noe som reduserer risikoen for at modellen er utformet for å favorisere én plattform.
• Åpne bidrag. Alle kan foreslå endringer, noe som betyr at modellen kan utvikles for å reflektere virkelige integrasjonsbehov snarere enn et enkelt veikart.
• Spesifikasjonsorientert prosess. Joint Development Foundation-modellen er bygget rundt å produsere og vedlikeholde spesifikasjoner, noe som samsvarer med hvordan standarder blir vedtatt og referert til i anskaffelser og arkitekturgjennomganger.

Bidrag oppmuntres og er åpne for alle. Bidrag har typisk form av nye eller raffinerte fagområder, rettelser og presiseringer, eksempeldiagrammer og tilbakemeldinger fra reelle integrasjonsprosjekter. De mest verdifulle bidragene kommer ofte fra praktikere som har støtt på et spesifikt kartleggingsproblem og kan beskrive konseptet som løser det.

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

Bli involvert

Er du interessert i å bli med i CIM-initiativet? Flott! Send oss gjerne en e-post for mer informasjon.

Utover e-post er de naturlige måtene å engasjere seg på å gå gjennom de publiserte fagområdene for ditt interessedomene, prøve å kartlegge et av systemene dine til et domene, og bringe hullene du finner tilbake til fellesskapet. Fordi antallet og omfanget av fagområder vokser med konsortiet og bidragene, forbedres modellen proporsjonalt med hvor mange reelle integrasjonsproblemer brukerne bringer til den.

Vanlige spørsmål

Hva er egentlig Cloud Information Model?

CIM er en applikasjonsagnostisk, åpen datamodell som definerer vanlige forretningskonsepter og deres relasjoner slik at forskjellige applikasjoner kan utveksle data gjennom et delt vokabular. Den er produsert av et åpent konsortium og publisert som en åpen spesifikasjon. I stedet for å være et produkt du installerer, er det en modell du kartlegger systemene dine til.

Hvem er CIM for?

Den er rettet mot bedriftsdataarkitekter, integrasjons- og ETL-ingeniører, applikasjons- og plattformleverandører og bidragsytere til åpen kildekode. Alle som må koble sammen flere sky- og lokale systemer med ulike skjemaer er en potensiell bruker. Leverandører drar nytte av at en delt modell reduserer det tilpassede arbeidet som kreves for å integrere med produktene deres.

Hvordan styres og lisensieres CIM?

CIM er åpen kildekode som en del av Joint Development Foundation, som opererer under Linux Foundation. Dette gir et leverandørnøytralt, spesifikasjonsorientert styringsrammeverk. Denne strukturen er ment å holde modellen åpen for bidrag og uavhengig av en enkelt leverandørs kontroll.

Hvordan skiller CIM seg fra en leverandørs native datamodell?

En leverandørs native modell er optimalisert for den leverandørens produkt og økosystem; å adoptere den som din integrasjonshub har en tendens til å skape leverandørlåsing. CIM er designet for å være applikasjonsagnostisk, slik at ingen enkeltplattform definerer vokabularet. Avveiningen er at CIM krever styring og enighet på tvers av team, mens en leverandørmodell er klar til bruk innenfor den leverandørens verktøy.

Må jeg fortsatt skrive mappinger hvis jeg bruker CIM?

Ja. Hvert kildesystem trenger fortsatt en mapping til den delte modellen. Fordelen er at du skriver én mapping per system til CIM i stedet for en separat oversettelse for hvert systempar. Dette gjør kombinatorisk mapping-innsats til omtrent lineær innsats og gir deg en stabil kontrakt som overlever endringer i individuelle systemer.

Hvordan begynner jeg å ta i bruk CIM?

Start med en enkelt, smertefull og godt avgrenset integrasjon i ett fagområde. Kartlegg kildeskjemaene, map hvert system til CIM-domenet, definer en utvidelses- og styringspolicy, og behandle mappingene som versjonerte artefakter. Når det første domenet beviser sin verdi, utvider du domene for domene, og gjenbruker mønstrene og styringen du etablerte.

Videre lesing

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia