Otsikko on tietoisesti hieman provosoiva; vähän kuin kysyisi mikä on paras auto. Yhtä ainoaa parasta arkkitehtuuria ja rakennetta ei ole, vaan kyseessä olevaan organisaatioon sopiva arkkitehtuuri riippuu monista seikoista.
Ei siis onnistu aina se, että tarjotaan samaa arkkitehtuuria kaikille organisaatioille. Tämä on toki ymmärrettävääkin – tarjotaan sitä mitä osataan. Tulee mieleen vanha vertaus: kun omistetaan vasara, kaikki näyttää nauloilta. Välillä tarvittaisiin kuitenkin ruuveja.
Erilaiset ympäristöt
Yhteistä lähes kaikille tietovarastoratkaisuille on, että tietoja on hajallaan eri operatiivisissa järjestelmissä ja näitä tietoja halutaan yhdistää, jotta lopulta voitaisiin helposti kysellä ja raportoida niitä eri näkökulmista.
Konsulttina on päässyt näkemään, että tilanteet ovat usein hyvin erilaisia eri organisaatioissa. Voi olla vain muutama lähdejärjestelmä, tai sitten useita kymmeniä. Osa järjestelmistä voi olla samalta alueelta (useita taloudenhallinnan järjestelmiä), voi olla laaja ERP (kuten SAP tai Apotti), voi olla monimutkainen, itse tehty järjestelmä.
Datan monimutkaisuus on myös erilaista. Joskus käsitemallintamalla selviää, että datan rakenteet ovat melko yksinkertaisia (esim. HR, taloushallinta) tai sisältävät monimutkaisia riippuvuuksia (esim. pankki, terveydenhuolto). Tietojen rakenne on yksi tekijä arkkitehtuurin valinnassa, niinpä rakenteen selvittäminen pitäisikin tehdä ensin.
Kriteerit onnistuneelle tietovarastoinnille
Minkälainen on sitten onnistunut tietovarastointi? Aika moni on kuullut epäonnistumisistakin: aikaa kuluu vuosia, raportit virheellisiä, valtavan kallis, juuri kukaan ei tunnu ymmärtävän mitä tietovarastossa on tai ei ole, tietovarasto on täysin musta laatikko, toimittajalukko.
Tietovarastolle voidaan asettaa useita kriteerejä. Alla kerron tämän artikkelin kannalta tärkeitä tietovaraston ominaisuuksia.
Tietovaraston ymmärrettävyys. Onko käsitemalleja, jotka ovat omien IT-ihmisten ja jopa liiketoimintaihmisten ymmärrettävissä. Vai onko tietovarasto musta laatikko, jonka tuntee vain toimittaja.
Tietovaraston kyselemisen ja raportoinnin helppous/vaikeus. On tärkeää, että omat henkilöt pystyvät itse tekemään kyselyjä raportointikerrokseen ja myös itse tietovarastoon. Tällöin on eduksi, että rakenne on riittävän yksinkertainen ja selkeä, eikä tarvitse esim. tehdä valtavasti liitoksia tai ottamaan huomioon monimutkaisia historiointisääntöjä.
Datan siirto- ja muuntamiskerrosten määrä. Sisältyykö ratkaisuun monia tiedon siirtämis- ja muuntamiskerroksia. Ne vievät aikaa, vaativat valvontaa, aiheuttavat virheitäkin ja ajot voivat kaatua. Vai onko siirtoja vähän, suosien suoria kopiointeja ja/tai näkymäkerroksia.
Relaatiokantapohjaisuus. Se on osoittautunut parhaaksi tietovaraston alustaksi, useimmiten pilvipalveluna. Perinteisten relaatiokantojen lisäksi on tarjolla myös uudempia, tietoallaspohjaisia tuotteita, jotka kuitenkin näyttäytyvät ulospäin SQL-relaatiokannoilta.
Tietovaraston laajennettavuus. Tätä kohtaa usein ylipainotetaan. Jos ympäristö suhteellisen stabiili, laajennettavuus ei ole keskeisin kriteeri.
Nykyisin käytettävät ratkaisut
Yleisimmät tietovarastoratkaisut ovat tietoallaspohjainen, ns. normalisoitu ratkaisu, Data Vault- toteutus ja tähtimalliratkaisu. Usein vielä näiden yhdistelmä.
Tietoallaspohjaisessa ratkaisussa tiedot tuodaan tietoaltaaseen samassa rakenteessa kuin ne ovat lähtöjärjestelmässä. Hyvällä tuurilla osa rakenteista on ymmärrettäviä ja niistä päästään eteenpäin, mutta yleensä eri lähtöjärjestelmistä tulee erityyppisiä rakenteita. Esimerkiksi asiakkaaseen liittyvien tietojen yhdistäminen on vaikeaa, ja pahimmillaan sama työ tehdään uudestaan ja uudestaan. Tietoallasta käytetään usein vain lastauslaiturina, mikä sikäli on ok, että lataaminen on kopiointia, mikä on vähäriskistä.
Normalisoitu ratkaisu on alkuperäinen, tietovarastokonseptin ”isän”, Bill Inmonin suositus. Siinä tiedot tuodaan käsitemallin mukaiseen selkeään rakenteeseen, jota on suhteellisen helppo kysellä. Tauluja ei tule valtavaa määrää ja rakenne on helpompi pitää ymmärrettävänä, mikä helpottaa kyselyjen tekoa suoraan tietovarastoon. Tärkeää on tehdä mallinnus hyvin, myös mallintaa kokonaisuus ennen vaiheittaista toteutusta. Miettimistä voi tulla historioinnista ja laajentamisesta.
Data Vault on Dan Linstedtin kehittämä, nykyisin suosittu mallintamismenetelmä ja arkkitehtuuri. Se vaatii kehittäjiltään paljon osaamista. Etuna on laajennettavuus ja tietynlainen standardointi, mikä viehättää monia tietovarastospesialisteja. Lopputuloksesssa on paljon tauluja, mikä tekee kyselemisesstä vaikeaa ja hidasta. Riskeinä Data Vault -ratkaisussa ovat vaikea ymmärrettävyys, usein hidas toteutus sekä toimittajalukko: vain toimittaja ymmärtää mitä kannen alla on ja miten kyselyjä tehdään.
Tähtimallirakenne on Kimballin kehittämä ns. dimensionaalisen suunnittelun menetelmä. Sen tuloksena syntyy joukko tähtimalleja, jotka rakenteensa puolesta sopivat hyvin esim. PowerBI-toteutuksiin. Tähtimallikerros tehdään usein itse tietovaraston päälle. Jos data on valmiiksi rakenteeltaan tähtimallimaista, voi koko tietovarastoratkaisu olla tähtimallin mukainen tai siitä hieman modifioitu.
Mallinnuksen merkitys
Kaikissa edellä mainituissa arkkitehtuureissa kannattaisi tehdä ensin käsitemallinnusta, jotta saadaan ymmärrys alueen tiedoista ja tietorakenteiden monimutkaisuudesta. Käsitemallinnus johtaa selkeisiin tietovarastorakenteisiin.
Käsitemallinnuksesta on saatu myös huonoja kokemuksia; silloin on kuitenkin tehty työ väärillä menetelmillä tai puutteellisella osaamisella. Pahimmillaan tietoarkkitehdit ovat vääntäneet käsitemalleja jopa vuosikausia ja tuloksena on joukko vaikeasti ymmärrettäviä UML-kaavioita jossakin hankalassa työkalussa. Näiden hyöty lopulta voi olla lähes nolla.
Käsitemallinnus ei oikein tehtynä vie liikaa aikaa. Tärkeää on, että liiketoiminta osallistuu ja että on osaavia tekijöitä, tarvittaessa konsultteja sekä koulutusta aiheeseen. Kannattaa hankkia helppokäyttöinen ER-mallinnusta tukeva mallinnustyökalu, josta tehtyjä malleja voi kuka tahansa asianosainen helposti tutkia.
Tekoäly on tulossa mallinnukseenkin: aivan näköpiirissä on huomattavaa kehitystä ja nopeutusta mallinnuksessa, kun mallinnustyökalu voi ehdottaa käsitemallia suoraan kirjoitetusta tekstistä tai jopa kuvasta!
Tietorakenteiden muutos
Operatiivisten lähtöjärjestelmien tietokantojen rakenne heijastelevat ko. järjestelmän toimittajan ”maailmankuvaa”, eli miten toimittaja on aikanaan määritellyt käsitteet ja ja tietorakenteet. Esimerkiksi isossa ERP-järjestelmässä – kuten SAP tai vaikkapa Apotti (Epic) – voi olla melko lailla erilainen tietojen rakenne kuin miten oma liiketoiminta ajattelee.
Toisaalta järjestelmän tietokanta saattaa olla selkeä ja hyvin suunniteltu, kuten esimerkiksi kuntien yhteistyönä tehty varhaiskasvatuksen malli.
On ainakin kaksi tapaa suhtautua tietojen muokkauksiin. Jos lähtöjärjestelmän perusrakenne on hyvä -mikä siis paljastuu käsitemallintamalla – on mahdollista melko suoraviivaisesti kopioida lähtöjärjestelmän tietokanta tietovarastoon ja jatkaa siitä.
Jos taas rakenne on erilainen kuin liiketoiminta näkee, täytyy tiedot muokata oman käsitemallin mukaiseksi. Yleensä tietovaraston toteuttajat tekevät tämän muunnostyön latausten yhteydessä. Toinen vaihtoehto on tilata lähtöjärjestelmän toimittajalta tietojen muunnos, jolloin he toimittavat datat valmiiksi halutussa muodossa ja jäljelle jää vain tietojen lataaminen suoraviivaisesti tietovarastoon.
Mikä on yhteistä – mikä erilaista
Jos lähtöjärjestelmiä on paljon, on hyvä selvittää paljonko niissä on yhteistä tai toisiinsa liittyvää tietoa – vai ovatko tiedot hyvinkin erillisiä, toisiinsa liittymättömiä. Esimerkiksi opetuksen puolella, varhaiskasvatuksen ja ylemmän koulutuksen puolella on omat järjestelmät. Molemmissa on tietysti samoja asioita, kuten oppilaita, opettajia ja opetustiloja, mutta samoja tai yhteisiä tietoja ei ehkä ole (tietysti historian saatossa päiväkotilaisesta tulee koulun oppilas).
Taas kerran mallinnus auttaa. Toisiinsa liittymättömiä tietoja ei kannata väkisin yhdistää. Tai sitten on vain muutama alue, jotka ovat yhteisiä. Nämä ovat yleensä ns. masterdatoja, kuten asiakas, tuote, organisaatioyksikkö ja työntekijä. Ne esiintyvät läpi organisaation monissa järjestelmissä ja liiketoimintaa kiinnostaa nimenomaan mitä tietoa esim. asiakkaaseen liittyy eri järjestelmissä.
Käsitemallinnuksessa onkin hyvä merkitä masterdatat. Ne muodostavat sitten tietovaraston ikäänkuin ytimen, johon sitten kiinnittyy muuta dataa. Esim pankkipuolen asiakas on ytimessä olevaa masterdataa. Siihen sitten kytketään eri järjestelmistä haetut tilit, lainat, sopimukset, vakuutukset jne.
CASE Länsi-Uudenmaan hyvinvointialue
Länsi-Uudenmaan hyvinvointialueella on varsin nopeasti lähdetty toteuttamaan laajaa tietovarastoa useista eri kuntien erillisistä tietojärjestelmistä, kertoo product owner Eetu Salminen. Ratkaisussa on painotettu selkeää, keskitettyä arkkitehtuuria sekä sitä, että omat henkilöt – kuten tietoasiantuntijat ja kontrollerit – ovat mukana kehitystyössä.
Hyvinvointialueella on useita järjestelmiä eri kunnissa sekä terveydenhuollon puolella että sosiaalipuolella. Lisäksi tulevat taloushallinnan ja henkilöstönhallinnan järjestelmät. Tiedot halutaan tuoda yhteen tietovarastoon, mahdollistaen hajallaan olleiden tietojen yhdistämisen monenlaiseen raportointiin – esim. palvelulinjoittain erilaisten tunnuslukujen tuottamiseen.
Itse tietovaraston on suunniteltu ns. normalisoiduksi, ns Inmon -tyyppiseksi tietovarastoksi. Toteutus perustuu käsitemalleihin, joiden lähtökohtana ovat DigiFinland Oy:n tekemät valtakunnalliset mallit. Tietovaraston päälle on rakennettu tähtimalli-rakenteella datamartkerros, joka on suunniteltu nimenomaan kyselemistä ja PowerBI-käyttöä varten. Niitä on suunniteltu eri palvelulinjoille.
Salminen kertoo, että hyvinvointialueen tietoasiantuntijat osaavat itse tehdä SQL-kyselyjä sekä itse tietovarastoon että siitä johdettuihin tähtimalleihin. Tämä on suuri etu, sillä tietovaraston hyöty kasvaa huomattavasti, kun osataan omatoimisesti tutkia dataa. Monimutkaisemmissa arkkitehtuureissa joudutaan monasti koko ajan turvautumaan toimittajan apuun.
Onnistuakseen tällainen järjestely vaatii oman organisoinnin, roolitukset ja vastuut. Länsi-Uudellamaalla on nimetty eri palvelulinjoille ns. tiedonhuoltotriot, koostuen tietovastaavasta, tietoasiantuntijasta/analyytikosta ja controllerista.
Tietojen huono laatu on yleinen ongelma tietovarastoinnissa. Länsi-Uudenmaan hyvinvointialueella laadun tarkastaminen on yksi tärkeistä tietovastaavien tehtävistä.
Hankkeessa on huolehdittu käsitemallien ylläpidosta, jotta tietovaraston rakenne tehdään johdonmukaisesti ja myös käyttäjät ymmärtävät mitä tietovarastossa ja tähtimalleissa on. Käsitemallit ovat toimittajan lisäksi omien asiantuntijoiden käytettävissä.
Teknisellä tasolla toteutus on ns. Data Lakehouse ja ohjelmistona on käytetty Databricksia. Kaikki tiedot ovat tietoaltaalla, mutta Databricksin avulla tiedot näyttävät olevan SQL-pohjaisessa relaatiokannassa. Tämä vähentää siirtoja eri järjestelmien välillä.
Selkeän arkkitehtuuriin, modernien työkalujen sekä onnistuneen organisoinnin ansioista tietovarastoinnin onnistumisen ennuste näyttää hyvältä.
Ari Hovi
