Toteutus päin puuta – blogisarja tietovarastoinnista osa 3

10.07.2018 Tietovarastointi

Tietovarasto muodostaa nykyaikaisten BI-sovellusten perustan. Liiketoimintatiedon hyödyntäminen kasvaa ja monipuolistuu jatkuvasti – tämän takia on ensisijaiseen tärkeää suunnitella ja rakentaa hyödyntämisen perusta eli tietovarasto oikein. Toteutuksessa tulisi pyrkiä välttämään ainakin seuraavat virheet.

1.  “Mekaaninen” toteutus

Mekaanisessa toteutuksessa keskitytään pelkästään tekniseen suoritukseen unohtaen kokonaan järjestelmän käyttötarkoitus.  Näissä tilanteissa voidaan päätyä esimerkiksi kopioimaan ohjelman osia aiemmasta vastaavasta toteutuksesta ajattelematta ratkaisumallin toimivuutta kokonaisuuden kannalta.

2. Kovakoodaus ja ad hoc -korjaukset

Kovakoodaukset ja ad hoc -korjaukset ovat usein hätäratkaisuja, joilla on tarkoitus korjata jokin asia nopeasti ja väliaikaisesti. Suunnitelma siitä, että asiat korjataan kuntoon myöhemmin, toteutuu hyvin harvoin.

Yksikin väärin koodattu parametri voi jättää lataamatta tai hävittää tuhansia rivejä tietovarastossa.

Ad hoc -korjaukset ovat todella varallisia, sillä niillä useimmiten ohitetaan suunnitelmallinen kehitys, katselmointi ja muutoksenhallinta. Ylläpito-vaiheessa tällainen menettelytapa kostautuu, sillä virheselvittelyt ja vaikutusanalyysit ovat huomattavasti työläämpiä kuin kurinalaisessa kehitysmallissa. Tilannetta pystyy vielä merkittävästi pahentamaan jättämällä purkkapaikkaukset dokumentoimatta.

3. Automaattisesta tulee automaagista

Virheiden käsittelyn pitää olla kurinalaista. Virheitä ei pidä pyrkiä kiertämään, vaan niiden alkusyy pitää korjata. Tämän vuoksi ns. itse toipuvat järjestelmät ovat vaarallisia, sillä ne voivat ohittaa fataalitkin virheet ilman, että varsinaista juurisyytä huomataan tai koskaan korjataan. Etenkin tuotannossa automaation pitäisi olla hallittua ja valvottua.

4. Testaus on tekninen suoritus

Testauksen pitäisi varmistaa järjestelmän laatu, mutta kiireellä, heikolla suunnittelulla, valitsemalla testaajiksi resursseja, jotka eivät tunne järjestelmän liiketoimintavaatimuksia sekä käyttämällä vajaata testiaineistoa on pelottavan helppoa saada koko vaihe epäonnistumaan.

Ohjelmistoja suunniteltaessa loppukäyttäjän tulee aina olla keskiössä, ja hyväksymistestauksessa tulisi testata kokonaista valmista järjestelmän osaa mahdollisimman lähellä tuotantoa olevalla datalla. Vain loppukäyttäjätestaus tuo kehitettyyn ominaisuuteen objektiivisen näkökulman, koska vain loppukäyttäjä voi oikein arvioida testin tulokset. Tarkoitus on varmistaa järjestelmän liiketoiminnalle tuottaman palvelun laatu – ei sitä, että tekninen nippelinappeli toimii täsmälleen, kuten on määritelty.

Mikäli käyttäjät pääsevät tutustumaan järjestelmään vasta tuotannossa, suurella todennäköisyydellä suuria virheitä paljastuu vasta tässä vaiheessa, ja silloin niiden korjaaminen on kallista.

5. Suorituskykyä ehtii pohtia paremmalla ajalla

Järjestelmien suunnitteluvaiheessa ei kiinnitetä tavallisesti riittävästi huomiota suorituskykyyn, vaan järjestelmää ryhdytään tehostamaan vasta, kun ongelmia alkaa ilmetä – hyvällä onnella vasta useiden vuosien kuluttua käyttöönotossa, mutta valitettavan usein kuitenkin jo parin vuoden kuluttua.

Suorituskyky-ongelmaa korjataan aluksi vain pikapaikkauksilla, jolloin ongelmat tyypillisesti vain siirtyvät jonnekin muualle sovelluksessa. Huonosti suunnitellun sovelluksen korjaaminen jälkikäteen on kallista ja aikaa vievää, koska usein joudutaan uudelleen toteuttamaan kokonaisia järjestelmän osia.

Esimerkiksi käsiteltävä data pitää rajata mahdollisimman aikaisessa vaiheessa, ettei turhaan kysellä miljoonia rivejä, joista aiotaan käyttää vain marginaalisen pientä osaa.

Jaa tämä artikkeli