Hei,
Yrityksissä on viime vuosina investoitu valtavasti moderneihin data-alustoihin. On rakennettu lakehouseja, ja kehittyneitä raportointiratkaisuja.
Monessa organisaatiossa on juuri päästy tilanteeseen, jossa vuosia kestänyt siirtymä vanhoista on-premise-tietovarastoista Snowflakeen, Databricksiin, Fabriciin tai muihin pilviratkaisuihin alkaa olla ainakin jollain tasolla valmis.
Nyt tekoäly tulee kovaa vauhtia seuraavaksi suureksi datan käyttötapaukseksi. Luonteva ajatus on tietenkin se, että käytetään samaa data-alustaa myös AI:lle, siellähän data jo on. Mutta olen viime aikoina miettinyt, onko asia välttämättä näin yksinkertainen.
Voisiko seuraava data-alustojen migraatioaalto olla siirtyminen pilvidata-alustoista AI-ready data-alustoihin?
En tiedä itsekään varmaa vastausta tähän. Ajattelin siis pohtia vaihtoehtoja enemmän arkkitehtuurin näkökulmasta kuin julistaa yhtä oikeaa ratkaisua.
Pilveen siirtyminen ei vielä tehnyt alustasta AI-readyä
Ensimmäisessä modernisointiaallossa ratkaistiin pitkälti infrastruktuuriin liittyviä ongelmia. Data siirrettiin pois omista konesaleista, laskenta ja tallennus eriytyivät, kapasiteettia pystyttiin skaalaamaan paremmin ja uusien datalähteiden tuominen helpottui. Samalla syntyi kokonaan uusi työkalupino dbt:n, lakehousejen, cloud warehousejen ja modernien BI-ratkaisujen ympärille.
Mutta alustan pääasialliset käyttötavat eivät välttämättä muuttuneet yhtä radikaalisti. Data engineer rakentaa transformaatiot, BI-kehittäjä tietää, mitä tauluja pitää käyttää ja miten mittarit lasketaan, minkä jälkeen käyttäjä saa eteensä valmiiksi rakennetun Power BI -raportin tai muun dashboardin.
Conversational BI toimii hieman eri tavalla. Käyttäjä ei välttämättä valitse valmista raporttia, vaan kysyy vaikka: “Miksi asiakaspoistuma kasvoi viime kuussa?” tai “Mitkä asiakkaat ovat tällä hetkellä suurimmassa riskissä ja miksi?”
AI:n pitäisi silloin ymmärtää paitsi data, myös sen merkitys. Mitä asiakas tarkoittaa? Mitä poistuma tarkoittaa? Mikä on virallinen lähde? Miten taulut liittyvät toisiinsa? Mitä käyttäjä saa nähdä? Ja mikä laskentalogiikka pitää valita, jos sama mittari löytyy useasta eri paikasta?
Aikaisemmin aika suuri osa tästä tiedosta on voinut olla ihmisten päässä. BI-kehittäjä tietää, ettei yhtä taulua enää kannata käyttää, data engineer tietää jonkin järjestelmän päivittyvän päivän viiveellä ja analyytikko tietää, miksi tietty KPI lasketaan juuri sillä tavalla. Ratkaisu voi silti toimia erittäin hyvin, vaikka kaikkea tätä ei olisi dokumentoitu.
AI ei tiedä näitä asioita, ellei sille kerrota.
Kolme vaihtoehtoa nykyiselle data-alustalle
Tästä päästään minusta käytännöllisempään kysymykseen. Jos conversational BI ja muut AI-käyttötapaukset alkavat olla oikeasti agendalla, mitä nykyiselle data-alustalle pitäisi tehdä?
Näen ainakin kolme vaihtoehtoa. Melko uusi ja hyvässä kunnossa oleva alusta voidaan re-engineerata AI-readyksi. Selvästi vanhemman alustan kohdalla voi olla järkevämpää aloittaa uuden sukupolven alustan rakentaminen. Kolmas vaihtoehto on pitää nykyinen alusta ennallaan ja rakentaa AI-käyttötapauksille rajattu ympäristö rinnalle.
Mikään näistä ei ole automaattisesti oikea tai väärä.
Jos alusta on uusi, re-engineeraa se
Jos Snowflake-, Databricks- tai Fabric-ympäristö on rakennettu vaikka pari vuotta sitten, se on hyvin mallinnettu eikä ole ihan mahdoton “spagetti”, olisi aika erikoista lähteä heti rakentamaan uutta data-alustaa.
Silloin kyse on enemmän nykyisen ympäristön tekemisestä AI-readyksi. Tämä ei kuitenkaan tarkoita vain chatbotin liittämistä warehouseen, vaan käytännössä pitää selvittää paljon sellaista tietoa, jota ei alustan rakentamisen yhteydessä ehkä tarvittu eksplisiittisessä muodossa.
Mitä liiketoiminnan käsitteet tarkoittavat? Missä ovat niiden auktoritatiiviset lähteet? Mitkä taulut ja kentät vastaavat niitä? Missä KPI:den laskentalogiikka sijaitsee? Kuka omistaa määritelmät? Mitä poikkeuksia niihin liittyy? Mitä dataa AI saa yhdistää ja kenelle näyttää?
Tämä alkaa helposti muistuttaa reverse engineering -projektia. Olemassa olevat dashboardit, datamallit, KPI-katalogit, SQL-koodi ja dokumentaatio ovat arvokasta lähtöaineistoa, mutta niiden perusteella pitää rakentaa yhtenäisempi semanttinen kuvaus siitä, mitä data oikeastaan tarkoittaa.
Tässä kohtaa alustan ikä ei muuten välttämättä ole ratkaiseva. Pari vuotta sitten rakennettu cloud platform voi olla teknisesti moderni ja silti semanttisesti aika huonosti dokumentoitu. Cloud native ei automaattisesti tarkoita AI-readyä.
Jos alusta on huono, sitä on vaikea korjata – ehkä kannattaa rakentaa seuraava
Jos nykyinen ympäristö on rakentunut huonosti tai se on päässyt vuosien mittaan happanemaan, siellä voi olla tuhansia tauluja, useita transformaatiokerroksia, vanhoja datamarteja, päällekkäisiä mittareita ja liiketoimintalogiikkaa SQL:ssä, BI-työkaluissa, Excelissä ja ihmisten päässä.
Jos koko tästä ympäristöstä halutaan tehdä AI-ready, työmäärä voi olla valtava.
Käytännössä lähes koko alusta pitää ymmärtää uudestaan: mikä tieto on oikeaa, mitä kannattaa enää käyttää, mitä termit tarkoittavat ja miten vanhat ratkaisut liittyvät nykyiseen liiketoimintaan.
Silloin kannattaa ainakin kysyä, missä vaiheessa modernisointiprojekti muuttuu uuden alustan rakentamiseksi.
Pilvimigraatioissa on tehty samaa pohdintaa pitkään. Vanhaa järjestelmää voidaan lift-and-shiftata, modernisoida pala kerrallaan tai rakentaa kokonaan uusi ratkaisu rinnalle ja siirtää käyttötapaukset sinne vähitellen. En näe syytä, miksi AI-migraatio olisi tässä täysin erilainen.
Jos nykyinen data-alusta on joka tapauksessa tulossa elinkaarensa päähän, tilanne on oikeastaan aika hyvä. Seuraava alusta voidaan rakentaa alusta asti niin, että AI on yksi keskeisistä käyttötapauksista eikä jälkikäteen lisättävä ominaisuus.
Jos rakentaisin data-alustan nyt, aloittaisin liiketoiminnasta
Tässä toteutustapa muuttuu mielestäni olennaisesti.
En lähtisi liikkeelle vain lähdejärjestelmistä tai nykyisestä dashboard-listasta. En myöskään rakentaisi koko semanttista mallia nykyisten KPI:den ympärille, koska KPI:t ovat aina rajallinen näkymä liiketoimintaan. Niitä syntyy jatkuvasti uusia, ja conversational BI:n koko idea on, että käyttäjä voi kysyä huomenna jotain, mitä emme tänään osanneet ennakoida.
Parempi tapa on lähteä liiketoiminnasta ja sen omasta kielestä. Mistä liiketoiminta koostuu, mitä siellä tapahtuu, mitkä ovat keskeiset prosessit ja mitkä käsitteet liittyvät niihin?
Prosessit ovat tähän usein erittäin hyvä lähtökohta. Liiketoiminnan ihmiset osaavat yleensä kuvata oman alueensa prosessit varsin hyvin, kun keskustelua ei aloiteta tietokantatauluista tai IT-järjestelmistä. Vakuutusliiketoiminnassa puhutaan asiakkaasta, vakuutuksesta, sopimuksesta, vahingosta ja korvauksesta. Logistiikassa asiakkaasta, tilauksesta, toimituksesta, varastosta ja kuljetuksesta.
Tästä muodostetaan liiketoiminnan omaa kieltä käyttävä semanttinen malli, jossa kuvataan käsitteet ja niiden väliset suhteet. Vasta tämän jälkeen mukaan tuodaan tarkemmin KPI:t, laskentasäännöt, omistajuudet ja linkitys fyysiseen dataan.
Olen käyttänyt tästä laajemmasta kokonaisuudesta aiemmin termiä enriched data model eli rikastettu datamalli. Siinä datamalli ei ole vain tekninen kuva tauluista ja kentistä, vaan siihen yhdistetään liiketoimintakonteksti: käsitemäärittelyt, suhteet, KPI:t, business rules, omistajuudet ja lopulta fyysisen datan mappaus.
Tämä on juuri sitä kontekstia, jota AI tarvitsee.
Jos pitäisi tiivistää, miten AI-ready data platformin rakentaminen eroaa perinteisestä data-alustasta, nostaisin ehkä neljä asiaa. Mallinnus aloitetaan liiketoiminnasta eikä teknologiasta, semantiikka tehdään eksplisiittiseksi osaksi alustaa, liiketoiminnan käsitteet linkitetään fyysiseen dataan ja lopuksi testataan teknisen toimivuuden lisäksi myös sitä, ymmärtääkö AI liiketoiminnan kysymykset oikein.
Kyse ei siis välttämättä ole yhdestä uudesta teknologiakerroksesta tai uudesta tuotteesta. Kyse on hieman erilaisesta tavasta suunnitella, mallintaa, rakentaa ja testata koko data-alusta.
KPI:t ovat hyvä testi, mutta huono lähtökohta
Nykyisiä KPI:itä ei tietenkään heitetä pois. Päinvastoin, niitä voidaan käyttää erittäin hyvin mallin testaamiseen.
Kun liiketoiminnasta on tehty semanttinen malli, voidaan katsoa, pystymmekö muodostamaan sen avulla kaikki tärkeät nykyiset mittarit. Jos haluamme laskea asiakaspoistuman, löytyvätkö mallista asiakas, sopimus, tarvittavat tapahtumat ja niiden väliset suhteet? Jos eivät löydy, mallia täydennetään.
Sama voidaan tehdä nykyisille raporteille ja liiketoimintakysymyksille. Ne toimivat hyvänä reality checkinä sille, onko malliin saatu mukaan oikeita asioita.
En silti rakentaisi mallia vain KPI-listan ympärille. Muuten vaarana on, että rakennamme uudelleen tämän päivän BI-ratkaisun vähän hienommalla nimellä.
Hyvän semanttisen mallin pitäisi auttaa vastaamaan myös kysymyksiin, joita kukaan ei vielä ole kirjoittanut dashboardille.
Sitten linkitetään fyysiseen dataan
Kun liiketoiminnan käsitemalli on riittävän hyvä, se linkitetään fyysiseen dataan. Katsotaan, missä järjestelmissä käsitteiden data sijaitsee, mitä tauluja ja kenttiä käytetään, mikä lähde on auktoritatiivinen ja miten liiketoiminnan määritelmät toteutetaan teknisesti.
Tällöin AI ei joudu katsomaan tietokantaskeemaa ja arvaamaan, mitä customer_status tai contract_type tarkoittaa. Sillä on yhteys liiketoimintakäsitteestä fyysiseen dataan ja laskentalogiikkaan.
Prosessi voisi siis mennä suurin piirtein näin:
liiketoiminta → prosessit ja käsitteet → semanttinen malli → business rules ja KPI:t → fyysinen data → AI
Tämän päälle tarvitaan vielä yksi asia, jota vanhoissa data-alustoissa ei ole välttämättä mietitty samalla tavalla: testaus.
AI muuttaa myös data-alustan testaamista
Perinteisessä data-alustassa testaamme esimerkiksi, että transformaatiot toimivat, tietotyypit ovat oikein ja liikevaihdon summa täsmää lähdejärjestelmään. Nämä testit tarvitaan edelleen.
AI:n kohdalla pitää tämän lisäksi testata sitä, ymmärtääkö järjestelmä liiketoimintakysymyksen oikein.
Jos käyttäjä kysyy “paljonko meillä oli aktiivisia asiakkaita viime kvartaalilla?”, valitseeko AI oikean aktiivisen asiakkaan määritelmän, oikean datan ja oikean aikajakson? Saadaanko sama oikea vastaus, jos kysymys esitetään eri tavalla? Pystyykö järjestelmä osoittamaan, mihin määritelmään ja dataan vastaus perustuu?
Tällaisista kysymyksistä voidaan rakentaa testisettejä aivan kuten muustakin datakehityksestä. AI-ready data product ei olisi valmis vain silloin, kun pipeline menee vihreäksi, vaan myös silloin, kun sovitut liiketoimintakysymykset tuottavat luotettavia ja toistettavia vastauksia.
Tämä on minusta yksi suurimmista eroista, jos data-alusta rakennetaan nyt AI:n käyttötapaukset alusta asti huomioiden.
Entä kokonaan oma AI-ympäristö rinnalle?
Kolmas vaihtoehto on ehkä kiinnostavin, mutta voi jakaa mielipiteitä.
Nykyistä data-alustaa ei välttämättä tarvitse re-engineerata kokonaan eikä uutta enterprise-alustaa rakentaa heti. Yhden AI-käyttötapauksen ympärille voidaan rakentaa oma rajattu ympäristö, johon tuodaan vain tarvittava, kuratoitu data ja semantiikka.
Tämä voisi olla varsin tehokas tapa lähteä liikkeelle esimerkiksi conversational BI:ssä. Valitaan yksi liiketoiminta-alue, tehdään siitä hyvä semanttinen malli, linkitetään tarvittava data ja rakennetaan AI-käyttötapaus toimivaksi. Nykyiseen massiiviseen data-alustaan ei tarvitse koskea kaikkeen samalla kertaa.
Yritykset ovat muutenkin tottuneet elämään useiden alustojen kanssa. Keskittäminen vastaan hajauttaminen on IT:ssä ikuinen kysymys. Enterprise Resource Planning kuulostaa jo nimensä puolesta yhdeltä yhteiseltä ratkaisulta, mutta isoilla kansainvälisillä yrityksillä voi silti olla useita ERP-järjestelmiä eri maissa ja liiketoiminnoissa. Yritysostojen mukana tulee uusia järjestelmiä, migraatiot ovat vaikeita ja jossain vaiheessa rinnakkaisten ympäristöjen kanssa eläminen voi olla järkevämpää kuin massiivinen keskittämisprojekti.
Sama pätee data-alustoihin. Isoissa organisaatioissa voi olla rinnakkain Snowflakea, Databricksia, Azurea, AWS:ää ja vanhempia tietovarastoja. Osa on historiaa, mutta osa johtuu yksinkertaisesti siitä, että eri työkalut ja ympäristöt sopivat eri käyttötarkoituksiin ja eri tiimeille.
Miksi AI ei voisi olla yksi tällainen käyttötarkoitus?
Tässä on kuitenkin selvä haittapuoli. Uusi ympäristö tarkoittaa taas yhtä uutta siiloa. Jos “asiakas” määritellään AI-alustalla eri tavalla kuin raportoinnissa, olemme nopeasti takaisin täsmälleen samassa ongelmassa, jota semanttisen kerroksen piti ratkaista. Dataa pitää synkronoida, governancea tehdä useassa paikassa ja arkkitehtuuri muuttuu jälleen hieman monimutkaisemmaksi.
Siksi ajattelisin tätä enemmän yhtenä mahdollisena migraatiopoluna kuin automaattisena tavoitetilana.
Seuraava migraatioaalto?
On mielenkiintoinen huomio, että ehkä juuri huonoin tuuri on käynyt sellaisilla firmoilla, jotka ovat 2–4 vuotta sitten rakentaneet data-alustan. Se on tehty viimeisen päälle pilveen, dbt:tä hyödyntäen, ketterästi ja huippukoodarien toimesta.
Mutta se on tehty kuitenkin perinteiseen use caseen, eli dashboardeille ja raportointiin. LLM:t tulivat vasta sen jälkeen. Ei kukaan tiennyt pari vuotta sitten, missä ollaan nyt.
Tavallaan ideaalitilanteessa ovat ne, jotka eivät ole vielä tehneet pilvisiirtymää tai ovat nyt muutenkin uusimassa data-alustaansa. Heillä on mahdollisuus rakentaa seuraava ympäristö alusta asti erilaisista lähtökohdista.
En kuitenkaan väitä, että kaikkien pitäisi nyt heittää nykyinen data-alustansa pois ja rakentaa AI-data platform.
Mutta minusta jokaisen data-alustan seuraavaa versiota suunnittelevan kannattaa miettiä tätä kysymystä.
Jos nykyinen alusta on uusi ja hyvässä kunnossa, sitä voidaan re-engineerata AI-readyksi. Jos se on jo vanhempi ja reverse engineeringistä uhkaa tulla valtava projekti, ehkä on aika aloittaa uuden rakentaminen. Ja jos halutaan nopeasti kokeilla AI-käyttötapausta ilman isoa alustaremonttia, rajattu rinnakkainen ympäristö voi olla hyvä vaihtoehto.
Ensimmäisessä modernisointiaallossa data-alusta siirtyi pitkälti on-premisestä pilveen. Se muutti erityisesti sitä, missä ja miten infrastruktuuri toimii.
Seuraava aalto voi olla siirtyminen cloud data platformista AI-ready data platformiin. Siinä muutos ei ehkä tapahdu edes teknologiabrändissä, vaan siinä, miten data mallinnetaan, dokumentoidaan, rikastetaan semantiikalla ja testataan.
Nykyiset data-alustat on suurelta osin rakennettu ympäristöön, jossa ihminen toimii datan ja liiketoiminnan välissä.
Nyt yksi käyttäjistä voi olla AI.
Se on minusta riittävän iso muutos, että myös data-alustan rakennetta kannattaa miettiä uudestaan.
Ps. Kannattaa tutustua tähän tulevaan kurssiin, jonka vetäjänä on data-alan todellinen asiantuntija Winfried Etzel: Data Management Fundamentals and DAMA Certification Preparation 9-11.2026
Johannes Hovi
Growth Director, Ari Hovi. Yksi Ellie.ai:n perustajista. Kirjoittaa data-arkkitehtuurista, semanttisesta mallinnuksesta ja AI:n hyödyntämisestä BI-kontekstissa.
