Cloud Information Model

Tervetuloa CIM:ään, sovellusagnostiseen tietomalliin, joka yksinkertaistaa integrointia ja nopeuttaa innovaatioita.

Keskeiset kohdat

• CIM on avoin, sovellusagnostinen tietomalli – liiketoimintakonseptien (asiakkaat, tilaukset, tuotteet ja niin edelleen) yhteinen sanasto, jonka avulla erilaiset pilvi- ja on-premises-järjestelmät voivat vaihtaa tietoja ilman räätälöityä point-to-point-kartoitusta.
• Se on olemassa tietyn, kalliin ongelman ratkaisemiseksi: jokainen sovellus toimittaa oman tietomallinsa, joten integraatiotiimit päätyvät kirjoittamaan ja ylläpitämään mukautettua käännöskoodia, joka on hauras ja hidastaa innovaatioita.
• Sitä hallinnoidaan avoimena standardina, konsortion tuottamana ja avoimena lähdekoodina Joint Development Foundationin (osa Linux Foundationia) alaisuudessa – joten kuka tahansa voi osallistua, tarkistaa ja ottaa sen käyttöön.
• Sisältö on järjestetty aihealueisiin (domainit), joista jokainen edustaa merkittävää liiketoimintakonseptia. Suunnitelmat on julkaistu useissa muodoissa, mukaan lukien esimerkkikaaviot.
• CIM on malli, ei tuote. Se määrittelee merkityksen ja rakenteen; valitset silti itse, miten kartoitat, tallennat ja siirrät tietoja omissa järjestelmissäsi.

Uusi standardi tietojen yhteentoimivuudelle

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

Kiihdyttääkseen digitaalista muutosta ja tarjotakseen henkilökohtaisia vuorovaikutuksia asiakkaille kaikilla kanavilla, monet yritykset ottavat käyttöön useita pilvi- ja on-premises-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 muutoksen kiihdyttämisen sijaan tämä prosessi hidastaa innovaatioita ja johtaa hauraisiin integraatioihin.

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

Miksi sovelluskohtaiset tietomallit pettävät

CIM:n ratkaisema keskeinen ongelma ei ole se, että yksittäisellä sovelluksella olisi huono tietomalli. Useimmat ovat täysin järkeviä omien rajojensa sisällä. Ongelmana on kombinatorinen räjähdys, joka tapahtuu, kun yhdistät useita niistä.

Harkitse tyypillistä yrityspinoa: CRM, ERP, markkinoinnin automaatioalusta, tukipalvelu, tietovarasto ja kourallinen liiketoimintakohtaisia SaaS-työkaluja. Jos jokaisella järjestelmällä on oma käsityksensä “asiakkaasta”, “tilistä”, “tilauksesta” ja “tuotteesta”, jokainen tietoja jakavan järjestelmäparin välillä tarvitaan oma kartoitus. Integraatioiden määrä kasvaa suunnilleen järjestelmien lukumäärän neliössä, ja jokainen kartoitus on pieni, dokumentoimaton ja omistamaton logiikan pala, jota jonkun on ylläpidettävä ikuisesti.

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

Oireet ovat tuttuja kaikille, jotka ovat johtaneet integraatiotoimintoja:

• Semanttinen ajautuminen. “Asiakas” tarkoittaa CRM:ssä laskutusyksikköä; tukipalvelussa se tarkoittaa henkilöä, joka tekee tukipyyntöjä. Sama sana, kaksi merkitystä, hiljaa sovitettuna kartoituksella, jota kukaan ei muista kirjoittaneen.
• Hauraita putkia. Toimittaja nimeää kentän uudelleen tai muuttaa enum-arvoa, ja ETL-ajo epäonnistuu kello 2 yöllä, koska kartoitus oli koodattu kovakoodattuna vanhan rakenteen mukaan.
• Kaksoistyö. Kaksi tiimiä rakentaa itsenäisesti lähes identtiset käännökset samojen kahden järjestelmän välillä, koska yhteistä viitekehystä ei ole.
• Toimittajalukitus tietojen perusteella. Alustalta siirtyminen on kallista ei ohjelmiston, vaan sen skeemaan sidotun kertyneen käännöslogiikan vuoksi.

Jaettu, sovellusagnostinen malli iskee juurisyyhyn: N-to-N-kartoitusten sijaan jokainen järjestelmä kartoitetaan kerran yhteiseen malliin, ja yhteinen malli kantaa merkityksen.

Mitä “sovellusagnostinen” oikeastaan tarkoittaa

On syytä olla tarkka suunnittelufilosofian suhteen, koska “agnostista” käytetään usein löyhästi.

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

Sovellusagnostinen malli ei ole minkään yksittäisen toimittajan tuotteen omistuksessa eikä sille optimoitu. Se kuvaa liiketoimintakonsepteja termein, jotka olisivat tunnistettavia toimialan asiantuntijalle – asiakas, tilaus, tuote, sijainti – eikä termein, jotka heijastavat yhden sovelluksen sisäisiä taulukoita. Tämä neutraalisuus tekee siitä hyödyllisen keskittimen: kenenkään osallistujan ei tarvitse omaksua kilpailijan maailmankuvaa toimiakseen yhdessä.

Tämä on sama arkkitehtoninen vaisto muiden neutraalien vaihtostandardien takana. Aivan kuten Resource Description Framework (RDF) ja schema.org antavat verkolle jaetun sanaston asioiden kuvaamiseen, ja aivan kuten EDI ja myöhemmin UBL (Universal Business Language, OASIS-standardi) antoivat toimitusketjuille jaetun muodon transaktioille, CIM pyrkii antamaan yrityssovelluksille jaetun sanaston niiden ydintoimintojen entiteeteille. Erona on laajuus ja nykyaikaisuus: CIM kohdistuu yhdistettyyn, API-ohjattuun pilvi- ja on-premises-maailmaan eräajastettujen tiedostojen vaihdon sijaan.

Hyödyllinen mentaalinen malli on yritysintegraation kanoninen tietomalli -malli, joka tuli tunnetuksi Gregor Hohpen ja Bobby Woolfin Enterprise Integration Patterns -teoksessa. CIM on käytännössä yhteisöllisesti ylläpidetty kanoninen malli – “hub” hub-and-spoke-integraatiotopologiassa – mutta sellainen, joka on avoin, versioitu ja jaettu organisaatioiden välillä sen sijaan, että se olisi keksitty yksityisesti yhden yrityksen sisällä.

Miten CIM on järjestetty: aihealueet ja domainit

Yhteisöllisesti 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ä.

Käytännössä tämä tarkoittaa, että CIM:ää tulisi ajatella liittyvien mallien kirjastona eikä yksittäisenä monoliittisena skeemana. Tyypilliset aihealueet ryhmittyvät tunnistettavien liiketoiminnallisten kokonaisuuksien ympärille – esimerkiksi osapuolet ja tilit, tuotteet ja luettelot, tilaukset ja tapahtumat sekä niitä yhdistävät suhteet. Koska jokainen alue on julkaistu kaavioiden ja koneellisesti luettavien määritelmien kera, eri tiimit voivat ottaa käyttöön eri alueita eri aikoina odottamatta koko mallin valmistumista.

Tästä rakenteesta seuraa muutamia käytännön vaikutuksia:

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

• Ota käyttöön asteittain. Sinun ei tarvitse kartoittaa koko yritystäsi CIM:ään ensimmäisenä päivänä. Aloita aihealueesta, joka aiheuttaa eniten ongelmia – yleensä asiakas- tai tilausdomainista – ja laajenna siitä.
• Laajenna mieluummin kuin haarauta. Kun CIM:stä puuttuu tarvitsemasi konsepti, avoin malli on suunniteltu laajennettavaksi. Laajennuksen kontribuointi takaisin on parempi vaihtoehto kuin yksityisen haarukan (fork) ylläpitäminen, koska haarukka eriytyy ja menettää yhteentoimivuusedun.
• Käsittele kaavioita dokumentaationa, älä totuuden lähteenä. Esimerkkikaaviot on tarkoitettu ihmisille; koneellisesti luettavat määritelmät ovat sitä, mitä työkalujesi tulisi käyttää.

CIM integraatiomaisemassa: Kuinka päättää

CIM on yksi useista vaihtoehdoista integraation monimutkaisuuden hallitsemiseen. Oikea valinta edellyttää työkalun sovittamista ongelmaan. Alla oleva taulukko vertailee tärkeimpiä lähestymistapoja, joita yritystietoarkkitehti tyypillisesti harkitsee.

Lähestymistapa	Mikä se on	Paras kun	Tärkein kompromissi
Point-to-point-kartoitus	Mukautettu koodi, joka kääntää tiedot suoraan kahden järjestelmän välillä	Vain kaksi järjestelmää, vakaat skeemat, lyhyt aikajänne	Ei skaalaudu; N-N-räjähdys; hauras
Kanoninen malli (esim. CIM)	Jaettu, neutraali malli, johon kukin järjestelmä kartoitetaan kerran	Monet järjestelmät, eri toimittajat, pitkäikäinen integraatio	Alustava mallinnustyö; vaatii hallintaa (governance)
Toimittajan iPaaS-liittimet	Integraatioalustan valmiiksi rakennetut liittimet	Yleiset SaaS-parit, nopeus hallinnan kustannuksella	Liitinkohtainen semantiikka; mahdollinen lukitus (lock-in)
Toimialan vaihtostandardit (EDI, UBL, HL7 jne.)	Domain-kohtaiset viestimuodot	Säännellyt tai vakiintuneet vertikaalit	Kapea soveltamisala; usein eräajo-orientoitunut
Datan virtualisointi / federaatio	Kyselyt eri lähteistä ilman keskittämistä	Analytiikka, pääasiassa lukupainotteinen käyttö	Ei ratkaise semanttisia ristiriitoja itsestään

Päätösheuristiikka on suoraviivainen: jos sinulla on useampi kuin kourallinen järjestelmiä, joiden on sovittava yhteisten entiteettien merkityksestä, ja nämä järjestelmät ovat eri toimittajien, kanoninen malli maksaa itsensä takaisin. Jos sinulla on kaksi järjestelmää eikä suunnitelmia lisätä uusia, point-to-point on riittävä. Jos tarpeesi on puhtaasti analyyttinen ja vain luku -tilassa, federaatio voi riittää – mutta huomaa, että federaatio siirtää semanttista ongelmaa sen sijaan, että se ratkaisisi sen.

CIM täydentää ympärillään olevia työkaluja, ei korvaa niitä. ETL- tai ELT-putki (rakennettu esimerkiksi Apache Airflow’lla, dbt:llä tai kaupallisella alustalla) hoitaa edelleen siirron; CIM määrittelee, mitä data tarkoittaa, kun se saapuu. Viestinvälittäjä, kuten Apache Kafka, hoitaa edelleen kuljetuksen; CIM määrittelee tapahtumien muodon. Malli on sopimus; työkalut ovat putkisto.

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

Hallinto, lisensointi ja miksi säätiöllä on merkitystä

CIM on avoimen lähdekoodin projektina osa Joint Development Foundationia, joka toimii Linux Foundationin alaisuudessa. Tämä ei ole vähäpätöinen yksityiskohta – se on keskeistä sille, miksi yritys voi turvallisesti rakentaa CIM:n päälle.

Linux Foundation on vakiintunut neutraali koti yhteisöllisille avoimen lähdekoodin projekteille, ja Joint Development Foundation tarjoaa kevyen oikeudellisen rakenteen standardien ja spesifikaatioiden yhteisölliseen kehittämiseen. CIM:n isännöinti siellä tarkoittaa:

• Neutraali hallinto. Yksikään toimittaja ei hallitse mallia, joten sen käyttöönotto ei tarkoita kilpailijan tiekartan omaksumista.
• Avoin kontribuointi. Kuka tahansa – toimittajat, yritykset, yksittäiset kehittäjät – voi ehdottaa muutoksia, ja prosessi on läpinäkyvä.
• Ennustettava lisensointi. Säätiön isännöimissä spesifikaatioissa on tyypillisesti ehdot, jotka on suunniteltu laajaa, rojaltivapaata käyttöönottoa varten, mikä on erittäin tärkeää standardia arvioiville laki- ja hankintatiimeille.

Arkkitehdille, joka perustelee asiaa sisäisesti, tämä hallintomalli on usein yhtä tärkeä kuin tekninen sisältö. ”Se on Linux Foundationin avoin standardi” vastaa kysymyksiin, jotka usein estävät standardien käyttöönoton: Kuka sitä hallitsee? Mitä tapahtuu, jos toimittaja poistuu? Voimmeko kontribuoida omia laajennuksiamme?

Aloitus: Käytännön käyttöönottopolku

Jaetun mallin käyttöönotto on yhtä paljon organisatorinen kuin tekninen harjoitus. Pragmaattinen järjestys on seuraava:

1. Inventoi jaetut entiteettisi. Tunnista liiketoimintakonseptit, jotka esiintyvät useammassa kuin yhdessä järjestelmässä – yleensä asiakas, tuote, tilaus ja sijainti. Nämä ovat ehdokkaitasi.
2. Valitse yksi aihealue ja yksi integraatio. Valitse mallin todentamiseksi integraatio, jossa on suurin kipupiste mutta pienin vaikutusalue (blast radius). Yksittäinen raportointiputki tai yhden uuden sovelluksen käyttöönotto on ihanteellinen.
3. Kartoita jokainen järjestelmä CIM:ään kerran. Rakenna käännös kustakin lähdejärjestelmästä CIM-esitykseen ja CIM:stä kuhunkin kohteeseen. Vastusta tarvetta kartoittaa järjestelmästä järjestelmään suoraan.
4. Dokumentoi laajennuksesi. Jos CIM ei kata jotain konseptia, kirjaa laajennus nimenomaisesti ja harkitse sen kontribuointia takaisin.
5. Määritä omistajuus. Kanoninen malli ilman ylläpitäjää rappeutuu. Nimeä tiimi tai rooli, joka vastaa kartoituksista ja ylävirran muutosten seurannasta.
6. Versioi ja testaa. Käsittele mallia ja sen kartoituksia versioituina artefakteina, joilla on testit, aivan kuten sovelluskoodia.

Yleisin vikatila on CIM:n käsitteleminen kertaluonteisena mallinnusharjoituksena elävän sopimuksen sijaan. Menestyneet organisaatiot kohtelevat mallia samalla tavalla kuin API:a: versioituna, testattuna, omistettuna ja tietoisesti kehitettynä.

Kumppanit osallistuvat CIM:ään

CIM on konsortiotyö, ja sen arvo kasvaa osallistumisen myötä. Kumppanit tuottavat aihealueiden sisältöä, tarkistavat ehdotuksia ja auttavat muokkaamaan mallin suuntaa. Koska työ on avointa, panokset eivät rajoitu suuriin toimittajiin – yritykset, joilla on todellisia integraatio-ongelmia, ja yksittäiset toimijat, joilla on toimialueen asiantuntemusta, ovat yhtä tervetulleita.

Ota yhteyttä

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

Usein kysyttyjä kysymyksiä

Mikä on pilvitietomalli (CIM)?

CIM on sovelluksista riippumaton avoimen lähdekoodin tietomalli, joka tarjoaa jaetun, standardeihin perustuvan sanaston liiketoimintakonsepteille, joita yritysten on vaihdettava pilvi- ja on-premises-sovellusten välillä. Sen tuottaa avoin konsortio, ja sitä isännöi Joint Development Foundation, joka on osa Linux Foundationia. Sen tarkoituksena on vähentää mukautettua kartoituskoodia, jota hauraat point-to-point-integraatiot vaativat.

Onko CIM tuote vai spesifikaatio?

CIM on spesifikaatio – malli ja joukko määritelmiä – ei ajettava tuote. Se määrittelee jaettujen entiteettien merkityksen ja rakenteen; valitset silti omat ETL/ELT-työkalusi, viestivälittäjäsi ja tallennustilasi. Ajattele sitä sopimuksena, jonka integraatioputkistosi toteuttaa, eikä itse putkistona.

Miten CIM eroaa toimittajan integraatioalustasta?

Integraatioalusta (iPaaS tai liitinkirjasto) siirtää tietoja ja toimittaa usein valmiita liittimiä, mutta nämä liittimet koodaavat toimittajakohtaista semantiikkaa. CIM on neutraali ja toimittajariippumaton, joten se ei lukitse sinua yhden alustan maailmankuvaan. Nämä kaksi täydentävät toisiaan: voit käyttää CIM:ää kanonisena mallina missä tahansa integraatioalustassa.

Mitä ovat CIM:n aihealueet?

Aihealueet (kutsutaan myös domaineiksi) ovat mallin organisointiyksiköitä, joista jokainen edustaa suurta liiketoimintakonseptia, kuten asiakkaita, tuotteita tai tilauksia. Suunnitelmat julkaistaan useissa muodoissa, mukaan lukien esimerkkikaaviot, ja aihealueiden määrän odotetaan kasvavan, kun konsortio ja yhteisö tuottavat lisää sisältöä.

Voimmeko laajentaa CIM:ää, jos se ei kata käsitteitämme?

Kyllä. CIM on suunniteltu laajennettavaksi, ja koska se on avointa lähdekoodia neutraalin säätiön alaisuudessa, voit ehdottaa lisäyksiä osallistumisprosessin kautta. Jaetun mallin laajentaminen ja panosten palauttaminen on huomattavasti suositeltavampaa kuin yksityisen haarukan (fork) ylläpitäminen, joka eriytyy ajan myötä ja menettää yhteentoimivuusedun, joka motivoi CIM:n käyttöönottoa alun perin.

Kenen tulisi ottaa CIM käyttöön?

Se on arvokkainta organisaatioille, jotka käyttävät monia eri toimittajien sovelluksia ja joiden on sovittava jaettujen entiteettien merkityksestä – klassinen tilanne yritystietoarkkitehtien ja integraatioinsinöörien kannalta. Sovellus- ja alustatoimittajat hyötyvät myös kohdistamalla skeemansa neutraaliin malliin, mikä helpottaa tuotteidensa integrointia asiakkaiden kannalta. Jos sinulla on vain kaksi vakaata järjestelmää, yksinkertaisempi point-to-point-kartoitus saattaa riittää.

Lisälukemista

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