Hur gör vi när vi vill ta hem information från en molntjänst på ett säkert sätt. Denna artikel beskriver ett sätt som utifrån it-arkitektur kan stötta verksamheten på ett övergripande sätt. 

Molntjänster innebär för många verksamheter en smidig tillgång till applikationer, information samt problemfri drift, men det kan också innebära utmaningar. Hemtagning av information på ett säkert sätt är ett sådant exempel. Ett sätt att adressera detta är en strategi kring en helhetsvy från IT-arkitektur och som kan ingå i utforskande och agila arbetssätt. Denna strategi syftar till att skapa förutsättningarna för alla de roller som behövs för att säkerställa information och informationshantering, direkt genom roller som säkerhetsspecialister men även andra roller som beställare, användare från verksamheten, tjänstedesigners och roller inom projektledning och test.  

Vid en första anblick kan det verka enkelt att ta hem sin information på ett säkert sätt. Vi vet ju vilken information som finns i tjänsten. Vi vet hur säkerheten ser ut kring förbindelse och åtkomst till informationen. Eller vet vi det? Vet vi vad som döljer sig bakom de funktioner molntjänsten erbjuder? Vet vi hur den är uppbyggd och hur informationen egentligen hanteras? Och framför allt, vet vi egentligen hur vi själva faktiskt använder den och hur verksamheten ser ut på vår sida? 

Ett helhetsperspektiv på hur en verksamhet använder en molntjänst 

Figur 1 – En arkitekturell översikt 

Detta är en generell modell av en produkt eller molntjänst utifrån verksamhetens eller kundens perspektiv, och som även visar olika nivåer på kundens verksamhet och hur dessa motsvaras av vad tjänsten erbjuder. Detta helhetsperspektiv är grunden för att skapa förståelse för hur digitalisering går till och vad det är verksamheten behöver. Perspektivet från en kund är också viktigt eftersom det är så tjänsten uppfattas utifrån.  

Vad är det vi gör tillsammans? Detta handlar om syfte och mål med tjänsten och vad verksamheten vill ha ut av den. Detta kan ofta hämtas från ett projektdirektiv eller annat måldokument och exempelvis vara att verksamheten behöver en molntjänst för att lagra arbetsdokument och där tjänsten erbjuder ett smidigt sätt att jobba, säkerhet i form av tillgänglighet, backup och problemfri drift. Om vi antar att scenariot att ta hem sin information handlar om en molntjänst för dokumentlagring, behöver man börja redan här och beskriva syftet med att informationen skall tas hem. Det kan vara förändrad driftsform eller en lokal backup. Utifrån det kan man börja förstå vad det innebär att ta hem informationen.  

Vad är det verksamheten vill med tjänsten? Detta är en första detaljering för att förstå både vilken information tjänsten egentligen har, och hur den används, så att vi alltså vet både vad det är vi behöver ta hem och hur vi kan fortsätta använda informationen. I exemplet med molnlagring av dokument kan verksamhetens behov vara möjlighet att lägga upp, hämta, ändra dokument, men också samarbeta kring dokument, dela ut dokument till olika användare och kanske kunna arbeta med dokumenten direkt i molntjänsten. Man brukar benämna detta förmågor. 

Detta är viktigt både för att säkert kunna ta hem sin information och för att informationen ska vara förståelig och användbar för verksamheten eller vid migrering till en ny tjänst.

---

Vad är tjänsten och vad kan den göra? Motsvarar nivån som ovan beskrivits, men för tjänsten. Här måste vi börja i vad det är vi vill ha innan vi kan tolka vad tjänsten erbjuder och vad det innebär. Men sedan måste vi även se vad tjänsten erbjuder för förmågor som vi kanske inte tänkt på, eller var medvetna om att vår verksamhet faktiskt använde. Vi börjar här också få en bild över de stora dragen kring hur information lagras och flyttas, grundläggande perspektiv för den mera tekniska säkerheten, men även för det säkerhetsmässiga perspektivet. Med detta avses den mera tekniska säkerheten men eftersom säkerhet börjar med hur information används, att den alltså kan användas på samma sätt efter att den hämtats hem och används lokalt eller migrerats till en ny tjänst. 

Vem använder tjänsten, hur, med vilken information? Detta är en detaljering som utgår från användarna, vilka roller de har och vad de gör, mera detaljerat. Här ingår processperspektivet med aktiviteter och mera detaljerade beskrivningar av informationen, det som löser förmågorna vi hittade i tidigare nivåer. Det viktiga är att inte gå in på lösningar och teknik utan hålla sig på nivån kring användare som utför aktiviteter och vilka leverabler i form av dokument och annan information som produceras och förändras. En viktig aspekt här är att även verksamheten har mål och syften. Detta är lika viktigt att fånga som användarnas perspektiv. 

Hur gör tjänsten? är motsvarande nivå för tjänsten, och även här är det bra att utgå från verksamhetens sätt att göra saker, men även vad tjänsten erbjuder för funktioner som vi kanske inte var medvetna om, till exempel versionshantering kanske finns i en dokumentlagringstjänst och som verksamheten först inte var medvetna om men visar sig vara användbar. Det säkerhetsmässiga perspektivet fortsätter här att utvecklas genom de grundläggande insikterna om vad det faktiskt är vi skall säkerställa; att verksamheten kan fortsätta arbeta, kanske inte på samma sätt, men med samma resultat, vad användare och verksamhet vill uppnå och vi måste förstå hur saker görs för att veta att vi hämtar hem all information vi behöver och att vi kan arbeta med den på samma sätt. Vi får också en mera detaljerad bild kring vad tjänsten innehåller för information, var den finns och hur den flyttas. 

Hur vill vi ha tjänsten, vilka egenskaper skall den ha? samt Hur ser tjänsten ut, hur presenteras den? Gällande egenskaper så börjar vi närma oss it-lösningar och i viss mån teknik. Detta brukar också kallas ’icke-funktionella krav’. Att börja med vad verksamheten behöver är viktigt men det är ofta så att man även tittar på vad tjänsten erbjuder. Egenskaper som skalbarhet för ökade krav på prestanda både vad gäller volym, antal användare och responstider är sådant som har säkerhetsmässig betydelse framför allt vid en migrering, för att användare ska kunna fortsätta hantera informationen. Kanske inte direkt säkerhetsmässigt kopplat, men en aspekt är kostnad som dessa egenskaper ofta är förknippade med. Är det lösbart om vi flyttar vår information. Mera direkt säkerhetsmässigt är en förståelse av redundans, backup och att tjänsten är tillgänglig. Detta är ofta något man behöver förstå praktiskt tillsammans med leverantören.  

Andra egenskaper som är viktiga är ’Leverantör’. Vad erbjuds för support? Var finns leverantören eller underleverantörer? Detta är viktigt säkerhetsmässigt utifrån dataskyddslagstiftning men även praktiskt. Vi behöver veta var vår information egentligen finns, både geografiskt men även om informationen är samlad eller om informationen är samlad inom molntjänsten alternativt lagras eller hämtas från andra tjänster. Detta berör återigen underleverantör men även tredjeparts-tjänster och vad dessa gör. Mera tekniska aspekter här rör driftmiljö: Hur är redundans och backup utformad? Var finns alternativa datacenter och vad händer vid driftstörningar? Hur länge kan tjänsten vara nere innan ett backupsystem tar över? Riskerar vi att tappa information i dessa lägen? Även aspekter som hur ofta backup utförs och vad som kan gå förlorat mellan dessa behöver has i åtanke. Det finns även egenskaper utifrån användbarhet som behöver beaktas. Är tjänsten och hur verksamheten tillämpar den förståeligt och hur får vi med förståelsen vid en migrering så att informationen säkras mot felhantering? En sista egenskap att titta på rör integrering med andra system vi använder. I exemplet med en dokumenthanteringstjänst hur hantering av dokument hänger ihop och risker när vi lämnar en tjänst utifrån både teknisk kompabilitet och sätt att använda tjänsten.  

Hur får vi till tjänsten praktiskt? och Hur får man tjänsten att fungera? Dessa frågor rör lösningar och teknik. Detta avslutar egentligen det vi började med högst upp. Det vill säga att tjänsten ska kunna realisera verksamhetens syfte och vision med den, den ska erbjuda användarna vad de vill ha och de egenskaper de behöver Allt detta skall realiseras med det som tjänsten erbjuder. På denna nivå finns tekniska specifikationer som operativsystem, kommunikationsprotokoll, filformat och beskrivningar av informationsobjekten. Detta är viktigt både för att säkert kunna ta hem sin information och för att informationen ska vara förståelig och användbar för verksamheten eller vid migrering till en ny tjänst. Det är också viktigt för att uppskatta storlek och kapacitet, både hos leverantör, i förbindelse och hos verksamheten när det gäller att ta hem stora mängder, eller komplexa strukturer, av information.  

I ett sammanhang 

Den modell av en tjänst och hur den används som beskrivs här är generell, men i det här sammanhanget rör det informationssäkerhet. Modellen visar därför hur säkerhet inte bara handlar om information och hur den lagras och överförs eller teknisk implementation, utan även om vad användare behöver samt hur verksamheten säkras utifrån olika situationer som kan uppkomma kring livscykeln när man använder en molntjänst.  

Detta arbete befinner sig också i ett sammanhang där det finns en beställare och med projektledning. Arbetssättet passar bra in i agila former men fungerar även i mera traditionella, linjära projekt. Att adressera en helhet i nivåer stöttar också i att ta fram underlag för planering och riskbedömning, särskilt scenariobaserad sådan som ofta utgår från vad användare gör.  

Beskrivningen i denna artikel ligger på en strategisk nivå. Hur man sedan utför de olika delarna praktiskt, analyserar, beskriver, verifierar, beror på typ av arbete och hur man gör i den verksamhet där man arbetar. Framför allt också utifrån de roller som finns i verksamheten, arkitekter, tjänstedesigners och kompetenser inom säkerhet och systemutveckling. En bra fortsättning för att få sådant här arbete på plats är att hämta inspiration ifrån utforskande arbetssätt från designrörelsen, som också utgår från syfte och behov och hela tiden provar slutsatser 

Verktyg och resurser 

Verktyg och resurser finns i stor omfattning och det som erfarenhetsmässigt fungerar och som brukar användas inom IT-arkitekturarbete är förmågebaserad kartläggning, process- och informationsmodeller. Dessa använder ofta formella modellspråk, exempelvis Archimate. På nivåerna kring lösning används ofta informations-, integrations- och lösningsmodeller för att detaljera. För egenskaper kan man söka på färdiga listor för ”system quality attributes”, hos b.la Wikipedia. Resurser inom IT-arkitektur finns hos svenska www.iasa.se samt Iasa International iasaglobal.org.  

Om man vill veta mer kring att bedriva arbetet enligt utforskande och ansatsdrivna arbetssätt så beskrivs det bra i böckerna ”Lean UX” av Josh Gothelf och Josh Seiden och ”Continous discovery habits” av Teresa Torres. Flera bra verktyg finns i metodiken ”Design sprint”, ursprungligen framtagen av Jake Knapp,och från SKR ”Innovationsguiden.se”.  

För att stärka samarbete kan den övergripande modellen skrivas ut och hängas på en vägg, whiteboard eller liknande och där kan man fästa Post-It:s, anteckna, rita eller skriva ut modeller för att driva arbetet. Digitala verktyg som fungerar bra med detta sätt att arbeta och visualisera är t.ex. Visio, Miro, Milanote och Draw.io. 

Detta arbetssätt beskrivs och utvecklas av artikelförfattaren, mera specifikt för informationsförvaltning, på siten www.informationsforvaltning.com och för Design av Digitala Produkter, på siten www.attt.se som författaren driver. På dessa webbplatser finns fördjupningar kring metodik och nedladdningsbara modeller i olika format. 

Mats Andréasen är verksamhetsarkitekt i Göteborgs stad. Han är IT-arkitekt med erfarenhet från offentlig förvaltning och industri b.la. telekom och medicintekniska produkter. Engagerad i information och dokumentförvaltning genom uppdrag i Näringslivets Arkivråd. Också engagerad i att etablera IT-arkitektur, designtänkande och agila metodiker genom engagemang i Sveriges IT-arkitekter och olika Meetup-forum.