PIENI ON KAUNISTA

Näin pidät Qlik-ympäristösi ketteränä

Edellisessä blogiartikkelissamme havainnoimme, mitä haittaa liian suureksi kasvaneista Qlik-sovelluksista voi olla ja miten ongelman tunnistaa. Seuraavaksi keskitymme korjaaviin toimenpiteisiin. Cubiq Analytics:n konsultti Phuoc Tran Minh kertoo, millaisilla toimenpiteillä on mahdollista rakentaa ja kehittää suuriakin tietomääriä käsitteleviä Qlik-sovelluksia.

Kuten artikkelin edellisessä osassa totesin, liian suureksi tai kompleksiseksi kasvaneista sovelluksista voi olla monenlaista haittaa sekä sovellusten käytölle että kehittämiselle. Sovellusten koon kasvaessa hiljalleen myös hitaus ja muut pulmat lisääntyvät huomaamatta.

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

Phuoc Tran Minh

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