Hei,
Olen kirjoittanut viime aikoina semanttisesta kerroksesta, koska se on hyvin ajankohtainen aihe ja tarjoaa paljon mahdollisuuksia datatiimeille.
Niin sanottu self-service BI ei ole koskaan oikeasti toteutunut, mutta nyt AI myötä sille on ehkä parhaat mahdollisuudet historiassa. Kutsun tätä conversational BI:ksi: bisnes voi luonnollisella kielellä kysyä AI-chatissa esimerkiksi, mikä on asiakaspoistuma viime kvartaalilla, tai hävikki tietyllä tuoteryhmällä viime vuosipuoliskolla.
Varmasti semanttisella kerroksella on muitakin käyttötapauksia, mutta datan hyödyntämisen näkökulmasta juuri tuo conversational BI on se graalin malja.
On minusta myös selvää, että semanttinen kerros ei ole vain teknologiaa, vaan liiketoiminnan käsitteiden ja mittareiden määrittelyä ja sitä, miten ne saadaan dokumentoitua tehokkaasti.
Joku lukija voi ajatella, että hyvä juttu, mutta millä tämä sitten käytännössä rakennetaan?
Se on reilu kysymys, ja tässä blogissa yritän vastata siihen. Mutta haluan heti alkuun tehdä yhden rajauksen: en käy läpi, kannattaako valita Snowflake vai Databricks, Claude vai ChatGPT, tai mikä yksittäinen datakatalogi on paras.
Nämä ovat valideja kysymyksiä, mutta ne ratkeavat yrityksenne omassa kontekstissa: olemassa olevan alustan, budjetin ja tiimin osaamisen perusteella.
Enkä missään tapauksessa voi olla objektiivinen kaikista näistä, olen itse yksi Ellie.ai perustajista, joka sekin toimii yhtenä vaihtoehtona tähän kokonaisuuteen.
Sen sijaan haluan avata, mistä palasista setup ylipäätään koostuu, mikä rooli kullakin palasella on, ja minkä tyyppisiä vaihtoehtoja kussakin kategoriassa on. Kun ymmärtää roolit, oman organisaation työkaluvalinta muuttuu paljon helpommaksi tehdä itse.
Muutama ulottuvuus ensin
Ennen kuin mennään palasiin, kannattaa erottaa toisistaan muutama ulottuvuus, jotka menevät helposti sekaisin, kun puhutaan ”semanttisesta kerroksesta”.
Ensimmäinen on päätös ja prosessi. Jonkun, ihmisen tai tiimin, pitää päättää, mitä ”asiakas” tai ”tuote” tarkoittaa, ja miksi jokin KPI lasketaan juuri niin kuin se lasketaan. Miksi vaikkapa CAC (customer acquisition cost) lasketaan juuri näillä kustannuksilla?
Kuka päätti, että aktiivinen asiakas tarkoittaa käyttöä viimeisten 30 päivän aikana eikä 60 päivän? Tämä on se päätöksentekoprosessi, ja se tapahtuu ihmisten kesken, ei minkään työkalun sisällä.
Toinen ulottuvuus on se, onko tämä päätös jaettu määritelmä. Onko olemassa jokin prosessi, joka varmistaa, ettei myynti, markkinointi ja talous päädy kukin laskemaan samaa mittaria omalla tavallaan? Pelkkä määritelmän kirjoittaminen jonnekin ei vielä riitä, jos kukaan ei omista sitä, ylläpidä sitä, tai varmista, että kaikki osastot oikeasti käyttävät samaa versiota.
Tämä hallintomalli (data governance), kuka omistaa määritelmän ja miten ristiriidat ratkaistaan, ratkaisee usein enemmän kuin mikään yksittäinen työkaluvalinta.
Kolmas ulottuvuus on itse termi ”semantic layer” teknisessä mielessä. Sen historia juontaa juurensa vanhoihin BI-työkaluihin, ja termin lanseerasi alun perin ranskalainen Business Objects -yhtiö, joka jätti patenttihakemuksen tästä lähestymistavasta jo vuonna 1991 (patentti myönnettiin 1996).
AtScalen perustaja Dave Mariani on itse kertonut lainanneensa termin ”semantic layer” suoraan Business Objectsilta 1990-luvulta, se oli tuolloin jo pitkään käytössä ollut termi, kun moderni semantic layer -sukupolvi otti sen uudelleen käyttöön 2010-luvulla.
Tämä historia selittää, miksi termi sekoittuu edelleen niin helposti moneen eri asiaan. Alun perin semantic layer tarkoitti BI-maailmassa abstraktiokerrosta fyysisen datan ja raportointikäyttäjän välillä: tekniset taulut, joinit ja SQL piilotettiin liiketoimintatermien, dimensioiden ja mittareiden taakse. Nykyään sama sana kattaa kaiken business glossarystä metric layeriin ja AI-orchestrationiin asti.
Siksi kannattaa aina kysyä keskustelukumppanilta tarkennusta, mitä hän tarkalleen tarkoittaa ”semanttisella kerroksella”, koska kolme eri ihmistä samassa palaverissa voi tarkoittaa kolmea aivan eri asiaa. Seuraavaksi puran tämän auki.
Monia eri rooleja ja työkaluja
Kun ihmiset puhuvat ”semanttisesta kerroksesta”, he tarkoittavat usein hyvin eri asioita. Osa tarkoittaa business glossarya. Osa tarkoittaa datakatalogia. Osa tarkoittaa dbt metriikkamäärityksiä. Osa tarkoittaa sillä KPIä. Sitten on vielä erikseen ontologiat ja knowledge graph -mallinnus, joilla on hieman eri käyttötapaus kuin datamallinnuksella, joskin hyvin edistyksellinen ajattelutapa.
Käytännössä kyse on eri näkökulmista tai rooleista, jotka voivat asua samassa työkalussa tai eri työkaluissa:
Ensimmäinen on liiketoiminnan semantiikka: käsitteet, niiden väliset suhteet, business glossary ja KPI. Tässä päätetään ja dokumentoidaan, mitä ”asiakas”, ”aktiivinen asiakas” tai ”CAC” tarkoittavat, miten käsitteet liittyvät toisiinsa ja kuka ne omistaa. Tämä on se liiketoiminnan työ, josta kirjoitin edellisessä blogissa.
Toinen on metadata ja governance, jonka keskeinen työkalu on usein datakatalogi. Tässä elää metadata, omistajuustiedot, lineage ja tieto siitä, mistä mikäkin data löytyy fyysisesti. Käytännössä katalogit sisältävät nykyään usein myös glossarya ja muita semanttisia ominaisuuksia, joten raja ensimmäiseen kategoriaan ei ole enää kovin tarkka.
Kolmas on suoritettava semantiikka, eli metriikka- tai semantic layer. Tässä käsitteiden ja KPI määritelmät linkitetään laskettuun, uudelleenkäytettävään logiikkaan, joka tarjoillaan johdonmukaisesti kaikille kuluttajille, oli kysyjä sitten Power BI, Tableau tai Claude.
Neljäs on AI kulutus- ja integraatiokerros, eli se, miten tekoäly, Claude tai muu, pääsee käsiksi edellä mainittuihin kolmeen. MCP (Model Context Protocol) ei ole semanttinen kerros itsessään, vaan yksi standardoitu rajapinta, jonka kautta agentti voi löytää ja kutsua työkaluja ja resursseja — API, SQL/JDBC, GraphQL ja vendor-kohtaiset integraatiot eivät ole kadonneet mihinkään. Mutta MCPä on nopeasti muodostumassa yksi keskeisistä standardeista tähän tarkoitukseen.
Moni tuote yrittää nykyään tehdä useampaa näistä rooleista yhdessä paketissa. Snowflake ja Databricks rakentavat omiin alustoihinsa yhä enemmän ominaisuuksia, jotka kattavat useita näistä vastuista. Myös esimerkiksi Atlan asemoi itseään nykyään laajemmin kontekstikerroksena kuin pelkkänä datakatalogina. Mutta rooleja kannattaa silti ajatella erikseen, koska juuri se auttaa hahmottamaan, mistä oma puuttuva palanen löytyy.
Yksi asia kannattaa pitää mielessä koko loppuartikkelin ajan: nämä neljä eivät ole neljä pakollista tuotetta, vaan neljä loogista vastuuta. Yksi tuote voi toteuttaa kolme näistä vastuista, ja yhdessä organisaatiossa niitä voidaan tarvita neljä eri tuotetta. Tämä ei siis ole ostoslista, vaan kartta siitä, mitä vastuita jonkun, työkalun tai ihmisen, pitää kantaa.
Tästä seuraa myös se, että kategoriat menevät väistämättä päällekkäin: esimerkiksi Ellie.ai mallintaa myös metadataa, ja Collibra pystyy tallentamaan KPI-määrityksiä omassa glossary-moduulissaan. Kun sijoitan työkalun johonkin kategoriaan alla, tarkoitan sen pääasiallista vahvuutta ja fokusta, en sitä, että se ei kykenisi mihinkään muuhun.
Käydään nämä roolit läpi yksi kerrallaan.
Liiketoiminnan semantiikka: käsitteet, relaatiot ja KPI
Tässä määritetään käsitteet, niiden väliset suhteet ja niiden pohjalta rakennettavat KPI ja muu raportointi. Tämä on se kerros, jossa vastataan kysymykseen ”mitä aktiivinen asiakas tarkoittaa meillä?”.
Tyypillisesti, kun rakennetaan uusia KPI ja data-alustoja, tämä on se hetki, jolloin bisnes osallistuu (ei edes silloin aina) ja heiltä saadaan määrityksiä.
Tämän jälkeen datatiimit ovat usein omillaan. BI-raportointitarve seuraa tyypillisesti sitä vaihetta, jolloin nämä määritellään tai datatiimit kuulevat niistä bisnekseltä.
(Tiedän kyllä, etteivät kaikki datatiimit osallistu tähän, vaan uusien raporttien määrityksiä yritetään kaivaa olemassa olevista dashboardeista.)
Perinteisen prosessin mukaan määritelmät ovat asuneet BI-työkalun sisällä tai jonkun analyytikon Excel-kaavassa. Tämä on ymmärrettävää, koska juuri siellä mittari lasketaan ja näytetään ensimmäisen kerran.
Myöhemmin on kuitenkin ymmärretty, että se on huono paikka koko käsitteen kotipesäksi, ja tähän on kolme syytä. Ensinnäkin BI-työkalu tallentaa yhden lasketun tuloksen, ei sitä prosessia tai perustelua, jolla määritelmään päädyttiin: miksi CAC lasketaan juuri näillä kustannuksilla, kuka sen hyväksyi, milloin se on viimeksi tarkistettu.
Toiseksi BI-työkalun painopiste on eri: se on rakennettu näyttämään laskettu tulos, ei kuvaamaan rakennetta, jossa ”aktiivinen asiakas” on erikoistapaus käsitteestä ”asiakas” tai että eri osastot käyttävät samasta asiasta eri synonyymejä. Kolmanneksi määritelmät elävät raportti- tai työkirjakohtaisesti, joten täsmälleen sama mittari voi hiljaa haarautua moneen eri laskentatapaan eri dashboardeissa.
Lisäksi liiketoiminta harvoin pääsee, tai osaa, muokata DAX-kaavaa tai calculated fieldiä suoraan, joten omistajuus jää käytännössä IT, vaikka määritelmän pitäisi olla liiketoiminnan omistama.
Mallinnustyökalut ovat eri kerroksessa
Missä se glossary sitten oikeasti on? Tyypillisesti tätä problematiikkaa, käsitteiden, niiden suhteiden ja omistajuuden mallintamista, käydään läpi käsitemallinnuksen yhteydessä, eli data modeling -työkaluilla. Miksi siihen tarvitaan data-mallia? Koska relaatiot ovat olennaisia näissä määrityksissä:
Asiakas voi olla mikä tahansa yritys, mutta kun siihen määritetään relaatio sopimuksen kanssa, määritys selkeytyy, nyt ”asiakas” tarkoittaa nimenomaan tahoa, jolla on voimassa oleva sopimus, ei esimerkiksi pelkkää liidiä CRMä.
Tähän kategoriaan kuuluu erilaisia data- ja semantic modeling -työkaluja, kuten Ellie.ai, jonka olen itse ollut perustamassa (en siis voi olla tässä objektiivinen, sama varaus kuin edellisessä blogissani), sekä perinteisempiä, tietokantojen suunnitteluun ensisijaisesti tarkoitettuja data modeling -ratkaisuja kuten erwin, SqlDBM ja ER/Studio.
Näiden työkalujen kyvykkyydet ja painotukset vaihtelevat. Osa painottaa enemmän konseptuaalista ja liiketoimintatason mallinnusta ja glossarya, osa taas loogista ja fyysistä tietokantasuunnittelua. Niillä voidaan eri tavoin mallintaa käsitteitä, niiden suhteita ja datarakenteita sekä linkittää liiketoiminnan semantiikkaa fyysiseen dataan. Tämän kategorian yhteinen ajatus on sama: käsitteet ja niiden suhteet eivät ole pelkkä tekninen sivutuote, vaan niitä voidaan hallita erillään yksittäisestä raportista tai tietokantatoteutuksesta.
Datakatalogeissakin on usein oma glossary-moduulinsa. Palaan tähän tarkemmin seuraavassa osiossa, koska katalogin ja edellä kuvatun käsitemallinnustyökalun ero kannattaa ymmärtää ennen kuin valitsee kumpaa käyttää.
Koska nämä kategoriat menevät käytännössä päällekkäin, tein artikkelin loppuun yhteenvedon siitä, mikä kussakin työkalussa on pääasiallinen syy ostaa se, ei kaikki mitä sillä teoriassa voi tehdä.
Kevyin ja manuaalisin vaihtoehto on Confluence, Notion tai Excel. Tämä ei ole huono vaihtoehto MVP-vaiheessa (minimum viable product). Se skaalautuu kuitenkin huonosti heti, kun käsitteitä pitää alkaa linkittää toisiinsa ja fyysiseen dataan systemaattisesti.
Datakatalogit: mikä niiden rooli oikeasti on
Kun puhutaan semanttisesta kerroksesta, keskeinen alue on tietysti metadata eli dataa datasta. Ja moni ajattelee intuitiivisesti, että datakatalogit tarkoittavat juuri tätä. Moni kysyy: eikö datakatalogissa ole jo glossary ja KPI valmiiksi?
Osittain kyllä. Mutta katalogin ja edellä kuvatun käsitemallinnustyökalun välillä on edelleen hyödyllistä tehdä ero, vaikka niiden rajat ovat hämärtyneet nopeasti.
Datakatalogit on rakennettu ensisijaisesti metadatan hallintaan: mitä dataa on olemassa, missä se sijaitsee, kuka sitä omistaa, mistä se on peräisin ja kuka sitä käyttää. Moni katalogi, kuten Atlan, kuvaa itsensä nykyään myös ”kontekstikerroksena” AI-agenteille, ja rakentaa glossaryn, käsitteiden välisiä suhteita ja muuta semanttista kontekstia osaksi tuotettaan. Tämä tarkoittaa, että raja business glossaryn ja datakatalogin välillä on hämärtymässä.
Silti ero on käytännössä yhä hyödyllinen. Katalogin perinteinen vahvuus on siinä, mitä dataa on, missä se sijaitsee ja miten se liikkuu, kun taas käsitemallinnuksen lähtökohta on enemmän siinä, mitä asiat tarkoittavat ja miten ne liittyvät toisiinsa. Uudet katalogituotteet tulevat koko ajan pidemmälle jälkimmäiselle alueelle, joten tämä ei ole enää mikään ehdoton tuoteryhmäraja. Tässä yksinkertainen yhteenveto yleisimmistä vaihtoehdoista, karkealla tasolla, tarkat ominaisuudet muuttuvat nopeasti, joten kannattaa aina tarkistaa toimittajalta ajantasainen tilanne:
- Collibra: vahva perinteinen data governance ja katalogi -tuote, laaja metadatan hallinta, glossary-moduuli mukana. Raskaampi käyttöönotettava, tyypillisesti suurille organisaatioille.
- Atlan: moderni, AI-agenteille suunnattu ”context”-lähestymistapa, laaja integraatioverkosto, glossary ja metriikka-avustus AI tuottamana ja ihmisen sertifioimana. Nuorempi tuote kuin Collibra.
- Alation: vahva datan löydettävyys ja käytön hallinta, pitkä historia data governance -puolella, glossary mukana osana laajempaa hallintamallia.
- Microsoft Purview: luonteva valinta, jos organisaatio on jo syvällä Microsoft-ekosysteemissä (Fabric, Azure) — integroituu näihin tiiviisti. Työkalu on hyvin tekninen, ja kuulen monilta, että vaikka se alkuun tuntuisi järkeen käyvältä, se ei ole päätynyt käyttöön.
- data.world: kevyempi, avoimempaan dataan ja yhteisölliseen glossary-ylläpitoon nojaava lähestymistapa.
Yhteinen huomio kaikille: jos organisaatiolla on jo jokin näistä käytössä, se on erinomainen lähtöpiste. Toisaalta, en ole varma kannattaako hankkia raskasta katalogituotetta pelkästään tähän AI use caseen, jos muuten pärjää ilman.
Metric layer -työkalut: mitä ne oikeasti tekevät, ja tarvitaanko niitä jos on dbt
Glossary ja datakatalogi ratkaisevat sen, missä käsite ja sen omistajuus asuvat. Mutta käytännössä organisaatiossa on tyypillisesti monta BI-prosessia, useita data-analyytikkoja ja useita tiimejä, jotka kaikki tarvitsevat saman laskennan käyttöönsä.
Juuri tähän tarpeeseen syntyivät erilliset metric layer -työkalut. On kuitenkin syytä olla tarkka siitä, mitä ne tekevät: glossary ja metric layer eivät ole automaattinen putki, jossa liiketoimintamääritelmä muuttuu suoraan lasketuksi logiikaksi. Kyse on ennemmin kahdesta toisiinsa linkitettävästä artefaktista, liiketoimintamääritelmästä ja sitä vastaavasta executable-metriikkamäärityksestä, ja jonkun tai jonkin integraation täytyy pitää ne kaksi synkassa.
Metric layer -työkalu tarjoilee tämän lasketun logiikan sitten johdonmukaisesti kaikille kuluttajille, sen sijaan että jokainen BI-työkalu tai AI-agentti kirjoittaisi oman tulkintansa samasta mittarista.
dbt oma vastaus tähän on dbt Semantic Layer, jota ajaa moottori nimeltä MetricFlow. MetricFlow mahdollistaa metriikan määrittelyn kerran mallinnuskerroksessa (dbt-projektissa), minkä jälkeen samaa määritelmää voidaan käyttää johdonmukaisesti kaikkialla.
Tässä on tapahtunut merkittävä muutos viime aikoina: vuoden 2025 lopulla dbt Labs avasi MetricFlow’n lähdekoodin Apache 2.0 -lisenssillä. Tämä ei kuitenkaan tarkoita, että koko dbt Semantic Layer olisi ilmainen, itse metriikkamoottori on nyt avoin, mutta valmiit liitännät BI-työkaluihin ja dbt hallinnoitu Semantic Layer -palvelu kuuluvat edelleen dbt kaupalliseen kokonaisuuteen.
Avautuminen liittyy laajempaan alan aloitteeseen, jonka tavoite on yksinkertainen: sama metriikkamääritys pitäisi toimia työkalusta toiseen, eikä jokainen alusta tulkitsisi samaa mittaria eri tavalla. Aloite on sittemmin siirtynyt Apache Software Foundationin alle ja dbt tukee sen mukaisia määrityksiä uusimmissa versioissaan. (Linkit tarkkoihin tiedotteisiin lopussa, jos haluat mennä syvemmälle.)
Jos data on jo läpikotaisin mallinnettu dbtä, MetricFlow on luonteva jatke, koska määritelmät istuvat samaan repoon transformaatiologiikan kanssa. Perusrajoite pysyy silti samana kuin ennenkin: määritelmät kirjoitetaan YAML, eli ne pysyvät käytännössä data-engineerin tai muun teknisen käyttäjän ylläpidettävinä, eivät liiketoiminnan, avoin lähdekoodi ei muuta sitä, kuka niitä käytännössä muokkaa.
Toinen ryhmä on alustariippumattomat metric/semantic layer -tuotteet, kuten Cube ja AtScale. Näiden lupaus on, että metriikka määritellään kerran keskitetysti, ja sama kerros palvelee sekä BI-työkaluja että AI-agentteja riippumatta siitä, missä data fyysisesti sijaitsee. Tämä on hyödyllistä erityisesti silloin, kun dataa on useassa eri alustassa, tai kun useampi kuluttaja, BI-työkalut kuten Tableau ja Power BI, tarvitsee saman metriikan johdonmukaisesti.
Data-alustojen omat metriikkakerroksen ominaisuudet
Kolmas ryhmä ovat data-alustojen omat natiivit ratkaisut. Snowflake tarjoaa Semantic Views -objekteja, jotka tallentavat faktat, metriikat ja dimensiot suoraan tietokantatasolle, ja joita Cortex Analyst voi käyttää generoidessaan SQL:ää luonnollisen kielen kysymyksiin. Databricks tarjoaa nykyään Unity Catalog Semantics -kokonaisuutta, jonka ytimessä ovat esimerkiksi keskitetysti hallittavat Metric Views -objektit ja muu liiketoimintakonteksti, jota myös Genie voi hyödyntää. Microsoft Fabricissa ja Power BIä vastaava rooli on semanttisella mallilla (”semantic model” , Microsoftin nykyinen termi, aiempi ”semantic dataset” on vanhentunut), jonka metadataa, DAX-mittareita ja kuvauksia Copilot käyttää kontekstinaan.
Näiden natiivien ratkaisujen etu on nopeus: jos kaikki data ja käyttö on yhden alustan sisällä, ei tarvita erillistä työkalua.
Tähän liittyy kuitenkin kaksi rajoitetta. Ensimmäinen: monilla isoilla organisaatioilla on käytössä useita data-alustoja rinnakkain, ja legacy-järjestelmiä on tyypillisesti vielä mukana. Siksi isommissa organisaatioissa tulee helposti vastaan tarve jollekin kerrokselle näiden yläpuolelle, jossa metadataa ja glossarya hallinnoidaan keskitetysti, natiivi ratkaisu kattaa erittäin hyvin oman alustansa, mutta ei välttämättä koko organisaation kokonaiskuvaa.
Toinen rajoite on pitkälti sama kuin dbtä: nämä työkalut on ensisijaisesti rakennettu data- ja analytiikkatiimien workflowhon. Niihin ei välttämättä kuulu sitä prosessia, jossa KPI määritellään yhdessä liiketoiminnan kanssa, se fasilitointityö pitää tehdä jossain muualla, tässä artikkelissa kuvatun kategorian 1 (liiketoiminnan semantiikka: käsitteet, relaatiot ja KPI) puolella.
Chatbotit, Claude ja MCP: miten tekoäly kytkeytyy data-alustaan
Kun kategoriat yksi, kaksi ja kolme ovat olemassa, jäljelle jää kysymys: miten Claude tai muu tekoäly oikeasti pääsee niihin käsiksi, kun käyttäjä kirjoittaa chattiin kysymyksen?
Loogisesti AI tarvitsee kaksi asiaa. Sen pitää ymmärtää, mitä käyttäjän käyttämät liiketoimintatermit tarkoittavat juuri tässä organisaatiossa, ja sillä pitää olla luotettava tapa muuntaa nämä käsitteet fyysistä dataa vasten suoritettavaksi kyselyksi. Nämä voivat sijaita eri työkaluissa tai saman alustan semantic modelissa.
Käyttäjä voi esimerkiksi kysyä ”mikä oli asiakaspoistuma viime kvartaalilla yritysasiakkailla”. Jossain semanttisessa kokonaisuudessa pitää silloin olla tieto siitä, mitä ”asiakaspoistuma” ja ”yritysasiakas” tarkoittavat, miten ne liittyvät dataan ja miten laskenta toteutetaan.
Joissain arkkitehtuureissa AI hakee määritelmän business glossarystä ja käyttää sen jälkeen erillistä metric layeria. Toisissa tämä kaikki tapahtuu saman alustan semantic modelin tai semantic view’n kautta. Lopputuloksen pitäisi kuitenkin olla sama: laskenta tehdään hallitun semantiikan perusteella eikä niin, että AI kirjoittaa joka kerta oman tulkintansa samasta mittarista. Parhaassa tapauksessa vastauksen mukana kulkee myös tieto siitä, mistä määritelmästä ja mistä datasta vastaus on peräisin.
MCP, Model Context Protocol, on tällä hetkellä yksi keskeisimmistä tavoista toteuttaa näitä yhteyksiä teknisesti, ei ainoa, mutta nopeasti yleistyvä. Se on avoin protokolla, jonka avulla AI-malli voi standardoidusti kutsua ulkopuolisia työkaluja ja lukea resursseja, sen sijaan että jokaiselle järjestelmälle pitäisi rakentaa oma räätälöity integraatio. Käytännössä tämä tarkoittaa, että esimerkiksi business glossary -työkalu tai metric layer -työkalu voi tarjota oman MCP-serverinsä, jota vasten Claude tai muu MCPä tukeva agentti keskustelee.
On hyvä muistaa, että vaikka MCP-tuki laajenee nopeasti kaikkialla, sen kypsyysaste vaihtelee vielä alustan mukaan, joten kannattaa tarkistaa juuri se rajapinta, jota itse tarvitsette.
Tässä kategoriassa tilanne on itse asiassa helpompi kuin edellisissä kolmessa: valinta ei ole niinkään ”mikä MCP-serveri on paras”, vaan ”miten valitsemani AI-provider ja data-alusta tarjoavat pääsyn näihin semanttisiin palveluihin”. MCP on yksi tärkeä vaihtoehto, mutta myös API ja alustojen omat integraatiot säilyvät. Tämä kerros on todennäköisesti kuitenkin se, jossa standardoituminen etenee nopeimmin.
Hyvä todiste siitä, että arkkitehtuuri ja prosessi ratkaisevat enemmän kuin yksittäinen työkalu, löytyy Anthropicin omasta esimerkistä.
He rakensivat sisäisen semanttisen kerroksen dimensionaalisen mallinnuksen periaattein, pitivät metriikkamääritykset, transformaatiologiikan ja dokumentaation samassa repossa, ja lisäsivät päälle niin sanotut ”skills”, markdown-muotoista proseduraalista tietoa, joka ohjaa AI oikeiden määritelmien ja työkalujen luo.
Ilman tätä kontekstikerrosta tarkkuus oli 21 prosenttia. Kontekstikerroksen ja ”skills”-mekanismin kanssa tarkkuus nousi yli 95 prosentin ja tietyillä osa-alueilla lähes 99 prosentin. Nämä ovat Anthropicin omia sisäisiä eval-tuloksia, ei yleinen benchmark siitä mitä metric layer tekee jokaisessa organisaatiossa, mutta suunta on silti kuvaava.
Tässä ei ollut kyse yhden oikean työkalun löytämisestä, vaan siitä, että käsitteet, laskentalogiikka ja fyysinen data saatiin yhdistettyä johdonmukaiseksi kokonaisuudeksi, jota AI pystyi luotettavasti käyttämään.
Miten sitten valita oma setup?
Palataan alkuperäiseen kysymykseen: mikä setup toimisi parhaiten? Vastaus riippuu muutamasta kysymyksestä, joita kannattaa käydä läpi ennen kuin katsotaan yhtään tuote-esittelyä.
Kuinka moneen alustaan data on hajautunut? Jos kaikki elää yhden alustan, esimerkiksi pelkän Snowflaken tai pelkän Databricksin, sisällä, kyseisen alustan natiivit työkalut kannattaa kokeilla ensin. Jos dataa on useassa alustassa ja SaaS-järjestelmässä, alustariippumaton metric layer tai muu yhteinen semanttinen kerros tuo enemmän hyötyä.
Onko organisaatiolla jo datakatalogi tai KPI dokumentoitu jonnekin? Jos on, lähtökohta ei ole uuden työkalun ostaminen, vaan olemassa olevan täydentäminen relaatioilla, laskentasäännöillä ja fyysisillä linkityksillä.
Kuka määritelmät oikeasti omistaa, ja kuka niitä ylläpitää jatkossa? Jos vastaus on ”data-engineering-tiimin YAML-tiedostossa”, määritelmät eivät todennäköisesti pysy ajan tasalla, jos liiketoiminta ei pääse niihin käsiksi. Tämä kysymys ratkaisee usein enemmän kuin mikään yksittäinen työkaluominaisuus.
Ja lopuksi, sama neuvo kuin ensimmäisessä blogissani: älä osta koko pinoa kerralla. Valitse yksi liiketoimintakriittinen KPI, esimerkiksi asiakaspoistuma, rakenna sille käsitemäärittely, semanttinen laskenta ja AI-yhteys, ja testaa toimiiko se luotettavasti ja toistettavasti. Vasta sen jälkeen kannattaa miettiä, mitkä palaset skaalataan koko organisaation käyttöön ja millä työkaluilla.
Teknologia on tässä lopulta toissijainen kysymys. Tärkeintä on ymmärtää, mitä roolia ollaan täyttämässä, ja rakentaa se palanen kerrallaan yhdessä liiketoiminnan kanssa.
Yhteenveto: työkalujen pääasialliset vahvuudet
Koska kategoriat menevät käytännössä päällekkäin (esim. Ellie mallintaa myös metadataa, ja Collibra pystyy tallentamaan KPI-määrityksiä glossary-moduulissaan), tässä on yhteenveto siitä, mikä kussakin työkalussa on pääasiallinen syy ostaa se, ei kaikki mitä sillä teoriassa voi tehdä. ”Relaatiot”-sarake viittaa entiteettien väliseen mallintamiseen (esim. asiakas–sopimus), josta puhuin aiemmin. Tuo business-friendliness-ulottuvuus on mielestäni myös tärkeä, koska bisneksen saaminen mukaan tähän määrittelytyöhön on olennaista, varsinkin skaalautumisvaiheessa.
Yhteenvetona vielä totetaisin, että minusta koko kokonaisuuden tärkein ja ehkä vaikein osa on tuo business glossary: miten käsitteet määritellään yhdessä liiketoiminnan kanssa, miten niitä ylläpidetään ja miten varmistetaan, että sama merkitys säilyy eri työkaluissa ja käyttötapauksissa. Teknologia voi auttaa tässä paljon, mutta se ei ratkaise itse hallintaongelmaa. Vähän samaan tapaan kuin moderni taloushallinnon järjestelmä ei itsessään ratkaise yrityksen talousongelmia. Kaikki lähtee siitä, että perusasiat on sovittu oikein.
Johannes Hovi
Growth Director, Ari Hovi. Yksi Ellie.ai perustajista. Kirjoittaa data-arkkitehtuurista, semanttisesta mallinnuksesta ja AI hyödyntämisestä BI-kontekstissa.
Lue myös:
- Semanttisen kerroksen vaikein osa ei ole teknologia
- Miten BI-ala siirtyy raporteista keskusteluun — ja miksi semanttinen kerros ratkaisee sen
Lähteet:
- How Anthropic enables self-service data analytics with Claude
- Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative
- Announcing open source MetricFlow: Governed metrics to power trustworthy AI and agents (dbt Labs)
- OSI is now Apache Ossie (Incubating) (dbt Labs)
