Resurssit

sivu on aloituspiste kaikille, jotka haluavat ymmärtää, ottaa käyttöön tai osallistua pilvitietomallin (Cloud Information Model, CIM) kehittämiseen. CIM on avoimen lähdekoodin, sovellusagnostinen tietomalli – jota hallinnoi The Linux Foundation –, joka määrittelee liiketoimintayksiköiden jaetun sanaston, jotta pilvi- ja on-premises-järjestelmät voivat vaihtaa tietoja ilman, että jokainen integraatiotiimi keksii uudelleen oman skeemansa. Tälle sivulle on koottu artefaktit, joita tarvitset CIM:n arvioimiseen, sen tukemat muodot, arkistot, joissa mallit sijaitsevat, sekä kanavat osallistumiseen.

Keskeiset huomiot

• CIM on jaettu, toimittajaneutraali tietomalli, ei tuote tai tietokanta – se kuvaa entiteettejä, attribuutteja ja suhteita, joihin useat sovellukset voivat yhdistää.
• Ensisijaiset tekniset resurssit sijaitsevat CIM GitHub -organisaatiossa, jossa mallin määritelmät ja työkalut on versioitu ja lisensoitu avoimesti.
• CIM ilmaistaan useissa vakiomuodoissa, jotta eri työkaluketjut voivat käyttää sitä sen sijaan, että lukittautuisit yhteen sarjoitukseen.
• Esittely-, UKK- ja uutissivut ovat nopein tapa rakentaa liiketoimintaperustelu ja vastata sidosryhmien kysymyksiin ennen teknistä syväsukellusta.
• Osallistuminen tapahtuu GitHub-arkistojen ja kontribuuttoreiden verkkolomakkeen kautta; malli kehittyy yhteisön arvioinnin, ei yhden toimittajan tiekartan perusteella.

Mikä pilvitietomalli oikeastaan on

CIM ymmärretään parhaiten kanonisena mallina: neutraalina, sovittuna esityksenä liiketoimintakonsepteista – asiakkaista, tileistä, tilauksista, tuotteista, yhteystiedoista ja niiden välisistä suhteista –, joka sijaitsee jo käyttämiesi järjestelmien välissä. Sen sijaan, että pakottaisit jokaisen sovelluksen puhumaan kaikkien muiden sovellusten murretta, yhdistät jokaisen järjestelmän CIM:ään kerran, jolloin CIM:stä tulee vaihtopiste.

Tämä on sama arkkitehtoninen malli, joka on esiintynyt toistuvasti yritysintegraatiossa: hub-and-spoke-kanoninen skeema pisteestä pisteeseen -kartoitusten verkon sijaan. Se liittyy käsitteellisesti ponnisteluihin, kuten OASIS Universal Business Language (UBL) asiakirjoille, Open Applications Group Integration Specification (OAGIS) liiketoimintaviestille ja schema.org verkkotason sanastoille. CIM:n erottuva painotus on, että se on sovellusagnostinen ja suunniteltu pilvi-plus-on-premises-todellisuuteen, jossa useimmat yritykset todellisuudessa toimivat.

Käytännön hyöty on kartoitushajaantumisen väheneminen. Jos sinulla on n järjestelmää ja jokaisen on keskusteltava jokaisen muun kanssa, kohtaat noin n² kartoitusta. Kanonisen mallin käyttöönotto vähentää työn määrän noin n kartoitukseen – yksi per järjestelmä jaettuun malliin. Tämä vähennys on keskeinen taloudellinen peruste CIM:n käyttöönotolle.

CIM-esitys

CIM-esitys on suositeltu aloitusartefakti kaikille, jotka rakentavat perusteluja sisäisesti. Se on suunniteltu esiteltäväksi sekalaiseen yleisöön – arkkitehdeille, tiedonhallintajohtajille ja liiketoimintasponsoreille – ja se kattaa jaetun mallin motivaation, CIM:n määrittelemän laajuuden sekä sen, miten se sopii olemassa olevaan integraatiomaisemaan.

Käytä sitä seuraavasti:

Aiheeseen liittyvä: Fivetran — Täysin hallittu ELT-putkisto, joka vain jatkaa käynnissä.

• Johtajille ja sponsoreille: aloita kartoitushajaantumisongelmalla ja toimittajaneutraaliusargumentilla. Esitys kehystää CIM:n riskin vähentämisenä, ei “rip-and-replace”-vaihtona.
• Arkkitehdeille ja insinööreille: käytä sitä kontekstin asettamiseen ja siirry sitten välittömästi GitHub-arkistoihin varsinaisia mallimääritelmiä varten.
• Hallinnon ja vaatimustenmukaisuuden sidosryhmille: käytä sitä avataksesi keskustelun omistajuudesta, versioinnista ja siitä, miten mallimuutoksia tarkastetaan.

Esitys on keskustelun avaaja, ei määrittely. Käsittele sitä ramppina ja arkistoja totuuden lähteenä.

CIM-muodot

CIM tukee tietoisesti useita standardeja ja muotoja yhden proprietäärisen sarjoituksen sijaan. Tällä on merkitystä, koska yritysten työkaluketjut ovat heterogeenisia: mallinnustyökalusi, ETL-alustasi, API-yhdyskäytäväsi ja dokumentaatiogeneraattorisi voivat kukin suosia eri esitystapaa.

Yleisesti asiaankuuluvia muotoperheitä tällä alueella ovat:

Jos olet ostoksilla: Boomi AtomSphere — Enterprise iPaaS hybridi pilvestä on-prem -integraatioon.

• Entiteetti-suhde- ja käsitteelliset merkinnät ihmisten tarkasteluun ja suunnittelutyöpajoihin.
• JSON-pohjaiset skeemaesitykset API- ja sovelluskäyttöön.
• RDF- ja ontologiatyyliset esitykset semanttisiin käyttötapauksiin ja tietograafeihin.
• Relaatio- ja taulukkokartoitukset tietovarasto- ja ETL-putkistoihin.

Suunnitteluperiaate on siirrettävyys: avoimessa muodossa esitetty malli voidaan muuntaa, vertailla (diff), versioida ja validoida vakiotyökaluilla. Kun arvioit CIM:ää organisaatiollesi, kysymys ei ole “mitä muotoa se käyttää?”, vaan “voinko kuljettaa mallini työkalujeni vaatimien muotojen läpi ilman hävikkiä?”. Jos muunnos poistaa hiljaa suhteen kardinaliteetin tai attribuuttirajoitukset, se on todellinen integraatioriski, joka kannattaa testata ajoissa.

Kuinka päättää, minkä muodon valita

Käytä tätä nopeana päätöksenteko-oppaana:

Jos ensisijainen kuluttaja on…	Suosi esitystapaa, joka…	Varo…
Sovellus-/API-kehittäjät	JSON-tyyliset skeemat	Suhteen semantiikan menetys tasaisessa JSONissa
Tietovarasto- / ETL-tiimit	Relaatio- tai taulukkokartoitukset	Monta-moneen-suhteet, jotka vaativat siltataulukoita
Tietograafi- / semanttikkitiimit	RDF/ontologia-esitykset	Työkalujen kypsyys ja kyselysuorituskyky
Suunnittelu- ja hallintotyöpajat	Käsitteellinen/ER-merkintä	Ajelehtiminen kaavion ja koneellisesti luettavan mallin välillä

Viimeinen rivi on yleisin vikatila: tiimit ylläpitävät kaunista kaaviota, joka ei enää vastaa versioitua mallia. Pidä kaavio generoituun arkiston artefakteihin perustuvana tai ainakin niiden kanssa synkronoituna.

CIM uutisissa

“CIM in the News” -osio kokoaa ulkoista näkyvyyttä – tiedotteita, analyytikoiden kommentteja ja yhteisön kirjoituksia – jotta näet, miten CIM otetaan vastaan projektin ulkopuolella. Tämä on hyödyllistä kahdesta syystä.

Ensinnäkin se tarjoaa kolmannen osapuolen vahvistuksen. Kun ehdotat yhteisen mallin käyttöönottoa, riippumattoman kattavuuden mainitseminen on vakuuttavampaa kuin hankkeen oman markkinoinnin viittaaminen. Toiseksi se tuo esiin tosielämän käyttöönotto-tarinoita ja integraatiomalleja, joita ydindokumentaatio ei välttämättä kata.

Lue uutisointi kriittisesti. Ilmoitukset kuvaavat usein tarkoitusta ja kumppanuutta pikemminkin kuin tuotantokäyttöön otettua käyttöä. Erota toisistaan “organisaatio X liittyi ponnisteluihin” ja “organisaatio X käyttää CIM:ää tuotannossa järjestelmälle Y”. Edellinen on yleistä; jälkimmäinen on todiste, jolla on merkitystä rakennetaanko vai adoptoidaanko (build-vs-adopt) -päätöksessä.

Aiheeseen liittyvä: Matillion — Push-down ELT rakennettu pilvitietovarastoihin.

CIM GitHub-organisaatio

GitHub-organisaatio on paikka, jossa varsinainen sisältö sijaitsee. Teknisille lukijoille tämä on tärkein kohde. Sieltä löydät:

• Mallimääritelmät — entiteetit, attribuutit, suhteet ja rajoitteet, jotka muodostavat CIM:n.
• Työkalut (Tooling) — skriptit ja apuohjelmat mallin artefaktien validointiin, muuntamiseen ja luomiseen.
• Versiointi ja historia — commit-historia, joka näyttää, kuinka malli on kehittynyt ja miksi.
• Issues- ja keskusteluosiot — ehdotusten, kysymysten ja päätösten työpöytäkirja.

Muutamat käytännön tavat tekevät arkistoista paljon hyödyllisempiä:

• Kiinnitä versio julkaisuun tai tagiin sen sijaan, että seuraisit oletushaaraa, jotta kartoituksesi eivät muutu projektin puolivälissä.
• Lue kiinnostavien entiteettien commit-historia ennen niiden käyttöönottoa. Kenttä, joka on muuttunut kolme kertaa vuodessa, viestii epävakaasta alueesta.
• Tarkista lisenssi jokaisesta arkistosta. Avoimen lähdekoodin projektit yhdistelevät joskus eri lisenssejä työkalujen ja mallisisällön välillä.
• Tee issue-ilmoitus epäselvyyksistä. Jos suhteen kardinaliteetti on epäselvä, se aiheuttaa ongelmia jokaiselle loppupään tiimille; asian nostaminen ajoissa parantaa mallia kaikille.

Jos organisaatiollasi on tiukat toimitusketju- tai alkuperävaatimukset, tarkastele arkistoja samalla tavalla kuin tarkastelisit mitä tahansa kolmannen osapuolen riippuvuutta: lisenssi, ylläpidon aktiivisuus, kontribuuttoreiden monimuotoisuus ja julkaisutahti. Malli, joka riippuu yhdestä ylläpitäjästä, on riskiprofiililtaan erilainen kuin malli, jolla on laaja organisaatiotuki.

Lukijan suosikki: Airbyte — Avoimen lähdekoodin ELT hallitulla pilvivaihtoehdolla.

Usein kysytyt kysymykset

Onko Cloud Information Model tuote, jonka voin ostaa?

Ei. CIM on avoimen lähdekoodin tietomalli – joukko määritelmiä ja tukevia artefakteja – jota hallinnoi The Linux Foundation. Otat sen käyttöön kartoittamalla järjestelmäsi siihen ja käyttämällä julkaistuja mallimääritelmiä; itse mallista ei peritä lisenssimaksua. Toimittajat voivat rakentaa tuotteita, jotka tukevat tai sisältävät CIM:n, mutta malli itsessään ei ole kaupallinen tarjous.

Pitääkö minun korvata nykyiset järjestelmäni käyttääkseni CIM:ää?

Ei, ja juuri siinä on pointti. CIM on suunniteltu toimimaan järjestelmien välillä kanonisena vaihtomallina. Säilytät sovelluksesi, tietokantasi ja tietovarastosi ja rakennat kartoitukset jokaisesta järjestelmästä CIM:iin. Tämä on inkrementaalista: voit aloittaa yhdestä korkean arvon integraatiosta ja laajentaa kattavuutta ajan myötä.

Mitä muotoa minun tulisi käyttää CIM:n hyödyntämiseen?

Se riippuu kuluttajasta. API- ja sovellustiimit suosivat yleensä JSON-tyylisiä skeemaesityksiä; tietovarasto- ja ETL-tiimit suosivat relaatio- tai taulukkomappauksia; semanttiset ja tietograafitiimit suosivat RDF/ontologia-esityksiä. Tärkein testi on häviötön kiertokulku (lossless round-tripping) – varmista, että muuntaminen muotojen välillä säilyttää suhteet ja rajoitteet ennen sitoutumista.

Miten CIM liittyy muihin standardeihin, kuten UBL:ään tai OAGIS:iin?

Ne kattavat vierekkäiset ongelma-alueet. UBL ja OAGIS keskittyvät voimakkaasti osapuolten välisiin liiketoiminta-asiakirjoihin ja viesteihin, kun taas CIM korostaa jaettua entiteettimallia, johon sovellukset kartoitetaan. Käytännössä ne voivat täydentää toisiaan: kanoninen entiteettimalli voi ohjata sitä, miten täytät asiakirjastandardit. Arvioi päällekkäisyydet omiin käyttötapauksiisi nähden sen sijaan, että oletat toisen korvaavan toisen.

Kuinka voin osallistua CIM:n kehittämiseen?

Osallistuminen tapahtuu ensisijaisesti CIM GitHub-organisaation kautta – issues-ilmoitusten, pull-pyyntöjen ja keskustelujen muodossa – sekä tältä sivustolta linkitetyn kontribuuttorilomakkeen kautta. Koska mallia hallinnoidaan yhteisöllisesti, ehdotukset tarkastetaan avoimesti. Aloita pienestä: selvennä epäselvää määritelmää tai lisää puuttuva attribuutti selkeällä perustelulla, ja keskustele ylläpitäjien kanssa ennen suurten rakenteellisten muutosten ehdottamista.

Mistä ei-teknisen sidosryhmän tulisi aloittaa?

Aloita CIM-esityksestä ja UKK-osiosta, ja selaa sitten “CIM in the News” -osiota saadaksesi kolmannen osapuolen kontekstia. Nämä antavat motivaation ja sanaston ilman, että sinun tarvitsee lukea mallimääritelmiä. Tuo tekninen tiimi mukaan, kun sinulla on ehdokas integraatio pilotointiin, ja anna heidän työskennellä GitHub-arkistojen kanssa.

Osallistuminen ja lisälukemista

Yhteisen mallin käyttöönotto on yhtä paljon organisatorinen kuin tekninen ponnistus. Menestyneimmät CIM-aloitteet alkavat yleensä yhdestä, hyvin rajatusta integraatiosta – sellaisesta, jossa kaksi järjestelmää vaatii tällä hetkellä hauraita räätälöityjä kartoituksia – todistavat kanonisen mallin lähestymistavan toimivuuden ja laajenevat sitten. Hallinto on tärkeää: päätä ajoissa, kuka omistaa sisäiset CIM-kartoituksesi, miten malliversioiden päivitykset hoidetaan ja miten liiketoimintamääritelmien väliset ristiriidat ratkaistaan.

Taustatietoja hallinnosta ja avoimesta ohjauksesta löytyy Linux Foundation -sivulta Wikipediasta. Aiheeseen liittyvistä standardointityöistä OASIS Universal Business Language ja schema.org ovat hyödyllisiä vertailukohtia kanonisten mallien lähestymistapoja vertailtaessa. Syvällisempää tietoa semanttisesta mallinnuksesta varten World Wide Web Consortium (W3C) julkaisee RDF- ja OWL-spesifikaatiot, jotka muodostavat ontologiatyylisten esitysten pohjan.

Käytä tämän sivuston navigointia päästäksesi esitykseen, UKK-osioon, formaattidokumentaatioon, uutiskatsaukseen ja GitHub-arkistoihin – ja käytä kontribuuttorilomaketta, kun olet valmis osallistumaan mallin muotoiluun.