364
UTFORSKA vad vi kan och gör
UTFORSKA vad vi kan och gör

Stäng

Kompetensområden

Kontakta mig

Vill du veta mer och ta reda på hur vi kan hjälpa just dig? Lämna dina kontaktuppgifter

Valdation:
* Förnamn:
* Efternamn:
Företag:
Tel:
* Email:
Land:
* Meddelande:
Successfully sent!
Could not send the mail, try again later!
KAFFE ELLER TÉ? Vi kan väl ses över en kopp.

Blogg oktober 05, 2015

Tips från coachen: Börja använda QlikView Deployment Framework (QDF) nu!

Jag börjar med slutsatsen för Er som inte orkar läsa till slutet.

En stor beslutsstödssatsning med QlikView som är tänkt att leva i många år måste ha en bra grundarkitektur. Då går utveckling och förvaltning snabbare och använder mindre resurser.

Om stor vikt fästs vid arkitekturen vid förarbetet både kring analysplattformen i sig, och även applikationsarkitekturen, byggs en bättre lösning som håller längre. Då blir det även enklare att bygga kraftfulla visualiseringar som ger stor affärsnytta och som klarar av att skala mot de ständigt ökande datamängderna och antalet samtidiga användare.

QlikView Deployment Framework (QDF) ger Er kostnadsfritt bland annat:

– Ett enhetligt strukturerat och väldokumenterat ramverk

– Modulärt, skalbart och återanvändbart. Använd de delar Ni behöver

– Enklare produktionssättningar och kortare förvaltningscykler

– Affärslogik på färre ställen

– Tydligare spårbarhet

Om ett standardiserat ramverk redan används är besparingarna självfallet inte lika stora. Dock är fördelarna verkliga.

Ni som kommit såhär långt kanske vill veta hur jag tänker? – Hur kan jag dra så kaxiga men samtidigt enkla slutsatser som att bra arkitektur kostar mindre i reda pengar? Nu kanske ni tänker att det inte gäller er, att ni har en småskalig QlikView- eller QlikSensemiljö och att ett ramverk bara gör miljön och utveckling samt förvaltning i dito mer komplex. Detta är helt fel.

Baserat på min snart åttaåriga högst ovetenskapliga samlade erfarenhet som beslutsstödsarkitekt har jag äran att avslöja att det är så de värsta miljöerna ser ut idag. De som har börjat småskaligt och vuxit okontrollerat. Miljöer och applikationer som fått växa fritt, agilt och utan någon som helst struktur eller mål.

Miljöer och applikationer som fått växa fritt, agilt utan någon som helst struktur eller mål. För det var ju bara en Proof of Concept, en demo, en pilot eller varför inte en Seeing is Believing, som var så populärt för några år sedan. Där sex pilotanvändare plötsligt blev till hundra och de initiala QlikViewfilerna på några megabyte över tid växte till flera hundra gigabyte med miljarder faktarader i multipla faktatabellerna. Där ledorden i början av QlikViews livscykelhantering i organisationen var lättrörlig, decentraliserad, hade snabb utvecklingstid och var värdeskapande väldigt kvickt. Där kort initial utvecklingstid vunnit över tidskrävande och dyrt arkitekturarbete. Snabba cash. Snabbt resultat.

Med QlikViewterminologi något i stil med; ”Appar där all ETL görs i slutanvändarappen och logik kodas direkt i de grafiska analysobjekten”. Där olika applikationer eller funktionsområden har helt olika inbördes struktur eller ramverk. Där nya utvecklare spenderar dagar eller veckor på att förstå hur allt hänger ihop från ax till limpa. Genvägar tas bland annat genom att som sagt implementera affärslogik direkt i grafiska analysobjekt för att det går fortare än att göra en skriptomladdning som tar 4 timmar att utveckla och 3 timmar att exekvera.

Hårdkodade datatabeller (INLINE) istället för ”User Defined Data” på riktigt. Med följden att appen rullar skarpt sedan flera år tillbaka, ingen förstår den interna logiken, utvecklaren är borta sedan länge och de som förvaltar apparna känner en olust kring att göra förändringar i dem. Dessutom har apparna genom åren knutit ett par beroenden till andra appar som läser BINARY från dem. Dokumentation och kodkommentarer, vad är det för nymodigheter?

Om det gått såhär långt, vilket det gör om ramverk och tydliga riktlinjer saknas för kodstandard, test och datakvalitet, vågar jag påstå att en stor del av förvaltningstiden spenderas på fel saker. Förändringar och nyutveckling tar onödigt lång tid att implementera – tid som kunnat användas effektivare och ge mer affärsnytta i slutresultatet.

Vid startgroparna med att införa QlikView eller QlikSense finns det så vitt jag känner till alla skäl att använda QDF som ramverk. Åtminstone något ramverk. Tidsåtgången som behövs för att förstå ramverket sparar man in mot tidsåtgången som behövs för att ta fram ett eget. Visst finns det andra ramverk, vilka också tar tid att förstå sig på. De kanske till och med är bättre än QDF rent tekniskt eller är mer lättarbetade, men QDF är tillräckligt bra och lättillgängligt. Dessutom uppdateras det regelbundet vilket ofta andra Qlikramverk inte gör i samma utsträckning.

QDF kan införas stegvis, den gamla miljön kan migreras till QDF samtidigt som den gamla miljön finns kvar parallellt. QDF är, kort sagt, en objektorienterad katalog- och filstruktur med inbyggd funktionalitet för central variabelhantering och färdiga kodbibliotek för återkommande uppgifter.

Läs en två sidors överblick kring vad QDF är och vad det kan göra för Er.

Qlik Communitygruppen för QDF nedladdning och support (kräver inloggning)

Magnus Åvitsland, Beslutsstödsarkitekt och tekniskt produktansvarig för Qlik, Enfo Pointer

Läs Magnus tidigare inlägg:

Qlik Cloud Beta

QlikSense Makes Sense Del 1

QlikSense Makes Sense Del 2