1 Uppsala universitet
Inst. för informatik och media
Design och teknisk skuld i relationsdatabaser
En utvärdering av konsekvenserna av design och teknisk skuld i en driftsatt relationsdatabas
André Bizzarri, Gustaf Gröning
Kurs: Examensarbete Nivå: C
Termin: HT-20 Datum: 2020-01-07
Handledare: Jonas Sjöström
2 Sammanfattning/Abstract
I denna studie utvärderas designen i en befintlig databas som ska migreras från en lokal databashanterare till en molnbaserad lösning. Inför denna migrering har databasens normalisering och design varit ett föremål för diskussioner. Studien utreder vilka konsekvenser normalisering och design i relationsdatabaser har i en verksamhet. Studien presenterar teorin om normalisering i relationsdatabaser samt teknisk skuld. Som en del av studien testas och utvärderas en prototyp av en databas som antas vara normaliserad, ha god design och möta de behov som verksamheten har. Studien finner att teknisk skuld i databaser är tidskrävande, gör databaser opålitliga samt medför bristande kompatibilitet med andra artefakter.
Nyckelord:
relationsdatabas, normalisering, IT-operations, technical debt, teknisk skuld.
3
Innehållsförteckning
1 Inledning ... 5
1.1 Bakgrund ... 5
1.2 Problemformulering ... 5
1.3 Syfte och forskningsfrågor ... 5
1.4 Kunskapsintressenter ... 6
1.5 Avgränsningar ... 6
1.6 Disposition ... 7
2 Teori ... 7
2.1 Design i databaser ... 8
2.2 ER-diagram ... 8
2.3 Databasnycklar ... 9
2.4 Normalisering ... 10
2.5 Teknisk skuld ... 11
2.6 Beräkning av teknisk skuld ... 12
2.7 Research Setting ... 15
2.8 Tidigare forskning ... 15
3 Metod ... 16
3.1 Design Science ... 16
3.2 Ramverk ... 17
3.3 Riktlinjer ... 18
3.4 Problematik med Design Science Research ... 21
3.5 Val av forskningsmetod ... 21
3.6 Genomförande ... 22
4. Artefaktpresentation och utvärdering ... 22
4.1 Den ursprungliga databasen Sysinfo ... 22
4.2 Problem med Sysinfo ... 22
4.3 Teknisk skuld i Sysinfo ... 24
4.4 Den framväxande databasen ITOpsDB ... 27
4.5 Utvärdering av ITOpsDB ... 28
4.6 Teknisk skuld i ITOpsDB ... 29
5. Diskussion och slutsats ... 30
5.1 Forskningsfrågor ... 30
5.2 Forskningsbidrag ... 31
5.3 Kunskapsintressenter ... 33
4
5.4 Slutsats ... 33 6. Kritik och vidare forskning ... 34
5
1 Inledning
I den inledande delen av studien presenteras bakgrund och problemformulering tillsammans med syfte och forskningsfrågor som klargör varför ämnet är intressant att undersöka. Här presenteras även möjliga kunskapsintressenter, studiens avgränsningar samt uppsatsens disposition.
1.1 Bakgrund
Databaser är idag en grundsten i företag och myndigheters infrastruktur. De utgör själva kärnan i dagens informationssystem (Albarak et al. 2020) och används för strukturerad lagring av data om allt från personal och kunder till lager och andra IT-system. Vid skapandet av informationssystem är det av stor vikt att följa de regler och villkor som krävs för att systemen ska erhålla god design och därmed hög funktionalitet. Trots vikten av god design i system är det förekommande att man inte uppfyller de regler och villkor som krävs vid utvecklingen av system, vilket riskerar att leda till problem, framför allt när systemen används över tid. Dessa problem ger upphov till vad som kommit att kallas för teknisk skuld. Teknisk skuld är ett koncept lånat från ekonomin vars syfte är att kategorisera och tydliggöra problemen som uppstår som en konsekvens av förhastad utformning och driftsättning av ett system såsom en databas (Edith Tom et al, 2013). I vår studie görs en utvärdering av en driftsatt databas hos Payex Sverige AB, där har koncepten design och teknisk skuld har använts för att förtydliga de konsekvenser som design har i en verksamhet.
1.2 Problemformulering
På grund av att alla verksamheter idag använder informationssystem med databaser i grunden krävs det att dessa databaser fungerar tillfredsställande och är pålitliga källor till information.
För att en databas ska uppfylla dessa krav måste den designas korrekt genom att uppfylla nödvändiga regler och villkor (Padron-McCarthy & Risch, 2018). De regler och villkor som en databas ska uppfylla för att anses ha en god design är allmän kännedom inom sfären för arbete med databaser. Trots det finns många tecken på att dessa regler och villkor inte alltid följs.
Anledningen till detta kan vara allt från bristande kompetens till att en verksamhet försökt spara tid och resurser vid konstruktionen av en databas (Padron-McCarthy & Risch, 2018).
Oavsett anledning riskerar dålig design i en databas att bli ett problem när databasen sätts i drift.
Omfattningen av dessa problem varierar från fall till fall, inte minst med hänsyn till databasens storlek och dess syfte. För att öka förståelsen för vikten av design i databaser är det därför intressant att studera vilka konsekvenser design av databaser har i praktiken.
1.3 Syfte och forskningsfrågor
Syftet med denna studie är att utvärdera designen i en befintlig databas driftsatt i en verksamhet, samt vilka konsekvenser databasens design har för verksamheten. Designen utvärderas utifrån
6
det ramverk för normalisering som används vid design av databaser samt teorin om teknisk skuld, genom följande frågeställningar.
1. Vilka konsekvenser kan en dåligt normaliserad databas, som ett exempel på
teknisk skuld, ha för en verksamhet?
2. Hur kan konceptet teknisk skuld användas som ett verktyg för att förstå en
mindre väl fungerande systemdesign?
3. Uppfyller den nya databasen de villkor som gäller för god design i databaser?
1.4 Kunskapsintressenter
Kunskapen som denna studie bidrar med är avsedd att ge vägledning som kan assistera projektledare och beslutsfattare vid skapandet av databaser. Kunskapen och förståelsen kan även utgöra ett värde i utvecklingen av ett tydligare ramverk eller kravställning vid uteckling av databaser. De empiriska resultaten av forskningen kan även bidra till förstärkt inblick i de praktiska implikationerna av sådana projekt för forskare samt de konsekvenser som design av databaser har i verksamheter.
1.5 Avgränsningar
På grund av projektets utformning ges en naturlig avgränsning i den bemärkelsen att en unik, befintlig databas studeras. Studien avgränsas därmed till de egenskaper som denna databas ger vid handen. Däremot är de teorier kring normalisering och teknisk skuld som presenteras allmängiltiga inom sfären för databaser. Därmed förväntas att delar av vårt resultat kommer att kunna appliceras mer generellt samt att det kommer att bidra till utökad kunskap inom det berörda området, likväl som på andra databaser som andra typer av informationssystem.
Studien följer till stor utsträckning de riktlinjer som presenteras inom avsnittet för den valda metoden och kretsar till stor del kring utvärdering av en ny artefakt i form av en omdesignad databas som förväntas driftsättas.
Inom metoden för teknisk skuld ingår att fatta beslut om huruvida ett system ska omdesignas.
På grund av att studien är extern från verksamheten kommer detta beslutsfattande lämnas utanför denna studie.
Normalisering utförs sekventiellt från nivå ett till fem. Ytterligare nivåer existerar men ses mest som teoretiska. Denna studie behandlar därför normalisering upp till den tredje normalformen, då det anses vara den nivå där det praktiska värdet tar slut. “De högre formerna av normalisering
7
ses ofta som rent teoretiska”, menar Thomas Padron-McCarthy och Tore Risch i sin bok Databasteknik, “med litet praktiskt värde för en verksamhet”.
1.6 Disposition
Teori
I studiens andra avsnitt presenteras de teoretiska ramverk som ligger till grund för studien, tillsammans med en genomgång av tidigare forskning.
Metod
I studiens tredje avsnitt presenteras den valda metoden och forskningsstrategin.
Artefaktfpresentation och utvärdering
I studiens fjärde kapitel presenteras en beskrivning och utvärdering av den ursprungliga artefakten och en utvärdering av dess nuvarande tillstånd och problem. Efter det ges en presentation av den framväxande artefakten, följt av en utvärdering av densamma.
Diskussioner och slutsatser
I studiens femte del diskuteras studiens resultat. Forskningsfrågorna besvaras och presenteras tillsammans med de bidrag som forskningen tillför litteraturen och praktiken inom fältet, samt författarnas slutsats angeånde studien.
Kritik och vidare forskning
I studiens sjätte del förs en diskussion kring studien och dess kvalitet. Här presenteras också praktiska användningsområden, en kritisk reflektion av arbetet samt förslag på vidare forskning.
2 Teori
I detta avsnitt presenteras en genomgång av de teoretiska ramverk som ligger till grund för vår forskning. Här beskrivs grunderna för design i databaser, ER-diagram, normalisering samt metodiken för mätning av Teknisk skuld inom informationssystem.
8
2.1 Design i databaser
Olika typer att databaser existerar som bygger på olika typer av datamodeller, där den mest använda modellen kallas relationsdatabas (C-sharpcorner, 2020). I en relationsdatabas lagras data i relationer, även kallade tabeller, bestående av kolumner och rader. För att en databas ska anses ha god design och därmed bra funktionalitet behöver ett antal regler och villkor uppfyllas.
Uppfyller inte databasen dessa kriterier anses den ha dålig design. Dålig design i databaser kan exempelvis ge upphov till redundans, att data lagras dubbelt. Detta innebär att databasen blir otydlig och gör det svårt att hämta konkret värdefull information ur databasen, och riskerar dessutom att göra informationen opålitlig. Förutom otydlig information riskerar man att lagra onödigt stora mängder data vilket kräver onödigt stor datorkraft för att processa databasen. Tre grundläggande principer i arbetet med att skapa en databas med god design är ER-diagram, databasnycklar samt normalisering (Padron-McCarthy & Risch, 2018).
2.2 ER-diagram
Vid skapandet av en databas är det brukligt att först skapa en konceptuell modell av den databas man har för avsikt att bygga. Denna konceptuella modell består i grund och botten av ett schema som beskriver de tabeller som databasen innehåller, de samband som finns mellan tabellerna samt de nycklar som styr hur dessa tabeller refererar till varandra. Enligt Padron-McCarthy och Risch (2018) är det av stor vikt att denna konceptuella modell ritas korrekt för att dålig design inte ska föras vidare till den faktiska databasen. Författarna noterar att en dåligt designad databas kan ge upphov till stora svårigheter som riskerar att följa med under hela databasens livstid, vilket i vissa fall kan vara årtionden.
En vanligt förekommande konceptuell modell är den så kallade ER-modellen, också kallad ER- schema eller ER-diagram, där ER står för “entity” och “relationship”, fritt översatt till “saker”
och “samband” (Padron-McCarthy & Risch, 2018). Förenklat kan man säga att exempel på saker i en databas kan vara personer och motorcyklar. På samma förenklade vis kan man säga att samband utgörs av exempelvis ägande av en motorcykel. Med de förenklade premisserna kan man rita ett ER-diagram som innehåller saker i form av människor respektive motorcyklar, och som tydliggör sambanden mellan dessa genom att påvisa hur dessa motorcyklar ägs. I en relationsdatabas existerar tre sorters samband som presenteras nedan.
Ett-till-ett-samband (1:1) - Denna sambandstyp anger att en sak av typ X bara kan höra ihop med en sak av typ Y (Padron-McCarthy & Risch, 2018). Exempelvis kan en person vid ett och samma tillfälle bara köra en motorcykel, och varje motorcykel kan vid ett och samma tillfälle bara köras av en person.
Ett-till-många-samband (1:N) - Denna sambandstyp anger att en sak av typ X kan höra ihop med flera saker av typ Y, men en sak av typ Y bara kan höra ihop med en sak av typ X (Padron- McCarthy & Risch, 2018). Exempelvis kan en person äga flera motorcyklar, men en motorcykel kan bara ägas av en person. Detta samband kan även spegelvändas och benämns då N:1.
Många-till-många-samband (N:M) - Denna sambandstyp anger att en sak av typ X kan höra ihop med flera saker av typ Y, och varje sak av typ Y kan höra ihop med flera saker av typ X
9
(Padron-McCarthy & Risch, 2018). Exempel på detta kan vara att en person kan äga flera hus, och varje hus kan ägas gemensamt av flera personer.
I figur 1 ovan presenteras exempel på ett ER-diagram som visar sambanden mellan tabellerna motorcykel, person och hus. Enligt diagrammet kan en person kan äga flera motorcyklar, men en motorcykel endast kan ägas av en person. Samtidigt kan en person kan äga flera hus, och ett hus kan ägas av flera personer. Sambandet mellan respektive tabell anges av de streck med symboler i respektive ända som knyter samman tabellerna, där strecket mellan motorcykel och person anger ett N:1-samband och strecket mellan person och motorcykel anger ett N:M- samband.
2.3 Databasnycklar
Som tidigare nämnt är en av de grundläggande principerna för funktionaliteten i databaser de specifika nycklar som definierar respektive rad i en tabell. Dessa nycklar består huvudsakligen av primärnycklar (PK, efter engelska primary key) och främmande nycklar (FK, efter engelska foreign key) (Padron-McCarthy & Risch, 2018). I varje tabell bör alltid en primärnyckel finnas, vilken är den nyckel som används för att identifiera en specifik rad. I många fall finns det även en rad med främmande nycklar i en tabell, vilka alltid refererar till primärnyckeln i en annan, eller samma tabell (Padron-McCarthy & Risch, 2018). Dessa främmande nycklar fungerar som referensattribut, vilket innebär att de härleder till de attribut som finns på den rad med samma primärnyckel i tabellen som den främmande nyckeln refererar till. I figur 2 på nästa sida går det exempelvis att utläsa att en order har en primärnyckel som benämns OrderID. Denna order hämtar sedan information om en kund genom en främmande nyckel i samma tabell som refererar till primärnyckeln KundID i tabellen Kund, där samtliga attribut för kunden finns lagrad.
10
2.4 Normalisering
Enligt Thomas Padron-McCarthy och Tore Risch (2012) är normalisering “en teori för
relationsdatabaser, som används för att undvika vissa typer av dålig design.” Vid utvecklingen av databasen följer man en typ av regler som kallas normalformer. Dessa appliceras
sekventiellt efter varandra och startar med första normalformen. Normalisering kan göras i sammanlagt sju olika steg. I praktiken anses dock en relationsdatabas ha god design om den har normaliserats till tredje normalformen. Högre former anses i största utsträckning ha ett teoretiskt värde, eller ha ett praktiskt värde i vissa specifika databaser (Padron-McCarthy &
Risch, 2018). På grund av avgränsningarna som gjorts i denna studie kommer de högre normalformerna varken att presenteras eller användas i analysen av den avsedda databasen.
Första normalformen (1NF)
Första normalformen anger att “tabeller ska innehålla atomära värden, med andra ord högst ett värde per ruta” (Padron-McCarthy & Risch, 2018). Detta innebär att en kolumn i en tabell som beskriver en person exempelvis inte får innehålla både attributen namn och
telefonnummer, utan delas istället upp på två olika kolumner.
Andra normalformen (2NF)
Andra normalformen anger att “en tabell, förutom att vara i första normalformen, inte får innehålla några fullständiga funktionella beroenden på delar av primärnyckeln.” (Padron- McCarthy & Risch, 2018). Ett funktionellt beroende (fb) attribut är en variabel vars värde bestäms fullständigt av ett eller flera andra attribut. Rent krasst innebär det att “om värdet på ett attribut A entydigt bestämmer värdet på ett annat attribut B, är B funktionellt beroende av A” (Padron-McCarthy & Risch, 2018). För att ge en tydligare beskrivning hänvisas till Figur 2 ovan. Tabellen “Motorcykel” inkluderar en kolumn med attributet “Pris”, vars värde enkom bestäms av kolumnen “Modell”, då priset är anges av respektive modell. Kolumnen “Pris” är därför i denna tabell funktionellt beroende av kolumnen “Modell”.
Tredje normalformen (3NF)
11
Tredje normalformen anger att “en tabell, förutom att vara i andra normalformen, inte får innehålla några transitiva beroenden till icke-nyckelattribut”, vilket innebär att ett attribut inte får vara fullständigt beroende av ett attribut som inte är en primärnyckel (Padron-McCarthy &
Risch, 2018).
Normalisering i praktiken
Konventionella metoder inom databasdesign förespråkar att arbeta för att uppnå högsta möjliga normalform i en relationsdatabas, då det leder till bättre kvalité och livslängd på databasen. Det stämmer i teorin, men i praktiken är det inte lika entydigt. Arbetet med normalisering är av stor vikt, men det kan också vara en kostsam process (Padron-McCarthy
& Risch, 2018). Att göra om designen i en relationsdatabas är tidskrävande och hänsyn måste alltid tas till andra artefakter som bygger på databasen. Exempelvis kan det krävas
förändringar i kopplingar till gränssnitt eller andra artefakter som är knutna till databasen. En avvägning behöver därför göras mellan graden av normalisering, arbetet det kräver och de kostnader det medför.
2.5 Teknisk skuld
Technical debt, härmed kallad teknisk skuld, är ett koncept och ett forskningsfält inom domänen för informationssystem. Begreppet är en metafor lånad från ekonomin, där
konceptet teknisk skuld är informationssystemens motsvarighet till finansiell skuld (Tom et al, 2013). Konceptet används för att beskriva och definiera de kostnader som uppstår som en direkt konsekvens av en dålig eller icke genomtänkt design av en IS-artefakt, eller som Edith Tom et al beskriver, “Technical debt is a metaphor that refers to the consequences of poor software development.” (Tom et al, 2013). Konceptet har över tid blivit allt mer accepterat som en relevant aspekt vid forskning inom informationssystem. Albarak et al. (2020) menar dock att teknisk skuld inte alltid behöver anses som dåligt. Om man kan acceptera en liten teknisk skuld kan det nämligen tillåta utvecklare att genomföra produktionscykler betydligt snabbare och på så vis spara resurser.
Det finns flera typer av teknisk skuld och begreppet används lite olika beroende på kontext och domän, menar Zengyang Li, Paris Avgeriou och Peng Liang i sin studie A systematic mapping study on technical debt and its management (2015). J. H. Weber et al. (2014) menar att databaser har unika förutsättningar och svårigheter jämfört med annan mjukvara, vilket leder till en unik situation, och därmed definition, av teknisk skuld för vår studie.
Albarak et al. (2020) har skapat en modell för beräkning av den tekniska skulden i en relationsdatabas. Albarak et al. (2020) menar att ju längre tid en databas förblir dåligt normaliserad, och ju mer data som lagras - som då är ineffektivt strukturerad - desto svårare blir databasen att arbeta med. Den tekniska skulden ökar därmed över tid. Detta fenomen
12
lägger extra tyngd på vikten av god design och normalisering. Metoden för att mäta teknisk skuld används av denna anledning för att utreda huruvida det kan anses vara värt att driva ett projekt för att förbättra designen i en databas. Med andra ord, är vinningen i att lösa
databasens tekniska skuld mer värd än de resurser som måste investeras för att genomföra förändringen?
Flera faktorer har tydlig och erkänd påverkan på teknisk skuld. Däremot är det inte helt klarlagt på vilket sätt och till vilken grad, samt hur många de faktorer är som har en negativ effekt på skuldräntan. Tom et al. (2012) skriver att “whilst code decay and architectural deterioration are commonly recognised to be major dimensions of technical debt, accurately communicating the extent of technical debt in a system poses a significant challenge. It is evident that the boundaries of technical debt, as reflected in academic literature, are fuzzy – they lack clarity and definition – and represent a barrier to efforts to model, quantify and manage technical debt.” Att med fullständig klarhet fastställa faktorers effekt på den tekniska skulden i ett utvecklingsprojekt är med andra ord svårt. Den litteratur som är fokuserad på teknisk skuld i relationsdatabaser ger dock en relativt klar bild av faktorerna som berör vår domän. Viktigt att poängtera är dock att modellen för teknisk skuld inte bidrar med några tekniska direktiv för hur normalisering utförs. Syftet med modellen är endast att vägleda verksamheter i en utvärdering av huruvida det är lönsamt att genomföra normalisering av en databas eller inte.
2.6 Beräkning av teknisk skuld
Nedan presenteras de faktorer som enligt Albarak et al (2020) representerar kostnader för ett projekt som avser att förbättra designen i en databas enligt teorin för teknisk skuld.
● Uppdatering av schema - data i de nya tabellerna måste uppdateras och
matchas med den nya designen. Alla views, stored procedures och funktioner från andra artefakter måste uppdateras så att dessa kan nå de nya tabellerna.
● Migrering - en noggrann strategi måste planeras för att kunna migrera all data till den
nya designen utan några förluster av viktiga data.
● Fler potentiella lösningar behöver appliceras på andra artefakter.
Vidare identifierar Albarak et al. (2020) tre steg som måste genomföras sekventiellt för att identifiera, värdera och potentiellt lösa situationer som ger upphov till teknisk skuld i databasen.
Steg 1: Potential Debt Identification
13
Det första steget följer enligt Albarak et al (2020) krasst modellen för normalisering. Detta steg kräver en analys av databasen tabell för tabell för att undersöka vilken normalform som respektive tabell uppnår i det ursprungliga läget. Målet är att identifiera vilka tabeller som inte uppnår den tredje normalformen. Analysen genomförs huvudsakligen med hjälp av en
databasadministratör som helst har erfarenhet av den aktuella databasen, detta för att minimera tidsåtgången. I detta arbete ingår även enligt Albarak et al. (2020) att granska eventuell dokumentation med koppling till databasen. Steg 1 utgör ett förarbete och är menat att definiera vilka delar av databasen, om några, som behöver normaliseras.
Steg 2: Debt Impact and Cost Estimation
I modellens andra steg görs en granskning av storleken på den tekniska skulden i förhållande till databasens syfte, samt den potentiella kostnad som ligger i arbetet med att lösa skulden.
Detta görs med hjälp av en analys som undersöker ett antal variabler, följt av ett vägt beslut av projektgruppen. Nedan presenteras respektive variabel som ligger till grund för analysen.
Datakvalitet
I modellens definieras datakvalitet som ett mått på datas konsistens (Albarak et al. 2020).
Dåligt normaliserade tabeller lagrar stora mängder, ofta redundant data. Risken är här stor att en förändring eller uppdatering av data leder till att redundant data förblir oförändrad. Då data kan lagras på fler än ett ställe som inte alltid minns av individen som uppdaterar eller
förändrar data. Därför försämras konsistensen, och därmed datas kvalitet.
Hållbarhet
Hållbarhet definieras som ett mått på hur enkelt det är att genomföra förändringar, åtgärda problem och lägga till funktioner i ett system. Albarak et al. (2020) nämner antalet attribut i en tabell som ett bra mått på komplexitet. Detta på grund av att en dåligt normaliserad databas innehåller tabeller med för många attribut, vilket innebär en högre komplexitet och en därmed en sämre hållbarhet. Anledningen till detta är att mängden attribut i en tabell har stor inverkan på hur krävande arbetet med att uppdatera en databas som redan är i bruk blir, enligt G.
Papastefanatos et al. (2012).
Prestanda
Vanliga kommandon som genomförs i en databas inkluderar update, insert, delete och hämtning av data. Vart och ett av dessa kommandon ställer krav på hårdvarans prestanda vilket medför en kostnad för detta (Albarak et al. 2020). Teknisk skuld kopplad till prestanda är därför nära kopplad till den grad som tabellerna är normaliserade - en dåligt normaliserad tabell med data på tre olika platser kräver exempelvis att update genomförs på samtliga tre platser, vilket därmed kräver tre gånger mer prestanda.
14 Datatillväxt och tabeller
Olika tabeller används olika mycket, vilket drastiskt påverkar hur kostsamma ovanstående variabler blir för den specifika tabellen (Albarak et al. 2020). Albarak et al. (2020) skriver att
“Tables’ growth rate is a crucial factor that will cause the impact of the debt on the three qualities to accumulate faster.”. Vad den innebär är att ju snabbare en tabell växer (ju mer data som adderas och/eller uppdateras) desto större påverkan har ovanstående faktorer. I en dåligt normaliserad databas är det större risk att en insert inte hamnar på alla rätta platser (kvalitén på data blir sämre), det blir svårare att avgöra exakt vart data ska placeras
(hållbarheten blir sämre) och det blir ännu fler input/outputs när man väl försöker hitta data (prestandan är sämre). Därför är en tabells generella tillväxt en viktig parameter som ovanstående variabler mäts mot, då det i stora drag är det som avgör hur pass skadliga faktorerna är (Albarak et al. 2020). Även en svagt normaliserad tabell kan vara hanterbar om den sällan uppdateras eller förändras - normaliseringen är alltså inte ett lika stort problem.
Arbetstid
Den sista faktorn i modellen baseras på den beräknade arbetstiden som krävs för att normalisera en given tabell (Albarak et al. 2020). Det är här som den direkt finansiella kostnaden av normalisering kommer in. I en optimal situation vill man alltid normalisera samtliga tabeller till högsta möjliga normalform, men det är inte alltid praktiskt lämpligt att utgå från att man har resurserna för det. Därför tar man analysen från tidigare steg
(faktorerna) och jämför det med den förväntade resursåtgången kopplad till arbetet - en större tabell med flera kopplingar kräver mer arbete än en mindre, mer självständig, tabell. Med dessa steg genomförda går modellen över till sitt tredje och sista steg:
Prioritering av arbetet genom portföljteorin
Teknisk skuld metoden bedömer den generella risken av en tabell likt en tillgång i ekonomin, därav portföljteorin (Albarak et al. 2020). Syftet med portföljteorin är att välja ut ett antal tillgångar som tillsammans ska generera största möjliga tillväxt med minsta möjliga risk (H.
Markowitz, 1952). Tillväxten representeras metaforiskt av hur mycket tabellen skulle tjäna på att bli normaliserad, vilket till störst del beror på hur pass normaliserad den redan är; ju svagare normaliseringen är i nuläget, desto större blir vinsten vid normalisering till tredje normalformen. Risken handlar huvudsakligen om tabellens tillväxt; ju mer tabellen växer, desto större är risken med att inte normalisera den.
Steg 3: Beslutsfattande
Det tredje steget kräver ett beslutsfattande baserat på den analys som gjorts i steg 1 och 2. Här beslutas om, och isåfall vilka delar (om inte hela) av databasen som måste normaliseras.
15
2.7 Research Setting
För vår studie har vi givits möjligheten att utvärdera en databas driftsatt hos PayEx AB.
Företaget är verksamma inom FinTech och är en av Sveriges ledande aktörer inom sin nisch.
Databasen som studeras heter Sysinfo och används av IT-Operations som en del i IT- förvaltningen med syftet att logga incidenter eller aktiviteter som exempelvis uppdateringar av system. Viktigt att poängtera är att denna databas inte används i produktionen och inte behandlar data om kunder, transaktioner eller annan känslig information.
Sysinfo har varit driftsatt sedan tidigt 2000-tal och ligger idag lokalt. Inom IT-operations har beslut nu fattats om att migrera databasen till den molnbaserade databashanteraren Azure.
Under tiden som Sysinfo har använts i drift har en del brister i funktion och hantering identifierats som man har för avsikt att åtgärda innan migreringen. Dessa brister har uppkommit som en konsekvens av databasens design. Av den anledningen har man beslutat att skapa en ny databas från grunden med namnet ITOpsDB. Till denna databas ska alla väsentliga data migreras från Sysinfo innan den slutliga migrationen till databashanteraren Azure.
ITOpsDB kommer att fylla samma syfte som den tidigare Sysinfo, men förhoppningen är att den nya designen ska ska göra ITOpsDB betydligt effektivare. Mycket av det förberedande arbetet inför migrationen till Azure är redan utfört av teamet inom IT-Operations. De har skapat ett ER-diagram som definierar de tabeller, nycklar och samband som ska utgöra den nya databasen. Baserat på detta ER-diagram har en testversion av ITOpsDB skapats. Vår primära uppgift blir här att testa och utvärdera den nya databasen för att säkerställa att den fungerar tillfredsställande och att designen i den nya databasen är optimal. Detta arbete består i att fylla databasens respektive tabeller med lämpliga data för att sedan skapa och exekvera ett antal queries som är relevanta för databasens funktion. Det praktiska arbetet kommer naturligt att ge upphov till en diskussion kring normaliseringen i den nya databasen där vi också kommer att granska hur designen skiljer sig mellan Sysinfo och ITOpsDB. Genom att granska databasen Sysinfo kommer vi också få möjligheten att analysera den tekniska skuld som uppkommit i där, och huruvida den har förbättrats eller lösts i och med den nya designen i ITOpsDB.
2.8 Tidigare forskning
Begreppet teknisk skuld introducerades av Ward Cunningham (1992) med avsikt att förklara behovet av att förbättra och omstrukturera kod för icke-tekniska intressenter. Sedan dess har det forskats mycket inom området med fokus på att hantera nuvarande eller undvika framtida teknisk skuld. Teknisk skuld tar olika former och en mängd forskning har menat att bidra till definitionen och kategoriseringen av teknisk skuld. P. Kruchten, R. L. Nord och I. Ozkaya (2012) menar att de flesta författare håller med om att teknisk skuld huvudsakligen uppstår som en konsekvens av schemaläggningsproblem, alltså tidsbrist. Men författarna poängterar även att det på senare tid har uppmärksammats att teknisk skuld även kan uppkomma som en konsekvens av arbetssätt, då främst i formen av ansvarslöshet, bristande utbildning, eller osystematisk verifiering av kvalitetsmått. W. Cunningham (1992) pekar på att den iterativa naturen av agilt projektarbete även är en stor faktor till uppkomsten av teknisk skuld, då agila
16
projekt ofta ser teknisk skuld som en naturlig konsekvens av deras arbetssätt som kan lösas i efterhand, vilket sällan görs.
Den litteratur som stått att finna fokuserar nästan uteslutande på hur man undviker uppkomsten av teknisk skuld, samt hur man eliminerar existerande teknisk skuld. Artiklar som “measuring and monitoring technical debt” och “an exploration of technical debt” är frekvent citerade och representerar den generella trenden inom forskningen. Den här studien har en tydlig förankring i den teoretiska basen som existerar i forskningen inom teknisk skuld, både inom normaliseringsteori och teknisk skuld. Att däremot finna studier som har undersökt praktiska implikationer och faktiska konsekvenser av teknisk skuld i en verklig organisation har visat sig svårt. Flera studier menar att konceptualisera teknisk skuld på ett vis som överför kunskapen från ett rent teoretiskt fält till ett praktiskt sådant, men målet har då oftast varit en omformulering av teoretisk kunskap - den välciterade artikeln av P. Kruchten et al, "Technical Debt: From Metaphor to Theory and Practice” (2012), kategoriserar och delar upp olika komponenter inom fältet för senare forskning. Ovan nämnda artiklar är det närmaste praktiskt relevant litteratur som fanns att hitta inom fältet, och ingen av dem ger en kvalitativ empiri avseende de konsekvenser som teknisk skuld har i en verksamhet. Av den anledningen har det visat sig svårt att förankra denna studie i tidigare forskning trots att det teoretiska ramverket finns; studier med liknande syfte verkar saknas inom fältet. Detta verkar indikerar ett kunskapsgap avseende de konsekvenser som teknisk skuld har för en verksamhet i praktiken, och därmed ett utrymme för denna studie att bidra med något nytt inom detta område.
3 Metod
I detta avsnitt presenteras den forskningsmetod som valts för studien.
3.1 Design Science
Informationssystem används i organisationer för att öka effektivitet och precision i verksamheten. Systemen utgör en avancerad, artificiell och noggrant designad komponent i organisationernas drift. En metodik vid forskning inom informationssystem är Design science.
Design science bygger på att med hjälp av kunskap och förståelse lösa problem inom ett område, genom att bygga och applicera en artefakt. För att förstå vikten av Design science är det nödvändigt att läsa in design som både en process, likväl som en produkt (Hevner et al.
2004). Design är en iterativ process som utgår från kunskap och leder till utformandet av en produkt. Produkten utvärderas sedan vilket skapar en djupare kunskap och ger en möjlighet att ytterligare förbättra produkten likväl som processen i nästa iteration. Denna loop upprepar sig generellt ett antal gånger innan den slutgiltiga designen kan presenteras (Hevner et al. 2004).
Mark och Smith (1995) presenterar två designprocesser, och fyra designartefakter i forskningen inom Design Science. Designprocesserna benämns som byggandet och utvärderandet.
Designartefakterna benämns som konstruktioner, modeller, metoder och instanser. Artefakter byggs för att möta problem inom ett område, och utvärderas baserat på deras förmåga att lösa problemen. Konstruktioner beskrivs som det språkliga ramverk som formulerar hur problem och lösningar definieras och presenteras. Modeller används för att visualisera ett verkligt designproblem och dess lösning, baserat på en konstruktion. De används för att underlätta förståelsen av ett problem och dess lösning samt ger forskare en möjlighet att utforska en designs påverkan och effekter i ett verkligt fall. Metoder definierar en process och ger en vägledning i arbetet med att studera problemområdet och lösa de problem som avses. Metoder
17
kan bestå av informella beskrivningar i textform eller strikta matematiska algoritmer, eller en blandning därav. Instanser bekräftar att metoder, modeller eller konstruktioner fungerar och kan implementeras i ett befintligt system. De ger också forskare en möjlighet att studera hur artefakterna fungerar i en verklig situation och hur den påverkar ett system (Hevner et al. 2004).
Design science används för att lösa vad de beskriver som wicked problems (Rittel & Webber, 1984). Dessa problem karaktäriseras enligt nedan:
● Otydliga krav och begränsningar baserade på dåligt definierade sammanhang i en miljö.
● Komplexa interaktioner mellan problemets komponenter och dess lösning.
● En inneboende flexibilitet för att förändra en designprocess likväl som designartefakter.
● Ett kritiskt beroende av individers kognitiva förmågor, exempelvis kreativitet, för att skapa effektiva lösningar.
● Ett kritiskt beroende av individens sociala förmåga, exempelvis lagarbete, för att skapa
effektiva lösningar.
3.2 Ramverk
Metodiken för design science inom informationssystem utgår från ett ramverk som vilar på tre fundament, miljö, forskning och kunskapsbas. I figur 3 på sida 16 ges en översikt av ramverket och hur dess fundament förhåller sig till varandra.
Miljön som avses vid forskning inom informationssystem definierar det problemområde inom vilket ett system används. Enligt Hevner et al. (2004) består miljön av organisationer och människor samt de befintliga eller planerade teknologier som existerar inom organisationen. I denna miljö finns möjligheter, problem, mål och uppgifter som definierar företagens behov.
Företagens behov utvärderas och bedöms inom ramen för deras strategier, struktur och befintliga arbetsprocesser. Behoven står i sin tur i relation till existerande applikationer, teknologisk infrastruktur och utvecklingsmöjligheter. Hevner et al. (2004) definierar dessa faktorer som de behov eller problem som är relevanta för forskare att studera.
Forskningen som avses i detta ramverk består i att utveckla eller bygga antingen teorier eller artefakter utifrån den givna miljön (Hevner et al. 2004). Dessa teorier eller artefakter utvärderas sedan genom exempelvis analyser, experiment eller simuleringar. Vid dessa utvärderingar kan brister i den utvecklade artefakten eller teorin upptäckas. Detta gör det möjligt för forskarna att återgå till bygg- och utvecklingsfasen och åtgärda bristerna, för att sedan göra en ny utvärdering. Syftet här är enligt författarna att möta företagens behov genom att skapa en teori eller artefakt som främjar användbarhet.
Kunskapsbasen som avses i ramverket för design science består enligt Hevner et al. (2004) av fundament och metoder. Fundamenten utgörs bland annat av teorier, modeller, ramverk och instanser som används vid bygg- eller utvecklingsfasen. Metoderna utgörs av tekniker för att
18
analysera data, mätningar, och eventuella kriterier som bör uppfyllas. Dessa metoder används enligt författarna för att rättfärdiga eller utvärdera de teorier eller artefakter som skapas. Inom design science är det framför allt datorberäkningar eller matematiska formler som används för att utvärdera effektiviteten eller kvalitén hos en artefakt.
Figur 3
3.3 Riktlinjer
Hevner et al. (2004) beskriver design science som en process avsedd för problemlösning. För att underlätta för forskare, redaktörer, läsare och recensenter att förstå de krav som ställs på en effektiv forskning inom design science har de skapat sju riktlinjer som forskare bör förhålla sig till . Författarna framhäver att riktlinjerna inte behöver följas strikt, men att man alltid bör ta hänsyn till dem för att ett forskningsfall inom design science ska kunna ses som komplett. I vilken utsträckning riktlinjerna ska följas lämnas till respektive intressent att värdera. Nedan följer en översikt av de sju riktlinjerna samt en närmare beskrivning av de riktlinjer som är relevanta för vår forskning.
Riktlinje 1: Design som artefakt
Forskning inom design science måste producera en livskraftig artefakt i form av en konstruktion, modell, metod eller
instansiering.
19 Riktlinje 2: Problemets
relevans
Målet med forskningen är att utveckla teknologibaserade lösningar på viktiga och relevanta affärsproblem.
Riktlinje 3:
Utvärdering av design
En designartefakts användbarhet, kvalitet och effektivitet måste rigoröst demonstreras genom väl utförda utvärderingsmetoder.
Riktlinje 4:
Forskningsbidrag
Effektiv forskning inom design science måste erbjuda tydliga och verifierbara forskningsbidrag inom området för aktuella
designartefakter, designfundament, och/eller designmetodiker.
Riktlinje 5:
Forskningens rigorositet
Forskning inom design science vilar på appliceringen av rigorösa metoder, både i skapandet och utvärderingen av designartefakten.
Riktlinje 6: Design som en sökprocess
Sökandet efter en effektiv artefakt kräver användning av de resurser som finns tillgängliga för att möta önskade mål, samtidigt som det tar hänsyn till de villkor som
problemområdet uppställer.
Riktlinje 7:
Kommunikation av forskningen
Forskningen inom design science måste presenteras effektivt gentemot både den teknologiorienterade likväl som den driftorienterade publiken.
Design som en artefakt
Enligt Hevner et al. (2004) ska en meningsfull artefakt vara resultatet vid forskning inom design science. Artefakten ska användas för att lösa viktiga organisatoriska problem och måste beskrivas på ett tydligt sätt för att kunna appliceras och implementeras i sin rätta domän.
Författarna inkluderar utöver instanser även konstruktioner, modeller och metoder i sin definition av en designartefakt. Som exempel på en artefakt nämner de ERD-modellen, tidigare beskriven i denna studie, som en konstruktion som har haft en enorm inverkan på hur databaser ska byggas och analyseras. I vårt forskningsfall ses den nya databasen och dess ER-diagram
20
som den artefakt som uppkommer genom design. Ingen av dessa artefakter är på något sätt en ny upptäckt, utan kommer endast vara föremål för utvärdering. Utvärderingen kan komma att vara grund för ny design av artefakten.
Problemets relevans
För en lyckad forskning inom design science krävs en djup förståelse och kunskap som möjliggör utveckling och implementering av teknologibaserade lösningar på tidigare olösta affärsproblem (Hevner et al. 2004). Författarna definierar problem som “skillnaden mellan ett önskat mål och det nuvarande tillståndet”. Problemlösning definieras som en sökprocess som genom handlingar söker att reducera skillnaden däremellan. Enligt författarna måste problemet vara relevant för den sfär som berörs av det. För att vara relevant inom sfären informationssystem måste forskningen adressera möjligheter och problem som uppstår vid interaktionen mellan organisationer, individer och informationsteknologi. Enligt Keil et al.
(1998) spenderar företag årligen miljardbelopp på IT, som ofta inte genererar några nämnvärda vinster. Hevner et al. (2004) menar därför att denna sfär varmt skulle mottaga lösningar på relevanta problem. För vårt forskningsfall är det relevant med en databas som har bra användbarhet och ger tydlig, korrekt information. Den ursprungliga databasen som skall designas om har inte uppfyllt de förväntade kraven vilket har orsakat en del problem i verksamheten. Målet med forskningen blir därför att med stöd i denna riktlinje att lösa detta affärsproblem.
Utvärdering av design
Enligt Hevner et al. (2004) är utvärdering av yttersta vikt vid forskning inom design science.
På grund av detta menar författarna att rigorösa utvärderingar med hjälp av väletablerade modeller måste användas för att utvärdera designartefakters effektivitet, kvalitet och användbarhet. De krav på utvärdering som ställs baseras på respektive fall inom olika affärsområden. Ofta utförs utvärderingar baserat på dataanalyser som mäter exempelvis precision, prestanda, funktionalitet eller användbarhet. Hevner et al. (2004) menar att design är en iterativ process, där en utvärdering ger möjlighet att gå tillbaka och korrigera eller förbättra designen. Enligt författarna är det först när en artefakt ställda krav och begränsningar på ett tillfredsställande vis som den anses vara komplett och effektiv. I vårt forskningsfall kommer utvärderingen av databasen vara den mest centrala delen. Med stöd av det teoretiska ramverket för normalisering och teknisk skuld kommer utvärderingen göras enligt denna riktlinje.
Forskningsbidrag
Hevner et al. (2004) nämner tre områden vid forskning inom design science där forskningen måste ge tydliga bidrag och ställer upp en simpel men kritisk frågeställning för denna riktlinje;
“Vad är de nya och intressanta bidragen?”. De tre områdena avser designartefakten, fundamenten och metoderna. Designartefakten är oftast i sig själv det väsentliga bidraget, vilket löser ett hittills olöst problem. Den kan enligt författarna lösa problem genom att applicera
21
existerande kunskap på nya, innovativa sätt eller utöka den befintliga kunskapsbasen.
Fundament som bidrag utgörs av väl utvärderade modeller, metoder eller instanser som utökar eller förbättrar de existerande fundamenten. Bidrag i form av metoder avser förbättrade eller nya metoder för exempelvis utvärderingar. Det bidrag vi hoppas kunna ge med vår forskning består i en djupare kunskap kring de konsekvenser som design i en databas har för en verksamhet.
3.4 Problematik med Design Science Research
Trots fördelarna som beskrivits ovan finns det givetvis nackdelar med metoden och arbetssättet.
Den främst förekommande kritiken gäller den generellt otydliga definitionen av “design”, som beskrivet av Baskerville, R.L, Et al (2018). Design har flera olika definitioner, vilket kan göra det svårt att påvisa vad konceptet faktiskt innebär, hur det förankras i en studie, och därmed om en studies tillvägagångssätt går att motivera. Förutom definitionen av design är det dessutom tämligen oklart hur man forskar inom design - vilka metoder och vilket arbetsflöde ska tillämpas för att med någon form av säkerhet kunna avgöra huruvida en forskare har kommit fram till något användbart?
Avseende definitionen av design så appliceras det förhållningssätt som beskrivs av Baskerville, R.L, Baiyere, Abayomi, Gregor, Shirley, Hevner, Alan och Rossi, Matti (2018); “för att kvalificeras som design inom ramen av design science måste studiens fokus ligga på designen av en artefakt, designen av en teori, eller båda”. Då studiens syfte är att analysera och utvärdera en databas, samt att bidra med kvalitativ empiri avseende effekterna av teknisk skuld i en verksamhet täcker studien båda definitionerna, men argumenterbart med mer fokus på designen av en artefakt.
Avseende hur man forskar inom design applicerar vi Baskerville R.L, Kaul M och Storey, V.C (2011) tillvägagångssätt; att analysera och söka förståelse angående hur designernas kunskap påverkar projektet. Tillvägagångssättet passar bra till studiens forskningsfrågor och teoretiska bas, då både problematik med normalisering och teknisk skuld är något som till stor del kan uppkomma som en konsekvens av bristande kunskap inom områdena bland designers.
3.5 Val av forskningsmetod
Som förklarat ovan är Design Science en lämplig modell i de fall där forskningen som ska bedrivas innehåller praktiska komponenter och där bidraget delvis uppkommer som en konsekvens av forskarnas egna lärdomar och erfarenheter under projektets gång. Då denna studie kommer att bygga på en utvärdering av ett givet system, presenterat i kapitel 4, bedöms att metoden passar syftet väl. I projektets start diskuterades möjligheten att bedriva
forskningen som en litteraturöversikt, men i ett tidigt stadie blev det tydligt att majoriteten av forskningen inom fältet bedrevs med en teoretisk utgångspunkt. Denna studie är ämnad att påvisa praktiska konsekvenser av teknisk skuld i form av dålig design, något som presenteras i forskningsfråga 1 och 2. På grund av detta praktiska tillvägagångssätt valdes design science över andra metoder.
22
3.6 Genomförande
I denna studie har metoden för design science används för att utvärdera två databaser, varav en är i drift och en förväntas driftsättas för att ersätta den förstnämnda. Metoden har använts med fokus på utvärderingsmomentet i design science, genom att luta sig mot den kunskapsbas i form av teorier och modeller gällande design av databaser och teknisk skuld som presenterats i kapitel 2, samt de affärsbehov som databasen avser att uppfylla. I Kapitel 4 presenteras resultaten för utvärderingen av respektive databas. I utvärderingen har tabellerna i respektive databas och den lagrade datan har analyserats utifrån de presenterade teorierna om design i databaser samt de parametrar för teknisk skuld som behandlar datans struktur tillsammans lösningsförslag på identifierade problem avseende datatyper och lagring. I kapitel 4 presenteras resultatet av denna utvärdering samt en presentation av de aktuella databaserna.
4. Artefaktpresentation och utvärdering
I detta kapitel presenteras och utvärderas de artefakter som utgör fokuset för vår studie. Kapitlet inleds med en beskrivning av den ursprungliga databasen Sysinfo. Därefter ges en beskrivning av de identifierade problemen och utvärdering av den tekniska skulden i Sysinfo tillsammans med potentiella lösningsförslag. Efter detta presenteras den nya, framväxande databasen ITOpsDB, följt av en utvärdering av dess normalisering och tekniska skuld.
4.1 Den ursprungliga databasen Sysinfo
Den ursprungliga databasen Sysinfo har som huvudsyfte att “logga incidenter inom verksamhetens servrar och nätverk, samt att logga patchar eller uppdateringar.” Databasens tabeller ska därför innehålla data om dessa loggar, vilka objekt eller system de berör, vilka tekniker som är ansvariga och liknande. Teamet inom IT-Operations har kontinuerliga möten där bland annat incidenter diskuteras så att mer långsiktiga lösningar kan appliceras. Den historik som loggarna erbjuder kan ha stor betydelse för driften, varför det är av vikt att loggarna som skapas innehåller korrekt, pålitlig information som är enkel att tolka.
Loggning i Sysinfo sker via ett gränssnitt på en intern webbsida. Denna webbsida används för loggning av samtliga i teamet. I dagsläget arbetar enbart tekniskt personal med databasen och därmed även gränssnittet. I framtiden finns en önskan om att även andra användare, icke- teknisk personal, ska kunna använda systemet.
4.2 Problem med Sysinfo
Designen i SysInfo har orsakat en hel del problem som har negativa konsekvenser för arbetet med databasen. Nedan sammanställs en lista över de upplevda problemen tillsammans med möjliga lösningsförslag.
1. Den manuella loggningen av data genom gränssnittet
23
I dagsläget måste alla loggar göras manuellt i SysInfo genom ett internt webbaserat gränssnitt.
Detta gäller även återkommande rutinarbeten som patchningar av servrar eller andra uppdateringar. Denna typ av rutinarbeten utförs vanligen på flera system samtidigt, vilket innebär att flera mer eller mindre identiska loggar måste skapas manuellt. Detta är i vissa fall onödigt tidskrävande och kan i kombination med fritextfält skapa stora mängder otydlig data.
Lösningsförslag 1.
Delvis eller helt automatiserad loggning vore önskvärt i de fall det är möjligt. Trots att delar av loggarna fortfarande behöver matas in manuellt bör gränssnittet utvecklas så att det kan kopiera den väsentliga datan till nästa logg och ändra. Detta skulle minska mängden otydlig data som loggas.
2. Svag normalisering i databasen
Den svaga normaliseringen i SysInfo leder bland annat till redundans och osäkerhet kring huruvida information om incidenter har loggats korrekt på samtliga platser. Detta leder dels till att det lagras onödigt stora mängder data i databasen, dels till att informationen i databasen blir opålitlig, vilket man internt anser vara det största och mest allvarliga av dessa problem. Det är också en av de största anledningarna till att man känner att databasen behöver designas om.
Lösningsförslag 2.
Skapande av ny databas med noga genomtänkt design, fullgod normalisering och korrekt angivning av både primära och främmande nycklar. Som en del i detta led ritas först ett väl strukturerat ER-diagram.
3. Fritext i kolumner och andra problematiska datatyper
Flertalet tabeller i SysInfo tillåter fritext i attributen. Detta är dels mer tidskrävande gränssnitts- mässigt, dels blir informationen i loggarna mer otydlig, ibland opålitlig. Som exempel på detta kan nämnas ett attribut i tabellen för operativsystem, där användare loggat både “Windows 2000” och “Windows 2000 r”, alltså olika namn på samma operativsystem. Detta försvårar väsentligt möjligheterna att göra statistiska analyser och söka information om ett specifikt operativsystem.
Lösningsförslag 3.
Minimera mängden fält med fritext i största möjliga utsträckning. Använd istället checkboxar eller multiple-choice baserat på ENUM datatyper för att skapa precision, kvalitét och integritet i den data som lagras.
24 4. Automatisk loggning av datum
Automatisk loggning av datum är inte alltid optimalt i den här typen av databas. Syftet med loggningen av datum är att få historik kring när exempelvis en ändring i ett system har genomförts. Ibland kan det uppstå situationer som gör att en ändring loggas först någon dag efter att den genomfördes. På grund av att SysInfo lagrar DATETIME automatiskt när en logg skapas kan därför datum för ändring lagras felaktigt. I många fall är automatisk insättning av det nuvarande datumet en bra design, men för Payex syften leder det enbart till tvetydigheter i loggarna.
Lösningsförslag 4.
Användaren får i framtiden ange datum för utförande manuellt, snarare än att systemet automatiskt anger dagens datum.
5. Gränssnittet
Den hemsida som används för att skapa loggar är idag varken estetiskt tilltalande eller tydlig.
Anledningen till detta är den svaga normaliseringen och designen av SysInfo, som gör det svårt att få en tydlig struktur på gränssnittet.
Lösningsförslag 5.
Förbättrade design och normalisering av databasen kommer att göra det enklare att utforma ett gränssnitt med god användbarhet som snabbt och effektivt kan kommunicera med databasen.
Bättre struktur på tabellerna, något som sker naturligt via starkare normalisering, kommer göra det lättare att bygga ett uppdaterat gränssnitt, som i den största möjliga utsträckningen även ska inkludera multiple-choice och checkboxar, vilket även hjälper till att lösa problematiken med datatyper.
4.3 Teknisk skuld i Sysinfo
Steg 1. Potential Debt Identification
Det första steget vid utvärdering av teknisk skuld inom en relationsdatabas utgörs av en granskning av dess tabeller med syftet att identifiera dålig normalisering. I fallet med Sysinfo har ett flertal tabeller med dålig normalisering identifierats. Samtidigt har även flera problem orsakade av dålig normalisering lyfts av användare av databasen. Den bristfälliga
normalisering och de problem som det orsakat i verksamheten har i detta fall varit så omfattande att det har motiverat beslut om att bygga en ny databas från grunden, istället för att göra mindre korrigeringar av designen i den befintliga databasen.
25 Steg 2: Debt Impact and Cost Estimation
Nedan följer en analys av databasen med mer praktiska problem. Trots att problemen kan ta olika karaktär och kanske vara unika för detta system så grundar sig samtliga i ett problem med normaliseringen.
Datakvalitet
Flera tabeller innehåller redundant data. Detta orsakar otydlighet, och medför att onödigt stora mängder data lagras. Detta är en stor anledning till att inserts är omständliga, vilket i sin tur har lett till svårigheter med att designa gränssnittet som används för att skapa loggarna. Över tid kommer denna redundans potentiellt innebära större problem inom kategorierna hållbarhet och prestanda.
Systemet inkluderar även data som inte är redundant, men inte är relevant för databasens syfte. Även detta har en viss negativ effekt på loggarna som riskerar att bli svåra att tyda, framför allt för personal som inte är teknisk eller en del av IT-operations teamet. Eftersom ett av Payex önskemål i framtiden är att även icke-teknisk personal ska kunna använda
gränssnittet och skapa loggar blir det ett problem, då det just nu enbart är den tekniska personal som arbetar med systemet som förstår hur systemet fungerar.
Hållbarhet
SysInfo bedöms ha en låg hållbarhet. I databasen har det förekommit många tabeller som har lagrat irrelevant data, därtill har vissa kritiska tabeller, som exempelvis Objects, lagrat 17 olika attribut utan några databasnycklar som referens. Den låga hållbarheten i SysInfo har medfört stora svårigheter i förändringsarbetet. Dessa svårigheter har visat sig vara så pass omfattande att det har framstått som enklare att bygga om hela strukturen från grunden, istället för att försöka förändra det befintliga systemet. På grund av detta ses den tekniska skulden avseende hållbarhet som både stor och kritisk för systemet.
Prestanda
Trots de problem med designen som har identifierats bedöms inte prestandan utgöra en särskilt stor problematik i Sysinfo. Detta då databasen är relativt liten - det finns 18 tabeller och inte allt för många rader (drygt 30 000 rader när detta skrivs). Detta leder till att
operationer på systemet, trots problemen som existerar, inte är avsevärt krävande för
maskinen som arbetar. Detta hade kunnat vara ett stort problem i en större databas, men i den berörda databasen bedöms den tekniska skulden i hänsyn till prestanda vara relativt låg.
Datatillväxt och tabeller
Ett genomsnitt är svårt att framställa för detta system, men Payex uppskattar att det under en
“vanlig” vecka uppkommer mellan 100–200 nya rader i systemet, alltså incidenter som ska
26
loggas. Samtliga av dessa kretsar kring tabellen Objects som är grunden till alla incidenter.
Från Objects går sedan kopplingar till många av de andra tabellerna. I nuläget har Objects en dålig struktur, och flera nycklar är svåra att använda, samt att datan i de senare tabellerna inkluderar redundans och ofördelaktiga datatyper. Att förbättra Objects är grunden till att lösa alla problem med systemet, och utan att förbättra Objects ter det sig nästan lönlöst att försöka förbättra systemet alls.
Arbetstid
Den mängd arbete som krävs för att åtgärda de problem som finns i SysInfo bedöms vara mycket omfattande. På grund av att databasen behöver en helt omdesignad struktur innefattar arbetet ny design utav ett ER-diagram, följt av skapandet av en ny databas från grunden i SQL med tillhörande constraints och funktioner, samt en migrering av alla väsentliga data från SysInfo till den nya databasen. På grund av detta så bedömes den tekniska skulden avseende arbetstid som mycket hög.
Prioritering av arbetet enligt portföljteorin
Vid utvärderingen av den tekniska skulden i Sysinfo kan det konstateras att
normaliseringen är generellt svag. Detta har givit upphov till ett antal problem vilket har haft negativa konsekvenser för driften inom IT-operations. Att normalisera databasen är därför det som prioriteras högst. Arbetet med att normalisera Sysinfo är med tanke på dess nuvarande bristfälliga design är omfattande, varför det med fördel kan ses som rimligt att istället skapa en ny databas från grunden.
En normalisering av Sysinfo kommer att:
1. Göra inserts och updates simplare i systemet. Då inmatning av nya data har varit ett problem är det den högsta prioriteringen.
2. Göra informationen i databasen tydlig och pålitlig.
3. Tillåta en utveckling av ett bättre gränssnitt, då det som stoppat detta är problemen med redundans och vart data ska inmatas.
Utöver normalisering kan konstateras att det är högt prioriterat att korrigera samtliga
datatyper i tabellerna och minska antalet kolumner som tillåter fritext. Istället rekommenderas multiple-choice (ENUM), i största möjliga utsträckning. Detta skulle lösa det näst största problemet med systemet efter inmatning av nya data; att loggarna är otydliga och svåra att undersöka. Problemet med fritext i attribut märks mest i OS-delen av databasen, där olika namn för samma system (Windows 7, Windows N 7, Windows 7, etc) gör att alla försök att göra analyser baserat på operativsystemens namn blir problematiskt.
Denna förändring kommer att bli relativt kostsam, framför allt på grund av att Payex vill behålla väsentliga data från det tidigare systemet som därför måste sorteras manuellt. På grund av den svaga normaliseringen i Sysinfo kommer en hel del manuellt arbete krävas för
27
att sortera den data som ska migreras från Sysinfo till ITOpsDB, vilket medför ytterligare kostnader. Bedömningen är dock att vinsten som förändringen medför överskrider den tekniska skuld som har byggts upp och fortsätter byggas upp.
4.4 Den framväxande databasen ITOpsDB
I figur 4 på nästa sida visas det nya ER-diagrammet för ITOpsDB. Här finns tydliga kopplingar mellan samtliga tabeller och deras samband, samt de primära och främmande nycklar som definierar databasen. Exempelvis kan man se att ItOpObject innehåller en primärnyckel och sex stycken främmande nycklar, och att denna tabell agerar som mittpunkt för hela databasen.
Vidare kan man exempelvis i det nya ER-diagrammet se de primär- och främmandenycklar som refererar mellan ItopObject, ItopIpAddress, Subnet, Vlan samt SecurityZone. Här finns också kopplingstabeller mellan ItopObject, ItopSystem samt EventLog.
Det gamla systemet Sysinfo hade 18 tabeller, medans det nya systemet har enbart 14. I den nya databasen ItOps har 4 tabeller droppats på grund av att datan i dessa ses som onödig för databasens funktioner. Detta inkluderar tabellen InfoListor, där man lagrade information om externa företag och kontaktpersoner, inklusive namn och telefonnummer. I SysInfo fanns dessutom två olika tabeller där data loggades, “inlagg” och “inlagg2”. I den nya finns enbart en tabell för loggar.
28
Figur 4, ER-diagram ITOpsDB
4.5 Utvärdering av ITOpsDB
Databasen ITOpsDB har utvärderats enligt de första tre normalformerna. Vid närmare granskning av exempelvis tabellen ItOpObject går det att konstatera att den uppfyller första normalformen (1NF), vilket innebär att alla värden i samtliga kolumner atomära. Den andra normalformen (2NF) uppfylls, då det kan konstateras att inga fullständiga funktionella beroenden (ffb) existerar på primärnyckeln i denna tabell. Tabellen uppfyller även kraven för tredje normalformen (3NF) då inget av attributen är fullständigt beroende av ett fält som inte är en primärnyckel. Enligt vår utvärdering uppfyller samtliga tabeller databasen ITOpsDB dessa krav på normalisering, vilket medför att designen på denna punkt får anses vara god.
29
4.6 Teknisk skuld i ITOpsDB
Steg 1 - Potential debt Identification
Vid utvärdering av normaliseringen i den nya databasen ITOpsDB står det klart att tabellerna nu uppfyller kraven för tredje normalformen (3NF). Som exempel på detta går det att göra en jämförelse mellan tabellerna som innehåller objekt i respektive databas. I det gamla systemet hade tabellen objects många rader med många NULL-värden. På vissa rader hade upp till hälften av kolumnerna NULL-värden, vilket försämrade datakvaliteten och ledde till
svårigheter i koppling mellan tabeller och tolkning av datan. I SysInfo loggades även t.ex IP- adresser flera gånger, både i tabellen objects och i iptable. Dessutom matades operativssystem (OS) in manuellt i objects-tabellen för respektive rad. Detta i kombination med att OS var ett fritext-fält medförde att OS benämndes olika beroende på vem som gjorde det specifika inlägget, vilket i sin tur gjorde det näst intill omöjligt att effektivt söka igenom databasen baserat på OS. I den nya databasen lagras OS i en separat tabell, ItOpOperatingSystem, som ItOpObjects sedan refererar till med främmande nyckel, vilket då inte tillåter något sådant problem. Därmed kan den tekniska skulden i form av bristande normalisering uteslutas i ITOpsDB.
Steg 2: Debt Impact and Cost Estimation Datakvalitet
Utöver den goda normaliseringen i ITOpsDB har ett antal tabeller som existerade i Sysinfo och lagrade irrelevant eller överflödiga data tagits bort. Detta medför en hög konsistens på datan och därmed en hög datakvalité. Datakvalitén utgör därmed ingen teknisk skuld i den nya databasen.
Hållbarhet
Vid utvärdering av hållbarheten i ITOpsDB har komplexiteten i tabellerna granskats. Här kan man enkelt se att den goda normaliseringen exempelvis har minskat antalet attribut i
respektive tabell som innehåller objekt från 17 attribut i Sysinfo till 10 attribut i ITOpsDB.
Att samtliga tabeller innehåller korrekta primär- och främmandenycklar i ITOpsDB bidrar även till en starkt ökad hållbarhet. Därmed utgör hållbarheten i ITOpsDB ingen teknisk skuld.
Prestanda
Den tekniska skulden avseende prestanda har inte gått att mäta på grund av att ITOpsDB idag saknar data. Däremot talar databasens goda normalisering för att någon teknisk skuld inte kommer att utgöras av prestandan i databasen.
30 Datatillväxt och tabeller
Datatillväxten beräknas vara i snitt mellan 10 - 25 rader per vecka i ITOpsDB. Det får i sammanhanget databaser ses som en relativt långsam tillväxt som tack vare databasens goda normalisering inte riskerar att utgöra någon teknisk skuld.
Arbetstid
Då designen i ITOpsDB bedöms vara god uppstår ingen teknisk skuld i form av arbetstid i databasen.
Slutsats för analysen av teknisk skuld i ITOpsDB
Efter analys av den tekniska skulden i den ursprungliga databasen Sysinfo respektive den nya ITOpsDB kan det konstateras att de faktorer som bedöms ha starkast negativa effekter på designen i Sysinfo nu har åtgärdats. Den tekniska skulden som fanns i SysInfo är löst i ITOpsDB med hjälp av ett gediget designarbete medett väl utvecklat ER-diagram, god normalisering samt en strikt tilldelning av primär- och främmandenycklar.
5. Diskussion och slutsats
I kapitel 5 diskuteras studiens forskningsfrågor och huruvida de har besvarats följt av studiens bidrag.
5.1 Forskningsfrågor
Studiens forskningsfrågor, som besvaras nedan, har adresserats genom att utvärdera designen i två databaser. Litteraturen ger vid handen att normalisering är en viktig del i arbetet med att skapa god design i databaser, och att en svag design kan medföra svåra problem som är bestående över tid. Vår studie har tydligt visat att designen i den utvärderade databasen Sysinfo har orsakat en teknisk skuld i systemet som har medfört negativa konsekvenser i verksamheten. De konsekvenser som identifierats består framför allt av att onödiga resurser i form av arbetstid krävts för det dagliga arbetet, att informationen i databasen blir otydlig eller opålitlig, samt att andra artefakter knutna till databasen får en sämre användbarhet som följd, vilket konkretiserats under kapitel 4.2.
1. Vilka konsekvenser kan en dåligt normaliserad databas, som ett exempel på teknisk skuld, ha för en verksamhet?
Den första forskningsfrågan har en väldigt tydlig förankring i det praktiska arbete som har genomfört. Den befintliga litteraturen om normaliseringsteori, som är av avsevärd storlek, visar tydligt hur det påverkar ett system negativt när tredje normalformen inte uppnås. Utvärderingen av Sysinfo visade dessutom tydligt hur en dåligt normaliserad databas får negativa konsekvenser för det dagliga arbetet i verksamheten och användningen av systemet.
