Forskningsbidrag

Som tidigare nämnt handlar majoriteten av tidigare forskning inom både teknisk skuld och normaliseringsteori om att teoretiskt förankra och hantera koncepten, snarare än att undersöka de praktiska implikationerna. Därför har det varit svårt att förankra studien i tillräckligt djup tidigare forskning som berör studiens syfte, något som kan komma att påverka resultatet negativt. Trots det ska resultatet betraktas som meningsfullt, just i det avseende att denna typ av studie förtjänar mer utrymme än den har fått i akademia. Teknisk skuld som koncept är välkänt som något som har negativa konsekvenser för system, men det lämnas på en abstrakt nivå som inte belyser de faktiska konsekvenserna av problemen. Därför representerar den här studiens bidrag något viktigt som kan lägga grunden för såväl praktiska regelverk för

uppdragsgivare och projektägare likväl som vidare forskning inom ämnet med en mer praktisk utgångspunkt.

32

Den litteratur som finns att tillgå inom ämnena normalisering och teknisk skuld behandlar dessa framför allt på en teoretisk nivå. Mycket av litteraturen utgår dessutom från att läsaren är införstådd med varför normalisering och teknisk skuld orsakar problem. Att finna litteratur knuten till verkliga fall har varit problematiskt. Studien ger ett kvalitativt bidrag rikt på empiri avseende hur design i en databas har en inverkan på det praktiska arbetet och den dagliga driften i en verksamhet, samt tydliga exempel på vilka delar i verksamheten som påverkas. Samtidigt ger studien ett kvalitativt bidrag avseende hur teknisk skuld i ett system inte bara utgör en finansiell kostnad, utan även en praktisk kostnad i form av hinder och tidsförluster i verksamheten.

Studiens bidrag ger huvudsakligen en ny infallsvinkel på ämnet. Teknisk skuld är inte ett nytt koncept och det har forskats mycket inom domänen, men väldigt lite av den forskningen har fokuserat på praktiken och de konsekvenser teknisk skuld har i en verksamhet. Detta bidrag är unikt i det avseendet, då det analyserat praktiska implikationer för en organisation och

dessutom har gett ett rikt exempel på effekterna av en icke-normaliserad databas. Vad vår studie har funnit, och dess kvalitativa bidrag inom området för teknisk skuld i praktiken, indikerar att teknisk skuld i databaser utgör problem på grund av att arbetet med databasen blir tidskrävande, samt att databasen blir opålitlig och får bristande kompatibilitet. Dessa tre faktorer granskas mer utförligt nedan.

Teknisk skuld är tidskrävande - Vår studie har gett tydliga exempel på att delar av

arbetet inom verksamheten har varit problematiskt som en ren konsekvens av svag design i den ursprungliga databasen Sysinfo. Förekomsten av reduntant och inkonsistent data i dababasen på grund av bristfällig normalisering har medfört att de loggar som databasen huvudsakligen existerar för att lagra i vissa fall har varit omständliga att skapa och varit svåra att tolka. Detta har i mångt och mycket förbrukat onödiga resurser i form av arbetstid som istället hade kunnat användas effektivt i den dagliga driften.

Teknisk skuld skapar opålitlighet - Vår studie visar att den svaga designen i Sysinfo

i vissa fall har haft konsekvensen att informationen i databasen blivit otydlig och bitvis opålitlig. På grund av att datan som lagrats i Sysinfo har haft en hög grad av inkonsistens har information som lagrats blivit svår att använda och förstå. Detta har skapat en viss otrygghet i det praktiska arbetet. En grundsten i arbetet med databaser är kravet på att data ska vara korrekt och pålitlig, detta är något svag design utgör ett starkt hot mot.

Teknisk skuld medför bristande kompatibilitet - Vår studie visar att bristande kompatibilitet med andra artefakter är en konsekvens av den svaga designen i Sysinfo.

Tabellernas utformning med reduntant och inkonsistent data har medfört stora svårigheter med att göra inserts från gränssnittet till databasen och samtidigt säkerställa att all data hamnar på rätt plats.

De två första punkterna (teknisk skuld är tidskrävande, respektive teknisk skuld skapar opålitlighet) stämmer in på de generella problemen som presenteras i litteraturen angående normalisering.

33

Den första punkten hanterar faktorer som ofta nämns i förbifarten som en konsekvens av dålig normalisering; att arbetstid utökas och spenderas mindre effektivt. Denna studie ger tydliga exempel på vad detta innebär rent specifikt, nämligen svårighet att jobba med system, medförd tid för utbildning, då systemet är mer svårhanterat, samt oförmåga att nå relevant data för visa sökningar, då tabellerna i databasen saknar korrekta kopplingar.

Rent teoretiskt är den andra punkten tämligen uppenbar - en stor del av syftet och

motiveringen till varför normalisering bör genomföras från första början är just för att undvika opålitlighet i formen av redundans och inkonsistens i en databas. Genom att vidare kunna koppla problematiken (opålitlig data) till teknisk skuld bidrar denna studie med ett tydligt exempel på hur detta medför negativa konsekvenser i en verksamhet, genom att flytta fokuset från ett teoretiskt problematiserande till en konkretisering av verkliga konsekvenser och problematiker.

5.3 Kunskapsintressenter

Vid studiens inledning antogs att de intressenter som torde ha störst nytta av

forskningsbidragen skulle vara projektledare och beslutsfattare aktiva inom systemutveckling. De implikationer och det kunskapsbidrag som denna studie gett upphov till bedöms även i slutfasen av studien vara av vikt för just dessa intressenter, och belysa för dem vikten av design vid utvecklingsfasen. Vidare forskning inom området kan till och med tänkas skapa ett tydligare ramverk för hur en projektledare eller projektägare ska prioritera ett

utvecklingsarbete från start, samt ge en tydlig bild av de konsekvenser man kan undvika genom ett gediget designarbete, och vilka vinster man erhåller genom att undvika en teknisk skuld.

5.4 Slutsats

Att analysera teknisk skuld med grund i teorin av Albarak et al. (2020) och

forskningsmetoden design science fungerade utmärkt i praktiken. Då ett av målen med studien var att undersöka i vilken utsträckning teorin om teknisk skuld var möjlig att använda i

praktiken i ett befintligt system lades mycket tid på att utvärdera databasen inom ramarna för teknisk skuld. Senare reflektion visade att vår utvärdering av designen i Sysinfo och dess brister stämde bra överens med de faktorer som noterats som kritiska av Albarak et al. (2020) och som presenterats i kapitel 2.. Detta pekar mot att teknisk skuld identifierar faktorer som varit problematiska, vilket i sin tur pekar mot att det går bra att använda teknisk skuld som ett teoretiskt supplement i planeringen av ett förbättringsarbete. Nyttjandet av metodiken

strukturerade dessutom upp målen för projektet på ett lättförståeligt vis, vilket alltid är av nytta i denna typ av projekt.

34

6. Kritik och vidare forskning

Reflektioner över studiens kvalitet

Att forska med design science som metod passade studien väl, men det finns delar av metoden som är relativt diffusa. Nedan diskuteras otillräckligheter i studien som bör beaktas för senare forskning med samma inriktning.

Tidsbrist och praktiskt arbete

På grund av tiden som var nödvändig att lägga på själva uppsatsen och analys av våra resultat, samt faktumet att Payex redan hade startat projektet när vi blev involverade, har studien inte haft någon avgörande inverkan på det faktiska arbetet med databasen. Vi anser att det inte haft en avsevärt negativ effekt på denna studie, men kanske fanns det ytterligare insikter och bidrag som hade kunnat hittas om forskningen inletts i ett tidigare skede. För forskare med längre tidsram och möjlighet att påverka projektet tycker vi att framtida forskare bör vara mer involverade i projektet, och gärna från start. Det skulle garanterat ge en större inblick i

faktorer av ett projekt som kan ha missats i denna studie, förmodligen hade det gett en mer detaljerad bild av projektet. En viktig komponent i teknisk skuld är hur mängden arbetstid ett förändringsarbete kräver, något som vi inte fick särskilt mycket insikt i. På grund av att tiden behövts disponeras tiden mellan uppsatsen och det praktiska arbetet, samt att vi inte varit en del av det interna projektet hos PayEx har vi bristande inblick i arbetstidens omfattning.

Riktlinjer för design science

I vår studie har vi följt fyra av de sju riktlinjer som presenterats av Hevner et al. (2004), vilka presenteras i kapitel 3. Vi följde de riktlinjer som vi bedömde låg innanför ramen för det arbete krävdes. Som Hevner et al. (2004) skriver är det inte nödvändigt att följa samtliga riktlinjer, men man bör ta hänsyn till och värdera dem.

Angående studiens litteraturgenomgång

Som bör vara tydligt från tidigare kapitel har den här studien varit svår att förankra i tidigare forskning. Trots det ska bidraget ses som viktigt, och om något kan det ses som ett ytterligare bidrag att författarna har påbörjat forskning inom en relativt outforskad del av fältet teknisk skuld.

Till framtida forskare rekommenderas att genomföra en grundlig genomsökning efter tidigare forskning vid projektets start. Under projektets gång har relevant litteratur kontinuerligt sökts utan resultat Detta garanterar inte det att sådan forskning inte existerar, möjligtvis finns litteratur att finna inom fält som knyter an till informationssystem från andra vinklar, men det är inte något som utforskats tillräckligt. Det finns goda skäl att anta att sådana studier är sällsynta, som har beskrivits utförligt tidigare i uppsatsen, men möjligheten att förankra åtminstone en del av forskningen i en tidigare studie vore givetvis fördelaktigt. Att kunna undersöka vilka tidigare frågeställningar som har ställts, samt att se över vilka metoder dessa studier har valt att använda, kan ge mycket för fortsatt forskning inom fältet.

35

Vidare forskning

En möjlig väg för framtida forskning är att se hur väl det arbetssätt vi nyttjat i studien

fungerar på en icke-relationsdatabas. Majoriteten av litteratur kring ämnet är generell och kan appliceras på vilken typ av IT-artefakt som helst. Men forskningen av Albarak et al (2020) som ligger till stark grund för vår ansats och våra antaganden är specifikt fokuserad på just relationsdatabaser; risken finns därför att en del av våra fynd inte är generaliseringsbara, utan huvudsakligen är applicerbara på relationsdatabaser.

Det andra, tämligen självklara problemet är att vår studie givetvis inte är generell, då den enbart behandlar ett givet på case hos en specifik organisation. Självklart kan det ha dykt upp problem, förbättringsmöjligheter och specifika svårigheter i det här projektet som inte kan ses som generella. För att generera mer data som faktiskt är generaliseringsbar bör framtida forskning göras med en liknande ansats men på olika system och situationer. Vi vill dock betona att flera av våra fynd rimligtvis kan ses som generellt applicerbara; att det är svårare att bygga ett gränssnitt kopplat till ett svagt system ter sig självklart. Även att arbetsprocessen är mer tidskrävande ses som ett rimligt antagande, men vidare forskning bör genomföras. Som nämnt i kapitel 5 anser vi att det huvudsakliga bidraget i vår studie handlar om de praktiska implikationerna av teknisk skuld och hur det hänger ihop med normaliseringsteori. Vi anser att fler projekt bör genomföras som fokuserar på just de praktiska implikationerna av teknisk skuld, för att ge en tydligare bild av vilka faktiska problem som kan uppstå och hur man isåfall kan undvika att skapa dessa tidigt i ett projekt. Som tidigare nämnt anser vi att projektledare och projektägare är två av de grupper som kan ha störst vinning av den här sortens studie, och med vidare forskning inom ämnet finns möjligheten att över tid utveckla ett tydligare ramverk för hur teknisk skuld påverkar IS-projekt av olika slag - en praktisk manual för arbetet.

Sannolikt finns det vissa faktorer som är relevanta i alla IS-projekt och vissa som är mer relevanta i specifika domäner - vissa delar av våra bidrag är förmodligen mer applicerbart på specifika databaser (kanske mer specifikt relationsdatabaser), vilket i sig inte är något

negativt. Men det är av intresse att få kännedom om vilka faktorer som kan appliceras på samtliga IS-projekt, och vad som är relevanta enbart inom en viss domän.

36

Tack

Vi vill rikta ett stort tack till Payex Sverige AB för deras förtroende och möjligheten att genomföra studien i samarbete med dem. Utan deras stöd och tillgång till deras databaser

37 7. Källförteckning

1. Albarak, M. Bahsoon, R. Ozkaya, I. and Nord, R. 2020 - Managing Technical Debt in

Database Normalization. Institute of electrical and electronic engineering. IEEE

systems journal.

2. Atwood, J. 2009. Paying down your technical debt. In: Coding Horror, Available from: http://www.codinghorror.com/blog/2009/02/paying-down-your-technical- debt.html (accessed 24.08.11). (Online).

3. Baskerville, R.L. Kaul, M. Storey, V.C (2011) - Unpacking the duality of design

science. Proceedings of the International Conference on Information Systems, ICIS

2011, Shanghai, China, December 4-7, 2011

4. Baskerville, R.L; Baiyere, Abayomi; Gregor, Shirley; Hevner, Alan; and Rossi, Matti (2018) "Design Science Research Contributions: Finding a Balance between Artifact and Theory,"Journal of the Association for Information Systems: Vol. 19 : Iss. 5 , Article 3.

5. Seaman, C. Guo, Y 2011 - Measuring and Monitoring Technical Debt, Advances in Computers, Volume 82, 2011, Pages 25-46.

6. Gregor, S. Hevner, A. 2013 - Positioning and Presenting Design Science Research for Maximum Impact. June 2013 MIS Quarterly 37(2):337-356

7. P. Kruchten, R. L. Nord and I. Ozkaya, "Technical Debt: From Metaphor to Theory and Practice," in IEEE Software, vol. 29, no. 6, pp. 18-21, Nov.-Dec. 2012, doi: 10.1109/MS.2012.167.

8. Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software, vol. 101, pp. 193–220, Mar. 2015. 9. Markowitz, H. “Portfolio selection,” The journal of finance, vol. 7, no. 1, pp. 77–91,

1952.

10. Padron-McCarthy, T. Risch, T. (2008) - Databasteknik, 2018

11. G. Papastefanatos, P. Vassiliadis, A. Simitsis, and Y. Vassiliou, 2012 -

“Metrics for the prediction of evolution impact in etl ecosystems: A case study,” Journal on Data Semantics, vol. 1, no. 2, pp. 75–97, 2012.

12. Rittel, H. J, Webber, M. M. “Planning Problems Are Wicked Problems. Developments

in Design Methodology”. John Wiley & Sons, New York, 1984.

13. Sharpcorner,C.2020-https://www.c-sharpcorner.com/article/what-is-the-most-popular-database-in-the-world/

14. Tom, E. Aurum, A. Vidgena, R. 2013 - An exploration of technical debt. The Journal of Systems and Software 86 (2013) 1498–1516.

15. Victoria, B.C. 2014 - Workshop on Managing Technical Debt, pp. 43-46, doi: 10.1109/MTD.2014.17.

16. Weber, J.H. Cleve, A. Meurice, L. and Bermudez Ruiz, F.J. "Managing Technical Debt in Database Schemas of Critical Software," 2014 Sixth International

17. Westland, J.C. 1992 - Economic Incentives for Database Normalization. School of BusinessAdministration, University of Southern California, Los Angeles, CA 90089-1421,U.S.A.