Cloud Information Model

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

Viktige takeaways

• CIM er en åpen, applikasjonsagnostisk datamodell – et delt vokabular av forretningskonsepter (kunder, ordrer, produkter og så videre) som lar ulike sky- og lokale systemer utveksle data uten skreddersydd punkt-til-punkt-kartlegging.
• Den eksisterer for å løse et spesifikt, kostbart problem: hver applikasjon leveres med sin egen datamodell, så integrasjonsteam ender opp med å skrive og vedlikeholde tilpasset oversettelseskode som er skjør og bremser innovasjonen.
• Den styres som en åpen standard, produsert av et konsortium og utgitt som åpen kildekode under Joint Development Foundation, en del av Linux Foundation – slik at alle kan bidra, gjennomgå og ta den i bruk.
• Innholdet er organisert i emneområder (domener), der hvert område representerer et viktig forretningskonsept, med design publisert i flere formater, inkludert eksempeldiagrammer.
• CIM er en modell, ikke et produkt. Den definerer mening og struktur; du velger fortsatt selv hvordan du vil kartlegge, lagre og flytte data i dine egne systemer.

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 personlig engasjement til kunder på tvers av alle kanaler, tar mange selskaper i bruk flere skybaserte 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 en del av Joint Development Foundation (under Linux Foundation) er CIM åpen kildekode, og vi ønsker alle bidragsytere velkommen.

Hvorfor applikasjonsspesifikke datamodeller bryter sammen

Kjerneproblemet CIM adresserer er ikke at en enkelt applikasjon har en dårlig datamodell. De fleste er helt rimelige innenfor sine egne grenser. Problemet er den kombinatoriske eksplosjonen som skjer når man kobler sammen mange av dem.

Tenk på en typisk bedriftsstabel: en CRM, en ERP, en plattform for markedsføringsautomatisering, en supportdesk, et datavarehus og en håndfull SaaS-verktøy for forretningslinjer. Hvis hvert system har sin egen forestilling om “kunde”, “konto”, “ordre” og “produkt”, krever hvert par av systemer som trenger å dele data sin egen kartlegging. Antall integrasjoner vokser omtrent med kvadratet av antall systemer, og hver kartlegging er et lite, udokumentert og ueiid stykke logikk som noen må vedlikeholde for alltid.

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

Symptomene er kjent for alle som har drevet med integrasjon:

• Semantisk drift. “Kunde” i CRM-systemet betyr en faktureringsenhet; i supportdesken betyr det en person som oppretter saker. Det samme ordet, to betydninger, stille forent av en kartlegging ingen husker å ha skrevet.
• Skjøre rørledninger. En leverandør gir nytt navn til et felt eller endrer en enum, og en ETL-jobb feiler klokken 02.00 fordi kartleggingen var hardkodet mot den gamle strukturen.
• Duplisert innsats. To team bygger uavhengig av hverandre nesten identiske oversettelser mellom de samme to systemene fordi det ikke finnes noen delt referanse å peke på.
• Leverandørlåsing via data. Det er dyrt å migrere fra en plattform, ikke på grunn av programvaren, men på grunn av den akkumulerte oversettelseslogikken knyttet til skjemaet.

En delt, applikasjonsagnostisk modell angriper grunnårsaken: i stedet for N-til-N-kartlegginger, kartlegger hvert system én gang til en felles modell, og den felles modellen bærer betydningen.

Hva “applikasjonsagnostisk” faktisk betyr

Det er verdt å være presis om designfilosofien, fordi “agnostisk” ofte brukes løst.

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

En applikasjonsagnostisk modell er ikke eid av, eller optimalisert for, noen enkelt leverandørs produkt. Den beskriver forretningskonsepter i termer som vil være gjenkjennelige for en domeneekspert – en kunde, en ordre, et produkt, en lokasjon – i stedet for i termer som speiler en applikasjons interne tabeller. Denne nøytraliteten er det som gjør den til et nyttig nav: ingen deltaker trenger å adoptere en konkurrents verdensbilde for å kunne samhandle.

Dette er det samme arkitektoniske instinktet bak andre nøytrale utvekslingsstandarder. Akkurat som Resource Description Framework (RDF) og schema.org gir nettet et delt vokabular for å beskrive ting, og akkurat som EDI og senere UBL (Universal Business Language, en OASIS-standard) ga forsyningskjeder et delt format for transaksjoner, har CIM som mål å gi bedriftsapplikasjoner et delt vokabular for deres kjerneforretningsenheter. Forskjellen er omfang og modernitet: CIM retter seg mot den tilkoblede, API-drevne verdenen med både sky- og lokale løsninger, snarere enn utveksling av batch-filer.

En nyttig mental modell er mønsteret for kanonisk datamodell fra bedriftsintegrasjon, popularisert i Gregor Hohpe og Bobby Woolfs Enterprise Integration Patterns. CIM er i praksis en samarbeidsvedlikeholdt kanonisk modell – “navet” i en hub-and-spoke-integrasjonstopologi – men en som er åpen, versjonert og delt på tvers av organisasjoner i stedet for å være oppfunnet privat innad i ett selskap.

Hvordan CIM er organisert: Emneområder og domener

Samarbeidsdefinert innhold er organisert i domener, eller emneområder. Hvert emneområde representerer et viktig 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.

I praksis betyr dette at du bør tenke på CIM som et bibliotek av relaterte modeller snarere enn et enkelt monolitisk skjema. Typiske fagområder grupperer seg rundt gjenkjennelige forretningsmessige behov – for eksempel parter og kontoer, produkter og kataloger, ordrer og transaksjoner, og relasjonene som knytter dem sammen. Fordi hvert område publiseres med diagrammer og maskinlesbare definisjoner, kan forskjellige team ta i bruk ulike områder til ulike tider uten å vente på at hele modellen skal være komplett.

Noen få praktiske implikasjoner følger av denne strukturen:

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

• Adopter inkrementelt. Du trenger ikke å kartlegge hele virksomheten til CIM på dag én. Begynn med fagområdet som er mest problematisk – vanligvis kunde- eller ordredomenet – og utvid derfra.
• Utvid heller enn å forgrene (fork). Når CIM mangler et konsept du trenger, er den åpne modellen designet for å utvides. Å bidra med en utvidelse tilbake er å foretrekke fremfor å vedlikeholde en privat forgrening, fordi en forgrening driver fra hovedmodellen og mister interoperabilitetsfordelen.
• Behandle diagrammer som dokumentasjon, ikke som kilden til sannhet. Eksempeldiagrammene er for mennesker; de maskinlesbare definisjonene er det verktøyene dine skal konsumere.

CIM i integrasjonslandskapet: Hvordan velge

CIM er ett alternativ blant flere for å temme integrasjonskompleksitet. For å velge riktig må verktøyet samsvare med problemet. Tabellen nedenfor kontrasterer hovedtilnærmingene en virksomhetsdataarkitekt vanligvis veier opp mot hverandre.

Tilnærming	Hva det er	Best når	Hovedavveining
Punkt-til-punkt-kartlegging	Egendefinert kode som oversetter direkte mellom to systemer	Kun to systemer, stabile skjemaer, kort tidshorisont	Skalerer ikke; N-til-N eksplosjon; skjørt
Kanonisk modell (f.eks. CIM)	En delt, nøytral modell som hvert system kartlegges til én gang	Mange systemer, på tvers av leverandører, langvarig integrasjon	Arbeid med modellering på forhånd; styring (governance) nødvendig
Leverandør iPaaS-kontakter	Forhåndsbygde kontakter fra en integrasjonsplattform	Vanlige SaaS-par, hastighet over kontroll	Kontaktspesifikk semantikk; potensiell innlåsing
Industristandarder for utveksling (EDI, UBL, HL7, etc.)	Domenespesifikke meldingsformater	Regulerte eller veletablerte vertikaler	Smalt omfang; ofte batch-orientert
Datavirtualisering / føderasjon	Spørring på tvers av kilder uten sentralisering	Analyse, primært lesetilgang	Løser ikke semantiske konflikter av seg selv

Beslutningsheuristikken er enkel: hvis du har mer enn en håndfull systemer som må være enige om betydningen av delte enheter, og disse systemene kommer fra forskjellige leverandører, betaler en kanonisk modell seg selv. Hvis du har to systemer og ingen planer om å legge til flere, er punkt-til-punkt greit. Hvis behovet ditt er rent analytisk og skrivebeskyttet, kan føderasjon være tilstrekkelig – men merk at føderasjon flytter det semantiske problemet i stedet for å løse det.

CIM er et supplement til, ikke en erstatning for, verktøyene rundt. En ETL- eller ELT-pipeline (bygget med noe som Apache Airflow, dbt eller en kommersiell plattform) står fortsatt for flyttingen; CIM definerer hva dataene betyr når de ankommer. En meldingsmegler som Apache Kafka står fortsatt for transporten; CIM definerer formen på hendelsene. Modellen er kontrakten; verktøyene er rørleggerarbeidet.

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

Styring, lisensiering og hvorfor stiftelsen er viktig

CIM er åpen kildekode som en del av Joint Development Foundation, som opererer under Linux Foundation. Dette er ikke en triviell detalj – det er sentralt for hvorfor en virksomhet trygt kan bygge på CIM.

Linux Foundation er et veletablert nøytralt hjem for samarbeidende åpen kildekode-prosjekter, og Joint Development Foundation gir en lettvint juridisk struktur for å utvikle standarder og spesifikasjoner i fellesskap. At CIM huser der betyr:

• Nøytralt forvalterskap. Ingen enkeltleverandør kontrollerer modellen, så å ta den i bruk betyr ikke at man adopterer en konkurrents veikart.
• Åpne bidrag. Alle – leverandører, virksomheter, individuelle bidragsytere – kan foreslå endringer, og prosessen er gjennomsiktig.
• Forutsigbar lisensiering. Spesifikasjoner hostet av stiftelsen har vanligvis vilkår designet for bred, royalty-vennlig adopsjon, noe som er enormt viktig for juridiske team og innkjøpsavdelinger som evaluerer en standard.

For en arkitekt som argumenterer for dette internt, er denne styringshistorien ofte like viktig som det tekniske innholdet. “Det er en åpen standard under Linux Foundation” besvarer spørsmålene som ofte hindrer adopsjon av standarder: Hvem kontrollerer den? Hva skjer hvis en leverandør trekker seg? Kan vi bidra med våre egne utvidelser?

Komme i gang: En praktisk adopsjonsvei

Å ta i bruk en delt modell er like mye en organisatorisk som en teknisk øvelse. En pragmatisk sekvens ser slik ut:

1. Kartlegg de delte enhetene dine. Identifiser forretningskonseptene som forekommer i mer enn ett system – vanligvis kunde, produkt, ordre og lokasjon. Dette er dine kandidater.
2. Velg ett fagområde og én integrasjon. Velg integrasjonen med høyest smerte og lavest risiko («blast radius») for å bevise modellen. En enkelt rapporteringspipeline eller onboarding av én ny applikasjon er ideelt.
3. Kartlegg hvert system til CIM én gang. Bygg oversettelsen fra hvert kildesystem til CIM-representasjonen, og fra CIM til hvert mål. Motstå trangen til å kartlegge system-til-system direkte.
4. Dokumenter utvidelsene dine. Der CIM ikke dekker et konsept, registrer utvidelsen eksplisitt og vurder å bidra med den tilbake.
5. Etabler eierskap. En kanonisk modell uten en forvalter forfaller. Tildel et team eller en rolle som er ansvarlig for kartleggingene og for å spore endringer oppstrøms.
6. Versjoner og test. Behandle modellen og dens kartlegginger som versjonerte artefakter med tester, nøyaktig slik du ville gjort med applikasjonskode.

Den vanligste feilmodusen er å behandle CIM som en engangsmodelleringsøvelse i stedet for en levende kontrakt. Organisasjonene som lykkes, behandler modellen slik de behandler et API: versjonert, testet, eid og utviklet bevisst.

Partnere som bidrar til CIM

CIM er et konsortiumarbeid, og verdien vokser med deltakelse. Partnere bidrar med innhold til fagområder, vurderer forslag og bidrar til å forme retningen for modellen. Fordi arbeidet er åpent, er bidrag ikke begrenset til store leverandører – bedrifter med reelle integreringsutfordringer og individuelle utøvere med domeneekspertise er like velkomne.

Ta kontakt

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

Vanlige spørsmål

Hva er Cloud Information Model (CIM)?

CIM er en applikasjonsagnostisk datamodell med åpen kildekode som gir et delt, standardbasert vokabular for forretningskonseptene bedrifter trenger å utveksle på tvers av sky- og lokale applikasjoner. Den er produsert av et åpent konsortium og huser under Joint Development Foundation, en del av Linux Foundation. Formålet er å redusere den tilpassede kartleggingskoden som skjøre punkt-til-punkt-integrasjoner krever.

Er CIM et produkt eller en spesifikasjon?

CIM er en spesifikasjon – en modell og et sett med definisjoner – ikke et kjørbart produkt. Den definerer betydningen og strukturen til delte enheter; du velger fortsatt dine egne ETL/ELT-verktøy, meldingsmeglere og lagring. Tenk på det som kontrakten som integrasjonsinfrastrukturen implementerer, snarere enn selve infrastrukturen.

Hvordan er CIM forskjellig fra en leverandørs integrasjonsplattform?

En integreringsplattform (en iPaaS eller et koblingsbibliotek) flytter data og leverer ofte forhåndsbygde koblinger, men disse koblingene koder for leverandørspesifikk semantikk. CIM er nøytral og leverandøruavhengig, så den låser deg ikke til én plattforms verdensbilde. De to er komplementære: du kan bruke CIM som den kanoniske modellen i enhver integrasjonsplattform.

Hva er fagområder i CIM?

Fagområder (også kalt domener) er de organiserende enhetene i modellen, der hver representerer et viktig forretningskonsept som kunder, produkter eller bestillinger. Design publiseres i flere formater, inkludert eksempeldiagrammer, og settet med fagområder forventes å vokse etter hvert som konsortiet og samfunnet bidrar med mer innhold.

Kan vi utvide CIM hvis det ikke dekker konseptene våre?

Ja. CIM er designet for å kunne utvides, og fordi det er åpen kildekode under en nøytral stiftelse, kan du foreslå tillegg gjennom bidragsprosessen. Å utvide den delte modellen og bidra tilbake er sterkt å foretrekke fremfor å vedlikeholde en privat gaffel (fork), som vil avvike over tid og miste interoperabilitetsfordelen som motiverte adopsjonen av CIM i utgangspunktet.

Hvem bør ta i bruk CIM?

Det er mest verdifullt for organisasjoner som kjører mange applikasjoner fra forskjellige leverandører som må bli enige om betydningen av delte enheter – den klassiske situasjonen for bedriftsdataarkitekter og integrasjonsingeniører. Applikasjons- og plattformleverandører drar også nytte av å samkjøre skjemaene sine med en nøytral modell, noe som gjør produktene deres enklere for kundene å integrere. Hvis du bare har to stabile systemer, kan enklere punkt-til-punkt-kartlegging være tilstrekkelig.

Videre lesing

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia