Cloud Information Model

CIM on avoimen lähdekoodin projekti Joint Development Foundationin alaisuudessa, joka on osa Linux Foundationia, ja se toivottaa tervetulleiksi toimittajat, yritykset ja laajemman yhteisön.

• Sisältö on järjestetty aihealueisiin (domainit). Jokainen domain edustaa merkittävää liiketoimintakonseptia ja se julkaistaan useissa muodoissa, mukaan lukien kaaviot, jotta arkkitehdit ja insinöörit voivat ottaa sen käyttöön asteittain.
• Ydinarvo on integraation haurauden vähentäminen. Kanoninen malli korvaa pisteestä pisteeseen -käännöskoodin vakaalla kohteella, johon monet järjestelmät voivat kartoittaa tietoja ja josta ne voivat niitä hakea.
• Käyttöönotto on suunnittelupäätös, ei kytkin. Valitset itse, mitkä domainit otetaan käyttöön, miten lähdejärjestelmät kartoitetaan ja miten laajennuksia hallinnoidaan ajan myötä.

Uusi standardi tietojen yhteentoimivuudelle

CIM:ää tuottaa avoin konsortio, joka on muodostettu tarjoamaan standardipohjainen ratkaisu yritystuotteiden yhdistämiseen. CIM:n avulla voit luoda saumattomia ja räätälöityjä henkilökohtaisia kokemuksia pilvinatiivissa sovelluksissa.

Kiihdyttääkseen digitaalista transformaatiota ja tarjotakseen henkilökohtaisia kokemuksia asiakkaille kaikissa kanavissa, monet yritykset käyttävät useita pilvi- ja on-premise-sovelluksia. Jokaisella on oma tietomallinsa, mikä pakottaa kehittäjät rakentamaan, testaamaan ja hallitsemaan mukautettua koodia, jota tarvitaan tietojen kartoittamiseen ja kääntämiseen eri järjestelmien välillä. Digitaalisen transformaation kiihdyttämisen sijaan tämä prosessi hidastaa innovaatioita ja johtaa hauraisiin integraatioihin.

CIM on moderni, avoin spesifikaatio, joka helpottaa tietojen integroinnin aiheuttamaa vaivaa. CIM tarjoaa määritellyn standardin helpoon viestintään eri tietomuotojen välillä. Avoinna osana Joint Development Foundationia (Linux Foundationin alaisuudessa), toivotamme kaikki osallistujat tervetulleiksi.

Ongelma, jonka CIM ratkaisee, on rakenteellinen, ei satunnainen. Kun jokainen järjestelmä puhuu omaa murrettaan – yksi kutsuu asiakasta “yhteyshenkilöksi” (Contact), toinen “osapuoleksi” (Party), kolmas “tiliksi” (Account) – integraatiotiimit päätyvät ylläpitämään kasvavaa parikohtaisten kartoitusten verkkoa.

Jokainen uusi sovellus moninkertaistaa tarvittavien käännösten määrän, ja jokainen skeeman muutos missä tahansa järjestelmässä voi heijastua eteenpäin ja rikkoa downstream-putkistoja. Kanoninen malli muuttaa ongelman luonnetta: sen sijaan, että N järjestelmää kartoittaisi toisiinsa, kukin järjestelmä kartoitetaan kerran jaettuun sanastoon.

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

Miksi pisteestä pisteeseen -integraatio pettää

Auttaa, jos tarkastellaan konkreettisesti niitä vikaantumistapoja, jotka motivoivat yhteisen mallin käyttöä.

• Kombinatorinen kasvu. Pisteestä pisteeseen -kartoituksissa käännöspolkujen määrä kasvaa suunnilleen järjestelmien lukumäärän neliössä. Kymmenennen sovelluksen lisääminen on huomattavasti kalliimpaa kuin toisen lisääminen.
• Semanttinen ajautuminen. Kaksi tiimiä voi molemmat “kartoittaa asiakkaan” ja silti olla eri mieltä siitä, onko asiakas henkilö, organisaatio vai laskutussuhde. Data virtaa, mutta merkitys eroaa.
• Hauras muutosten hallinta. Kentän uudelleennimeäminen tai uusi pakollinen attribuutti yhdessä lähdejärjestelmässä pakottaa tekemään muokkauksia jokaiseen sitä käyttävään kuluttajaan.
• Duplikoitu logiikka. Validointi-, deduplikointi- ja identiteetin ratkaisusäännöt toteutetaan uudelleen jokaisessa integraatiossa sen sijaan, että ne määriteltäisiin kerran.
• Toimittajalukon paine. Kun integraatiologiikka on kietoutunut tietyn toimittajan skeemaan, toimittajien vaihtaminen tai lisääminen muuttuu koko alustan uudistusprojektiksi.

Kanoninen malli, kuten CIM, ei poista kartoitustyötä – jokainen lähdejärjestelmä tarvitsee silti kartoituksen malliin. Se poistaa tämän työn moninkertaistumisen. Rakennat yhden kartoituksen per järjestelmä jaettuun malliin, ja malli itsessään tarjoaa vakaan sopimuksen niiden välille.

Miten CIM on järjestetty: Aihealueet

Yhteistyössä määritelty sisältö on järjestetty domaineihin eli aihealueisiin. Jokainen aihealue edustaa merkittävää liiketoimintakonseptia. CIM-suunnitelmat ovat saatavilla useissa muodoissa jokaiselle domainille, mukaan lukien esimerkkikaaviot. Aihealueiden määrä ja laajuus kasvavat konsortion ja kontribuutioiden myötä.

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

Tämä domain-orientoitunut rakenne on tärkeä käyttöönoton kannalta. Harvoin tarvitset koko mallia kerralla. Tyypillinen yritys aloittaa domaineista, jotka liittyvät sen tuskallisimpiin integraatioihin, todentaa lähestymistavan ja laajentaa sitä. Yleisiä aloituspisteitä ovat käsitteet, joita esiintyy lähes jokaisessa järjestelmässä:

• Party / Customer (Osapuoli / Asiakas) — ihmiset ja organisaatiot, joiden kanssa teet liiketoimintaa, sekä heidän roolinsa.
• Product (Tuote) — mitä myyt, tarjoat tai hallinnoit, mukaan lukien luettelot ja luokitukset.
• Account and relationship (Tili ja suhde) — miten osapuolet liittyvät tuotteisiin, sopimuksiin ja toisiinsa.
• Interaction and activity (Vuorovaikutus ja toiminta) — tapahtumat, transaktiot ja sitoumukset, jotka yhdistävät edellä mainitut.

Koska jokainen aihealue julkaistaan kaavioiden ja useiden esitysmuotojen kera, arkkitehdit voivat tarkastella käsitteellistä mallia, insinöörit voivat käyttää koneellisesti luettavaa muotoa ja liiketoiminnan sidosryhmät voivat vahvistaa, että käsitteet vastaavat todellisuutta. Tämä monimuotoinen lähestymistapa on tietoinen suunnittelupäätös: malli, jota vain insinöörit osaavat lukea, pyrkii ajautumaan erilleen liiketoiminnallisesta merkityksestä.

Miten CIM vertautuu muihin lähestymistapoihin

CIM on yksi useista vaihtoehdoista yhteentoimivuuden saavuttamiseksi. Oikea valinta edellyttää kompromissien ymmärtämistä.

Lähestymistapa	Mikä se on	Vahvuudet	Kompromissit
Point-to-point-kartoitus	Suorat käännökset kunkin järjestelmäparin välillä	Yksinkertainen kahdelle järjestelmälle; yhteistä hallintoa ei tarvita	Kasvaa kombinatorisesti; hauras; monistettu logiikka
Kanoninen malli (CIM-tyylinen)	Jaettu, sovellusagnostinen sanasto, johon kukin järjestelmä kartoitetaan	Lineaarinen kartoitustyö; vakaa sopimus; uudelleenkäytettävä projekteissa	Edellyttää hallintoa ja yhteisymmärrystä; kartoitus tarvitaan edelleen järjestelmäkohtaisesti
Toimialan tietostandardit	Vertikaaliset standardit tietylle sektorille (esim. terveydenhuolto, rahoitus)	Syvä toimialan kattavuus; sääntelyn yhdenmukaistaminen	Kapea soveltamisala; ei välttämättä kata toimialojen välisiä yrityskonsepteja
Toimittajan tietomallit	Alustan natiivi skeema, joka toimii integraatiokeskuksena	Tiivis työkalujen integrointi; nopeaa yhden toimittajan ekosysteemissä	Lukitusriski; muiden toimittajien on noudatettava yhden osapuolen mallia
API-first / schema-on-read	API-kohtaiset sopimukset; merkitys ratkaistaan kulutushetkellä	Joustava; nopea aloittaa	Semanttinen johdonmukaisuus riippuu kurinalaisuudesta; vaikeampi hallita mittakaavassa

Käytännön ohje: käytä kanonista mallia, kun sinulla on paljon järjestelmiä, toimialojen välisiä konsepteja ja pitkäikäinen integraatiomaisema. Käytä point-to-point-kartoitusta, kun laajuus on aidosti vain kaksi järjestelmää ja lyhytikäinen. Toimialastandardit ja CIM täydentävät toisiaan – vertikaalinen standardi voi antaa syötettä toimialueelle, kun taas CIM tarjoaa läpileikkaavan yrityssanaston.

Kuinka ottaa CIM käyttöön käytännössä

Käyttöönotto on tietoisten päätösten sarja eikä yksittäinen migraatio. Toimiva malli näyttää tältä:

1. Valitse korkean kipupisteen, hyvin rajattu integraatio. Valitse toimialue, jossa kartoituksen aiheuttama vaiva on todellista ja laajuus on riittävän pieni, jotta arvo voidaan osoittaa nopeasti.
2. Inventoi lähdejärjestelmät ja niiden skeemat. Dokumentoi, mitä kukin järjestelmä kutsuu valitsemasi aihealueen käsitteiksi ja missä ne eroavat toisistaan.
3. Kartoita kukin järjestelmä CIM-toimialueeseen. Luo yksi kartoitus per järjestelmä jaettuun malliin. Käsittele näitä kartoituksia versioituina artefakteina, ei kertakäyttöisinä skripteinä.
4. Määrittele laajennuskäytäntösi etukäteen. Päätä, miten käsittelet käsitteitä, joita CIM ei vielä kata – laajennukset tulee dokumentoida, nimetä johdonmukaisesti ja ehdottaa takaisin konsortiolle, jos niistä on laajasti hyötyä.
5. Perusta hallinto. Määritä kartoitusten omistajuus, muutosten tarkistusprosessi ja sykli CIM-päivitysten synkronointiin.
6. Laajenna toimialue kerrallaan. Hyödynnä ensimmäisen toimialueen kartoitusmalleja ja hallintoa seuraavan kustannusten pienentämiseksi.

Kaksi varoitusta kannattaa sanoa selvästi. Ensinnäkin kanoninen malli lisää kerroksen – se ei ole ilmaista, ja hyöty tulee uudelleenkäytöstä useissa integraatioissa, ei yhdestä. Toiseksi, kartoitus on se vaihe, jossa todellinen työ tapahtuu; malli antaa vakaan tavoitteen, mutta jonkun on silti päätettävä, miten kukin lähdekenttä vastaa sitä, ja tämä päätös hyötyy liiketoiminnan panoksesta, ei vain tekniikasta.

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

Hallinto, lisensointi ja osallistuminen

CIM on avoimen lähdekoodin projekti osana Joint Development Foundationia, joka toimii Linux Foundationin alaisuudessa. Tällä rakenteella on merkitystä sitä arvioiville yrityksille: Linux Foundation on vakiintunut koti yhteisöllisille, toimittajaneutraaleille avoimen lähdekoodin projekteille, ja Joint Development Foundation tarjoaa oikeudellisen kehyksen, joka on suunniteltu erityisesti standardien ja spesifikaatioprojektien kehittämiseen ja operointiin.

Yritystietoarkkitehdin kannalta tämän hallintomallin käytännön vaikutukset ovat:

• Toimittajaneutraalius. Yksikään toimittaja ei hallitse spesifikaatiota, mikä vähentää riskiä siitä, että malli on muotoiltu suosimaan yhtä alustaa.
• Avoin osallistuminen. Kuka tahansa voi ehdottaa muutoksia, mikä tarkoittaa, että malli voi kehittyä vastaamaan todellisia integraatiotarpeita yhden tiekartan sijaan.
• Spesifikaatiokeskeinen prosessi. Joint Development Foundation -malli rakentuu spesifikaatioiden tuottamiseen ja ylläpitoon, mikä on linjassa sen kanssa, miten standardeja otetaan käyttöön ja niihin viitataan hankinnoissa ja arkkitehtuurikatselmuksissa.

Osallistumista kannustetaan ja se on avointa kaikille. Panokset ovat tyypillisesti uusia tai jalostettuja aihealueita, korjauksia ja selvennyksiä, esimerkkikaavioita sekä palautetta todellisista integraatioprojekteista. Arvokkaimmat panokset tulevat usein käytännön tekijöiltä, jotka ovat kohdanneet tietyn kartoitusongelman ja osaavat kuvata sen ratkaisevan käsitteen.

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

Osallistuminen

Oletko kiinnostunut liittymään CIM-aloitteeseen? Hienoa! Lähetä meille sähköpostia saadaksesi lisätietoja.

Sähköpostin lisäksi luonnollisia tapoja osallistua on tarkastella julkaistuja aihealueita kiinnostavalla toimialueellasi, kokeilla yhden järjestelmän kartoittamista toimialueeseen ja tuoda löytämäsi puutteet takaisin yhteisöön. Koska aihealueiden määrä ja laajuus kasvavat konsortion ja panosten myötä, malli paranee suhteessa siihen, kuinka monta todellista integraatio-ongelmaa sen käyttäjät siihen tuovat.

Usein kysytyt kysymykset

Mikä Cloud Information Model tarkalleen ottaen on?

CIM on sovellusagnostinen, avoin tietomalli, joka määrittelee yhteiset liiketoimintakonseptit ja niiden suhteet, jotta eri sovellukset voivat vaihtaa tietoja jaetun sanaston avulla. Sitä tuottaa avoin konsortio ja se julkaistaan avoimena spesifikaationa. Se ei ole asennettava tuote, vaan malli, johon järjestelmäsi kartoitetaan.

Kenelle CIM on tarkoitettu?

Se on suunnattu yritystietoarkkitehdeille, integraatio- ja ETL-insinööreille, sovellus- ja alustatoimittajille sekä avoimen lähdekoodin kehittäjille. Kuka tahansa, jonka on yhdistettävä useita pilvi- ja on-premise-järjestelmiä, joilla on eri skeemat, on potentiaalinen käyttäjä. Toimittajat hyötyvät siitä, että jaettu malli vähentää räätälöityä työtä, jota tarvitaan integraatioihin heidän tuotteidensa kanssa.

Miten CIM:ää hallinnoidaan ja lisensoidaan?

CIM on avointa lähdekoodia osana Joint Development Foundationia, joka toimii Linux Foundationin alaisuudessa. Tämä tarjoaa toimittajaneutraalin, spesifikaatio-orientoituneen hallintakehyksen. Rakenteen tarkoituksena on pitää malli avoimena osallistumiselle ja riippumattomana yksittäisen toimittajan hallinnasta.

Miten CIM eroaa toimittajan natiivista tietomallista?

Toimittajan natiivi malli on optimoitu kyseisen toimittajan tuotteelle ja ekosysteemille; sen käyttöönotto integraatiokeskittimeksi pyrkii luomaan toimittajalukon (lock-in). CIM on suunniteltu sovellusagnostiseksi, joten mikään yksittäinen alusta ei määrittele sanastoa. Vastapainona on se, että CIM vaatii hallintoa ja yhteisymmärrystä eri tiimien välillä, kun taas toimittajamalli on valmis käytettäväksi kyseisen toimittajan työkaluilla.

Pitääkö minun silti tehdä kartoituksia, jos käytän CIM:ää?

Kyllä. Jokainen lähdejärjestelmä tarvitsee edelleen kartoituksen jaettuun malliin. Etuna on, että kirjoitat yhden kartoituksen järjestelmää kohden CIM:ään sen sijaan, että tekisit erillisen käännöksen jokaiselle järjestelmäparille. Tämä muuttaa kombinatorisen kartoitustyön suunnilleen lineaariseksi ponnisteluksi ja antaa sinulle vakaan sopimuksen, joka kestää yksittäisten järjestelmien muutokset.

Miten aloitan CIM:n käyttöönoton?

Aloita yhdestä kriittisestä, hyvin rajatusta integraatiosta yhdessä aihealueessa (Subject Area). Inventoi lähdeskeemat, kartoita jokainen järjestelmä CIM-domaaniin, määritä laajennus- ja hallintakäytäntö ja käsittele kartoituksia versioituina artefakteina. Kun ensimmäinen domaine osoittautuu arvokkaaksi, laajenna domaine kerrallaan hyödyntäen luomiasi malleja ja hallintoa.

Lisälukemista

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia