Hantering av hinder
vid implementationen
av DevOps
HUVUDOMRÅDE: Informatik
FÖRFATTARE: Pierre Fondelius, Alexander Sivertsson HANDLEDARE: Sonny Johansson
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom informatik. Författarna svarar själva för framförda åsikter, slutsatser och resultat.
Examinator: Anders Adlemo Handledare: Sonny Johansson Omfattning: 15 hp (grundnivå) Datum: 2021-06-19
Abstract
A reason why DevOps has become popular in many organizations with a focus on software development is because it brings development and IT-operations closer to each other, which increases efficiency. Furthermore, it appears that there is a knowledge gap in the implementation of DevOps. The purpose of this work was therefore to investigate how Swedish organizations handle the implementation of DevOps. The study also investigated which obstacles arose and how these obstacles were handled by the organizations. In this survey, semi-structured interviews were conducted to collect the necessary qualitative data to answer the question posed. These interviews were conducted at five Swedish organizations to gather a broad base. To create an understanding of the data, a thematic analysis was performed which was then compared with previous literature in the field. The study found that only two of the three implementation methods identified in a previous study were implemented in Swedish organizations. The study presents which implementation methods can suit different organizations, what obstacles may occur with the chosen implementation method, and an updated view on how organizations have proceeded in Sweden with the implementation of DevOps.
Keywords
Sammanfattning
En anledning till att DevOps har blivit populärt hos många organisationer med fokus på mjukvaruutveckling beror på att det för utveckling och drift närmare varandra vilket ökar effektiviteten. Vidare framgår det att det finns en kunskapslucka i implementationen av DevOps. Syftet med detta arbete var därför att undersöka hur svenska organisationer hanterar implementationen av DevOps. Studien utredde även vilka hinder som uppkommit och hur dessa hinder hanterats av organisationerna. I denna undersökning genomfördes semistrukturerade intervjuer för att samla in nödvändig kvalitativa data för att svara på studiens frågeställningar. Dessa intervjuer genomfördes hos fem svenska organisationer för att samla ett brett dataunderlag. För att öka förståelsen hos den insamlade datan utfördes en tematisk analys som sedan jämfördes med tidigare litteratur inom området.
Studien fann att endast två av de tre implementationsmetoder som identifierats i en tidigare studie fanns implementerade i svenska organisationer. Studien presenterar vilka implementationsmetoder som kan passa olika organisationer, vilka hinder som kan förekomma med vald implementationsmetod, samt en uppdaterad översikt hur organisationer har gått tillväga i Sverige med implementationen av DevOps.
Nyckelord
Innehållsförteckning
1
Introduktion ... 1
1.1 PROBLEMFORMULERING ... 2
1.2 SYFTE OCH FRÅGESTÄLLNINGAR ... 3
1.3 AVGRÄNSNINGAR ... 4
1.4 DISPOSITION ... 4
2
Metod och genomförande ... 5
2.1 DATAINSAMLING ... 5 2.1.1 Intervjustruktur ... 5 2.1.2 Datahantering ... 6 2.1.3 Urval av respondenter ... 6 2.2 DATAANALYS ... 8 2.3 TROVÄRDIGHET ... 9 2.4 ÖVERVÄGANDEN ... 10
3
Teoretiskt ramverk ... 12
3.1 VAD ÄR DEVOPS? ... 12 3.1.1 Principer ... 12 3.1.2 Praxis ... 13 3.1.3 Kunskapsdelning ... 14 3.2 AGILE ... 153.2.1 Scrum och Sprint ... 15
3.4 IMPLEMENTATIONSMETODER ... 16
3.4.1 Nära samarbetande arbetsgrupper ... 16
3.4.2 Multikompetenta arbetsgrupper ... 17
3.4.3 DevOps-grupp ... 17
4
Resultat & Analys ... 18
4.1 ORGANISATIONERNAS DEFINITION AV DEVOPS ... 18
4.2 IMPLEMENTATIONSMETODER ... 19
4.2.1 Övergången till DevOps ... 19
4.2.2 Identifierade implementationsmetoder ... 20
4.2.3 Positiva effekter av vald implementationsmetod ... 21
4.3 UPPSTÅDDA HINDER VID IMPLEMENTATION ... 24
4.3.1 Nära samarbetande arbetsgrupper ... 24
4.3.2 Multikompetenta arbetsgrupper ... 26
4.4 ANALYS KOPPLAT TILL FORSKNINGSFRÅGOR ... 28
5
Diskussion ... 32
5.1 RESULTATDISKUSSION ... 32
5.2 METODDISKUSSION ... 35
6
Slutsatser och rekommendationer ... 37
6.1 SLUTSATSER OCH REKOMMENDATIONER ... 37
6.1.1 Praktiska implikationer ... 38
6.1.2 Vetenskapliga implikationer ... 39
6.2 VIDARE FORSKNING ... 39
1
Introduktion
I en traditionell IT-miljö bedrivs utveckling och driftsättning av tjänster separat [1] men kraven som ställs på IT-organisationer blir allt större [2]. De system som används ökar i komplexitet samtidigt som kunders förväntningar stiger. När mjukvaruutvecklarna släpper kod samt uppdateringar sker det generellt i enskilda släpp några få gånger per år och med många förändringar [1, 3]. Detta innebär att mycket kod behöver testas för att fel ska upptäckas och åtgärdas. I vissa fall blir koden inte implementerad i drift, förrän ett nytt större kodsläpp sker. Agila arbetsmetoder är ett tidigare samlingsbegrepp för systemutvecklingsmetoder ämnade att representera ett mer flexibelt sätt att arbeta. Ur dessa arbetsmetoder utvecklades DevOps (Software Development & IT Operations) som tillsammans med konceptet Continuous Delivery ska öka effektiviteten av mjukvaruutveckling genom flera kodsläpp med mindre storlek [3]. Allt fler organisationer väljer nu att införa DevOps för att effektivisera deras leveransprocess av mjukvara [1, 3].
En anledning till att DevOps har blivit populärt hos organisationer idag beror på att många problem uppstår när olika arbetsgrupper, som i detta fall är mjukvaruutvecklare och drift, arbetar tillsammans. I en traditionell miljö, arbetar utvecklarna och IT-driftorganisationen separat från varandra i olika arbetsgrupper, men mot samma mål och med olika tillvägagångssätt [4]. DevOps har därför tagits fram för att öka samarbetet mellan arbetsgrupperna och därmed öka produktiviteten och effektiviteten av implementationsflödet, vilket i sin tur leder till högre kvalitet. För att ytterligare underlätta samarbetet fokuserar DevOps på att automatisera arbetsflödet och släppa regelbundna uppdateringar (Continuous Delivery) [1, 3]. Även mätningar av mjukvaruapplikationers prestanda ligger i fokus [5].
Medan organisationer hävdar att implementationen av DevOps ökar effektiviteten av mjukvaruutveckling kan tillvägagångssätt variera kraftigt [6, 7]. De olika tillvägagångsätten beror till stor del på att det inte finns någon konsensus kring en definition av DevOps [3]. Trots avsaknaden av konsensus kring definitionen behövs en grund för undersökningen och därför används denna definition inom studien:
DevOps is a collaborative and multidisciplinary effort within an organization to automate continuous delivery of new software versions, while guaranteeing their correctness and reliability. [3, p. 1]
1.1 Problemformulering
DevOps är ett samarbete mellan utvecklare och driftgruppen inom en organisation. Däremot råder ingen konsensus över implementationsprocessen eller framtida drift [3]. Denna avsaknad av konsensus leder till att organisationer skapar egna tolkningar och därmed hanterar DevOps olika gentemot varandra [3, 8]. Det finns studier om hur organisationer ska agera när det kommer till DevOps i form av principer, praxis och kunskapsdelning men det har ännu inte lett till någon enhällighet inom området [9]. Detta är även identifierat i studien nedan.
The fact that DevOps is lacking a standard definition implies that there is no simple approach to follow when adopting DevOps in an organization. [8, p. 131]
När en organisation implementerar DevOps kan samarbetet mellan de involverade arbetsgrupperna påverkas olika [3]. Ett problem som då kan uppstå är att samarbetet mellan arbetsgrupperna inte fungerar korrekt. En del i detta är att de inblandade arbetsgrupperna har sina egna sätt att arbeta på som kanske inte är kompatibelt med en annan arbetsgrupp som de nu behöver arbeta med när organisationen har bestämt sig för att implementera DevOps [1].
En tidigare studie [3] presenterar tre implementationsmetoder: samarbete mellan existerande arbetsgrupper, multikompetenta arbetsgrupper eller i en separat DevOps-grupp. Samarbete mellan existerande arbetsgrupper innebär ett närmare och effektivare arbete men kan dock leda till oklarheter kring ansvarsområden. Multikompetenta arbetsgrupper undkommer detta genom att utvecklarna själva ansvarar både för distribution samt drift av mjukvaran. Denna grupp kommer då ha ansvar för i stort sett hela processen vilket innebär väldigt mycket jobb samt mer kvalificerade ingenjörer och högre expertis. Det sista förslaget innebär att organisationen skapar en specifik DevOps-grupp för att fungera som en brygga mellan utvecklarna och de som hanterar driften. Däremot kan detta leda till att även denna grupp blir en egen silo (en separat arbetsgrupp), vilket i sin tur försämrar samarbetet. Oundvikligen slutar arbeten där arbetsgrupper delas upp i silos med att de spenderar lika mycket tid på att skylla på varandra när problem uppstår, som de spenderar på att faktiskt åtgärda felet [7]. Ingen av dessa tre metoderna är perfekta och trots internationella undersökningar döms litteraturen inom dessa områden som ofullständig [1, 3].
Ett ytterligare problem med att det inte finns någon enighet i implementationen är att ledningen ofta lämnar mycket av det administrativa arbetet åt DevOps-ingenjörerna, personer som är kunniga både inom utveckling och drift, under implementationsstadiet [3]. Detta slutar ofta med ett så kallat “guerillascenario” där arbetsgruppen lätt strävar långt ifrån organisationens standardprocedurer och bildar en helt egen arbetskultur [10, 11, 12]. En mer samlad bild av hur man som ansvarig ledare strukturerar implementationen av DevOps behövs för att arbetsgruppen införs i symbios med resten av organisationen.
Sammanfattningsvis finns det en avsaknad av svar på problem som definitionen av DevOps, hur DevOps bör implementeras, hur samarbete fungerar mellan olika arbetsgrupper och vilka hinder som påverkar effektiviteten i arbetsgruppen. Internationella studier som undersöker implementationen av DevOps existerar, däremot finns det få studier som riktar in sig på implementationen på svenska organisationer. Därför behöver en undersökning genomföras som presenterar implementationsstrategier i svenska organisationer som har genomgått denna implementationsprocess.
1.2 Syfte och frågeställningar
I problembeskrivningen framgår det att det finns en kunskapslucka i
implementationen av DevOps. Syftet med detta arbete är att beskriva hur svenska organisationer hanterar implementationen av DevOps. Studien kommer även att utreda svårigheter som uppkommit och hur dessa svårigheter hanterats av organisationen.
För att kunna besvara syftet har tre frågeställningar formulerats. Den första frågan behandlar problemet om hur organisationer implementerar DevOps. Därmed är studiens första frågeställning:
1. Vilka implementationsmetoder använder svenska organisationer vid införandet av DevOps?
Den andra frågan avser att utreda vilka hinder svenska organisationer har stött på under implementationsprocessen av DevOps. Därmed är studiens andra frågeställning:
2. Vilka hinder har identifierats vid implementationen av DevOps i svenska organisationer?
Den tredje frågan ämnar besvara hur organisationerna hanterade de problem som uppstod under implementationen av DevOps. Därmed är studiens tredje frågeställning: 3. Hur har de hinder som uppstod under implementationsprocessen hanterats av
svenska organisationer?
1.3 Avgränsningar
I denna studie genomfördes sex intervjuer på fem olika organisationer varav två var myndigheter och tre var företag. Detta urval gjordes för att generera en större bredd hos insamlad empiriska data.
1.4 Disposition
Studien inleds med metodkapitlet som beskriver vilken metod som användes för insamling av data. Även hanteringen av data beskrivs samt urvalet av respondenter som deltog i studien. Till sist hanteras studiens trovärdighet och överväganden.
Studien fortsätter sedan med en teoretisk bakgrund där viktiga begrepp förklaras för att ge en övergripande bild av DevOps vilket även inkluderar beskrivningar av implementationsmetoder. Därefter presenteras den insamlade data som sedan analyseras och diskuteras, även metodvalet diskuteras. Avslutningsvis presenteras studiens slutsatser, studiens implikationer och förslag på vidare forskning.
2
Metod och genomförande
För att kunna svara på och diskutera studiens frågeställningar, genomfördes en multipel fallstudie där informationen samlas in genom semi-strukturerade intervjuer. Respondenterna är, eller har varit, delaktiga eller drivande inom DevOps-implementationen i en organisation.
För att svara på studiens frågeställningar används en multipel fallstudie. En multipel fallstudie innebär, likt en traditionell fallstudie, att systematisk insamling av en större mängd data från “det verkliga livet” [13, p. 60] genomförs vilket är lämpligt när frågeställningen försöker svara på “hur” eller “varför” något gjordes på ett visst sätt och när kvalitativa data önskas utvinnas ur undersökningen [14]. Det som skiljer metoderna åt är att den traditionella fallstudien endast möjliggör analys i en begränsad miljö medan den multipla fallstudien tillåter teoretisering i ett större sammanhang [14, 15]. Kvalitativa data kan vidare användas för att för att skapa förståelse av en komplex helhet som i sin tur kan leda till en slutsats lämpad att svara på den ställda frågeställningen [16]. Detta tillåter att fallstudien fördjupas i ett fåtal intressanta fall. Alternativt övervägdes även att kvantitativa data skulle samlas in som komplement till den kvalitativa data som samlades in. Tidigare forskning antyder att kvantitativa data kan utnyttjas för att förstärka eller motsäga fynd upptäckta genom kvalitativa data [17]. Däremot tenderar kvantitativa data användas för statistisk behandling inte bedömdes bidra till denna studies syfte.
2.1 Datainsamling
2.1.1 Intervjustruktur
För att få en mer utvecklad bild över hur en organisation implementerar DevOps övervägdes möjligheten att följa processen inifrån en organisation och därigenom få en detaljerad bild av hur DevOps-verksamheten har strukturerats [16]. Medan detta var genomförbart ansågs det att ett bredare perspektiv från flera organisationer var bättre lämpat än en djupgående undersökning på en organisation och därför bedömdes semistrukturerade intervjuer med flera organisationer lämpligast för att besvara forskningsfrågorna. Semistrukturerade intervjuer innebär att det finns vissa förutbestämda frågor men intervjudeltagarna uppmuntras att utveckla sina svar med hjälp av öppna frågor [18, 19, 20]. Anställda från flera organisationer som har varit inblandade inom implementationsprocessen av DevOps på respektive organisation
intervjuades. Med tanke på att de olika deltagarna har varit inblandade i olika organisationer söktes olika perspektiv i deras svar. Därför bedömdes semistrukturerade intervjuer mest passande med öppna frågor av inledande, sonderande, tolkande och specificerande karaktär [13].
Intervjuguidens struktur inspirerades av en tidigare studie [20], med en inledande fas ämnad att samla in nödvändig bakomliggande information, följt av ytterligare tre faser för att svara på studiens frågeställningar. Öppna frågor eftertraktades för att få utvecklande svar som möjliggör en djupare analys och berikar frågeställningen. Dessa frågor framställdes med hjälp av litteraturen som presenteras i det teoretiska ramverket (se Kapitel 3, Teoretiskt ramverk).
2.1.2 Datahantering
Intervjuerna som genomfördes med deltagarna spelades in med deras medgivande och sparades på ett säkert sätt (se 2.4 Överväganden) för möjligheten att senare återvändas till och transkriberas. Detta är en betydelsefull process för att säkerställa att ingen information går förlorad i mängden då ett viktigt kriterium för intervjuerna är att ställa korta frågor med långa uttömmande svar, ämnade för att svara på frågeställningen [13]. Med mer utfyllda meningar blev det samtidigt viktigare att på ett läsbart sätt representera det innehåll som intervjuerna genererade. Detta åstadkoms genom att ta bort eller omformulera utfyllnadsord eller talspråk i den mån det var möjligt, utan att påverka innehållets betydelse. Detta är en metod som i sin tur leder till en mer läsbar transkribering och senare presentation [21]. Efter att intervjuerna var transkriberade påbörjades datareducering i samband med dataanalys.
2.1.3 Urval av respondenter
Urvalet av respondenter är baserat på följande tre kriterier:
• Studien undersöker både myndigheter och företag och därför valdes respondenterna baserat på vilken typ av organisation de arbetar i.
• Respondenterna ska ha både historisk samt aktuell information om implementationen av DevOps, de inblandade arbetsgrupperna och deras arbetsmetoder.
• Studien inkluderar endast organisationer som har implementerat DevOps, för att kunna undersöka implementationsprocessen.
Dessa kriterier säkerställdes vid första kontakt samt under intervjuernas gång.
De respondenter som deltog i studien bestod av representanter från två myndigheter och tre företag. Båda myndigheterna bestod av två olika respondenter där respondenterna från myndighet 1 deltog i samma intervju medan den respondenterna från myndighet 2 deltog i separata intervjuer. Dessa respondenter kom från olika arbetsgrupper på organisationerna för att få en helhetsbild av DevOps-miljön. Tabell 1 nedan beskriver de intervjuade respondenterna.
Tabell 1. Lista av respondenter.
Respondenter: Yrkesroll: Organisationstyp:
R1: Systemarkitekt (Dev) Större Företag 1 (F1) R2: Systemtekniker (Ops) Infrastrukturarkitekt Myndighet 1 (M1)
R3: IT-arkitekt (Dev) Myndighet 1 (M1)
R4: Enhetschef (Dev) Myndighet 2 (M2) R5: Enhetschef (Ops) Myndighet 2 (M2)
R6: IT-chef Mindre Företag 2
(F2)
R7 Konsultchef Mindre Företag 3
2.2 Dataanalys
I studien användes en tematisk analysmetod som innebär att det empiriska materialet sorteras och struktureras i olika kategorier [13]. När empirin har tematiserats kan man senare systematiskt undersöka varje tema för att fastställa hur det kan besvara studiens frågeställningar. I slutändan har man reducerat mängden material som behöver presenteras och materialet kan presenteras på ett strukturerat sätt. Därför valdes den tematiska analysmetoden som huvudmetod. Även narrativ analys övervägdes vilket innebär att studiens resultat presenteras i form av en berättelse för att på ett läsarvänligt sätt bryta ner den empiriska data som samlats in. Detta övervägdes till en början som huvudmetod för att förmedla studiens resultat och inspiration från denna metod användes vid utformandet av själva resultatkapitlet. Dock ansågs det i slutändan att den tematiska analysmetoden var lämpligare för att bearbeta resultatet inför diskussionskapitlet då studien jämför information från flera svenska organisationer. Sex faser för Tematisk analys [22]
1. Inläsning och Fördjupning - Forskaren bekantar sig med vad deltagarna framför i intervjun genom att åter lyssna igenom sparade ljudfiler och fördjupa sig i dess transkribering.
2. Gallring av transkribering - En systematisk process genomförs där forskaren sållar bort data som inte gynnar studiens frågeställningar.
3. Identifiera teman - Forskaren söker efter samband i empiriska data och kopplar samman denna med olika teman.
4. Granska teman - En fas som inte nödvändigtvis behöver betyda att ändringar görs bland skapade teman. Forskaren återblickar till de teman hen har skapat för att försäkra sig om att temats natur förhåller sig till studiens frågeställningar eller om något behöver ändras.
5. Sammanfatta och namnge teman - Forskaren sammanställer data kopplad till framställda teman under en definition. Detta för att lättare presentera teman i slutrapporten.
2.3 Trovärdighet
För att behandla studiens trovärdighet har särskilda klassificeringar använts: slutsatsvaliditet, intern validitet, begreppsvaliditet, extern validitet [23, 24] samt reliabilitet [25].
Inom slutsatsvaliditet är låg statistisk styrka ett hot mot studiens trovärdighet [23]. Detta betyder att ett för litet urval kan leda till svårigheter att kunna dra slutsatser från insamlade data, eller att felaktiga slutsatser dras. Låg statistisk styrka är inte relevant för denna studie, på grund av valet av kvalitativ metod går det inte att generalisera resultatet för populationen. Däremot kan framtida studier använda sig av resultatet och bygga vidare på det.
Intern validitet behandlar huruvida undersökningen stämmer överens med verkligheten
[23, 24]. Det finns flera hot mot intern validitet, ett sådant hot är mognadsprocessen av intervjudeltagarna. Detta innebär att det finns en risk där deltagarna blir uttråkade eller tröttnar, detta kan skada studiens tillförlitlighet. För att förhindra detta bör intervjuerna inte ta för lång tid. Ett annat hot är valet av deltagare, om man väljer deltagare med irrelevanta kunskaper kan inte relevant data samlas in. För att undvika detta innebar säkerställning av att deltagarna har kunskaper om organisationens DevOps-implementation.
Begreppsvaliditet hanterar det som forskaren tänkt undersöka och vad som egentligen
har undersökts [23, 24]. Ett relevant hot inom begreppsvaliditet är att deltagarna gissar sig fram till vad som ska undersökas och anpassar svaren utefter sin gissning. För att motverka detta informerades deltagarna om studiens syfte.
Hot mot extern validitet är sådant som begränsar möjligheten att generalisera och se om resultaten kan vara för intresse hos utomstående personer [23, 24]. Det hotet som är mest relevant för denna studie är att urvalet av deltagare inte är representativ mot den gruppen som studien generaliseras mot. Detta åtgärdas med valet av intervjudeltagare som har relevanta kunskaper om DevOps-implementation.
Reliabiliteten behandlar studiens replikerbarhet, om studien upprepas bör liknande
resultat kunna uppnås [25]. Datainsamlingen och analysen av data utformades och beskrevs på ett tydligt sätt för att öka reliabiliteten. Reliabiliteten hos de organisationer som undersökts anses vara hög. Av de typer av organisationer som undersökts har två av varje typ deltagit. Därför är det möjligt att i viss mån generalisera till liknande
organisationer. För att generalisera till populationen i stort krävs det en kvantitativ undersökning hos ett större antal och liknande svenska organisationer.
2.4 Överväganden
Denna studie följer Vetenskapsrådets fyra forskningsetiska principer inom humanistisk-samhällsvetenskaplig forskning [26]. Dessa presenteras nedan i tabell 2 tillsammans med studiens anpassade åtgärder.
Tabell 2. Vetenskapsrådets fyra forskningsetiska principer inom humanistisk-samhällsvetenskaplig forskning
De fyra principerna Principernas mening Åtgärd för att följa principerna
Informationskravet Intervjudeltagarna ska känna till studiens syfte och att deras deltagande är frivilligt.
Intervjudeltagarna har blivit informerade om hur de insamlade uppgifterna hanteras utefter
Vetenskapsrådets principer. De har även blivit
informerade om att intervjuerna spelas in och att person/företagsuppgifter hanteras anonymt för att sedan raderas vid studiens publicering.
Samtyckeskravet Forskaren ska inhämta intervjudeltagarnas samtycke för deltagande i studien.
Konfidentialitetskravet Alla uppgifter ska behandlas konfidentiellt på ett sådant sätt att deltagarna är oidentifierbar för utomstående.
Nyttjandekravet De insamlade uppgifterna ska endast användas till det syfte som deltagarna har informerats om.
De åtgärder som vidtagits följer även GDPR (General Data Protection Regulation) [27]. Artikel 12 tillför krav på transparens angående insamlad information samt att deltagarna behöver ge ett informerat samtycke. Deltagarna har även rätten att begära insamlad information kopplad till dem raderas, i enlighet med artikel 17.
3
Teoretiskt ramverk
I detta kapitel behandlas förklaringar till olika begrepp och annan information som förtydligar övriga delar av studien.
3.1 Vad är DevOps?
DevOps bygger på det agila arbetssättet men fokuserar på samarbetet mellan utvecklare och IT-driftarbetsgruppen [3, 6, 8]. Syftet med samarbetet är att effektivisera driftsättningen av ny kod, vilket ett agilt arbetssätt inte fokuserar på [3]. Samarbetet ökar kunskapsdelningen mellan utvecklare och IT-driften [8]. DevOps möjliggör korta och effektivare kodsläppscykler med arbetssätt som kompletterar det agila arbetssättet [3]. Eftersom DevOps inte har någon överenskommen definition kan missuppfattningar ske på grund av olika tolkningar av vad DevOps innebär [3, 6, 8]. Inom denna studie används denna definition då den ger en generell innebörd till vad DevOps innebär:
DevOps is a collaborative and multidisciplinary effort within an organization to automate continuous delivery of new software versions, while guaranteeing their correctness and reliability. [3, p. 1]
DevOps lägger fokus på rollerna utvecklare och IT-drift [3]. Utvecklare ansvarar för att utveckla den mjukvara organisationen säljer eller använder i produktionsmiljöer. IT-driftens ansvar är att drifta, anpassa eller uppgradera miljöerna där mjukvaran används. Dessa två roller har oftast sina egna arbetssätt och verktyg, vilket kan leda till konflikter. Om organisationen inte har implementerat DevOps brukar dessa roller kommunicera med varandra genom ticket-system. I dessa tickets frågar IT-driften efter förändringar eller nya funktioner i mjukvaran, utifrån förfrågningarna hanterar utvecklarna ärendet manuellt.
3.1.1 Principer
En beprövad metod som används vid implementation av DevOps är att följa tre övergripande principer [9]. Den första principen som DevOps byggs på är införandet av ett agilt arbetssätt med fokus på samarbetet mellan utvecklarna och IT-driftarbetsgruppen. (se delkapitel 3.2, “Agile”).
Den andra principen avser samarbete inom DevOps-arbetsgrupper där konceptet organisatorisk kultur är ett centralt begrepp [9]. Att folk som arbetar tillsammans inom en organisatoriskmiljö bygger upp en egen kultur som skiljer sig från den större
samhällskulturen är numera väl erkänt inom industrin [28]. Utvecklingen av en DevOps-kultur är lika kritiskt som att utnyttja rätt verktyg för att bli en effektiv arbetsgrupp. För att uppnå en optimal DevOps-kultur, och därmed ett bra samarbete, krävs vissa kulturella karaktärsdrag som öppen kommunikation, respekt, tillit, samt incitament- och ansvars-anpassning. Utan ovanstående karaktärsdrag kan arbetsgruppen få problem med att samarbeta tillsammans vilket då försvårar diskussioner under hela mjukvaruleveransen. De processer som DevOps utnyttjar (se delkapitel 3.1.2, “Praxis”) för en effektivare mjukvaruutveckling går även hand i hand med samarbetet då viktiga aspekter inom DevOps: är respekt för varandra, engagemang för delade mål, delat ägarskap och delade värderingar [29].
Den tredje principen handlar om integrationen av praxis och verktyg [9]. Detta ämnar förtydliga vikten av sömlös integrering genom tre huvudsakliga hjälpmedel. Ett sätt är att automatisera arbetsuppgifter och att genomföra ändringar med hjälp av skript. Ett annat sätt är att utnyttja molnlösningar för att minimera resursanvändning samtidigt som man möjliggör användning av fler system och verktyg vid utveckling av mjukvara. Ett tredje hjälpmedel är att utnyttja vedertagen praxis (best practise) för processeffektivisering som till exempel Capability Maturity Model Integration, Information Technology Infrastructure Library [9] eller Lean [29].
3.1.2 Praxis
Att leverera mjukvara med DevOps som arbetssätt kan delas in i fyra olika steg [9]. Dessa steg är: planering och mätning, utveckling och testning, släpp och driftsättning
samt övervakning och optimering. Dessa förklaras närmare i det följande.
Under planerings- och mätningsfasen (Plan & Measure) är det viktigt för
organisationen att lägga fokus på kundens eller användarens behov av och krav på mjukvaran [9]. Därför är det viktigt att ha kontinuerlig kontakt med användaren och göra förändringar baserat på deras feedback. De som arbetar med driften av mjukvaran ska tidigt vara inblandade i utvecklingen. Detta är tänkt att leda till en driftpersonal som har mer kunskap om mjukvaran och mjukvara som är bättre anpassad till den miljö som mjukvaran ska driftsättas på senare.
Under utvecklings- och testningsfasen (Develop & Test) ska mjukvaran testas för att se hur den presterar [9]. Detta kan åstadkommas med hjälp av virtuella miljöer som efterliknar den fysiska miljön där mjukvaran senare ska användas. Under utvecklingen
bör olika verktyg som säkerställer att koden och mjukvaruversionerna är synkroniserade mellan utvecklarna användas. Automatiska tester bör utföras kontinuerligt under utvecklingsprocessen för att fånga misstag tidigt och minska tiden som läggs på tester som behöver utföras efter att mjukvaran är färdigutvecklad. På så sätt går det även att tidigt få feedback och utföra nödvändiga ändringar.
Under kodsläpp- och driftsättningsfasen (Release & Deploy) bör kodsläppen ske i mindre storlekar för att minska risken av driftavbrott samt få snabbare feedback [9]. De uppgifter som är konfigurationskänsliga, tar mycket tid eller är repetitiva bör automatiseras. Detta leder då till att det kan det läggas mer fokus på de uppgifter som kräver mänsklig interaktion, till exempel val av mjukvaruversion som ska sättas i drift. Med hjälp av Continuous Delivery (CD) kan mjukvarans användare få uppdateringarna tidigare. Utvecklarna kan även se om den nya koden fungerar som den ska men i händelse av fel i koden är det relativt enkelt att rulla tillbaka ändringarna. Med automatisk driftsättning från och till olika miljöer under utvecklingen finns möjligheten att se vilka maskiner koden testades på och vem som skrev den. Detta underlättar tester av system, ändringar i systemen och risken för fel orsakade av manuella ändringar minskar.
Under övervaknings- och optimeringsfasen (Monitor & Optimise) är det viktigt för organisationen att övervaka mjukvaran och samla in information om prestandan i miljön [9]. Den insamlade informationen kan användas som utgångspunkt för framtida ändringar. Den mjukvara som utvecklas för övervakningen bör utvecklas parallellt med den mjukvara som driftsätts hos användaren. Detta ska då leda till en övervakningslösning som är anpassad för ändamålet. För att ge feedback kan användarna skapa ärenden, skicka in klagomål och så vidare. Driftpersonalen bör ge feedback om mjukvarans prestanda i miljön. Denna feedback kan då kombineras med data från övervakningen för att göra ändringar och optimera mjukvaran.
3.1.3 Kunskapsdelning
En viktig aspekt av DevOps är kunskapsdelningen och för att öka förståelsen runt detta kan SECI-modellen användas [9]. Denna modell beskriver hur tyst och uttalad kunskap omvandlas till organisationskunskap. Uttalad kunskap är sådan kunskap som individer känner till och kan formulera samt kodifiera den [30]. Tyst kunskap bygger på uttalad kunskap men är däremot svårare att beskriva eftersom den erhålls genom erfarenheter
som skapar rutiner och vanor. SECI är en akronym av de olika kunskapsdimensionerna: socialisation, externalisation, combination och internalisation, vilka beskrivs närmare nedan.
Socialisation innefattar den tysta kunskapen individer delar mellan varandra genom socialisering [9]. Denna kunskap kan vara känslor eller upplevelser som en individ har upplevt. När en annan individ tar del av denna kunskap skapas ny uttalad kunskap. Externalisering (Externalisation) är sådan kunskapsdelning av tyst kunskap som sker kollektivt via dialoger, till exempel under möten [9]. Denna tysta kunskap blir uttalad kunskap och delas med andra individer.
Kombination (Combination) behandlar den kunskapsdelningen som sker kollektivt och virtuellt där uttalad kunskap delas [9]. Detta kan till exempel ske via en organisations delade dokumentation.
Internalisering (Internalisation) handlar om hur individer använder den uttalade kunskapen de har införskaffat för att omvandla den till deras egen tysta kunskap [9]. Denna kunskapsomvandling kan beskrivas som: att lära genom att göra.
3.2 Agile
Agil mjukvaruutveckling är ett paraplybegrepp för en uppsättning av ramverk och metoder baserade på de värderingar och principer som uttrycks i Manifestet för Agil
systemutveckling [31]. Manifestet skapades år 2001 och innefattar olika metoder för att
i projekt kunna arbeta effektivare och mer flexibelt inom kortare tidsramar jämfört med den traditionella vattenfallsmodellen för mjukvaruutveckling [10, 32, 33]. Välkända exempel på dessa metoder är Extrem programmering (XP), Scrum, Lean Software
Development, Feature Driven Development (FDD) och Crystal [32]. Utöver dessa
metoder predikar Agile Manifestet även 12 principer använda för att bedriva Agil verksamhet [31]. Nedan beskrivs vissa arbetsmetoder som finns inom Agile som flera organisationer använder inom deras DevOps-implementation.
3.2.1 Scrum och Sprint
Scrum är ett ramverk inom Agile som utvecklades inom mjukvaruutveckling [34]. Detta ramverk används inom komplexa projekt där olika händelser är oförutsägbara. Meningen med Scrum är då att förse olika metoder för att göra så många aspekter som möjligt transparenta. Detta ska leda till en arbetsgrupp som känner till och har en bra
bild av all relevant information, vilket möjliggör ett flexiblare arbetssätt vid oförutsedda händelser. Scrum innehåller tre olika “pelare” som är: transparens (transparency), inspektion (inspection) och anpassning (adaptation). Inspektion behandlar de kontroller som bör göras för att se till att arbetet fortgår på ett sätt som inte negativt påverkar arbetet. Anpassning behandlar de anpassningar som kan behöva göras under arbetets gång för att undvika ett dåligt resultat.
Inom Scrum finns Sprint [34]. Sprint innebär en kortare tidsperiod där en arbetscykel sker och denna tidsperiod är oftast några få veckor. Sprint består även av vissa andra processer, till exempel ett planeringsmöte där nästa Sprint planeras. I slutet av en Sprint sker ett möte där den gångna Sprinten diskuteras, det kan handla om förbättringar som behöver göras eller andra lärdomar som samlats in.
3.3 Continuous Integration & Delivery
Continuous Integration (CI) innebär att utvecklarna frekvent slår ihop koden (merge),
vilket kan ske flera gånger om dagen [35]. I fokus ligger kod som byggs och testas automatiskt. CI möjliggör för organisationerna att ha flera och kortare kodsläppcykler. Även kvalitén på mjukvaran ökar samt utvecklarnas produktivitet.
Continuous Delivery (CD) innebär att processen för att släppa mjukvara/kod är
automatiserad [1, 7, 11]. CD inkluderar och bygger vidare på CI [35]. Detta betyder att koden byggs, testas samt driftsätts automatiskt, vilket plockar bort den mänskliga faktorn som kan orsaka olika fel i dessa steg [7]. Målet är att mjukvaran alltid är redo för driftsättning [35]. Med en automatiserad process för utveckling och kodsläpp kan organisationer snabbare och oftare göra ändringar i mjukvaran, vilket är en affärsmässig fördel [1, 7].
3.4 Implementationsmetoder
En tidigare studie [3] presenterar tre olika implementationsmetoder, nära samarbetande arbetsgrupper, multikompetenta arbetsgrupper och separata DevOps-grupper. Dessa är vanliga att se i organisationer som använder DevOps och därför beskrivs dessa nedan.
3.4.1 Nära samarbetande arbetsgrupper
Det första tillvägagångssättet innebär implementationen av ett närmare samarbete mellan de redan existerande arbetsgrupperna [3]. Mjukvaruutvecklarna och IT-Driften delar överlappande eller delade ansvarsområden vilket kan leda till både för- och
nackdelar. När utvecklarna arbetar närmare IT-Driften ökar förståelsen inte minst för hur IT-Driften arbetar, utan också för hur dem själva kan förbättra mjukvaran i framtiden [8]. Tack vare sin större insikt om hur den faktiskt används kan även IT-driften vara med och designa de nya verktygen.
Initialt är processen väldigt tidskrävande vilket har en negativ effekt på organisationens produktion [8]. Risk för att både irritation och tillitsproblem kan uppstå tidigt i samarbetets skede innan de anställda på arbetsgrupperna förstår varandras arbetsuppgifter och när ansvarsområden överlappar [3, 8]. Men trots vissa dispyter anser de båda arbetsgrupperna att tillit och förståelse har ökat och lett till en högre kvalité när det kommer till service stabilitet [8].
3.4.2 Multikompetenta arbetsgrupper
Multikompetenta arbetsgrupper innebär att gruppen för mjukvaruutvecklare är den enda arbetsgruppen i kedjan [3]. De står för såväl skapandet av ny kod som för testning av mjukvaran i drift. På detta sätt kan man minska cirkeln involverade i ett kodsläpp och därmed effektivisera mängden arbetstimmar investerade per kodsläpp, minska risken för missförstånd vid överlämningar och tydliggöra ansvarsområden [36]. Ett större ansvarsområde kräver dock också större expertis hos utvecklarna [3, 36]. Detta kan visa sig bli ett problem för vissa utvecklare som redan är upptagna med att ta till sig kunskap kopplad till mjukvaruutveckling [3].
3.4.3 DevOps-grupp
En DevOps-grupp skapas för att fungera som en brygga mellan utvecklarna och IT-driften [3]. Exakt vad denna metod innebär kan variera mellan olika organisationer. Ett problem med denna metod är att en ny silo skapas istället för att bryta ner de existerande [8]. Däremot är DevOps-grupper en av de mest populära implementationsmetoderna. En av uppgifterna för dessa grupper kan bestå av kunskapsdelning samt driftmässiga bekymmer mellan utvecklare och IT-drift.
4
Resultat & Analys
I detta kapitel presenteras och analyseras de resultat som framkommit från intervjuerna.
4.1 Organisationernas definition av DevOps
I problemformuleringen framgick det att det finns en avsaknad av konsensus angående definitionen av DevOps hos organisationer. Definitionen av DevOps upptäcktes i studien spela roll för hur organisationer gjorde val kopplat till sin implementationsmetod.
När DevOps kom upp på tapeten för ett antal år sedan, så fick vi ju en dragning på vad är konceptet DevOps. Och det handlade ju om att riva gränserna mellan utveckling och drift, i mångt och mycket. [...] Jag skulle nog nästan vilja säga att det enda formella införandet som vi har haft utav DevOps är ett möte som heter DevOps. Där vi en gång i veckan har representanter ifrån utveckling och drift, som går igenom om det finns någonting som någon känner att de vill drifta, dela med sig av eller funderar på något som inte har kommit upp till nivån att kalla på någon eller bara höra av sig till någon. -R2
Vi har nog aldrig enats om någon gemensam definition av DevOps och det tror jag kan vara lite svårt att hitta någon liksom “DevOps-definition” ute på nätet också som är allenarådande. Jag tänker ju kanske bredare på DevOps än bara relationen mellan utvecklare och driftenheten. Jag tänker ju mer kanske att det här med CD är lite synonymt för mig med DevOps. […] Vi jobbar ju med automatiseringar och hög kvalitet. -R3
Jag hade väl hört talas om DevOps tidigare men då mer utifrån en utvecklingsmetod. I och med att jag inte var en utvecklare så satte jag inte in mig i det på samma sätt som R3 gjorde. Utan för mig lät det mer som en konkurrent till Agile eller Scrum eller någonting annat. Men när vi började titta på det så kände jag att vi gör ju redan det här, eller åtminstone strävar vi efter det. Så i mångt och mycket finns det ett gammalt uttryck som stämmer ganska mycket och det är. 'Vi försöker plocka russinen ur kakan'. Vi försöker ta de delar som är bra från olika saker och göra det till vårt eget och få det att fungera för oss. Och även i de fall där det finns en skarp gräns att här får vi inte sudda ut gränsen mellan utveckling och drift, så försöker vi göra den gränsen så liten och låg som möjligt. -R2
Andra skillnader är att vi får en naturlig kompetensöverföring och en förståelse. Alltså utvecklare förstår tekniken och systemteknikerna förstår utveckling och vad
vi brottas med på den sidan. […] Och där ser vi att när vi för samman dessa två kompetenser eller förmågor lär vi oss mycket och hittar bättre lösningar och kommer snabbare framåt. -R4
Det är mer förflyttningen av ansvarsområdena tror jag som är det stora i DevOps som inte så många tänker på, i alla fall inte systemutvecklingssidan. Att vi skjuter på det ansvaret, från driften slussas ganska mycket över in i utvecklingsteamen. -R5 Jag tycker faktiskt att definitionen kan skilja även internt beroende på vad det är man syftar på. DevOps kan ju vara en process, det kan va ett rent operativt sätt att göra saker på, det kan också vara en mentalitet och vi definierar den lite beroende på vad vi vill utveckla och uppnå snarare. […] Tar man bara det generella så är det väl ändå mötet mellan den traditionella operationsmänniskan, den traditionella devutvecklaren och de teamen. Tittar man på person och roll så är det ju någon som kanske kommer från det ena eller andra spåret och lär sig den andra sidan och därmed har lite av bägge sidor. Tittar man på processerna och de bitarna så handlar det om sättet att ta nya förmågor och produktionssätta dem. -R6
Det finns väl någon gemensam bild kanske men inte någon formell definition. [...] Enklaste möjliga sättet att beskriva det är att utvecklingsteamet ansvarar för både vidareutveckling av systemet och drift av systemet. -R7
4.2 Implementationsmetoder
Detta område hanterar vilka implementationsmetoder organisationerna har använt vid införandet av DevOps samt hur dessa uppkom.
4.2.1 Övergången till DevOps
Näst intill alla intervjudeltagare svarade att deras övergång till DevOps startade som en naturlig övergång för att senare styras upp av organisationen eller chefer.
Ja både naturligt och påtvingat egentligen. Det här började ju med att ett par personer som jobbade på övervakningen satt och gjorde detta på kvällar och nätter när man jobbade men inte hade något att göra. Och då var det mer Guerrilla-verksamhet egentligen, att man satt vid en dator och ett skrivbord som man utvecklade på. -R1 Jag skulle väl säga en naturlig utveckling. Vad tror du R3? -R2
Nej jag vill påstå att det är mer av en naturlig utveckling och att det är en gemensam riktning. Vi ser att det är ett behov här att överbrygga saker och ting. Det handlar om två olika synsätt. Det ena är att utveckla, utmana, utforska. Det andra handlar om att säkerställa trygghet, stabilitet, tillgänglighet och säkerhet. Här gäller det att överbrygga dessa. Det kan du inte göra i två olika stuprör, vi märkte att vi behöver sammankoppla detta och då är DevOps en naturlig del i detta. -R4
Dels blev det ett naturligt steg att börja med de här kulturresorna, att vi gör det ihop och det är inga stuprör. För ungefär ett och ett halvt år sedan blev även ledningens inriktning att ‘Vi börjar titta på uppdrag med att hur kan vi utveckla DevOps-tänket.’. -R5
Jag skulle säg att det är en nödvändighet. Om man ska hänga med som ett teknikbolag som levererar tjänster så måste man effektivisera. Det jag tycker att DevOps handlar om är faktiskt att få ut värden på ett bra sätt och att göra det kostnadseffektivt. Det är nödvändigt om man ska vara ett modernt företag och de som inte gör den här satsningen eller har påbörjat den kommer inte att leva kvar. -R6
Jag skulle säga att en majoritet av tiden har den här typen av agila intiativ kommit underifrån från utvecklingsteamen men chefer har fått upp ögonen för det här sättet att arbeta mer och mer. […] Jag skulle säga att just i en DevOps-övergång behöver ledningen vara med på ett annat sätt än bara en agil transformation eller att teamet börjar köra SCRUM. […] Så jag skulle säga att i DevOps-fallet är det nog mer inblandning av chefer än tidigare. -R7
4.2.2 Identifierade implementationsmetoder
Myndigheterna har strikta avdelningsstrukturer där en arbetsgrupp sköter utvecklandet och en annan som sköter driften. I dessa fall har myndigheterna anammat DevOps för att förbättra samarbetet mellan utvecklarna och IT-driften. Både F2 och F3 använder sig istället utav multikompetenta arbetsgrupper där arbetsgrupperna sköter både utveckling och drift av sin mjukvara.
Då kommer vi till organisationen på M1. Ja vi jobbar på samma avdelning men vi jobbar på två helt olika enheter med två helt olika inriktningar. Vi jobbar på det som kallas digitaliserings och utvecklings –avdelningen. Förr kallades det för IT avdelningen. Och det inkluderar både alla utvecklare, testresurser och det som jag jobbar på är drift. Detta är vad vi numera kallar för infrastrukturenheten. Jag är Ops
Verksamheten är inte involverad i DevOps, utan det är mellan utveckling och infra kan jag vilja påstå. -R4
Nä men det är nog primärt det, utveckling och driftsidan som jobbar tillsammans. -R5
Jag skulle nog inte säga att det finns en renodlad arbetsgrupp för DevOps på det sättet. Det finns kompetens som har mer av en DevOps-karaktär på varje arbetsgrupp. […] Det är inte så tydligt att en person ligger i mitten som är DevOps och jobbar med utvecklarteamet på ena sidan och driftteamet på andra sidan. Sen är vi inte, i antal människor, så pass stora att vi ens kan ha det så, men jag tror inte heller att även om vi blev större skulle göra det. - R6
Det är oftast teamet som utvecklar den här tjänsten som också får ansvaret för drift och underhåll för att se till att det snurrar och förbättras kontinuerligt. Samt även monitorering och andra nödvändiga uppgraderingar. - R7
En utstickande variant var F1s där utnyttjandet av DevOps med större vikt rörde utvecklare, mer specifikt samarbete mellan flera utvecklingsgrupper snarare än med IT-driften. ‘IT’ beskrevs som de som tillhandahåller hårdvaran men det var utvecklarna själva som vanligtvis hanterade underhållet av mjukvaran.
Från början om vi räknar med den gruppen jag tillhör är det flera olika DevOps teams som har slagit ihop till en riktig arbetsgrupp. De här grupperingarna är fyra olika system. Så man har tagit medlemmarna, utvecklarna och arkitekterna för de här systemen och slagit ihop dem i en fysisk organisation. -R1
I den mån vi kan låter vi IT leverera infrastruktur, brandväggar, virusskydd och allting med backup och så vidare. vi utvecklar all kod själva och underhåller den men vi lämnar inte ifrån den till verksamheten. [...] Vi har ju inte serverdriften om vi kan lägga ut den på IT. Men vissa delar av våra servrar kan de inte lägga ut på IT. -R1 Det är det jobbet vi gör då givetvis men sen så måste vi också då ta hand om underhållet i vissa fall. [...] Därför blir det ju både utvecklingen och underhåll. -R1
4.2.3 Positiva effekter av vald implementationsmetod
Detta område rör vilka positiva aspekter som DevOps har lett till för organisationerna.
Nära samarbetande avdelningar
Respondent 5 från Myndighet 2 nämner att innan DevOps var det lite kommunikation mellan utvecklarna och IT-driften.
Då var det ännu mer att, ‘Imorgon ska vi driftsätta det här.’ följt av ‘Varför är det ingen som har sagt det?’. Där har vi faktiskt framförhållning nu, där vill man gärna känna till sakerna innan kanske minst två veckor innan så vi kan planera och ta höjd för saker. -R5
På båda myndigheterna anser de att samarbetet mellan utvecklare och IT-drift har förbättrats gentemot tiden innan DevOps och nämner att kommunikationen är en stor del av förbättringen.
Jag skulle nog säga att det har blivit bättre, även om det inte finns en allenarådande definition av DevOps ger det oss i alla fall ett ramverk att kunna prata utifrån. Det handlar mest om att man får gemensamma referensramar så att vi pratar om samma sak. I och med att samarbetet redan tidigare var väldigt rakt och att det fanns väldigt få gränser så har DevOps egentligen inte förändrat vad vi gör mer än att ha förbättrat sättet vi pratar om det. -R2
Jag vill påstå att det är färre konflikter. Det finns en större förståelse för varandras vardag om jag uttrycker mig så. Sen finns det också en större respekt för att det är mer komplext än vad man tror. -R4
Man kan ju alltid önska mer, men det har blivit mycket bättre sedan, åtta-tio år sedan när vi arbetade helt isolerade med vattentäta skott emellan grupperna. Nu flaggar projekterarna upp: ‘Vi behöver ha med nån från driften nu när vi drar igång det här för att vi vill få den inputen.’. Så det har blivit mycket bättre och alla vet vad som förväntas av varandra. Det har blivit mycket bättre sen tidigare. -R5
Något som R2 nämner blivit bättre sedan implementationen av DevOps är att det råder större flexibilitet rörande utveckling av nya idéer.
Den största förändringen sedan 2012 när jag började är att vi har börjat titta mer på att låta saker bli ‘proof of concept’. Förut var det mer att man formellt behövde be om att få tid till att utveckla någonting eller att bygga upp en driftsmiljö. Sedan 2016 så har vi en större acceptans på att ibland gör vi saker och ting på egen tid, bara så länge det inte påverkar andra uppdrag. Men att testa någonting och se ‘Fungerar det här för oss?’. Fungerar det kan vi gå in och göra det formellt, och fungerar det inte river vi det och säger att det var ett bra test. -R2
R6 och 7 nämner att det krävs större kompetens för att arbeta inom multikompetenta arbetsgrupper då alla behöver vissa kunskaper inom både utveckling och IT-drift. R6 nämner också att de inte har haft problem med samarbetet då de inte får krocken mellan utvecklare och IT-driften.
Vi har ett bättre samarbete men det är inte specifikt på grund av DevOps. DevOps är mer av en arbetsmetod tycker jag snarare än en samarbetsform. -R6
Men därför har vi inte riktigt den kulturen där man har dem här strikta områdena utan man måste vara ganska bred när man är lite mindre i storlek. Vi fortsätter att ha en bred kompetens som sen kan spetsa in sig inom vissa områden. På så sätt det blir ingen sådan krock överhuvudtaget. Det är ingen som vanligtvis ger sig in i någon annans område, men gör man det så gör man det av en anledning och då är det okej. -R6
Det är min erfarenhet att man på myndighetssidan kanske har en utvecklingsorganisation och en förvaltningsorganisation. Sedan har man kanske ett IT-driftsteam som ansvarar för servrar och driftsfrågor. Men vi jobbar gärna på så sätt att man slår ihop allt det här så att de här agila teamen och DevOps-teamen har all kompetens som behövs för att både utveckla och driftsätta lösningen. -R7 Man behöver ju kunna rätt mycket och det finns en trend också mot att man som utvecklare ska jobba full-stack. Där man tidigare kanske varit, ‘Jag är front end-utvecklare’ eller ‘jag är back end-utvecklare.’ men nu ska man kunna lite av varje. Nu krävs det förståelse för driftsaspekten i samband med det, då de måste förstå infrastrukturen där koden körs. -R7
Enligt R1 beskrevs miljön nu som mer kontrollerad och säker. Det är lättare att följa de regler som finns tack vare fler organiserade roller och fler stödsystem som säkerställer att allt fungerar som de ska.
Det är mer sanktionerat just nu i och med att nu följer man det regelverket som finns, man har talat om att systemet finns och man har tagit ut de rollerna som krävs. Nu vet vi till exempel att det krävs en ‘Application Manager’ och en ‘Information System Manager’ som ansvarar för att allting blir gjort och att alla checklistor genomförs och så vidare. -R1
Vi har någonting som heter ‘priority controls’, det innebär att du med vissa regelbundna intervall, det vill säga månadsvis, kvartalsvis eller årsvis ska göra vissa säkerhetscheckar. Till exempel kontrollera att backuperna funkar eller att kontrollera
att vi inte lagrar data längre än 180 dagar, för det är ju ett GDPR krav. Och tidigare när man gjorde källarverksamheten fick man inte de påminnelserna och man följde kanske inte riktigt alla de här reglerna heller. Man får både ett stöd av att man gör det på rätt sätt, men det medför ju också mer jobb. -R1
4.3 Uppstådda hinder vid implementation
Detta område beskriver vissa hinder som uppstod hos organisationerna i samband med DevOps-implementationen.
4.3.1 Nära samarbetande arbetsgrupper
De respondenter som arbetar inom myndigheter och nära samarbetande arbetsgrupper har stött på olika hinder. Inom M1 nämner de att det främst handlar om en avsaknad av ett formellt mål som de ska sträva mot. Även avsaknad av tid är något de påpekar. Respondenterna från M2 nämner kulturkrockar som ett hinder där utvecklare och IT-driften har olika tankesätt.
Jag skulle säga avsaknaden av ett formellt beslut kring arkitektur och delarna kring CD. Det känner jag är ett bekymmer. -R3
Vi kanske får lite för lite tid att bygga upp stödfunktionerna på det sätt vi skulle vilja. Vi är lite fast i att vi måste hinna med deadlines och producera de sakerna som vi åsatt att göra. -R3
Det som är utmaningen, det som är svårt. Det är ju att det blir ‘Vem har ansvaret egentligen?’. -R4
Till exempel nu då när en enkel grej som ‘Ska ett utvecklingsteam få driftsätta i produktion direkt, ska de ansvara för det?’. -R4
Man ska inte underskatta kulturfrågan i det hela. Alltså att det är två olika kulturer, operation och development, då gäller det att få en gemensam kultur. -R4
När man väl ska ut i produktionssättning måste vi ta hand om ansvarsbiten först. För då kan det bli att ‘Vi gjorde en deploy men nu blir det driftens ansvar att rätta upp.’. Jag vill inte hamna där för det blir verkligen en black box för oss, att de sköter sina containrar själva. -R5
Tidigare har det väl inte riktigt funnits förståelsen mellan de olika grupperingarna. På utvecklingssidan så tänker man ofta så här att ‘Vi vill trycka ut så mycket nya och
coola grejer som möjligt till slutanvändaren.'. Medan i drifts perspektiv är det ofta ‘Vi vill ha det så stabilt som möjligt. Vem vill ha saker var sjätte minut levererat till sig? Det kommer ju bara bli en härdsmälta!’. Det är väl de här två olika tankesätten som finns ibland känner jag. -R5
På M1 hanterades problem på olika sätt. Angående avsaknad av ett formellt mål hade de inga hanteringsmetoder, däremot försökte de arbeta iterativt med DevOps för att anpassa och förbättra deras arbetssätt. De hade även avsatt särskilda dagar där utvecklarna och IT-driften testar nya lösningar tillsammans vilket ger dem tid att testa något nytt. Respondenterna från båda myndigheterna nämner att de försöker jobba med kommunikationen så alla ska veta vad de ansvarar för, varför de utför något arbete och utöka förståelsen mellan arbetsgrupperna.
Det kan bli lite gnissel att försöka göra en förändring och att försöka få det formellt eller inte formellt. Det låter lite luddigt men det kan både vara en fördel och en nackdel att inte ha ett formellt beslut på hur vi ska göra. Det skapar mer flexibilitet på vad vi faktiskt gör. Men jag håller med R3 i och med att vi är närmare 200 personer på utvecklingssidan, så blir det också en liten brist att det inte finns ett formellt mål på vad vi ska nå. För det betyder också att de här 200 personerna kan dra lite åt olika håll. -R2
‘Fortsätt som ni alltid har gjort, ta och lär er utav det som finns i DevOps, gör det som passar för vår organisation. Förbättra saker och ting.’. Det är ju ett kontinuerligt arbete så det är ju ingenting som man gjorde för några månader tillbaka och sen har vi en ny modell. Utan modellen vi har förbättrar vi över tid. Vi ska inte vara rädda för att kasta ut nånting som vi har gjort när vi hittar någonting som är bättre. En fördel med avsaknaden utav formella beslut är att det blir också lite mer flytande, ‘Vad kan vi göra?’. Vi vågar göra saker och ting –R2
Jag ska nog skicka med att förändra kultur är svårt, och det krävs en väldigt medveten ansats att man verkligen förändrar kulturen. Jobbar man i en strikt och rigid organisation som är gammal så är inte DevOps nånting man bara säger ‘Nu jobbar vi DevOps.’. Utan man måste också få en acceptans, att folk ser att det här är ett värde för mig som person. Vi är ju belöningsorienterade som de djur vi är. Så om jag inte ser att det här ger mig någonting, varför ska jag då göra det? Så där handlar det om att man måste få kulturen att förändras, att sudda gränsen och säga att nu jobbar vi DevOps. Development och operations ska prata med varandra. Det är inte bara nånting man säger, det är nånting man måste göra också. Då kan olika typer av
team-bildande åtgärder vara nödvändiga, även om det inte är ett team det handlar om. Låt utvecklare och driftare träffas i mer informella sammanhang, lära känna varandra, upptäcka att det är inte så mycket skillnad på oss. -R2
Att ha en experimentdag där vi, avdelningen, får ägna en hel dag och tillsammans med andra enheter för att titta på nya lösningar förutsättningslöst. Pröva idéer och tankar utan att det finns något speciellt mål. -R3
Vi har jobbat mycket med att vi tre enhetschefer som är involverade pratar ihop oss, att vi är överens i budskap av vad vi vill ha. Sen försöker vi då jobba genom att skapa förutsättningar för våra medarbetare. Ta med dem tidigt i processen, låta dem ta ansvar och även trycka på att ‘Det här är vårt ansvar.’, ‘Här behöver vi vara med och påverka.’, ‘Det är nu vi kan påverka, inte senare.’. -R4
Vi brukar prata om avstånd ibland. Avstånd ifrån att den som ska ha nytta utav det man gör till den som gör det. Ju längre det avståndet är desto svårare är det att få en förståelse för att göra rätt. Vi har jobbat väldigt mycket med att minska det avståndet så att även teknikern ska förstå det. ‘Varför skruvar jag på den här routern?’ Har man den förståelsen så tror jag att man kan göra ett mycket bättre arbete. -R4
Leveransgruppen som jag pratade om, det är väl det de primärt tittar på nu, ‘Hur ska vi få det här att funka, hur går vi hela linan ut?’. […] Men deras nästa uppdrag blir väl som sagt, hur ska vi jobba tillsammans sen, vilka delar ska vi ta ansvar för och vilka delar ska utvecklingsteamen ta ansvar för? -R5
4.3.2 Multikompetenta arbetsgrupper
Respondenterna från de olika företagen nämnde olika hinder som de har stött på. R1 pratade om svårigheten att sätta en process för en grupp som bestod av fyra föregående arbetsgrupper där de har jobbat på sina sätt vilket liknade ett “guerillascenario”. R6 nämner flera generella hinder, ett exempel är budgeten. Däremot anser R6 att de största hindren har varit avsaknaden av tid och resurser. R7 nämner vanan vid att arbeta på ett visst sätt har varit ett hinder vid implementationer. Även mellanchefer beskrivs som ett hinder då de ofta sitter fast i ett visst tankesätt och har ganska låg förståelse för DevOps. R7 påpekar också att större organisationer kan ha större behov av flera arbetsgrupper vilket kräver en större synkning grupperna emellan. Ett annat hinder som R7 nämner är att driften kan bli svår att upprätthålla konstant med en mindre arbetsgrupp under semestertider. Vid frågan om R7 trodde att det krävdes ytterligare kompetens delgav han även att detta stämde.
Att sätta processen är ju en utmaning i sig, för vi var ju fyra grupperingar som slogs ihop till en och då vill man ha samma process egentligen, eller att man gör på samma sätt. Det är ju många starka viljor då kanske när man har kört källarstuket tidigare för att istället nu istället börja köra det mer ordentligt. -R1
Utvecklingen rör på sig väldigt fort men man kan däremot stå stilla på grund av olika begränsningar. Det kan vara allt ifrån organisatoriskt till budget till tid till att vi jobbar med kunder som inte kan röra sig åt ett visst håll lika snabbt som vi vill och så vidare. Men jag skulle nog säga att de största utmaningarna i en implementation av DevOps är tid och resurser. -R6.
Och det gäller ju både det man kallar DevOps och agil transformation överhuvudtaget, man är van vid att göra saker på vissa sätt. -R7
Storleken på organisationen spelar också roll. Jag har senaste tiden jobbat i ganska små kontexter där ett team har kunnat utveckla hela systemet medan större organisationer bygger ut större system, då krävs det fler teams som är involverade och då blir synkningen mellan teamen mycket viktigare. -R7
Det sitter ganska hårt rotat i våra processer, vår kultur och vår dokumentation så det är absolut en jätteutmaning. Och oftast om man ser på ingenjörssidan så har mjukvaruutvecklarna sällan några problem med att ställa om sig, utan det är oftast de som är pådrivande. Det är chefslager och framförallt det man kallar mellanchefslagret. Man har ett team och så har man första linjens chef som är chef för det teamet. Efter det har du även flera chefslager däremellan som kallas för mellanchefer. En mellanchef är chef för chefer kan man säga och där brukar man ha ganska låg förståelse för det här med DevOps. Och man är inte sällan ganska långt ifrån verksamheten och förstår inte fördelarna. Där brukar det finnas en hel del bromsklossar. -R7
En baksida som jag kom på är det här med att när man driftar ett system. I regel idag behöver de här systemen vara tillgängliga dygnet runt, 365 dagar om året. Om det då bara är ett förhållandevis litet utvecklingsteam så kan det bli svårt att få täckning över semestrar. Speciellt i Sverige då alla vill vara lediga fyra till fem veckor i juli. Vem kan ta hand om övervakningen under den här perioden? Man får hålla på med olika typer av beredskap och ha någon ‘on call’ som får övervaka det här under sin ledighet. -R7
Man behöver definitivt kunna mer. Du behöver ha en mer generalistkompetens, man brukar kalla det för T-formad kompetens. -R7
För att hantera problemet mellan de fyra olika arbetsgrupperna inom F1 togs det in en extern projektledare för att försöka sätta de processer som de skulle komma att använda sig av senare nä grupperna kombineras till en grupp. R6 nämner att hindren kring tids- och resursbrist hanteras med hjälp av en roadmap och strukturerat arbete. För att hantera hindren som kommer från mellanchefer nämnde R7 att de kan bytas ut eller utbildas, för att ge dem förståelsen för DevOps.
Vi hade en extern projektledare som var inhyrd och försökte sätta processerna innan vi blev en formell grupp. Då gjorde man ett projekt till att börja med där vi fortfarande jobbade kvar i våra ursprungliga organisationer. Där hade vi oftast stora möten där alla var inblandade och man diskuterade, vad man tyckte, vad man vill ta fram och rutiner togs fram. Efter ungefär två år anställdes en ledare för den här grupperingen och alla personer flyttades verksamhetsmässigt in under den här personen. -R1
Konkret krävs det en bra roadmap och ett strukturerat arbete. -R6
Precis, byta ut chefer. […] Ah, nej men det är ju oftast att personer i ledande positioner kan ha svårt för det här. Traditionella projektledare, chefer och så vidare. Jag tror att man behöver lägga rätt mycket tid på utbildning där samt att de får vara med och vara delaktiga i leveransen och få se fördelarna -R7
4.4 Analys kopplat till forskningsfrågor
Vilka implementationsmetoder använder svenska organisationer vid införandet av DevOps?
Ett mönster identifierades tidigt i analysstadiet att de implementationsmetoder som använts berodde på hur en organisation valt att definiera DevOps, vad de ämnat åstadkomma med hjälp av DevOps, samt vilken historia organisationen hade sedan tidigare. Respondenter från myndigheter pekade tydligt på att det för dem fortfarande var viktigt att särskilja på ansvarsområden mellan sina utvecklare och sin IT-drift på grund av säkerhetsmässiga skäl. Som R2 poängterade så handlade det för dem istället om att göra denna gräns så liten som möjligt snarare än att kombinera arbetsgrupperna helt. Definitionen av DevOps skiljde sig även inom organisationer beroende på vem som tillfrågades. Medan fokus låg på att främja samarbete och förtydliga ansvarsområden mellan arbetsgrupperna hos R2 och R5 som ansvarade för IT-driften, framgick det att utvecklarna R3 och R4, likt utvecklare på företag F1, F2 och F3, utöver detta även förknippade DevOps med diverse utvecklingsmetoder som CD och CI. R2
uttryckte detta som att de försökte plocka russinen ur kakan, alltså att plocka det som är bra från olika saker och göra något eget av det.
Utav de organisationer vars respondenter deltagit i studien finns ett mönster av att större organisationer till viss del arbetar mer med separata arbetsgrupper än mindre organisationer. Båda myndigheterna arbetade med dedikerade arbetsgrupper för utveckling och IT-drift. F1 som är ett väldigt stort företag arbetar med en multikompetent arbetsgrupp men har fortfarande kvar delar av driften hos andra arbetsgrupper. F2 och F3 är jämförelsevis relativt små organisationer och använder multikompetenta arbetsgrupper där all drift och utveckling hanteras inom gruppen. R7 nämnde att större organisationer oftast kräver flera arbetsgrupper då de oftast arbetar med större system.
På samtliga organisationer visade det sig i studien att DevOps var något som kom naturligt till organisationen. I samtliga av fallen var detta något som började nerifrån, från utvecklarna själva som då har identifierat sätt att effektivisera rutiner och arbetsmiljöer med hjälp av olika metoder eller verktyg. R7, som arbetar inom konsultbranschen och har hjälp flertalet kunder med att implementera DevOps, delger att denna typ av agila initiativ i majoriteten av deras fall har kommit underifrån. R7 säger däremot att han ser en trend i att chefer börjar bli allt mer involverade och att de börjar få upp ögonen mer och mer för DevOps. F1 var ett fall där respondenten själv beskrev att organisationens DevOps implementation utformats ur ett Guerilla format. Detta förklarade dem som något de har fått lägga extra mycket arbete på att få i bukt med.
Vilka hinder har identifierats vid implementationen av DevOps i svenska organisationer?
Även med de uppstådda hindren finns det mönster hos de större organisationerna men M1 sticker ut något. Respondenter från F1 och M2 menade att krockar kopplat till arbetskultur och metoder var ett stort hinder, för M2 är det fortfarande ett hinder. Hos F1 liknade situationen ett “guerillascenario” där olika regelverk eller uträkningar av projektens värde inte beaktades i en större utsträckning. Respondenterna från M1 däremot sade att de sedan tidigare redan hade börjat jobba på ett sätt som liknade DevOps men de sade också att kulturen inom en organisation är något man måste jobba aktivt med. M1 ser kulturen som ett visst hinder men i en lika stor utsträckning som de
