Pieni on kaunista – Näin pidät Qlik-ympäristösi ketteränä

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, ja kuinka asiat voidaan korjata siten, että BI-ympäristö voidaan pitää jatkuvasti terveissä mitoissa.

Ongelman tunnistaminen

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:

1. 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.
2. Sovelluksessa on suorituskykyongelmia. Sovellus avautuu hitaasti ja vasteajat ovat kaukana alle muutaman sekunnin tavoitteesta. Pahimmillaan sovellus aiheuttaa palvelimen stabiiliusongelmia.
3. Kehittäminen ja muutosten tekeminen on hidasta. Muutokset ja korjaukset aiheuttavat helposti uusia odottamattomia ongelmia.
4. 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.
5. 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.

Ongelman korjaaminen

Sovelluskoon pienentäminen ei usein kuitenkaan toteudu käytännössä ongelman tunnistamisen jälkeenkään. Miksi näin?

Yksi yleinen syy on, ettei kehittäjällä ole riittävää keskusteluyhteyttä sovelluksen käyttäjiin. Tällöin kehityksessä ei kyetä poistamaan sovelluksesta vanhentuneita ja käyttämättömiä elementtejä, vaan siihen lisätään aina uudet toiveet olemassa olevien lisäksi. Sovelluskehitystä ohjaava vahva visio, uusien ominaisuuksien priorisointi ja rajaus ovat keskeisiä menestystekijöitä, ja ratkaiseva rooli on pääkäyttäjillä, joiden pitäisi tuntea perinpohjaisesti sekä datat että liiketoimintatarpeet.

Sovellukseen halutaan usein yhdistellä tietoa kokonaisvaltaisesti eri yksiköistä ja toiminnoista (esim. ostot, myynnit, talous). Jos useamman sovelluksen välisiä riippuvuuksia ei osata hallita, helpoin tapa asian ratkaisemiseen on kaiken datan lukeminen yhteen sovellukseen. Kokonaisvaltainen tiedon analysointi voidaan kuitenkin toteuttaa myös jakamalla ja pilkkomalla sovellus oikeaoppisesti ilman ylläpidettävyyden vaikeutumista, mutta tämä vaatii laajempaa ymmärrystä hyvän Qlik-arkkitehtuurisuunnittelun periaatteista.

Olen usein törmännyt myös siihen, että QlikView:n dokumenttilisenssit ohjaavat sovellusten lukumäärän minimointiin. Yksittäisellä sovelluksella pyritään tällöin kattamaan yhä kasvavia analysointitarpeita, joka johtaa ennen pitkää sovelluksen koon kasvuun ja monimutkaistumiseen. Dokumenttilisensseistä saatavasta alkuvaiheen säästöstä joudutaan usein lopulta maksamaan moninkertainen hinta, eikä sitä voi suositella kuin poikkeustapauksissa.

Kuten yllä on kuvattu, sovelluskoon pienentämisessä tulee ottaa huomioon monia asioita. Seuraavaksi esittelen lyhyen toimenpidelistan, jonka avulla asioita voidaan alkaa korjata:

1. Käy läpi ja suunnittele ETL/data(QVD)-kerros uudelleen. Lähes aina ongelmat lähtevät täältä. Jo muutaman päivän työllä voidaan tyypillisesti tehdä näkyvät pikakorjaukset sekä tarkempi suunnitelma tarvittavista muutostöistä tällä alueella. Ketterät ja iteratiiviset sovelluskehitysprosessit jättävät lähes aina liian vähälle huomiolle data-arkkitehtuurin jatkuvan uudistamisen tarpeen: suositeltavaa olisi, että esimerkiksi joka neljännessä kehityssprintissä keskityttäisiin uuden toiminnallisuuden toteuttamisen sijasta datakerroksen ja sovellusten välisten rajapintojen refaktorointiin.
2. Käy läpi laskentasääntöjen toteutus ja ylläpito. Laskentasääntöjen määrittely tulee keskittää mahdollisimman pitkälle yhteen paikkaan siten, että muutokset voidaan kerralla tehdä kaikkiin sovelluksiin. Keskittämisessä on kuitenkin oltava varovainen, sillä liialliseksi vietynä se tekee kehittämisestä hidasta ja byrokraattista, kun taas siiloissa voidaan toimia nopeammin ja käyttäjäkeskeisemmin.
3. Pilko sovellukset erilaisten käyttäjäryhmien ja käyttötapausten kannalta järkeviksi kokonaisuuksiksi. Monissa tapauksissa toimiva ratkaisu on luoda yksi suurempi ’mammuttisovellus’ ja tämän lisäksi useampi pienempi sovellus. Oikein suunniteltuna moniulotteinen kaiken kattava analysointi voidaan tehdä mammuttisovelluksessa, mutta yli 90% käytöstä kohdistuu pieniin sovelluksiin, joita on helppo ja nopea käyttää myös mobiilina.
4. Keskity tarvittaessa mammuttisovellusten suorituskykyyn – tätä voidaan parantaa Qlikin monilla ositusmenetelmillä (loop&reduce, section access, on-demand app generation).
5. Suunnittele sovelluskäyttöliittymä yleisimpien käyttötapausten näkökulmasta: yksinkertaisuus ja selkeys on tärkeämpää kuin kaikkeen mahdolliseen varautuminen. Peruskäyttäjät eivät useinkaan jaksa opetella harvoin tarvittavia monimutkaisia ominaisuuksia, ja Qlik Sensen uudet itsepalvelutoiminnallisuudet tarjoavat oivallisia työkaluja erityistilanteissa tarvittaviin analyyseihin.

Kohdista 1 ja 2 voisi luulla, että Qlik-ympäristöt olisi parasta rakentaa tietovaraston päälle. Tämä on yksi mahdollinen lähestymistapa, mutta tietovaraston olemassaolo ei missään nimessä ole ennakkoedellytys Qlik-kehitystyön aloittamiselle. Paras lopputulos saavutetaan yhdistelemällä tietovarastojen parhaita käytäntöjä ja data-arkkitehtuurin huolellista suunnittelua Qlikin käyttäjäkeskeisiin ja ketteriin kehitysmenetelmiin.

Sovelluskoon pienentäminen tekee käytöstä nopeampaa ja helpompaa. Käyttökokemukseen vaikuttaa myös käyttöliittymän selkeytyminen. Kun turhat elementit karsitaan, käyttäjät löytävät helpommin oikeasti tarvitsemansa tiedon. Sovelluskoon pienentäminen tyypillisesti myös nopeuttaa ja selkeyttää sovelluskehitystä ja ylläpitoon menevä aika vähenee.

Sovelluksen koon optimointi pitäisi siis lähteä aina sovelluksen käytön ymmärtämisestä: Mitä tietoa oikeasti tarvitaan ja miten tätä tietoa halutaan analysoida. Terveen BI-ympäristön merkki on, että sekä vanhojen että uusien sovellusten kehittäminen on edelleen nopeaa, ja ajan myötä kasvaa ennemminkin yksittäisten sovellusten lukumäärä kuin kompleksisuus.

Kehittäjä – vietä asiakkaan kanssa aikaa, opi ymmärtämään liiketoiminnan lainalaisuudet, kysele ja myös haasta asiakasta!

Asiakas – vaadi kehittäjältä tätä kaikkea. Hyvä kehittäjä haluaa tuntea myös sovelluksen käyttäjiä, jotta hän voi esittää vaihtoehtoja ja erilaisia ratkaisuehdotuksia.

Phuoc Tran Minh

Kirjoittajalla on 10 vuoden kokemus Qlik-projektien toteuttamisesta ja 15 vuoden kokemus IT-konsultoinnista.

Cubiq Analytics on täysin Qlik-toteutuksiin keskittyvä yritys. Palvelumme laatu perustuu tiimimme vuosikymmenten kokemukseen QlikTechiltä. Erikoisosaamisaluettamme ovat laajat ja monimutkaiset Qlik-hankkeet ja -portaaliratkaisut, asiakkaina keskisuuret ja suuret suomalaiset organisaatiot eri toimialoilta.

Tervetuloa kuulemaan erilaisesta lähestymistavasta analytiikkaan ja juhlimaan Suomen Qlikin 10-vuotista taivalta 26.10.2017! Puhujina tapahtumassa mm. luovimmaksi suomalaiseksi valittu Perttu Pölönen, Keskon Chief Digital Officer Anni Ronkainen, Kiinteistömaailman varatoimitusjohtaja Marina Salenius, Procountorin CTO Lauri Lehtonen ja HopLopin CFO Mikko Laine. Lue lisää ja ilmoittaudu