Käsitemallinnuksella on tärkeä rooli modernin tietovaraston rakennushankkeessa. Perustelen tässä artikkelissa miksi.
Moderni tietovarastoarkkitehtuuri
Tietovarastoja rakennetaan, koska tiedot ovat siiloutuneet monien erillisten tietojärjestelmien taustalla oleviin suljettuihin tietokantoihin. Organisaatiot eivät edes tiedä mitä kaikkea tietoa järjestelmien uumenissa makaa – yhtenäinen kuvaus tiedoista puuttuu. Järjestelmien omat raportit eivät riitä yhäti kasvaviin ja muuttuviin liiketoiminnan tarpeisiin. Nykyisenä Big Data –aikakautena edistynyt data-analytiikka, ennustaminen ja muut uudet mahdollisuudet ja teknologiat halutaan valjastaa liiketoiminnan tueksi. Dataa pitää voida uudelleenkäyttää muihinkin tarkoituksiin kuin raportointiin ja analyyseihin, kuten data-aineistojen toimittaminen talosta ulos tai nopeat digitalisointi ja pikasovellus-ratkaisut tietovaraston päälle.
Modernissa tietovarastoarkkitehtuurissa on keskitetty relaatiokanta-osuus, johon ladataan dataa eri lähteistä. Tiedot integroidaan, mutta säilytetään muuten raakamuodossa analysointimahdolliuuksien maksimoimiseksi. Lisäksi yhä useammin on mukana ns. Data Lake –alue, joka perustuu Hadoopiin. Hadoopiin voidaan nopeasti ja edullisesti kopioida erilaisia tiedostoja, ei-strukturoitua dataa tai vaikkapa vanhojen tietovarastojen tiedot. Se saadaan näyttämään tarvittaessa relaatiokannalta määrittelemällä tiedostoille taulut päälle.
Tietolähteinä ovat siis talon omat tietojärjestelmät, mutta myös ulkoisia tietolähteitä sekä sensori- ja mittausdataa. Tietoja toimitetaan paitsi analyytikoille ja liiketoiminnan raporttikäyttäjille myös talosta ulospäin, asiakkaille, toimittajille ja kansalaisille esimerkiksi portaalien kautta. Keskitetty, yhdistetty ja tarkastettu data on siis talletettu kerran, mutta sitä käytetään moneen eri tarkoitukseen. Kyseessä on kokonaisarkkitehtuuriratkaisu.
Käsitemallinnuksen ylätaso
Koska tietovarasto kattaa hyvin suuren osan organisaation tiedoista, on sen suunnittelu keskeisen tärkeää. Ei kuitenkaan kannata aloittaa suoraan tietovaraton tietokannan suunnittelusta. Parhaiten onnistutaan, jos ensin laaditaan liiketoimintalähtöinen käsitemalli siitä tietoalueesta, joka on tulossa tietovarastoon. Kuvaan tätä esimerkillä.
Laadimme HUS:iin tietovarastoarkkitehtuurin, joka sai nimen Big Data Platform. Sen osana laadimme ensin koko tietovarastoalueen kokonaiskäsitemallin ns. ylätason mallina, joka mahtuu A4:lle. Malli antaa hyvän kokonaiskuvan tietovaraston kohdealueesta sekä auttaa huomaamaan samankaltaisia rakenteita yli organisaatio- ja sovellusrajojen. Tällaisessa mallissa tunnistetaan ja määritellään tärkeimmät käsitteet, kuten potilas, asiakas, organisaatioyksikkö, työntekijä, laite ja tuote. Nämä ovat masterdatatyyppisiä käsitteitä. Toisen pääryhmän muodostavat monenlaiset tapahtumatyyppistä dataa kuvaavat käsitteet. Esimerkkejä ovat hoitojakso, käynti, diagnoosi, toimenpide ja mittaus. Malli kuvaa master- ja tapahtumadata –tyyppisten käsitteiden väliset suhteet.
Ylätason mallin on oltava riittävän geneerinen. Esimerkiksi aluksi puhuimme hoitojaksoista ja käynneistä ja niistä tuli erilliset käsitteet. Myöhemmin huomattiin, että tapahtumia, joilla on samankaltaiset yhteydet potilaisiin, työntekijöihin ja organisaatioyksiköihin on muitakin, kuten soitto potilaalle tai vaikkapa nettiterapia. Niinpä yleistimme nämä kaikki käsitteeseen Vuorovaikutustapahtuma. Näin ylätason käsitemalli lisää muutosjoustavuutta, uusia vuorovaikutustyyppejähän on nyt helppo lisätä.
HUS –pilotti
Seuraavana vaiheena oli tehdä suppea pilottihanke eräästä HUS:ille tärkeästä potilastapahtuma-alueesta. Tästä alueesta tehtiin tarkemman tason ER-malli eli käsitemalli, joka tasoltaan vastaa kuvan 1 pyramidissa keskellä olevia malleja. Pilotissa tutkittiin tiettyjä potilastapahtumia eikä potilaasta tai organisaatioyksiköstä tarvittu juurikaan tietoa. Nopein tapa olisi ollut viedä tietovarastoon vain nämä tapahtumat, niissä oleva potilas- ja organisaationumero riittäisivät. Ylätason mallissa nämä oli mallinnettu kuitenkin erikseen – kuten laajassa mallissa pitääkin. Niinpä päätimme tehdä pilotissakin erikseen potilas- ja organisaatiokäsitteet ja lopulta taulut. Näin ne ovat valmiina kuin seuraava vaihe alkaa, eikä pilotista tule ns. poisheittotuote. Ylätason malli hieman yllättävästi siis ohjaa jopa tietovaraston taulutason rakenteita yhdenmukaiseen ja selkeään muotoon. Business-tason mallilla on yhteys tekniseen toteutukseen!
Tarkoitus oli kokeilla Data Vault –mallinnusta (ks. toinen artikkeli tässä lehdessä Data Vaultista), joten em. tarkka aluetason käsitemalli muunnettiin Data Vault muotoon ja siitä tietokantaan.
Analyysejä ja BI-välinettä varten tarvittiin vielä tähtimallin muodossa oleva oma datamartti, jonka avulla näitä potilastapahtumia voi analysoida monen eri dimension kautta. Tällainen datamartti voi olla fyysinen tai virtualisoitu.
HUS-pilotti oli nimensä mukaisesti asioiden kokeilua varten, lopulliset valinnat ovat vielä auki.
CIMO-case
Toinen esimerkkini on CIMO-organisaatiosta, joka välittää opiskelijoita kansainväliseen vaihtoon. Laadimme n. 10 eri alueita edustavien liiketoimintaihmisen kanssa ylätason mallin tulevaa tietovarastoa varten puolen päivän istunnossa. Kuvassa 2 on alustava malli, jonka mukaan hanke eteni. Selkeyteen ja ymmärrettävyyteen on kiinnitetty erityistä huomiota.
Mallintaa vai eikö mallintaa
Nykyisenä ketteryyden ja NoSQL-tuotteiden aikana voi tuntua, että käsitemallinnus on vanhanaikaista, eiväthän uudet tietokannat vaadi edes skeeman määrittelyä. Suosittelen kuitenkin voimakkaasti käsitemallinnuksen tekemistä. Tavoitteenahan on saada kattava, pitkäikäinen tietovarastoinfrastruktuuri ja toisaalta pitää saada nopeasti ja ketterästi uusia raportteja ja analyysejä. Käsitemallinnuksen avulla saadaan kokonaiskuva alueesta etukäteen, mikä auttaa suuresti seuraavien vaiheiden suunnittelua. Nyt voidaan edetä pala kerrallaan ja noudattamalla ylätason mallia saadaan yhdenmukainen kestävä ratkaisu. Ei siis rakenneta taloja uudelle alueelle miten sattuu, vaan noudatetaan etukäteen tehtyä asemakaavaa. Asemakaava (vrt. ylätason malli) ei ole kovin tarkka rakennusten (vrt. aluekohtainen toteutus) kohdalla, mutta antaa yleisrakenteen ja mahdollistaa rakentamisen ketterästi, yksi tai monta taloa kerrallaan, vuosien ajan.
Käsitemallinnus selkiyttää myös käsitteiden määrittelyjä. Jos halutaan tilastoida paljonko on hoidettuja potilaita, on ensin määriteltävä mitä tarkoittaa hoidettu potilas! Usein aivan peruskäsitteiden määrittely on yllättävän hankalaa, mutta itse asiassa työ onkin liiketoiminnan kehittämistä, joka samalla auttaa tietovarasto- ja raportointiympäristön rakentamista. Selkeät käsitteet auttavat ”puhumaan samaa kieltä”.
Menetelmien käytöstä
Yllä olen kuvannut monia mallinnusmenetelmiä. ER-menetelmä (Entity-Relationship Data Modling) harakanvarpaineen on minusta paras menetelmä liiketoiminnan kanssa mallinnettaessa, samoin tarkempia aluetason malleja laadittaessa. UML on vaihtoehtoinen menetelmä, mutta yksinkertaisesti vain vaikeaselkoisempi, kun täytyy lukea mikä yhteys on (esim 1..*) kun ER-mallissa yhteyden näkee (harakanvarvas). Käsitemallien mahdollisimman hyvä selkeys on mallintajan kunnia-asia. Sekavat mallit ovat yksi suuri syy siihen että mallinnuksia vältellään.
HUS:issa kokeiltiin myös Data Vault –menetelmää, joka on tarkoitettu keskitettyjen tietovarastojen suunnitteluun, etuna mm. ketteryys ja muutosjoustavuus. Menetelmä on yleistymässä Suomessakin. Raportointia ja BI-välineitä tukeva mallinnuksen muoto on tähtimalli, joka tässä juuri roolissa onkin erinomainen. Isohin keskitettyihin tietovarastoihin – kuten HUS:n tapaus – se sopii huonommin. Tähtimallin ilmaisuvoima ei riitä kompleksien riippuvuuksien kuvaamiseen.
Tietovaraston hyvä suunnittelu on yksi avaintekijöistä onnistuneessa hankkeessa (kuten myös osaavat toteuttajat ja vetäjä). Niinpä menetelmien osaamiseen ja kouluttautumiseen kannattaa panostaa. Ulkopuolisen konsultin lyhytaikainenkin käyttö voi parantaa toteutuksen laatua huomattavasti.
Ari Hovi konsultoi ja kouluttaa tietovaraston suunnittelua, käsite- ja tietomallinnusta sekä SQL:aa Ari Hovi Oy:ssä, hän on myös alueen tietokirjailija. www.arihovi.com