I början av vår studie hade vi en del antaganden som vi hade för avsikt att bekräfta eller avfärda. Till att börja med så ville vi ta reda på varför en del företag inom BI inte hade valt att bygga ut sina system med alternativa databaser för att kunna hantera den allt mer växande datamängden, eftersom vi, genom vår utbildning, kommit till den insikten att NoSQL-databaser lämpar sig ypperligt för just detta ändamål. Vårt antagande om detta var att de helt enkelt hade för lite kunskap om NoSQL-databaser, och därför inte kunde se förutsättningarna för en sådan implementation, eller kunde det vara så att de ägde kunskapen och ändå hade valt att inte använda sig av dem - och vad var då anledningen till detta?
Dessa antaganden utmynnade i studiens frågeställningar:
Hur ser behovet av alternativa databasmodeller ut inom BI-området?
Hur påverkar kunskap om NoSQL-databaser inom en organisation, eller bristen på densamma, nämnda behov?
För att besvara dessa frågor skickades en enkätundersökning ut till utvecklare och verksamhetskonsulter, samt genomfördes kvalitativa intervjuer. Resultatet av studien visar på att det idag finns ett behov av alternativa databasmodeller när det kommer till större kunder som har stora mängder data som ska analyseras. Detta påverkar verksamhetskonsulterna eftersom det tar lång tid att processa data, samt skapa OLAP-kuberna, men resulterar även i försämringar i analystjänstens prestanda för slutkunden. Idag har man försökt komma runt problemen när det kommer till stora datavolymer genom att skapa program som rensar i databaserna och selekterat bort data i högre utsträckning än tidigare. Kunskapsnivån bland de anställda gällande NoSQL-databaser är låg - både bland utvecklare och verksamhetskonsulter. En implementation av NoSQL-databaser för att täcka nuvarande och framtida behov skulle vara en krävande utmaning för företaget.
Vi är medvetna om att de konsulter och utvecklare som svarat på enkäten, och de som senare blev intervjuade, inte har så stora möjligheter att förändra verksamheten med den magnitud som skulle behövas för denna typ av implementering - vilket eventuella IT-arkitekter och chefer har. Trots detta är vår studie ändå relevant, då den speglar verksamhetens generella bild av vad icke-relationella databaser egentligen innebär och dess medarbetares defensiva inställning till deras befintliga system och databaser.
Även om det var uppenbart att de flesta av respondenterna var skeptiska inför en implementation av alternativa databaser, på grund av bland annat bristen av relationer, så var det lika uppenbart att det fanns begränsningar hos deras nuvarande databaser som riskerade att ställa till med stora bekymmer för företaget i framtiden. En av dessa begränsningar, som bland annat IO4 vittnar om, var att balansen mellan tiden det tar att processa data och tiden som kunderna är villiga att betala för börjar närma sig en brytpunkt.
Det vittnas vidare om att mycket av den data som gör att det tar lång tid att processa också är gammal, men ingen vågar riktigt att ta bort denna data. För att kunna göra något åt detta så skulle konsulterna behöva sitta och gå igenom all data och sortera ut det som inte längre
31
behövs, men detta är något som skulle ta mycket tid, och det är tid som ingen av företagets kunder skulle vara villiga att betala för.
Allt detta indikerar att det finns ett behov, om inte just idag så i framtiden, för företaget i vår fallstudie, och andra företag i en liknande situation, att utveckla sina system och databaser så att de kan möta kundernas krav och behov. Om företaget väljer att inte utveckla så att de kan möta kunderna, så finns det en risk för att konsulterna måste arbeta under så pass högt tryck att det orsakar stress och risk för deras hälsa, eftersom arbetsbelastning och påtvingad upprepad övertid, är en av de fem faktorerna som representerar en dålig arbetsmiljö (Modak & Joshi, 2019). Annars så finns risken att kunderna helt enkelt väljer något annat företag som kan processa deras data snabbare. Så för att gynnas i The Red Queen Effect så skulle företaget, som vi anser det, gynnas av att se sig om efter moderna lösningar på detta annalkande problem. Detta skulle kunna handla om en implementation av någon form av NoSQL-databas för att kunna hantera Big Data och kunna erbjuda sina kunder möjlighet till Big Data Analytics. Det hade varit värt den investering som skulle krävas då det öppnar upp möjligheter till att slå sig in på en ny, högt värderad marknad, vars värde dessutom beräknas fortsätta öka. Det hade även både hjälpt företaget att utvecklas och skapa sig en konkurrensfördel men även kunnat ge dess kunder ökad möjlighet till att själva få bästa förutsättningar för att överleva och öka chansen till att skapa fördelar över sina konkurrenter.
Vid intervjuerna framkom det att det finns en stor skillnad mellan verksamhetskonsulter och utvecklare, vilket egentligen inte är så konstigt eftersom utvecklarna inte arbetar lika mycket med databaser som verksamhetskonsulterna gör, då databashantering är själva kärnan i konsulternas arbete. Detta gjorde att kunskapen om NoSQL-databaser naturligt nog var lägre hos utvecklarna, och vi anade betydligt mer skepticism hos dessa inför implementation av alternativa databaser. Den största anledningen till detta har att göra med att medan konsulterna hanterar kunddata som yttrar sig i kolossala volymer, så arbetar utvecklarna mest med de interna databaserna som sparar information för den specifika produkt de arbetar med, vilket bara handlar om “100 MB eller nånting” och inte skulle bli någon större prestandavinst enligt IO2. Så resultatet blev i slutändan att de utvecklare vi intervjuade var de som gav de mest spekulativa svaren och inte ansåg att det fanns någon större mening att implementera databaser - även fast dessa kände till den växande datamängden hos konsulternas databaser.
Något som iakttogs under intervjuerna, samt av de svar vi fick, var att kraven på verksamhetskonsulternas prestation ökat i samband med att datavolymen blivit allt större. Det var tydligt både genom deras kroppsspråk och hur de uttryckte sig, att de var pressade över den nuvarande situationen. Detta tog sig uttryck både i form av att det tar längre tid att processa kundernas data, vilket gör att det blir fler konsulttimmar, vilket i sin tur ökar kostnaderna för kunden, men även i att beräkningarna som ska programmeras måste vara mer genomtänkta och analyserade för att inte påverka prestandan på vyerna för slutkunden.
Utifrån den data som samlats in kan vi se att de istället för att börja titta på andra databaslösningar valt att försöka komma förbi de utmaningar som ökade datamängder skapat. Detta genom att i högre grad selektera vilken data som ska importeras, samt åldern på denna. De har även skapat program som rensar gammal data från databaserna som ett led i att försöka öka prestandan. En aning varför dessa åtgärder gjorts, framför att börja titta på exempelvis NoSQL-databaser, är något som kan ha att göra med kunskapen om dessa är mycket låg på
32
företaget som resultatet från intervjuerna och enkätundersökningen visade. En annan anledning kan vara att det helt enkelt är den billigaste och snabbaste lösningen utan att behöva göra några förändringar i befintlig arkitektur.
5.1 Metodkritik
I denna del kommer vi att gå igenom de metoder vi använt oss av i studien och utvärdera utfallet av dem, samt ställa dessa mot kritik som finns från litteraturen.
Vi använde enkätundersökningen för att ge oss en övergripande bild av företaget, samt skapa ett underlag som skulle hjälpa oss att ta fram frågor till intervjuerna. Dock skriver Eriksson och Hultman (2014) att det är bra att ha ett flertal olika datakällor för att kunna få en heltäckande bild av det sammanhang vi har valt att analysera, något som benämns som “triangulering”. Vi hade till en början tänkt att ta en betydligt större del av företagets produkt, t.ex. för att kunna försöka förstå hur en implementation av NoSQL-databaser skulle göra sig rent praktiskt, men på grund av den knappa tiden vi hade på oss för vår studie, samt den rådande pandemin, så valde vi bort detta för att kunna fokusera på den data vi fick in genom enkäten och intervjuerna. Att vi använder få datakällor gör att det enligt Eriksson och Hultman (2014) finns risk till en beskrivning som är obalanserad och resultera i att man drar onyanserade slutsatser.
Även fast det företag som vi skulle studera var inom IT-området, så upptäckte vi dock att några av de termer som vi använde vid enkäten och intervjuerna inte var lika självklara för informanterna. Vi hade nyligen avslutat en kurs på universitetsnivå om NoSQL-databaser, så för oss var kunskapen väldigt färsk, medan för många av medarbetarna på företaget så hade det gått några år sedan de läst om alternativa databaser, och vissa hade aldrig läst om dem alls. Detta ledde till något som Eriksson och Hultman (2014) varnar för, nämligen att vi måste förklara facktermer (om NoSQL-databaser) för respondenterna.
Vi är dock väldigt nöjda med valet av fallstudie, eftersom den gav oss verklighetsnära beskrivningar av det område vi ville studera och ett sammanhang som annars hade haft svårt att greppa i enlighet med Eriksson och Hultman (2014). Under den tid vi spenderade hos företaget uppkom en mängd frågor och begrepp som vi kunde använda oss av, och vidareutveckla vår studie ytterligare.
När vi tog del av resultatet av enkäten så insåg vi att några av de frågor vi hade ställt hade varit en aning diffusa, då svaren blev något spekulerande. Det hade, till exempel framstått som att vi ämnade att byta ut de traditionella databaserna och ersätta dem med nya alternativa databaser. Detta gjorde förstås att många som besvarade enkäten antagligen blev skeptiska till en sådan förändring på deras arbetsplats.
När det kommer till bortfallet av svarsfrekvensen så menar Japec (1997) i en studie av Statistiska centralbyrån (SCB) att det kan vara svårt att säga vad som är ett acceptabelt bortfall, då ett bortfall på 10% i en undersökning kan vara mer förödande än 25% i en annan. Av den andel konsulter och utvecklare som fick möjligheten att svara på vår enkät hade vi ett bortfall på ca 32 %, vilket vi anser vara ett acceptabelt bortfall för vårt ändamål med enkäten.
Något som vi visserligen inte kunde råda över, men som likväl begränsade oss i vår studie var den rådande pandemin som vid tiden för intervjuerna började göra det allt svårare för oss. Som nämnts tidigare så var det många på företaget som vid den här tiden som hade valt att jobba hemifrån, så när vi väl skulle utföra våra intervjuer så handlade det mer om att hitta
33
tillräckligt många att intervjua, än att välja ut specifika medarbetare med specifika befattningar.
Vi uppfattade också att många av de svar vi fick var väldigt spekulativa och nästan något undvikande. Anledningen till detta kan ha varit att de visste att vi var där för att ta reda på varför de inte hade implementerat NoSQL-databaser, och därmed antog att vi föredrar dessa framför de traditionella och på så vis inte önskade att kliva oss på tårna. Därför ville de inte använda negativa extremvärden, något som Eriksson och Hultman (2014) benämner som centraltendensen och tar upp som en fallgrop i intervjustudie. Vad vi kunde ha gjort annorlunda idag, baserat på denna erfarenhet, är nog att vi inte skulle ha arbetat på plats hos företaget innan intervjuerna och inte varit lika öppna med vad vår studie gick ut på för att minska centraltendensen. Detta skulle emellertid i viss mån påverka vår möjlighet att uppfylla informationskravet, som bland annat innebär att deltagarna informeras om studiens syfte. En sådan metodjustering hade därför behövts utföras med försiktighet.
Något som vi däremot insåg var väldigt positivt med att utföra intervjuer, var att vi hade möjlighet att justera dem beroende på den respons vi fick av respondenterna. Som ett exempel så fann vi redan vid första intervjun att en fråga som hade tagits med var helt pleonastisk, för då den första respondenten hade svarat på den, behövde vi inte de andras svar på den frågan.