Problematiken kring samarbete och effektivitet

Något som kan läsas ur intervjuerna som gjorts är att driftens önskemål om ett gemensamt arbetssätt vid utvecklingen av applikationer syftar till att effektivisera och underlätta arbetet för dem. Dels att de önskar att alla använde sig av

ärendehanteringsprogrammet Remedy för att göra det enklare för drift att lämna över ärenden som inte de inte klarar av att hitta en lösning på. Samt att de uttrycker en önskan om någon form av standardisering, ramverk, när en applikation skall nyutvecklas. De pekar exempelvis på att man bör ha likadan loggning i applikationer. Detta är förståeligt då en enskild person från drift kan vara ansvarig för flertalet applikationer. Det kan då vara svårt att ha/få en djupare kunskap om applikationerna. Att felsökningsarbetet sker genom att gå igenom loggar manuellt gör det lätt att se en fördel med att loggning sker på ett

gemensamt sätt för att då underlätta och effektivisera arbetet för dem. Figur 7 nedan visar de behov, baserat på mål och problem, som framkommer.

29

Figur 7 - Felsöka & åtgärda, olika arbetssätt och flera system - behov

5.2.2. Överlämning till drift, applikationer inte helt överlämnade, avgränsningar mellan avdelningar och kompetens

Här kan vi se problemet från ”andra sidan” också. Utvecklarna har ett problem med att de tycker att de inte kan lämna över vissa applikationer till drift för att de ser att det är svårt för driften att ha tillräcklig kompetens för att sköta om

applikationerna. Detta leder i sin tur att utvecklarna tar hand om driften på dessa applikationer. Ett plus med detta är att genom att ha större kunskap och

kompetens om applikationerna är möjligheterna för en snabbare och effektivare felsökning. Istället för att om driften skulle lagt tid på felsökning som de sedan ändå behöver söka hjälp från de som utvecklat applikationen. Ett minus med detta upplägg är att utvecklare får lägga tid på att drifta applikationer istället för att fokusera på att förvalta och förbättra, eller att nyutveckla applikationer.

Det kan sägas att de två avdelningarna har två olika angreppsvinklar på de gemensamma problemen. Med den syn driften har på de problem som de upplever kan man se att fokus ligger på att underlätta deras arbetsprocess inom gränserna för deras avdelning. Medan utvecklarna mer ser lösningar i ett större samarbete mellan avdelningarna. Vi kan se att de sneglar mer på en gemensam organisation som samlar kompetensen. Något som förespråkas av Cois et al.

(2014) som säger att arbetssättet DevOps kan möjliggöra en lösning på de problem som uppstår när man har separerade avdelningar. DevOps förespråkar en integrering av driftteamen och systemutvecklingsteamen för att kunna minimera kommunikationssvårigheter dem emellan samt maximera kunskapsspridningen. Även att de två teamen arbetar tillsammans mot

gemensamma mål. Detta är något som vi kan se som behövligt om vi tittar på de

30

problem som de båda avdelningarna upplever. Cois et al. (2014) skriver även att ett införande av DevOps medför att de verktyg som används för drift och

utveckling delas mellan avdelningarna för att tillgodose en maximal tillgång av data. Något som går i linje med utvecklarnas önskan att ha mer insyn i hur ”deras”

applikationer presterar efter att de lämnats över till driften.

Samarbete mellan avdelningarna och kompetensöverföring är två behov som vi kan identifiera utifrån de mål och problem som f och visualiserar i figur 8 nedan.

Figur 8 - Överlämning till drift, applikationer inte helt överlämnade, avgränsningar mellan avdelningar och kompetens – behov

31

5.3. Applikationsövervakningens fem dimensioner

I den här delen kommer vi att gå igenom applikationsövervakningens fem dimensioner av funktionalitet som vi presenterar i kapitel 2.1.2 Applikationsövervakningens fem dimensioner. Vi kommer att gå igenom hur de här dimensionerna kan hjälpa till med bland annat de behov som tas upp i tidigare avsnitt. Vi presenterar i början på kapitlet här under en matris med de funna behoven ställda mot applikationsövervakningens fem dimensioner. För att därefter analyser dem.

Slutanvändarens upplevelser Upptäckt visualisering av applikationstopologi Profilering av användardefinierade transaktioner Djupdykning hos en applikations komponenter Analys

Behov

Ge utvecklare tillgång till

information i produktionsmiljö X X X X X

Kunna se samband i det data som

kommer från applikationen X

Gemensamt arbetssätt med applikationsövervakning Använda samma verktyg för kommunikation

Ett standardiserat sätt att förhålla sig till nyutveckling

Samarbete mellan avdelningar

Kompetensöverföring X

Tabell 1 - Matris över behov och applikationsövervakningens fem dimensioner

5.3.1. Slutanvändarens upplevelser

Att övervaka hur användarna av applikationen upplever den är en viktig del i att se om applikationen fungerar som den ska eller inte. Här kan man se hur lång tid en exekvering av en transaktion tar för användaren. Genom att man kan se hur användarna upplever användningen av applikationen så kan man upptäcka saker som inte går i linje men vad som är tänkt från början, och kan på ett tidigt stadie

32

gå in och utföra ändringar innan problemet blir till en incident. På samma sätt så kan man få en bekräftelse på att tillexempel den nya funktionen som man satt in i systemet fungerar som den ska, som en utvecklar respondent säger: ”Men även om det inte är någonting som går fel. Det är minst lika viktigt att ha en

övervakning för att se att någonting inte är fel.”

5.3.2. Upptäckt och visualisering av applikationstopologi

Som det framkom i intervjuerna så är information om mätplatser är tillgängliga eller inte viktig information. Genom att man har en visualisering av

applikationstopologin och hur de olika komponenterna kommunicerar med varandra så kan man se om det är specifika mätstationer som inte fungerar som de ska eller om det är något bakomliggande som gör att mätstationen inte kan skicka dess data. Genom att visuellt visa hur infrastrukturen hos komponenterna ser ut och hur de kommunicerar får man en helt annan möjlighet att med hjälp av den fjärde dimensionen, djupdykning hos en applikations komponenter att identifiera orsakerna till störningar i applikationen.

5.3.3. Profilering av användardefinierade transaktioner

Användardefinierade transaktioner är upptäckten av en användares förfrågningar gentemot applikationen. Även det här ger en möjlighet till att se hur användare använder applikationen. Även om det inte framkommer från intervjuerna som ett behov så framkom uppföljning som ett problem, eller snarare bristen på

uppföljning. Den här dimensionen av applikationsövervakning ger en annan vinkel på uppföljning, i form av hur applikationen används.

Här kan det vara bra att se om det finns funktioner i applikationen som inte används. Det ger möjligheten till att ställa sig själva frågan varför? Om den

funktionen inte var bra eller om användarna inte ens vet om att funktionen finns.

5.3.4. Djupdykning hos en applikations komponenter

I relation till att hitta prestanda problem i den första dimensionen så är det som Sahasrabudhe, et al. (2013) säger, att veta om att det finns ett prestanda problem är ett steg i rätt riktning men att veta vad det är som har orsakat problemet är absolut nödvändigt för att det ska kunna gå att lösa innan det påverkar

verksamheten. Genom att man i den här dimensionen kan gå in på djupet i en komponent så kan man identifiera orsaken till problemet och på det sättet så kan man åtgärda det i ett tidigt stadie innan det på verkar verksamheten eller i alla fall minska dess påverkan på verksamheten.

5.3.5. Analys

Genom att samla in och presentera data från de tidigare dimensionerna så kan man i den här dimensionen hitta lösningen på de behov som togs fram i kapitel 5.1. Problematiken kring proaktivt arbete. Panwar. (2013) menar att data som samlats in presenteras grafiskt för att man enkelt ska kunna se mönster och trender. Här är en viktig punkt för att kunna arbeta proaktivt, att se mönster och trender. Som vi presenterar finns behovet av att kunna se mönster hos

applikationer för att man ska hitta problem och åtgärda dem innan de påverkar verksamheten i form av att det blir en incident.

33

Att ha en sådan här typ av applikationsövervakning enad över organisationen ökar möjligheterna för samarbete mellan grupperingarna. Även i de applikationer där man kände att man inte kunde lämna över applikationen till driften för att det saknades kompetens så tror vi att det kommer att öppna upp för att det ska vara lättare att lämna över applikationer och minska den ”vi och dom” känsla som finns.