4.05.2017 / Ville Niemijärvi

Olimme aikanaan tekemässä QlikView-toteutusta ja ihmettelimme miten karmean näköistä jälkeä edellinen konsulttitalo oli tehnyt.

Koodi oli hirveää spagettia ja ulkonäkö oli karmea. Miten niin hyvällä tuotteella, joka on tunnettu hyvästä visualisoinnista, voi tehdä tällaista jälkeä?

Paljastuikin, että kyse ei ollut konsulttien taidoista vaan siitä, että asiakas oli halunnut säästää ja investoida vain muutaman päivän kerralla.

Välillä yritys teki kehitystä omin voimin ja sitten taas konsultti paikalle pariksi päiväksi.

Toisaalta arkkitehtuurisuunnitteluun ja tietomallinnukseen ei panostettu laisinkaan. Lähdettiin vain tekemään.

Ei paljoa mietitty miten ja missä dataa summataan. Mikä lataus hoitaa keskitetysti tuotetiedot ja tallentuuko johonkin tuote- tai asiakasmaster.

Yhtenäisestä käyttöliittymäsuunnittelusta (UI/UX) puhumattakaan.

Tehtiin siis tilkkutäkkiä ja kokonaisuutta ei ehditty tai pystytty hahmottamaan. Vuosien varralle toteutus paisui ja paisui. Lopulta oli kasassa 20GB mötkylä, jonka suorituskyky oli heikko ja jota ei voitu laajentaa. Ja se näytti aivan karmealta.

Oltiin solmussa.

Vaikka et käytä tietovarastoa, älä laista arkkitehtuurisuunnittelusta ja tietomallinnuksesta.

Vaikka lähtisitkin nopeasti liikkeelle, älä unohda arkkitehtuurisuunnittelua ja tietomallinnusta.

Vaatimusmäärittelyn ohella nämä ovat tärkeimmät vaiheet business intelligence -hankkeissa.

Tämä pätee myös silloin kun et käytä tietokantaratkaisua pohjalla tiedon tallentamiseen.

Myös Qlik, Tableau tai PowerBI toteutus vaatii sen arkkitehtuurisuunnittelun.

Niihin ei tarvitse käyttää aikaa viikkotolkulla. Päivässäkin saat aikaan valtavasti ja saatat säästää ehkä kymmeniä tai satojatuhansia tai ainakin annat BI-ympäristöllesi pari vuotta lisäaikaa kun spagettikoodihirviöitä ei tarvitse rakentaa uudestaan vuoden päästä.

Tässä oma esimerkki yhdestä isohkosta tietovarastohankkeesta.

  • piirsin loogisen tietoarkkitehtuurin tunnissa powerpointiin. Karkea esimerkki löytyy edellisestä blogikirjoituksesta.
  • heitin sen asiakasorganisaation experttien kommentoitavaksi
  • muutamat asiat olivat vaihtoehtoisia, emme osanneet päättää (pilvi vs. on-premise vs. hybridi, datan aggregointi: miten ja missä, MPP vs. normirelaatio)
  • näitä päätöksiä varten tilasimme ulkopuolisen asiantuntijan, pidimme 2 kpl noin 3h työpajoja
  • vedimme konsulttien, meidän ja asiakasorganisaation suositukset yhteen ja teimme päätökset arkkitehtuurista

Kalenteriaikaa saattoi kulua ehkä pari viikkoa mutta työaikaa ehkä vain pari päivää. Ei kovin iso investointi kun lähdetään rakentamaan satojen tuhansien investointia.

Älä hinkkaa arkkitehtuuria liian kauan, tärkeintä on lähteä liikkeelle

On tapauksia missä yritys ei ole osannut lähteä liikkeelle laisinkaan.

On pohdittu kumpi on parempi:

  • MS SQL Server vai Oracle
  • Azure vai AWS
  • SSIS vai Informatica
  • normi-sql vai mpp vai datan virtualisointi

Vaihtoehtojen runsaus ja joskus myös konsulttien kykenemättömyys antaa suosituksia (ja olla jotain mieltä) on aiheuttanut sen, että ei ole tehty mitään tai että hanke on viivästynyt kuukausilla.

Vaikka tekisit “väärän” päätöksen, voi tuon päätöksen muuttaa. Ja hankkeen menestykselle on tärkeämpää saa loppukäyttäjän palautetta ja kokemusta uudesta arkkitehtuurista mahdollisimman nopeasti, kuin yrittää päättää täydellinen arkkitehtuuri kerralla.

Ahteri edellä puuhun, soitellen sotaan ja takki auki ei kannata edetä. Mutta älä yliajattele, älä ylisuunnittele. Sekään ei ole hyväksi.

Kyseessä on oppimisprosessi. Lähde siis liikkeelle pienesti ja opi matkan varrella. Tärkeintä on vain lähteä.

Kyllä nämä jutut vähän maksavatkin

Vedin kerran asiakkaalla toimittajien kilpailutusta. Erään toimittajan konsultin hieman ylimielinen kommentti hieman kummaksutti kun kysyimme häneltä perusteluja suurille työmääräarvioille:

“No kyllä nämä vaan maksavat”

Kaveri oli tietovarastoinnin huippuosaaja ja hänen leipälajina ei ollut myynti tai (potentiaalisten) asiakkaiden ärsyttäviin kysymyksiin vastaaminen.

Mutta hän oli oikeassa tuossa tylyssä vastauksessa.

Kyllä näissä vain menee aikaa ja se maksaa.

Ne ketkä tuntevat työtapaani tai kirjoituksiani, tietävät että halveksin ylisuuria työmääräarvioita ja asiakkaita kuppaavia konsultteja. Tykkään tehdä hommat nopeasti ja joskus oikoa mutkiakin.

Mutta olen itsekin joskus vääntänyt 20-30 päivää yhtä dashboardia. Se oli kallis työpöytä.

Mutta kannattaa huomata, että tuotetoimittaja haluaa myydä asiakkaalle lisenssin.

Hänen etuna on vähätellä työmäärän suuruutta. Jos työmäärä on kovin iso, voi se haitata lisenssimyyntiä. Siksi kannattaa mainostaa, että meidän softalla teet hienot raportit päivässä.

Konsultit näkevät usein pidemmälle. Se on heidän intresseissään. Ajatella pari vuotta eteenpäin. Ajatellaan laajennettavuutta, skaalautuvuuta, suorituskykyä, tulevia käyttötapauksia. Ajatellaan käytettävyyttä, käyttöönottoa, koulutusta.

Konsulttina tietenkin näen jälkimmäisen näkökannan paremmaksi.

Kuuntelit sitten konsulttia, tuotemyyjää tai lompakkoasi, suosittelen seuraavaa:

  • pysähdy edes edes päiväksi miettimään tietoarkkitehtuuriasi
  • älä mieti päätäsi puhki, loppukäyttäjän palaute ja oppi on niin tärkeämpää kuin saada täydellistä kerralla


18.01.2016 / Ville Niemijärvi

Käytännön analytiikan blogisarjamme jatkuu. Viime kerralla määrittelimme liiketoimintaongelman, joka pitää ratkoa ja sovimme toimenpiteistä joilla tähän päästään.

Ennen kuin päästään itse datan pariin, pitää meidän pystyttää tekninen ympäristö. Käydään se nyt läpi. Otetaan ensiksi katsaus ylätason arkkitehtuuriin, tuotteisiin ja komponentteihin. Sen jälkeen alempana näytetään miten kaikki tehdään käytännössä.

Edistyneen analytiikan arkkitehtuuri

Mitä tuotteita, tietokantoja ja sovelluksia tarvitaan kun rakennetaan täysiverinen, tuotantokelpoinen analytiikkaympäristö? Otetaan selvää.

Katsotaan ensiksi ihan ylätasolla, mitä meillä pitää olla ja mitä pitää tehdä?

  • lähdedata: meillä pitää olla jotain mitä työstää ja analysoida
  • tietojen poiminta, muokkaus ja integrointi. Eli meillä pitää olla jokin ns. etl-työväline (extract-transform-load, tuttu tietovarastomaailmasta). Yleensä valtaosa analytiikkaprojektin työajasta (n. 70%) menee datan muokkaamiseen ja käsittelyyn.
  • tietokanta, johon lähdetieto tallennetaan, jossa sitä myös muokataan etl-välineellä ja jonne myös valmiit tuotokset tallennetaan
  • analytiikkatyöväline: eli se missä varsinainen tiedon mallinnus, data science ja algoritmit sijaitsee
  • visualisointi, julkaisu: analytiikkatyöväline on harvoin se missä tulokset näytetään loppukäyttäjille. Usein, miltei aina tulokset viedään johonkin raportointi- tai visualisointiohjelmistoon.

Eli tiedon arvon jalostusta ja niihin liittyviä komponentteja voisi kuvata kuten alla.

Analytiikka-arkkitehtuuri Azure-ympäristössä Louhia

Arkkitehtuurin voi myös kuvata perinteisesti tietovarastotyyliin kuten alla kuvassa:

Analytiikka-arkkitehtuuri Azure-ympäristössä Louhia 2

Ja muistetaan, että kaikki tuotteet, palvelimet ja komponentit pitää löytyä pilvestä. Lähdetietoja lukuunottamatta. Mitään ei asenneta omalle koneelle tai omaan palvelinsaliin.

Heitän seuraavaksi pallon Lasselle, joka toipui influessasta yhdessä päivässä, kuulemma pelkästään proteiinipatukoiden voimalla.

Teknisen ympäristön pystyttäminen

Seuraavassa käydään läpi miten edellä luetellut kaikki tarvittavat tuotteet, tietokannat ja palvelimet otetaan käyttöön Microsoft Azure -ympäristössä.

1. Luo Azure tili

Azure tilin osalta voidaan puhua ihan tavallisesta Microsoftin käyttäjätilistä. Microsoftin käyttäjätilillä (yritys/yksityinen) pääsee kirjautumaan kaikkiin Microsoftin palveluihin. Microsoftin käyttätilin voi luoda osoitteessa signup.live.com

22_Create_azure_account

 

Kun Microsoftin käyttäjätili on luotu, pääset kirjautumaan osoitteessa https://account.windowsazure.com/, jossa seuraavaksi luodaan Azure-tilaus (Subscription). Tässä yhteydessä valitaan haluttu maksutapa ja kerrotaan kenen pussista rahat otetaan. Meidän blogisarjaa varten rahat viedään minun eli Lassen tililtä Pay-As-You-Go-tyyppisesti, eli maksetaan kiltisti viulut mitä palveluiden käytöstä aiheutuu, eikä tippaakaan ylimääräistä (kiitos Lasse uhrauksesta. T. Johto)

31_Azure_Subscription

Kun edellä olevat kohdat kyselyineen ovat täytetty, voidaan siirtyä seuraavaan kohtaan.

 

2. Azure virtuaalipalvelin ja sinne ETL-työväline (SSIS)

Kirjautumalla osoitteeseen https://portal.azure.com/ edellisessä kohdassa luomalla käyttäjätililläsi, pääset käsiksi Azuren palveluihin, yhdestä paikasta. Tarkkasilmäisimmät huomaavat, että alla olevassa kuvassa näyttäisi olevan jo ostettuina palveluita, mm. Azure SQL-tietokanta, Azure Virtuaalipalvelin, jne… Eli ei pitkälle päästy, kun jäätiin housut kintuissa kiinni,

a. Emme luoneet blogisarjaa varten uutta Microsoft-käyttäjätiliä vaan käytimme jo olemassa olevaa,

b. Unohdin ottaa screenshotin portaalin aloitusnäkymästä ennen kuin suoritin kohdat 3.-4.

Aloitusnäkymä poikkeaa täten aivan blankosta näkymästä

32_Azure__portal

Valitaan New -> Compute -> Windows Server 2012 R2 Datacenter

33_Azure_VM_1

Deployment method: Recource Manager (tai Classic) -> Create

33_Azure_VM_2

Seuraavaksi määritellään virtuaalipalvelimen asetukset

33_Azure_VM_4

Huomioitavaa on se, että tässä vaiheessa luodaan uusi Resource Group, jonka alle eri palveluita voidaan ottaa käyttöön (seuraaminen/hallinnointi helpompaa). Seuraavaksi määritellä raudan speksit, demoa varten meille riittää A1 Basic-tason virtuaalikone. Saamme valinnalla tuulahduksen nostalgisista 386:n ajoista. Tämän tason virtuaalimasiinasta on kokemuksia ja tiedän ettei hyvä heilu suorituskykymielessä, mutta mennään tällä jotta luottorajat ei pauku ja saan tuotua leivän perheelle ensi kuussakin.

33_Azure_VM_3

Ja kun kun kaikki on tarkistettu vähintään kertaalleen, painetaan OK

33_Azure_VM_5

Kun OK-nappia on painettu palaa Azure-portaali aloitusnäkymään, johon on ilmestynyt sininen suorakulmio, jossa viuhahtelee valkoisia viivoja, tämä tarkoittaa sitä, että palvelinta ollaan pystyttämässä. Pystytystä odotellessa voidaan siirtyä seuraavaan kohtaan ja palata ETL-työvälineen asentamiseen kun virtuaalipalvelin on luotu.

ETL-työväline, ts. Microsoftin Data Toolsin (tarkemmin demosarjan tapauksessa: (Microsoft SQL Server Data Tools – Business Intelligence for Visual Studio 2012) saa ladattua Microsoftin sivuilta (https://www.microsoft.com/en-us/download/confirmation.aspx?id=36843).

Nyt kun virtuaalipalvelin on luotu, voimme kirjautua sinne esimerkiksi suoraan Remote Desktop Connectionilla (palvelimen tiedot löytyvät Azure-portaalista). Kiikutetaan Data Toolsin sisältävä tiedosto (SSDTBI_VS2012_x86_ENU.exe) virtuaalipalvelimelle, keinoja on tietysti monia, esimerkiksi “copy & paste”. Exe-tiedosto purkautuu automaattisesti haluttuun kansioon, jonka jälkeen käydään klikkaamassa SETUP-applikaatio käyntiin ja edetään lyehkön wizardin mukaisesti. Ei siis tämä ETL-työvälineenkään asentaminen ole vaikeaa (huomattavasti vaikeampaa voi olla löytää palvelinspekseihin sopiva Data Toolsin sisältävä tiedosto).

[Villen lisäys tähän väliin]. Huom: koko virtuaalipalvelin hässäkkä on tarpeen vain SSIS:ää eli etl-työvälinettä varten. Toki sitä voi käyttää myös tiedostojen tallennuspaikkana.

Useimmiten (=aina) analytiikkahankkeissa meidän pitää yhdistää eri tietolähteitä ja/tai muokata dataa, laskea uusia muuttujia jne.

Ja harvoin analytiikkatyövälineen oma tiedonkäsittely ja integraatio-ominaisuudet riittävät tähän. Tai se vaatisi kovaa koodaamista. Itse pitäisin analytiikkasoftan analytiikkakäytössä ja hankkisin aina parhaan työvälineen sille tarkoitettuun tehtävään. ETL-työväline ja sille dedikoitu palvelin tulee käyttöön viimeistään siinä vaiheessa jos rakennetaan tietovarastoa tai erillistä raportointitietokantaa.

Vaihtoehto SSIS:lle olisi Microsoftin Data Factory, mutta se ei ole vielä valmis tuote oikeaan datan käsittelyyn, enemmänkin tietojen lataukseen paikasta a paikkaan b. Tulevaisuudessa Data Factoryn pitäisi kuitenkin olla Microsoftin ykkösvaihtoehto pilvipohjaiseen ETL-työhön.

3. Azure SQL tietokanta

SQL tietokannan luonti on helppoa Azure Portaalin kautta, seuraava kuvasarja näyttää kuinka helppoa se on.

Valitaan New -> Data + Storage -> SQL Database

32_Azure_SQL_1

Määritellään tietokannalle nimi, kontin tilavuus, hevosvoimat, maksutapa ja lopuksi Create

32_Azure_SQL_2

Demon aineiston luonteen ja Louhian maksaman tilinauhan perusteella jätimme hevosvoimat minimiin valitsemalla B Basic-tyypin tietokannan. On siis hyvä alustavasti tuntea tarpeet ennenkuin tietokannan luo, skaalaus/hevosvoimien vaihtaminen onnistuu myös jälkikäteen (ei paneuduta tässä kuitenkaan siihen).

Azure-portaalin aloitusnäkymään ilmestyy jälleen sininen suorakulmio, nyt tiedätte jo mitä se tarkoittaa… hetken odottelun päästä tietokanta on käyttövalmiina. Valmistumista odotellessa voidaan siirtyä jälleen seuraavaan kohtaan.

Noniin, nyt se on pystytetty, tässä todiste siitä (tietokantaan pääsee käsiksi vaikkapa omalta läppäriltä SQL Management Studio:lla, edellyttää, että määrittelet ip:si sallituksi Azure-portaalista: Firewall settings)

35_Azure_SQL

 

4. Azure Machine Learning Studio

Sanotaanko, että hommat senkun helpottuu tässä vaiheessa, tämä on jo niin helppoa, oikein hirvittää. Siispä asiaan, tässä on käytännössä vain 2 välivaihdetta

Valitaan Azure-portaalista New -> Data + Analytics -> Machine Learning

34_Azure_ML

Kun valinta on tehty, ponnahtaa selaimeesi uusi ikkuna, joka näyttää seuraavalta

34_Azure_ML_2

Tämä on vanha näkymä ja uusi näyttäisi olevan myös tarjolla (sininen laatikko ylälaidassa), mutta kun sitä painaa päästään takaisin samalle sivulle (loogista?).

Azure ML:n käyttöä varten tarvitsee (ainakin ensimmäisellä kerralla) luoda ns. Azure ML Workspace (työtila) ja Storage account. Nämä 2 asiaa saadaan luotua yhdellä kertaa seuraavasti

Valitse New -> Data Services -> MACHINE LEARNING -> Täytä tiedot ja luo

34_Azure_ML_3

Azure ML:n käyttöliittymän kuvia tulee blogisarjan edetessä.

 

Enää puuttuu siis Power BI, Ville ota koppi ja nopeasti, menee mun laskuun, hopihopi!

5. Microsoft Power BI

Ville tässä taas. Olen ottanut aiemmin käyttöön MS Power BI desktopin. Asennus + ensimmäiset raportit kesti pari minuuttia. Katsotaan mitä kestää pilvipalvelun käyttöönotto.

Huomioikaa, että nyt ei olla enää Azure-ympäristössä. Tämä on enemmänkin sitä Office 365 maailmaa. Mutta mennään asiaan.

  • Mene osoitteeseen: https://powerbi.microsoft.com/en-us ja klikkaa Get started free
  • Valitse joko Power BI Desktop for Windows tai Power BI (pilviversio). Me otamme jälkimmäisen
  • Kirjaudutaan Microsoftin käyttäjätilillä (ks. kohta 1.), painetaan kerran tai pari OK
  • Ja valmis. Kesto: 42 sek.
Microsoft Power BI käyttöönotto 1 Louhia
Valitse haluatko desktop-sovelluksen vai pilviversion. Molemmat ilmaisia.

Microsoft Power BI käyttöönotto Louhia

Microsoft Power BI käyttöönotto 2 Louhia

Microsoft Power BI käyttöönotto 3 Louhia
Power BI valmiina ottamaan yhteyttä Azure SQL -tietokantaan tai muihin tietolähteisiin.

Otimme nyt käyttöön Power BI:n ilmaisversion. Siinä on rajoituksensa verrattuna Pro-versioon. Löydät erot täältä: https://powerbi.microsoft.com/en-us/pricing/

Pro-version hinta on siis 9,99$/kk/käyttäjä eli esim. 10 hengen organisaatiossa vuosikustannus olisi 1200$.

No niin, nyt meillä on koko paketti kasassa. Asensimme siis:

  • Azure virtuaalipalvelimen
  • ETL-työvälineen ko. virtuaalipalvelimelle
  • Azure SQL -tietokannan
  • Azure ML  analytiikkaa varten
  • MS Power BI:n raportointia ja analytiikkatulosten visualisointia varten

Nyt meillä on pystyssä täysiverinen, skaalautuva, täysin pilvipohjainen arkkitehtuuri, jolla voisi lähteä toteuttamaan myös tietovarasto- ja raportointiympäristöä.

Toisaalta jos sinulla on jo oma ETL-työväline (esim. SSIS, Informatica, IBM DataStage, Pentaho…) tai datasetti on valmiina ja odottaa pelkkää numeronmurskausta, voit skipata kohdat 1-3 eli hankkia pelkän Azure Machine Learning Studion.

Teknisen arkkitehtuurin ja sovellusten asennukseen käytetty aika

[Lasse]: Kohtien 1.-4. suorittaminen kesti pyöreästi 4h, sisältäen ruoka- ja kahvitauot. Suurin osa ajasta meni tiedoston SSDTBI_VS2012_x86_ENU.exe siirtämiseen ja asentamiseen palvelimelle, onneks säästy kuitenkin massii.

[Ville]: Kohdan 5 suorittaminen kesti 42 sekuntia. Sisältäen vessa- ja kahvitauot.

Seuraavassa osassa siirrymme lähdetietojen pariin. Pysy kuulolla!


15.03.2015 / Ville Niemijärvi

Olen kirjoittanut aiheesta Qlik ja tietovarastointi aiemminkin (Qlik ilman tietovarastoa on kuin talo ilman perustuksia) mutta törmään jatkuvasti uusiin asiakkaisiin ja Qlik-toimittajiin, jotka sinnikkäästi uskovat, että on ihan fiksua rakentaa yrityksen tietoarkkitehtuuri puhtaasti Qlikin varaan.

Sanon suoraan: teette virheen. Mitä isompi putiikki ja mitä isommassa merkityksessä tieto on teillä, sitä isomman virheen teette. Kerron seuraavaksi miksi.

5 syytä miksi Qlik ilman tietovarastoa on typerä ratkaisu

  1. Qlik ei ole tarkoitettu organisaation tiedon tallennusalustaksi, tietovarasto on
  2. Qlik ei ole integraatioalusta, tietovarasto on
  3. Tiedon lukeminen ulos Qlikistä (esim. budjetointiin, analytiikkaan, ERP:iin, CRM:ään..) ei onnistu, tietovarastosta onnistuu
  4. Qlik ei ole ammattimainen tiedon muokkaussovellus (ns. etl-sovellus)
  5. Qlik ei ole vaihtoehto master data –ratkaisuksi, tietovarasto on

Qlik on markkinoiden johtavia tiedon visualisointi ja raportointivälineitä. Se on siinä todella hyvä. Olen käyttänyt sitä yli 6 vuotta ja se on omassa roolissaan mahtava. Mutta kaikessa muussa yllämainitussa, se on keskinkertainen tai todella huono.

Teetkö pistemäistä ratkaisua vai kestävää, monikäyttöistä tietoarkkitehtuuria?

Jos aiot tehdä pistemäisen raportointiratkaisun, esimerkiksi vain ja ainoastaan myynnin tarpeisiin, voit tehdä sen huoletta Qlikillä suoraan ERP:stä tai mistä tahansa järjestelmästä.

Tiedon harmonisointi ja hallinta
Mutta jos aiot rakentaa laajemmin yrityksen tietoarkkitehtuuria, haluat rakentaa yhden yhtenäisen paikan esimerkiksi masterdatalle tai määritellä yhteiset käsitteet (asiakas, tuotehierarkia, kate + muut tärkeät kpi-mittarit) ylitse järjestelmä- ja osastorajojen ja hallita näitä keskitetysti, ei tätä kannata missään nimessä rakentaa puhtaasti Qlikin varaan.

Integraatiot
Tietovarastoa ei pidä ajatella vain raportoinnin tietolähteenä (ja hidasteena). Tietovarasto on usein välttämätön ennakoivan analytiikan toteutuksissa. Se toimii myös yhä useammin integraatioalustana kun siellä laskettua business logiikkaa ja analyysien tuloksia halutaan viedä esimerkiksi CRM:ään, taloushallinnon järjestelmiin tai takaisin ERP:iin.

Modulaarisuus ja riskien hallinta
Tietovarasto tuo myös ratkaisuun modulaarisuutta ja on elintärkeä riskienhallinnan kannalta. Kun liiketoimintalogiikka, käsittelysäännöt ja historiadata on tietovarastossa (ja siihen liittyvässä etl-sovelluksessa), voidaan tarvittaessa raportointisovellus heittää hiiteen ja ottaa milloin vain uusi tilalle. Samoin ERP-järjestelmä voidaan vaihtaa ja vanhat tiedot jäävät talteen. Puhtaasti Qlikin varassa oleva yritys on suoraan sanoen lirissä siinä vaiheessa kun ERP menee vaihtoon tai halutaankin siirtää raportointi vaikka sitten Tableauhun.

Kestävä arkkitehtuuri vs. sillisalaatti

Alla on kaksi kuvaa. Ensimmäisessä on raportointiarkkitehtuuri rakennettu Qlikin varaan suoraan operatiivisista tietolähteistä.

Qlik arkkitehtuuri ilman tietovarastoa on kestämätön ratkaisu
Qlik-sovellusarkkitehtuuri ei ole kestävä ratkaisu tiedon tallennusalustaksi.

Jälkimmäisessä kuvassa alla on rakennettu kestävämpi ratkaisu tietovaraston pohjalle. Tämä mahdollistaa tiedon integroinnin 3. osapuolen tuotteisiin, raportoinnin vaihtoehtoisilla tuotteilla sekä ennakoivan analytiikan hyödyntämisen – kaikki yhdestä lähteestä.

Edelleen on mahdollisuus raportoida Qlikillä suoraan operatiivisista tietolähteistä.

Tietovarastoarkkitehtuuri ja Qlik
Tietovarastoarkkitehtuuri luo kestävän ja monikäyttöisen pohjan sekä raportoinnille, analytiikalle että integraatioille muihin järjestelmiin.

 

Milloin Qlik ilman tietovarastoa on järkevä ratkaisu

Jos vastaat alla oleviin kysymyksiin kaikkiin “kyllä”, on ihan OK rakentaa raportointi puhtaasti Qlikin varaan:

  1. Sinulla on vain yksi lähdejärjestelmä, tietoa ei tarvitse harmonisoida
  2. Lähdejärjestelmäsi ei tule koskaan vaihtumaan
  3. Et tule koskaan luopumaan Qlikistä
  4. Tietoa ei tarvitse integroida muihin järjestelmiin ja siirtää pois Qlikistä, esim. CRM:ään, ERP:iin tai ennakoivan analytiikan tarpeisiin.
  5. Sinulla on varaa sijoittaa koko touhuun max. 20 000€ (jonka tietovarasto usein vähintäänkin vie).

Olen viimeisen vuoden aikana keskustellut noin kourallisen yrityksiä kanssa siitä, miten he ovat menneet solmuun puhtaasti Qlikiin perustuvan arkkitehtuurin kanssa. He halusivat edetä nopeasti ja saivatkin tuloksia aikaan. Sitten raportointi laajeni, vaatimukset kasvoivat ja nyt pelkkä Qlik-ratkaisu on kestämätön. Ja nyt he maksavat siitä kovan hinnan kun koko hoito rakennetaan uudestaan.

Tämä sama koskee tietenkin myös Tableauta ja Microsoftin PowerBI –tuotteita. Tai oikeastaan mitä tahansa business intelligence -tuotetta.

Voit mennä perse edellä puuhun, kyllä niinkin sinne pääsee. Mutta jos käytät hetken aikaa miettiäksesi miten sinne puuhun kannattaa kiivetä, pääset sinne nopeammin ja turvallisemmin.