Pilvitietomalli

(CIM) on avoin, sovellusagnostinen skeema nykyaikaisessa yrityksessä liikkuvien entiteettien kuvaamiseen: osapuolten, tuotteiden, tilausten, maksujen ja niitä yhdistävien suhteiden. Sen sijaan, että jokaiseen integraatioon keksittäisiin räätälöity tietomalli, CIM tarjoaa jaetun sanaston, jotta CRM, ERP, kaupankäyntialusta ja analytiikkavarasto voivat sopia siitä, mitä “myyntitilaus” tai “tuotesuhdetyyppi” todellisuudessa tarkoittaa. Tässä artikkelissa käydään läpi mallin muodostavat entiteettiryhmät ja tarkastellaan sitten yhtä edustavaa entiteettiä — ProductRelationshipType — osoittaakseen, kuinka CIM ilmaisee suhteita, rooleja ja avaimia käytännössä.

Keskeiset havainnot

• CIM järjestää yritystiedot entiteettiryhmiin (Party, Product, Sales Order, Payment ja muut), jotka voidaan ottaa käyttöön asteittain eikä kerralla.
• Jokainen entiteetti määritellään Term URI:n, kuvauksen, skalaariominaisuuksien ja linkkiominaisuuksien avulla – rakenteella, joka kartoitetaan selkeästi JSON-LD-, RDF- ja property-graph-tietokantoihin.
• Suhde-entiteetit, kuten ProductRelationshipType, koodaavat rooleja (parent/child), jotta tuotepaketit, vaihtoehdot ja suojukset voidaan mallintaa ilman liiketoimintalogiikan kovakoodausta.
• Malli on tarkoituksella sovellusagnostinen: se kuvaa, mitä data tarkoittaa, ei sitä, miten tietty toimittaja tallentaa sen.
• CIM:n käyttöönotto on kartoitusharjoitus, ei “rip-and-replace” -prosessi – kohdistat olemassa olevat järjestelmät yhteisiin termeihin ja sovitat erot.

Miksi jaettu malli on tärkeä

Yritysintegraatiossa on tuttu vikatila: jokainen järjestelmä puhuu omaa murrettaan. Salesforce kutsuu sitä Accountiksi, SAP kutsuu sitä Business Partneriksi ja kotitekoinen laskutuspalvelu Asiakkaaksi. Kun rakennat pisteestä pisteeseen -kartoituksia jokaisen parin välille, käännösten määrä kasvaa järjestelmien määrän neliössä, ja jokainen uusi järjestelmä moninkertaistaa ylläpitotaakan.

Kanoninen malli katkaisee tämän neliöllisen ongelman. Kartoitat jokaisen järjestelmän kerran jaettuun malliin, jolloin jaettu malli toimii keskuksena. Tämä on sama arkkitehtoninen periaate standardien, kuten OAGIS:n (Open Applications Group Integration Specification), OMG:n Common Warehouse Metamodelin ja schema.orgin kaupan sanaston takana.

CIM noudattaa tätä perinnettä, mutta se on rajattu pilviaikakauden yhteentoimivuuteen ja julkaistu avoimina termeinä dereferentoitavilla URI-tunnisteilla.

Käytännön hyöty on, että data-arkkitehti voi vastata kysymyksiin kuten “millä järjestelmillä on osapuolen (Party) virallinen tietue?” tai “miten esitämme tuotepaketin johdonmukaisesti sekä luettelossa että tilauksessa?” käyttämällä yhtä viitepistettä.

Entiteettiryhmät yhdellä silmäyksellä

CIM ei ole yksi monoliittinen skeema, vaan joukko löyhästi kytkettyjä ryhmiä. Mallissa nimettyjä ryhmiä ovat:

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

• Account — osapuolen kaupallisen suhteen konteksti.
• Contact Point — puhelinnumerot, sähköpostiosoitteet ja vastaavat tavoitettavuuskanavat.
• Lead — potentiaalinen osapuoli, jota ei ole vielä karsittu.
• Party ja Party Role — toimijan yleinen käsite ja sen roolit (asiakas, toimittaja, työntekijä).
• Payment ja Payment Method — miten raha liikkuu ja mitä välineitä käytetään.
• Product Attribute, Product Catalog ja Product — myytävät ja kuvailtavat tavarat ja palvelut.
• Sales Order ja sen laaja alakokonaisuuksien perhe – mallin transaktiokeskus.
• Shipment — täyttäminen ja logistiikka.

Myyntitilausryhmä on ylivoimaisesti rakeisin, ja on tärkeää ymmärtää miksi. Tilaus on kohta, johon liiketoimintasäännöt keskittyvät: hinnoittelu, verot, oikaisut, toimitusryhmät ja rivikohtaiset huomautukset liittyvät kaikki siihen.

CIM jakaa tilauksen useisiin pieniin entiteetteihin — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log ja muihin — yhden leveän taulukon sijaan. Tämä hajottaminen on tietoinen suunnitteluvalinta: se antaa jokaisen osa-alueen kehittyä itsenäisesti ja antaa järjestelmien tilata vain niille tärkeitä osia.

CIM-entiteetin anatomia

Jokainen CIM:n entiteetti noudattaa samaa muotoa, mikä tekee mallista ohjelmallisesti ennustettavan. Tarkastellaan ProductRelationshipType-entiteettiä, joka kuvaa, miksi kaksi tuotetta liittyvät toisiinsa.

Meidän valintamme: Workato — Automaatiovetoinen iPaaS, jonka varaan yritystiimit voivat itse asiassa rakentaa.

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Tämä on käsitteen maailmanlaajuisesti ainutlaatuinen tunniste. Koska se on URI, se voidaan dereferentoida ja käyttää suoraan RDF/JSON-LD-graafeissa.
• Kuvaus — “Reasons why products are related such as bundle, option or covering.” Tämä kertoo, että entiteetti on tyyppi tai luokitus, ei itse suhde-instanssi.
• Skalaariominaisuudet — primitiiviset kentät, jotka sisältävät dataa.
• Linkkiominaisuudet — viittaukset muihin entiteetteihin. ProductRelationshipType:lla ei ole sellaisia, mikä on itsessään informatiivista: se on lehtientiteetti, kontrolloitu sanasto eikä keskus.

Skalaariominaisuudet ovat:

Ominaisuus	Term URI	Alue	Pakollinen	Kuvaus
id	.../model/id	guid	kyllä	Ensisijainen avain
parentProductRole	.../model/parentProductRole	string	kyllä	Ensimmäinen rooli suhteessa, esim. “Consists of”
childProductRole	.../model/childProductRole	string	kyllä	Toinen rooli suhteessa, esim. “Component of”

Se, että id on GUID, on merkittävä konventio: se tarkoittaa, että tunnisteet ovat maailmanlaajuisesti ainutlaatuisia ilman järjestelmien välistä koordinointia, mikä on juuri sitä, mitä halutaan, kun tietueita luodaan eri pilvissä ja yhdistetään myöhemmin.

Suhteiden mallintaminen rooleilla

ProductRelationshipType:n opettavaisin osa on rooliominaisuuksien pari. Tuotesuhde on suunnattu, ja CIM tallentaa tämän suunnan kahdella nimetyllä roolilla yhden läpinäkymättömän “tyyppi”-merkkijonon sijaan.

Ajattele pakettia. “Aloituspakkaus” koostuu “reitittimestä” ja “kaapelista”. CIM-termeillä:

• Emotuote toimii parentProductRole:n kuvaamassa roolissa – esimerkiksi “Koostuu”.
• Lapsituote toimii childProductRole:n kuvaamassa roolissa – esimerkiksi “Komponentti”.

Tallentamalla molemmat roolit merkkijonoina tyyppiin, saat uudelleenkäytettävän määritelmän. Mikä tahansa määrä todellisia tuotteiden välisiä linkkejä voi viitata samaan ProductRelationshipType-riviin, joten sanasto pysyy pienenä ja johdonmukaisena, kun taas suhdeesiintymiä voi olla lukuisia. Tämä on klassinen normalisointimalli: erota suhteen tyyppi sen esiintymistä.

Kuvauksessa nimetään nimenomaisesti kolme tyyppiä – paketti, optio ja covering – mikä vihjaa kaupalliseen semantiikkaan, jonka malli aikoo kattaa:

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

• Paketti (Bundle) — tuotteet, jotka myydään yhdessä yksikkönä (emo “koostuu” lapsista).
• Optio (Option) — perustuotteeseen liittyvä valinta tai lisäosa.
• Covering — tuote, joka käärii tai suojaa toista; yleinen vakuutus- ja takuukonteksteissa.

Kuinka päättää roolisanasto

Koska parentProductRole ja childProductRole ovat vapaamuotoisia merkkijonoja, malli ei sanele tarkkaa sanamuotoasi. Tuo joustavuus on sekä ominaisuus että riski. Muutama käytännön sääntö:

1. Valitse kontrolloitu sanasto ja lukitse se. Sovi pieni joukko roolilausekkeita (“Koostuu” / “Komponentti”, “Valinnainen lisäosa” / “Sisältää option”) ja dokumentoi ne. Vapaa teksti johtaa merkityksen ajautumiseen.
2. Pidä roolit symmetrisinä ja luettavissa molempiin suuntiin. Hyvä testi: pystytkö lukemaan suhteen ääneen kummastakin päästä niin, että se on järkevää?
3. Älä ylikuormita rooleja liiketoimintalogiikalla. Jos rooli vaatii ehdollista toimintaa, kyseinen logiikka kuuluu kuluttavaan sovellukseen, ei merkkijonoon.
4. Versioi sanastoasi. Kun lisäät roolin, käsittele sitä skeeman muutoksena, jossa on siirtopolku, ei ad-hoc-lisäyksenä.

CIM:n käyttöönotto käytännössä

Kanonisen mallin käyttöönotto on kartoituskuria, ei migraatiota. Toimiva järjestys:

• Inventoi tietuejärjestelmäsi. Päätä kunkin entiteettiryhmän osalta, mikä järjestelmä on auktoriteetti. Osapuoli (Party) saattaa olla CRM:ssä; Tuote PIM:ssä; Myyntitilaus ERP:ssä.
• Kartoita jokainen lähde CIM-termeihin. Luo taulukko: lähdekenttä $\rightarrow$ CIM-ominaisuus. Jos lähteellä ei ole vastaavaa, huomioi aukko; jos CIM:llä ei ole vastaavaa, huomioi laajennus.
• Täsmää tunnisteet. CIM:n GUID-käytäntö tarkoittaa, että ylläpidät tyypillisesti vastaavuustaulukkoa (crosswalk) natiiviavaimien ja CIM id-arvojen välillä.
• Valitse serialisointi. CIM:n URI-pohjaiset termit mapautuvat luonnollisesti JSON-LD- ja RDF-muotoihin; ne kääntyvät myös selkeästi relaatiotaulukoiksi tai ominaisuusgraafiksi. Malli ei pakota tiettyyn tallennustekniikkaan.
• Hallitse sanastoa. Lisäämäsi roolijonot, luettelot ja laajennukset ovat osia, jotka todennäköisimmin ajautuvat, joten aseta ne muutoshallinnan piiriin.

Hyödyllinen mentaalinen malli on käsitellä CIM:ää vaihtomallina (interchange schema) ja operatiivisia tietovarastoja tietuejärjestelminä (system of record). Et pyydä jokaista sovellusta luopumaan natiivimallistaan, vaan pyydät niitä julkaisemaan ja kuluttamaan jaettua mallia rajapinnoilla.

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

Varoitukset ja kompromissit

Mikään kanoninen malli ei ole ilmainen, eikä CIM ole poikkeus.

• Abstraktiolla on hintansa. Malli, joka on riittävän yleinen kattamaan useita toimialoja, ei sovi täydellisesti yhteenkään niistä. Varaudu lisäämään laajennuksia.
• Myyntitilausryhmä on raskas. Sen hienojakoinen hajautus on tehokas, mutta se tarkoittaa enemmän liitoksia (joins) ja kartoitettavia entiteettejä. Tiimit, joilla on yksinkertaiset tilausvirrat, voivat ottaa käyttöön vain osajoukon.
• Vapaamuotoiset roolijonot tarvitsevat hallintaa. Kuten todettiin, parentProductRole- ja childProductRole-kenttien joustavuus on vain niin hyvä kuin sitä ympäröivä kurinalaisuus.
• Avoimet mallit kehittyvät. Koska CIM on yhteisölähtöinen, termejä voidaan lisätä tai tarkentaa ajan myötä. Lukitse versio ja tarkista muutokset harkitusti.

Kompromissi on pohjimmiltaan klassinen valinta uskollisuuden tietylle järjestelmälle ja siirrettävyyden järjestelmien välillä. CIM optimoi siirrettävyyden, mikä on oikea valinta, kun tavoitteena on yhteentoimivuus.

Usein kysyttyjä kysymyksiä

Mikä on Cloud Information Model?

Cloud Information Model on avoin, sovellusagnostinen tietomalli, joka määrittelee jaetut entiteetit ja termit yritystiedoille, kuten osapuolille, tuotteille, tilauksille ja maksuille. Se tarjoaa yhteisen sanaston, jotta eri pilvi- ja on-premises-järjestelmät voivat vaihtaa tietoja ilman räätälöityjä point-to-point-kartoituksia.

Mihin ProductRelationshipType-elementtiä käytetään?

ProductRelationshipType määrittelee syyt, joiden vuoksi kaksi tuotetta liittyvät toisiinsa – esimerkiksi paketti, optio tai covering. Se tallentaa emoroolin ja lapsiroolin, jotta suunnattujen tuotteiden välisten linkkien voidaan viitata uudelleenkäytettävään, jaettuun määritelmään sen sijaan, että semantiikka toistettaisiin jokaisessa linkissä.

Miksi CIM käyttää GUID-tunnisteita pääavaimina?

GUID:n käyttäminen id-ominaisuudessa tarkoittaa, että tunnisteet ovat maailmanlaajuisesti ainutlaatuisia ilman keskitettyä koordinointia. Tämä on tärkeää monipilvi- ja monitoimittajaympäristöissä, joissa tietueita luodaan eri järjestelmiin ja yhdistetään myöhemmin, koska näin törmäykset vältetään tehokkaasti.

Onko CIM tietokantaskeema vai tiedonvaihtomuoto?

Se on parasta ymmärtää käsitteellisenä ja vaihtomallina fyysisen tietokantaskeeman sijaan. Sen URI-pohjaiset termit mapautuvat luonnollisesti JSON-LD- tai RDF-muotoihin, relaatiotaulukoihin tai ominaisuusgraafeihin, joten voit toteuttaa sen millä tahansa tallennustekniikalla, jota arkkitehtuurisi jo käyttää.

Miten CIM liittyy muihin standardeihin, kuten OAGIS- tai schema.org-standardeihin?

CIM jakaa näiden ponnistelujen tavoitteen – yhteisen sanaston yhteentoimivuutta varten – mutta se on suunniteltu pilviaikakauden yritysintegraatioon ja julkaistu avoimina, dereferentoitavina termeinä. Käytännössä voit mapata CIM:n muihin standardeihin rajapinnoissa, joissa kumppanit niitä vaativat.

Pitääkö minun ottaa koko malli käyttöön kerralla?

Ei. CIM on järjestetty löyhästi kytkettyihin entiteettiryhmiin, joten voit ottaa käyttöön tarvitsemasi ryhmät – esimerkiksi Party ja Product – ja laajentaa myöhemmin. Useimmat tiimit aloittavat entiteeteistä, jotka aiheuttavat eniten integraatio-ongelmia, ja kasvattavat mallia siitä eteenpäin.

Lisälukemista

• Myyntitilaus – Wikipedia
• Resource Description Framework (RDF) – Wikipedia
• JSON-LD – Wikipedia
• schema.org – jaettu sanasto strukturoidulle datalle verkossa