Tunnista liian monimutkaiseksi paisunut Qlik-ympäristö
Qlik-tuotteiden menestystä on siivittänyt kehittämisen ja käyttöönottoprojektien äärimmäinen nopeus. Ajan myötä nopeus usein kuitenkin hiipuu sovellusten kasvaessa tarpeettoman suuriksi. Cubiq Analytics:n konsultti Phuoc Tran Minh kertoo, kuinka tämä ongelma voidaan tunnistaa.
Olen käyttänyt Qlik-tuotteita pian 10 vuotta. Innostustani ylläpitää, kun näen asiakkaillamme päivittäin uusia tapoja edistää tiedolla johtamista. Suurimmat Qlik-ympäristöt ovat tänä aikana kasvaneet täällä Suomessakin satojen sovellusten ja tuhansien käyttäjien kokoluokkaan, ja olen itse saanut olla mukana monissa näistä joko kehittäjän tai auditoijan roolissa.
Merkittävin suurten Qlik-ympäristöjen yksittäinen haaste on mielestäni ketteryyden eli sovelluskehityksen nopeuden säilyttäminen käyttöönoton kasvaessa. Qlik-tuotteiden menestystä on siivittänyt kehittämisen ja käyttöönottoprojektien äärimmäinen nopeus. Ennemmin tai myöhemmin tämä nopeus tuntuu kuitenkin hiipuvan, ja jossain määrin tämä on tietenkin väistämätöntä: Minkä tahansa IT-järjestelmän kehitys hidastuu, kun koodipohja ja kompleksisuus kasvavat.
Useimmissa ympäristöissä olen kuitenkin huomannut, että ajan myötä sovellukset ovat kasvaneet tarpeettoman suuriksi, mikä johtaa kehitysnopeuden ja käyttäjäkokemuksen heikkenemiseen.
Usein sovelluksen koosta puhuttaessa ensimmäisenä mieleen tulee tyypillisesti sovelluksen fyysinen koko eli sovelluksen viemä levytila. Itse näen sovelluskoon kuitenkin kokonaisuutena, joka kattaa kaikki sovelluksen suorituskykyyn ja ylläpidettävyyteen vaikuttavat tekijät: käyttöliittymän laajuus, laskentojen monimutkaisuus, tietosisältö sekä eri käyttökohteet, käyttäjät ja käyttäjäryhmät.
Kuva 1: Kehittämisen nopeus hidastuu ja ylläpitokustannukset kasvavat sovelluskoon kasvaessa.
Uusien analyysinäkymien ja laskentojen toteuttaminen Qlikillä on niin nopeaa, että on suuri houkutus lähteä heti toteuttamaan kaikki mahdolliset käyttäjätoiveet ilman tarkempaa suunnittelua ja harkintaa. Sovelluskehityksen äärimmäinen nopeus ja iteratiivisuus on eduksi alkuvaiheen prototypointivaiheessa, mutta jos samalla tavalla jatketaan sovelluskoon sekä data- ja käyttäjämäärien kasvaessa tuotantokäytön aloittamisen jälkeenkin, ollaan nopeasti vaikeuksissa.
Kuva 2: valitettavan usein Qlik-ympäristöt viipyvät turhan pitkään vaiheissa 2-3.
Tässä muutamia merkkejä, joista voi päätellä, että yksittäinen Qlik-sovellus on kasvanut liian suureksi ja monimutkaiseksi:
Sovellus sisältää paljon elementtejä (jopa satoja!) – välilehtiä, graafeja, taulukkoja, mittareita ym. Monet näistä ovat sellaisia joista kukaan ei enää tiedä, mitä varten ne on alun perin tehty tai käyttääkö niitä enää kukaan.
Sovelluksessa on suorituskykyongelmia. Sovellus avautuu hitaasti ja vasteajat ovat kaukana alle muutaman sekunnin tavoitteesta. Pahimmillaan sovellus aiheuttaa palvelimen stabiiliusongelmia.
Kehittäminen ja muutosten tekeminen on hidasta. Muutokset ja korjaukset aiheuttavat helposti uusia odottamattomia ongelmia.
Sovelluksen omistajuudesta ja todellisesta käytöstä ei ole tarkkaa tietoa. Jos sovellukseen halutaan tehdä merkittäviä muutoksia, ei ole käsitystä siitä, keneltä kaikilta pitäisi kysyä palautetta.
Sovelluksessa on paljon monimutkaista laskentalogiikka ja datan käsittelyä, joka on paljolti päällekkäistä toisten sovellusten kanssa. Sovellusten latausajat kestävät jopa toistakymmentä tuntia.
Sovelluskoon pienentämisellä on selkeitä etuja. Luonnollisesti suorituskyvyn paraneminen näkyy sovelluksen käyttäjille lyhyempinä vasteaikoina ja tätä kautta käyttökokemuksen paranemisena. Myös sovellusten jatkokehitys säilyy lähes yhtä ketteränä ja nopeana kuin alussa.
Nopeuteen voidaan toki vaikuttaa myös hankkimalla järeämmät ja kalliimmat palvelimet, mutta usein tämä tarkoittaa vain ongelmien siirtoa eteenpäin. Tähän päädytään kuitenkin usein siksi, että sovelluskoon pienentäminen optimaalisen kokoiseksi vaatii ymmärrystä sekä Qlikin teknisistä ominaisuuksista, käyttäjätarpeista että sovelluskehitysprosessin ohjaamisesta.
Seuraavassa postauksessa käyn tarkemmin läpi, kuinka pidät BI-ympäristösi terveissä mitoissa. Oikealla tavalla rakennettu data- ja sovellusarkkitehtuuri mahdollistaa nopeat kehityssyklit ja hyvän käyttäjäkokemuksen myös tuhansien käyttäjien ympäristöissä.
