CIM-malli

(CIM) on avoin, sovellusagnostinen tietomalli, jonka tarkoituksena on antaa yrityksille yhteinen sanasto CRM-, ERP-, markkinointi-, palvelu- ja analytiikkajärjestelmissä esiintyville entiteeteille. Sen sijaan, että jokainen toimittaja keksisi omat objektinimensä ja -suhteensa, CIM määrittelee yhteisen joukon aihealueita, entiteettejä ja attribuutteja, joihin mikä tahansa järjestelmä voi kartoittaa. Mallia ohjataan avoimen lähdekoodin projektina Linux-säätiön (The Linux Foundation) alaisuudessa, joka isännöi laajaa valikoimaa yhteistyöhön perustuvia data- ja infrastruktuuriprojekteja.

Tässä artikkelissa kerrotaan, kuinka CIM on rakennettu, miten sen komponentit liittyvät toisiinsa, miten supertyypit ja alatyypit toimivat ja miten aihealueet on järjestetty. Se kattaa myös käytännön päätökset, joita arkkitehti kohtaa CIM:n käyttöönotossa – kartoituksen, hallinnan, versioinnin ja laajennukset – sekä sen, mihin malli sijoittuu suhteessa muihin alan standardeihin.

Keskeiset havainnot

• CIM järjestää liiketoimintakonseptit aihealueisiin (Subject Areas), joista jokainen sisältää entiteettiryhmiä (Entity Groups), entiteettejä (Entities) ja attribuutteja (Attributes) – hierarkian, joka kartoittuu selkeästi skeemoihin, taulukoihin ja sarakkeisiin.
• Supertyypit ja alatyypit mahdollistavat yhteisten ominaisuuksien ilmaisemisen (osapuoli, joka on henkilö tai organisaatio) sallien silti erikoistumisen.
• Malli on tarkoituksella sovellusagnostinen: se kuvaa liiketoimintakonsepteja, ei minkään yksittäisen toimittajan toteutusta.
• CIM on julkaistu useissa muodoissa esimerkkikaavioineen, joten sitä voivat hyödyntää mallinnustyökalut, koodigeneraattorit ja dokumentaatio.
• Aihealueiden määrä ja laajuus kasvavat konsortion ja yhteisön panosten myötä, joten käyttöönotossa on huomioitava versiointi ja muutosten hallinta.
• CIM on yksi useista vaihtoehdoista; oikea valinta riippuu siitä, tarvitsetko laajaa domeenien välistä mallia vai kapeaa ja syvällistä standardia yhdelle toimialalle.

Kuinka CIM on rakennettu

CIM on järjestetty komponentteihin, jotta sisältöä voidaan navigoida ja hyödyntää helpommin. Jokainen hierarkian taso vastaa eri kysymykseen, ja hierarkian ymmärtäminen on ensimmäinen askel mallin tehokkaaseen käyttöön.

• Aihealue (Subject Area) — CIM-konsortion tunnistama keskeinen liiketoimintakonsepti, kuten Party. Jokainen aihealue sisältää yhden tai useamman entiteettiryhmän. Ajattele aihealuetta rajoitettuna kontekstina (bounded context): se ryhmittelee kaiken, mitä yrityksen on tiedettävä yhdestä laajasta teemasta.
• Entiteettiryhmä (Entity Group) — looginen ryhmittely aihealueen sisällä olevista liittyvistä entiteeteistä, kuten Account. Entiteettiryhmät pitävät suuret aihealueet hallittavina ja antavat tiimeille luonnollisen yksikön omistajuuden määrittämiseen.
• Entiteetti (Entity) — yksilöllinen objekti, josta organisaatio kerää tietoja, kuten Account Contact. Entiteetti on analoginen tavallisen tietokantataulukon kanssa.
• Attribuutti (Attribute) — entiteetin yksilöllinen ominaisuus, kuten Account Id tai Contact Email. Attribuutti on analoginen taulukon vakiotietokantakentän kanssa.

Tämä nelitasoinen hierarkia on tarkoituksella tuttu. Tietoarkkitehdit, jotka ovat työskennelleet relaatiomallinnuksen, dimensiomallinnuksen tai entiteetti-suhdekaavioiden (ER-kaaviot) parissa, tunnistavat kuvion välittömästi. CIM:n tuoma lisäarvo ei ole uusi mallinnustekniikka, vaan jaettu, ennalta neuvoteltu joukko nimiä ja suhteita, joista useat organisaatiot ja toimittajat voivat sopia.

Hyödyllinen mentaalinen malli: aihealue on suunnilleen skeema tai domeeni; entiteettiryhmä on karkeasti nimiavaruus tai moduuli; entiteetti on taulukko; attribuutti on sarake. Tämä kartoitus on likimääräinen – CIM on käsitteellinen ja looginen malli, ei fyysinen – mutta se auttaa, kun käännät CIM:n fyysiseksi toteutukseksi.

Supertyypit ja alatyypit

Neljän ydinkomponentin lisäksi CIM-suunnittelu mukauttaa ja laajentaa entiteettejä lisäryhmiin käyttämällä supertyyppejä ja alatyyppejä. Tässä malli saa suuren osan ilmaisuvoimastaan.

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

• Supertyyppi (Supertype) — entiteetti, jota alatyyppientiteetit laajentavat ja joka määrittää yhteiset attribuutit samankaltaisille käsitteille.
• Alatyyppi (Subtype) — entiteetti, joka laajentaa toista entiteettiä ja perii attribuutit supertyyppientiteetiltään.

Klassinen esimerkki on Party. Party on kuka tahansa tai mikä tahansa, jonka kanssa yritys on tekemisissä. Henkilö (Person) ja organisaatio (Organization) ovat molemmat partyja, ja niillä on yhteisiä attribuutteja – nimi, tunnisteet, yhteyspisteet – mutta kummallakin on attribuutteja, joita toisella ei ole.

Party-entiteetin mallintaminen supertyyppinä ja Person- sekä Organization-entiteettien mallintaminen alatyyppeinä välttää jaettujen attribuuttien monistamisen ja pitää suhteet (esimerkiksi “tämä mahdollisuus kuuluu tälle osapuolelle”) johdonmukaisina riippumatta siitä, mikä alatyyppi on kyseessä.

Tällainen periytyminen on vakiintunut konsepti tietomallinnuksessa, ja se esiintyy standardeissa, kuten Object Management Groupin UML:ssä ja koko toimialalla käytetyissä entiteetti-suhde-konventioissa. Kun toteutat CIM:n fyysisesti, sinun on päätettävä, miten periytyminen esitetään:

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

• Yksi taulukko (Single table) — tallenna kaikki alatyypit yhteen taulukkoon erotinsarakkeen (discriminator column) avulla. Yksinkertainen kysellä, mutta voi tuottaa paljon tyhjiä (nullable) sarakkeita.
• Luokkataulukon periytyminen (Class table inheritance) — yksi taulukko supertyypille ja yksi per alatyyppi, yhdistettynä jaetun avaimen avulla. Normalisoitu ja puhdas, mutta vaatii liitoksia (joins).
• Konkreettisen taulukon periytyminen (Concrete table inheritance) — erillinen, itsenäinen taulukko per alatyyppi. Nopea alatyyppikohtaisille kyselyille, mutta monistaa jaetut attribuutit.

Universaalia oikeaa vastausta ei ole. Oikea valinta riippuu kyselymalleista, alatyyppien määrästä ja siitä, kuinka usein jaetut attribuutit luetaan yhdessä. Dokumentoi päätös, koska se vaikuttaa jokaiseen loppupään integraatioon.

CIM-aihealueet

Aihealueet edustavat merkittävimpiä liiketoimintakonsepteja, jotka konsortio on tähän mennessä mallintanut. Jokainen on julkaistu omilla kaavioillaan ja muodoillaan, ja useissa on eksplisiittiset versiomerkit (esimerkiksi v1.0 tai v0.1.1), mikä heijastaa sitä, että jotkut alueet ovat kypsempiä kuin toiset.

Setup — Määrittää, kenen kanssa toimit, esimerkiksi asiakkaan, toimittajan ja myyjän. Se kattaa myös organisaation käyttämät ohjelmisto- ja infrastruktuurikonseptit: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job ja IoT Device.

Data Model — Itse perustavanlaatuiset mallinnuskonseptit.

Hire — Yrityksen perustamiseen liittyvät toiminnot, esimerkiksi sisäinen liiketoimintayksikkö ja työntekijä. Entiteettiryhmiä ovat Job Application, Employee, Compensation, Training, Location, Work Territory ja Work Report.

Biz Process — Liiketoimintaprosessien ja liiketoiminnan jatkuvuuden käsitteet.

Aiheeseen liittyvä: Airbyte — Avoimen lähdekoodin ELT hallitulla pilvivaihtoehdolla.

Produce — Materiaalien käsittely, joita ostat, siirrät ja myyt, esimerkiksi tuote ja varastotuote. Entiteettiryhmiä ovat Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order ja Sales Agreement.

Market — Tuotteen markkinointiin käytettävät toiminnot, esimerkiksi markkinointikampanja ja verkkokauppa. Entiteettiryhmiä ovat Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy ja Web Site.

Sell — Tuotteen myyntiin käytettävät toiminnot, esimerkiksi tarjousten ja mahdollisuuksien luominen. Entiteettiryhmiä ovat Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program ja Competitor.

Mistä aloittaisimme: Matillion — Push-down ELT rakennettu pilvitietovarastoihin.

Service — Myydyn tai huolletun tuotteen tukeen liittyvät toiminnot, esimerkiksi tapaus tai kysely. Entiteettiryhmiä ovat AI Assistant, Asset, Asset Subscription, Web Content, Case, Task ja Event.

Fulfill — Toiminnot, joita suoritat asiakastilauksen täyttämiseksi, esimerkiksi lähetys ja palautustilaus. Entiteettiryhmiä ovat Fulfillment Order, Shipment, Return Order, Work Order, Work Resource ja Work Forecast.

Interact — Toiminnot, joilla seurataan vuorovaikutusta joko loppukäyttäjien tai muiden järjestelmien kanssa. Entiteettiryhmiä ovat Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey ja Loyalty.

Finance — Toiminnot, joilla seurataan yrityksen taloudellisia tietoja, esimerkiksi maksu, lasku ja kuluraportti. Entiteettiryhmiä ovat Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar ja Tax Policy.

Analyze — Tiedon analysointiin liittyvät toiminnot, esimerkiksi mallien, tuotteiden käytön, tiedon liikkumisen, datan muutosten ja asiakastyytyväisyyden analysointi. Entiteettiryhmiä ovat AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty ja Journal.

Huomaa, kuinka aihealueet kattavat sekä toiminnalliset (Sell, Fulfill, Service) että analyyttiset (Analyze, Finance) osa-alueet. Tämä laajuus on asian ydin: jaettu malli on arvokkain, kun se pystyy kuvaamaan saman asiakkaan, tuotteen tai tilauksen johdonmukaisesti riippumatta siitä, sijaitseeko data transaktiollisessa järjestelmässä vai tietovarastossa.

Valinta CIM:n ja muiden standardien välillä

CIM ei ole ainoa jaettu malli yrityksessä. Useat vakiintuneet standardit menevät päällekkäin sen soveltamisalan osien kanssa, ja kypsä arkkitehtuuri käyttää usein useampaa kuin yhtä. Päätös ei ole niinkään voittajan valitsemista, vaan mallin laajuuden ja hallinnon sovittamista ongelmaasi.

Standardi	Ensisijainen painopiste	Tyypillinen vahvuus	Missä CIM eroaa
CIM	Domeenien väliset liiketoimintakonseptit	Laaja, sovellusagnostinen kattavuus CRM/ERP/markkinointi/palvelu	Suunniteltu jaetuksi sateenvarjoksi domeenien välillä
OMG Common Core Ontologies / UML-pohjaiset mallit	Käsitteellinen mallinnusnotaatio ja ylemmät ontologiat	Tiukka muodollinen semantiikka	CIM on suoremmin liiketoimintasuuntautunut
Toimialakohtaiset mallit (esim. vähittäiskauppa, terveydenhuolto, rahoitusalan vertikaalit)	Yhden sektorin syvä kattavuus	Tarkkuus vertikaalin sisällä	CIM vaihtaa syvyyttä laajuuteen
Toimittajatietomallit (CRM/ERP-alustat)	Yhden tuotteen objektit	Tiivis integrointi kyseiseen tuotteeseen	CIM on suunnittelultaan toimittajaneutraali

Käytännön nyrkkisääntö:

• Jos tarvitset jaetun sanaston useiden järjestelmien ja toimittajien välille, laaja malli kuten CIM sopii hyvin.
• Jos tarvitset syvää, säänneltyä, toimialakohtaista semantiikkaa, vertikaalinen standardi on yleensä tarkempi, ja voit kartoittaa sen CIM:ään rajapinnoilla.
• Jos integroit yhden toimittajan ekosysteemin sisällä, kyseisen toimittajan oma malli saattaa riittää – mutta se ei auta sinua yhdistämään tietoja seuraavaan toimittajaan.

Yleisin käytännön malli on hub-and-spoke -lähestymistapa: CIM (tai jokin muu kanoninen malli) on keskellä, ja jokainen lähdejärjestelmä kartoitetaan siihen. Tämä on sama periaate, joka on kanonisten tietomallien taustalla perustiedonhallinnassa (master data management) ja Ralph Kimballin dimensiomallinnuksessa suosiman “conformed dimension” -idean takana.

Käytännön ohjeita CIM:n käyttöönottoon

Yhteisen mallin käyttöönotto on yhtä paljon organisatorinen kuin tekninen harjoitus. Muutamat päätökset ratkaisevat, tuottaako ponnistus tulosta.

Aloita rajatulla laajuudella. Älä yritä kartoittaa jokaista järjestelmää jokaiseen aihealueeseen kerralla. Valitse yksi korkean arvon domeeni – Party ja Sell ovat yleisiä aloituspisteitä, koska asiakas- ja mahdollisuustiedot ovat laajalti päällekkäisiä – ja toteuta kartoitus päästä päähän.

Päätä laajennuskäytännöstäsi ajoissa. CIM on suunniteltu kasvamaan konsortion ja kontribuutioiden myötä, mutta organisaatiosi tarvitsee väistämättä attribuutteja, joita malli ei vielä määrittele. Luo käytäntö paikallisille laajennuksille (esimerkiksi nimiavaruusetuliite), jotta mukautetut attribuutit erottuvat selvästi standardimääritelmistä ja ne voidaan sovittaa yhteen myöhemmin.

Käsittele versiointi ensiluokkaisena huolenaiheena. Aihealueet sisältävät versiomerkit, kuten v1.0 ja v0.1.1, jotka osoittavat, että malli kehittyy. Kiinnitä versio, jota vasten rakennat, seuraa muutoksia ja suunnittele migraatio. Tämä on sama kurinalaisuus, jota soveltaisit mihin tahansa riippuvuuteen.

Kartoita, älä kopioi. CIM on käsitteellinen ja looginen malli. Vastusta kiusausta luoda fyysisiä skeemoja suoraan siitä ottamatta huomioon suorituskykyä, indeksointia ja niiden järjestelmien käyttökuvioita, jotka kuluttavat dataa. Käytä mallia merkitysten yhdenmukaistamiseen ja suunnittele sitten fyysinen tallennustila työkuormasi mukaan.

Hallitse kartoitusta. Lähdejärjestelmän ja CIM:n välinen kartoitus on itsessään voimavara. Versioi se, tarkista se ja määritä omistajuus. Tietojen integroinnin työkalut – ETL- ja ELT-alustat, tietoluettelot ja lineage-työkalut – voivat auttaa sinua seuraamaan, mistä kukin attribuutti on peräisin ja miten se virtaa, mikä on juuri sellaista metatietoa, jota Analyze-aihealue ennakoi entiteeteillä kuten Data Lineage.

Ota yhteisö mukaan. Koska CIM on avoimen lähdekoodin ja konsortiolähtöinen, löytämäsi puutteet ovat usein puutteita, jotka myös muut ovat löytäneet. Ehdotetun entiteetin tai attribuutin lahjoittaminen takaisin projektiin on sekä hyvää kansalaisuutta että tapa vähentää pitkäaikaista ylläpitotaakkaasi.

Formaatit, kaaviot ja kulutus

CIM-mallit ovat saatavilla useissa formaateissa jokaiselle toimialueelle, mukaan lukien esimerkkikaaviot. Tällä on merkitystä, koska eri kohderyhmät kuluttavat tietomallia eri tavalla:

• Arkkitehdit haluavat kaavioita ja suhdenäkymiä rakenteen analysoimiseksi.
• Insinöörit haluavat koneellisesti luettavia määritelmiä, joita he voivat syöttää koodigeneraatioon, skeeman validointiin tai kartoitustyökaluihin.
• Analyytikot ja data stewardit haluavat dokumentaatiota, joka selittää, mitä kukin entiteetti ja attribuutti tarkoittaa liiketoimintatermein.

Julkaiseminen useissa formaateissa on tietoinen suunnitteluvalinta, joka alentaa käyttöönoton kynnystä. Kun arvioit mitä tahansa jaettua mallia, tarkista, että se toimitetaan formaateissa, joita työkaluketjusi voi todella lukea – malli, joka on olemassa vain PDF-tiedostona, on paljon vähemmän hyödyllinen kuin malli, jossa on jäsennellyt määritelmät.

Usein kysyttyjä kysymyksiä

Mikä on Cloud Information Model (CIM)?

Cloud Information Model on avoin, sovellusagnostinen tietomalli, joka määrittelee jaetut liiketoimintakonseptit – kuten Party, Account ja Sales Order – jotta erilaiset pilvi- ja on-premises-järjestelmät voivat vaihtaa tietoja yhteisen sanaston avulla. Se on järjestetty aihealueisiin, entiteettiryhmiin, entiteetteihin ja attribuutteihin, ja sitä hallinnoidaan avoimen lähdekoodin projektina The Linux Foundationin alaisuudessa.

Mitä eroa on supertyypillä ja alatyypillä CIM:ssä?

Supertyyppi on entiteetti, jota alatyyppientiteetit laajentavat ja joka määrittelee samankaltaisille käsitteille yhteiset attribuutit. Alatyyppi laajentaa toista entiteettiä ja perii supertyyppinsä attribuutit. Esimerkiksi Party voi toimia supertyyppinä, jolloin Person ja Organization ovat alatyyppejä; näin jaetut attribuutit määritetään kerran ja erikoistuneet attribuutit sijaitsevat alatyypissä.

Miten CIM liittyy tietokantaskeemaan?

CIM on käsitteellinen ja looginen malli, ei fyysinen skeema. Sen entiteetit ovat analogisia tietokantatauluille ja sen attribuutit kentille, mikä tekee kääntämisestä intuitiivista, mutta sinun tulee silti suunnitella fyysinen tallennustila – indeksointi, osiointi, denormalisointi – omien kyselykuvioidesi mukaan sen sijaan, että kopioisit mallia kirjaimellisesti.

Korvaako CIM toimialakohtaiset tietostandardit?

Ei. CIM on laaja ja monialueinen, kun taas vertikaaliset standardit ovat syvällisiä ja sektorikohtaisia. Monet organisaatiot käyttävät hub-and-spoke-lähestymistapaa, jossa CIM toimii kanonisena mallina keskellä ja toimialastandardit tai toimittajamallit kartoitetaan siihen reunoilla.

Miksi CIM-aihealueilla on versionumerot?

Versiomerkit, kuten v1.0 ja v0.1.1, osoittavat, että malli kehittyy ja että jotkut aihealueet ovat kypsempiä kuin toiset. Version kiinnittäminen, muutosten seuranta ja migraatioiden suunnittelu on samaa riippuvuuksien hallinnan kurinalaisuutta, jota soveltaisit mihin tahansa jaettuun kirjastoon tai skeemaan.

Miten käsittelen attribuutteja, joita CIM ei määrittele?

Luo dokumentoitu laajennuskäytäntö, kuten nimiavaruusetuliite, jotta mukautetut attribuutit ovat selvästi erotettavissa standardeista. Harkitse sitten puutteen raportointia ja täydentämistä takaisin projektiin, koska malli on suunniteltu kasvamaan konsortion ja yhteisön panoksilla.