Kannattaako Data Vault? Onko Data Vault toimiva tai hyvä? Nämä ovat kysymyksiä, mitä Hovin asiakkaat ja sidosryhmät aika ajoin esittävät meille. Edeltäviin kysymyksiin on kuitenkin mahdotonta antaa yksiselitteistä kaikille sopivaa vastausta. Data Vault -arkkitehtuurilla on vahvat ja heikot puolensa ja sen sopimista tietyn organisaation tietovarastoarkkitehtuuriksi on punnittava tapauskohtaisesti.
Systemaattisuus kunniaan
Yksi Data Vault arkkitehtuurin ehdottomista vahvuuksista on vahva ohjaus systemaattisuuteen. Data Vaultin rakenteet ovat standardisoituja ja sen rakentamista ohjaavat selkeät säännöt. Tietovarastokehittämisessä systemaattisuus voi usein olla jopa merkityksellisempää kuin se, minkä toteutustavan eri vaihtoehdoista valitsee.
Yksinkertainen esimerkki tästä ovat taulujen nimeämiskäytännöt. Ei välttämättä ole paljon merkitystä, onko lähdejärjestelmän nimi taulun nimessä etuliitteenä vai loppuliitteenä, mutta oikean taulun löytämistä helpottaa, kun taulut on nimetty systemaattisesti tietyllä tavalla. Systemaattisuus parantaa selkeyttä ja mahdollistaa automatisointia.
Mitä laajempi ympäristö on, sitä tärkeämpää on olla systemaattinen, koska selkeyden merkitys korostuu ja automatisoinnilla voidaan saavuttaa suurempia hyötyjä laajassa ympäristössä. Toisaalta mitä laajempi ympäristö on, sitä vähemmän systemaattinen siitä myös yleensä tulee ilman selkeitä kehittämisen sääntöjä.
Varastointifunktion ja hyödyntämisfunktion eriyttäminen
Toinen Data Vaultin ominaisuus, joka toimii hyvin useimmissa organisaatioissa, on tietovarastoarkkitehtuurin kaksitasoisuus. Toki tietovarastossa on monesti enemmänkin kerroksia kuin kaksi, mutta tässä tarkoitetaan loogista jakoa varastointikerrokseen ja hyödyntämiskerrokseen ja samojen tietojen ilmenemistä näissä kerroksissa kahdessa keskenään erillisessä tietomallissa.
Usein tiedon säilyttämiseen ja tiedon käyttämiseen ovat optimaalisia erilaiset rakenteet. Yleensä tietovarastoon halutaan varastoida paljon tietoa joustavissa rakenteissa tulevia vielä tunnistamattomia käyttötarpeita varten. Tällöin rakenteisiin tulee tämän hetken käyttötarpeiden kannalta turhaa tietoa ja monimutkaisuutta. Ratkaisu ei ole käyttötarpeiden kannalta optimaalinen. Toisaalta täysin käyttötarpeista ohjautuvasta tietovarastosta ei tule kovin tulevaisuudenkestävää. Eri käyttötarpeet voivat myös vaatia erilaisia rakenteita, joten samaa tietoa tallennetaan helposti vähän eri tavoin moneen eri paikkaan ja rakenteesta ei tule selkeää ja yhtenäistä.
Hyvä ratkaisu on Data Vault -arkkitehtuurin tyyliin rakentaa erilliset varastointi- ja hyödyntämiskerrokset. Varastointikerros on säännönmukainen ja yhtenäinen ja jokainen tiedonmurunen löytyy omasta loogisesta lokerostaan tietomallissa. Saatavilla olevista tiedoista ja niiden liittymisestä toisiinsa saa kokonaiskuvan. Esimerkiksi asiakas-taulusta löytyvät yhtenäisellä asiakasnumeroinnilla kaikki entiset, nykyiset ja potentiaaliset asiakkaat ja näiden historiatiedot. Hyödyntämiskerroksessa kaikki tiedot eivät välttämättä ilmene, samat tiedot voivat ilmentyä tarpeen mukaan eri tavoin ja tiedot eivät välttämättä liity toisiinsa kaikin mahdollisin tavoin. Johonkin käyttötarpeeseen tarvitaan ehkä vain osa niiden asiakkaiden tällä hetkellä voimassa olevista tiedoista, joilla on tällä hetkellä voimassa oleva sopimus.
Joustavuuden ja monimutkaisuuden tasapaino
Tietovaraston rakenteita koskevissa valinnoissa on usein tehtävä punnintaa rakenteiden muutosjoustavuuden ja kokonaisuuden monimutkaisuuden välillä. Joustavammat rakenteet mahdollistavat paljon erilaisia käyttötarpeita – jopa sellaisia, mitä ei vielä suunnitteluvaiheessa osata ennakoida. Ne myös minimoivat tarvetta muutoksiin, kun jokin lähdejärjestelmissä tai käyttötarpeissa muuttuu.
Toisaalta yksinkertainen on kaunista. Jos joustavuutta ei koskaan tarvita mihinkään, sen rakentamiseen, ylläpitämiseen ja ymmärtämiseen vain hukataan resursseja. Pahimmillaan koko tietovarasto jää täysin hyödyntämättä, jos sen rakenteet ovat niin monimutkaisia, että kukaan ei jaksa tai uskalla käyttää sitä.
Data Vault -tietomalli on muutosjoustavuuden huipentuma. Kaikki data historioidaan sellaisenaan, jolloin siitä saadaan irti niin paljon kuin ylipäänsä on mahdollista. Mikäli esimerkiksi kokonaismyynnin laskukaavaa halutaan muuttaa, näin voidaan tehdä ja menneet ja tulevat kuukaudet raportoida vanhoilla ja uusilla laskukaavoilla.
Data Vault -mallissa jo rakennettua osuutta ei myöskään koskaan muuteta, vaan muutosten myötä lisätään aina uusia aiempaan kokonaisuuteen integroituvia rakenteita. Näin julkaistut ja käytössä olevat toteutukset voidaan säilyttää entisellään muutostenkin myötä.
Toki kaiken historian ja kaiken raakadatan säilyttämisen sekä useiden rakenteiden hintana on monimutkaisuus ja panostukset väistämättä osin hyödyntämättä jäävään potentiaaliin.
Neuvoja arkkitehtuurivalintaan ja toteutukseen
Data Vault kannattaa siis valita, jos halutaan vahvasti painottaa muutosjoustavuutta ja tuleviin tietotarpeisiin varautumista esimerkiksi suhteessa kehittämisestä muodostuviin työn kustannuksiin. Rakenteiden suhteellinen monimutkaisuus vaatii organisaatiolta korkeaa datamaturiteettia. Lisäksi on tärkeää, että organisaatiossa on omia henkilöitä, jotka ymmärtävät, mitä Data Vaultissa on ja miten se toimii. Osaamiseen kannattaa panostaa.
Käsitemallinnus on Data Vault -suunnittelun lähtökohta. Arkkitehtuurin perusajatus on organisoida raakadata eri tietojärjestelmistä ohjautuvien rakenteiden sijaan liiketoiminnan logiikkaa mukaileviin rakenteisiin. Näin esimerkiksi asiakastiedot saadaan eri järjestelmistä samaan yhtenäiseen malliin. Mikäli toteutusta lähdetään tekemään vain perusjärjestelmien rakenteiden pohjalta, päädytään tilanteeseen, jossa on ikään kuin monta rinnakkaista Data Vaulttia, joiden tiedot eivät integroidu yhteen. Tällöin osa Data Vaultin tarjoamista hyödyistä menee sivu suun ja rakenteesta tulee entistäkin monimutkaisempia.
Data Vaulttia ei kannata lähteä rakentamaan ”big bang” -tyylillä ajatellen, että ensin tuodaan kaikki data raakavaulttiin ja vasta sen jälkeen lähdetään suunnittelemaan liiketoiminnan tietotarpeiden täyttämistä. Tällaisella lähestymistavalla menee liian kauan ennen kuin Data Vaultista saadaan käytännön hyötyä. Data Vault mahdollistaa uusien osuuksien lisäämisen vähitellen ja tätä mahdollisuutta kannattaa hyödyntää. Käsitemallinnuksen jälkeen on kokonaisuudesta muodostunut tarpeeksi kattava kuva, että kehittämistä voidaan tämän jälkeen jatkaa liiketoiminnan tietotarpeita priorisoiden ketterästi.
Mikäli Data Vaulttiin ei päädytä, kannattaa siitä joka tapauksessa ottaa oppia soveltuvin osin. Systemaattisuutta ei voi korostaa liikaa. Hyvään alkuun pääsee käsitemallinnuksella ja ohjaamalla toteuttamistyötä käsitemallin pohjalta. Datatiimissä on myös oltava henkilö, joka tekee lopulliset päätökset esimerkiksi siitä, millaisia nimeämiskäytäntöjä noudatetaan. Jos ympäristö on niin laaja, ettei yksi henkilö pysty tarkistamaan kaikkia uusia toteutuksia, vertaisarviointikäytäntö on toimivaksi todettu ratkaisu. Kun tietovarastokehittäjä on toteuttanut uuden kokonaisuuden tietovarastolle, toinen kehittäjä arvioi, onko yhteisesti sovittuja käytäntöjä noudatettu.
Lisäksi kaksitasoista arkkitehtuuria kannattaa vakavasti harkita, ellei lähdejärjestelmiä ja lähdedataa ole vain vähän tai niistä tuleva data ole jo valmiiksi hyödyntämisen kannalta sopivassa muodossa. Varastointikerros voidaan hyvin toteuttaa myös perinteisellä normalisoidulla mallilla Data Vaultin sijaan. Hyödyntämiskerrokseen tulee usein tähtimalleja, mutta hyödyntämistarpeesta ja työkalusta riippuen voidaan myös rakentaa esimerkiksi leveitä tauluja.
Mirjamaria Petäjäniemi
Lead Consultant, Trainer
