Scenario - att avveckla en tjÀnst

Detta scenario illustrerar hur man kan nÀrma sig hanteringen av att avveckla en molntjÀnst som verksamheten anvÀnder. Scenariot innebÀr att man har ett verksamhetssystem med viss information. Vad hÀnder nÀr denna avvecklas och man byter till ny leverantör. Hur skall informationen hÀmtas och överföras, hur adresserar man sÀkerhet i ett brett perspektiv inklusive att informationen i det nya systemet Àr anvÀndbar. Detta scenario anvÀnds för att exemplifiera. SÀttet att gÄ tillvÀga Àr oavsett tjÀnst och fungerar Àven nÀr man bygger en egen produkt, om man ser produkten och utvecklingsteamet som 'Leverantör'.

Inledning

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. Hur gör man om man vill ta hem sin 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 borde inte vara sÄ svÄrt. 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?

Helhetsperspktiv pÄ molntjÀnst
 

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 att man vill ha en lokal backup. UtifrĂ„n och utifrĂ„n detta det kan man börja förstĂ„ vad det innebĂ€r att ta hem informationen. 

’Vad Ă€r det verksamheten vill ha 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. Ett bra sĂ€tt att beskriva detta Ă€r att tĂ€nka i förmĂ„gor, som Ă€r en sammanfattande nivĂ„ ovanför processmodellering och som inbegriper anvĂ€ndare, vad dessa gör, information som behandlas och i vilka system. Exempel pĂ„ övergipande förmĂ„gor Ă€r 'Inköp' eller 'Utveckling' och dessa kan sedan brytas ner och detaljeras i delförmĂ„gor som 'Avtalshantering'.

’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, d. 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 utifrĂ„n 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 ocksĂ„ om informationen Ă€r samlad inom molntjĂ€nsten alternativt lagras eller hĂ€mtas frĂ„n andra tjĂ€nster. Detta berör 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 vad som hĂ€nder vid driftstörningar? Hur lĂ€nge kan kan tjĂ€nsten kan 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 dessemellan 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 det vid en migrering sĂ„ att informationen sĂ€kras mot felhantering? En sista egenskap att titta pĂ„ rör integration med andra system vi anvĂ€nder. I i vĂ„rt tĂ€nkta fallexemplet 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’. HĂ€r Ă€r vi nere pĂ„ 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, men ocksĂ„ för att informationen ska vara Ă€r förstĂ„elig och anvĂ€ndbar för verksamheten eller en ny tjĂ€nst 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. 

Ett utforskande arbetssÀtt

Ett utforskande arbetssÀtt

Ett sÀtt att anvÀnda det helhetsperspektiv som beskrivs ovan Àr att arbeta utforskande. Detta beskrivs i modellen ovan. Syftet Àr att arbeta i olika steg som leder frÄn vad man vill uppnÄ och verifierar detta genom praktiska prov, och som arbetar i flera iterationer utifrÄn tillgÀnglig tid och resurser.

Det börjar med ’Vad’. Att ringa in vad det Ă€r man skall lösa, det kan röra vision och syfte men Ă€ven detaljer som att förstĂ„ ett visst anvĂ€ndarfall eller en teknisk lösning.

NĂ€sta steg ’Hur hĂ€nder det’ handlar om projekt, vilka roller som Ă€r med, vad behöver vi för resurser för att lösa det vi ringat in, vilken tid har vi.

Steget ’Hur’ handlar om analys, att samla in bakgrundsmaterial, att se hur andra gjort, intervjuer eller att lĂ€sa in sig pĂ„ hur tjĂ€nsten fungerar. Detta arbete har tvĂ„ distinkta faser, en divergerande del dĂ€r vi letar brett, samlar material och en konvergerande dĂ€r vi hittar mönster, klustrar och sammanstĂ€ller, analyserar.

Det sista steget Ă€r att prova, sĂ„ praktiskt som möjligt. Detta har ocksĂ„ tvĂ„ faser. Dels att beskriva hur vi kan prova, vad behöver vi, skall vi utgĂ„ frĂ„n en mockup, wireframe eller en mera fungerande prototyp. Detta Ă€r kopplat till ’Vad’ och ’Hur’ genom att beskriva och formulera som en ansats, att vi antar att en insikt eller förstĂ„else vi gjort kring det vi skall lösa kan provas genom ett experiment. Den andra fasen Ă€r att prova ansatsen, att utföra sjĂ€lva experimentet.

Detta arbetssĂ€tt kvalitetssĂ€krar arbetet med att förstĂ„ information och arbetssĂ€tt i vĂ„r tjĂ€nst och verksamhet. Genom att prova praktiskt kan vi hela tiden sĂ€kerstĂ€lla att vi Ă€r pĂ„ rĂ€tt spĂ„r, att vi löser rĂ€tt problem och vi skapar Ă€ven framdrift genom att minska risken för att fastna i utredningar och det breda anslaget i den divergerande fasen ger insikter om förhĂ„llanden som vi kanske missat annars. Det adresserar ocksĂ„ det sĂ€kerhetsmĂ€ssiga arbetet mera direkt genom att sĂ€tt att prova kan vara vad en sĂ€kerhetsroll föreslĂ„r, hur man klassificerar information eller sĂ€krar dess riktighet. 

Ett inkrementellt arbetssÀtt

Att arbeta utforskande passar ocksÄ ihop med att arbeta inkrementellt. Att börja med det övergripande som sedan fördjupas och detaljeras och förfinas. Detta kan beskrivas utifrÄn den övergripande modellen med sina olika nivÄer och perspektiv, samt de olika stegen i det utforskande arbetsÀttet. Detta kan beskrivas visuellt som i figurerna nedan, och passar bra för att skriva user stories, de kortfattade beskrivningar pÄ verksamhetens sprÄk och utifrÄn anvÀndares behov, som agila metodiker anvÀnder.

Ett tidigt inkrement
Modellen ovan visar hur det utforskande sĂ€ttet kombineras med modellen kring helhetsperspektiv i ett tidigt skede av arbetet. Den illustrerar hur vi börjar med ’Vad’ vi skall göra. LĂ„t sĂ€ga att den molntjĂ€nst som vi anvĂ€nt som exempel stĂ„r i begrepp att ersĂ€ttas, vi behöver ta hem informationen sĂ„ den kan migreras till en ny tjĂ€nst. Detta Ă€r ’Vad’ och det utgĂ„r ifrĂ„n ’0’ Vad verksamheten och tjĂ€nsten gör tillsammans’, pĂ„ en nivĂ„ kring syfte och mĂ„l som Ă€r att vi skall avveckla en tjĂ€nst för att ersĂ€tta med en annan. Det Ă€r ett tillrĂ€ckligt scope för ett första inkrement. ’Hur hĂ€nder det’ handlar i detta fall om att hitta de roller som har intresse och nĂ„got att tillföra pĂ„ denna nivĂ„, det kan vara bestĂ€llare, beslutsfattare men ocksĂ„ arkitekt och sĂ€kerhetsroller pĂ„ mera övergripande nivĂ„. 

NĂ€sta steg Ă€r ’Hur’. UtifrĂ„n ’vad’ och att det handlar om sĂ€kerhet sĂ„ kan vi börja lista aspekter som att informationen skall hanteras sĂ€kert. Men sĂ€kerhet handlar ocksĂ„ om att vi fĂ„r med all information och att den kan anvĂ€ndas pĂ„ samma sĂ€tt som tidigare, i en ny tjĂ€nst. Detta handlar dĂ€rför om förstĂ„else av hur verksamheten utför arbete med tjĂ€nsten. Vad verksamheten har för syfte och hur tjĂ€nsten möter detta. För att begrĂ€nsa och inte fastna i analys sĂ„ utgörs detta första inkrement av nivĂ„erna i (A) kring vad verksamheten vill med tjĂ€nsten och (Y) vad tjĂ€nsten erbjuder. Detta Ă€r den översta nivĂ„n pĂ„ ett sĂ€kerhetstĂ€nk som formulerar vad som skall kunna göras nĂ€r tjĂ€nsten Ă€r migrerad. FrĂ„n detta kan vi i ’Prova’ formulera hur vi kan testa detta. HĂ€mta informationen, simulera eller kanske prova i den nya tjĂ€nsten, att det fungerar som vi gjort tidigare. 

Ett senare inkrement

I modellen ovan illustreras en senare del av arbetet. I det tĂ€nkta scenariot, kan vi anta att nĂ€r vi tidigare utförde ’Prova’, sĂ„ anmĂ€rkte en anvĂ€ndare pĂ„ att Ă€ldre versioner av dokument inte fanns med i det vi hĂ€mtat hem. Vi hade bara fĂ„tt aktuella dokument. Vi fĂ„r gĂ„ tillbaka och lĂ€gga till denna insikt. Vi har redan tĂ€ckt in ’0’-nivĂ„n, det gemensamma hĂ„ller fortfarande. Men vi har gjort en insikt om hur verksamheten arbetar, emellanĂ„t behöver man alltsĂ„ hantera Ă€ldre versioner, nĂ€r nĂ„got gĂ„tt fel, nĂ€r man vill spĂ„ra Ă€ndringar, kanske finns Ă€ven andra anvĂ€ndarfall knutna till detta, som att kunna jĂ€mföra dokument.
Vi börjar dĂ€rför ’Vad’-steget med denna insikt och fortsĂ€tter arbetet utifrĂ„n A och B-nivĂ„erna och Ă€ven C kring de egenskaper vi vill ha. Vi tittar Ă€ven pĂ„ motsvarande nivĂ„ utifrĂ„n vad tjĂ€nsten erbjuder och i ’Prova’ testar vi om vĂ„r ansats hĂ„ller och vi sĂ€krat den information som behövs för att lösa Ă€ven versionshistorik och anvĂ€ndandet kring detta. 
En rad andra kombinationer finns givetvis, men principen Ă€r att ta arbetet i skikt och att driva mot praktiska prov. Detta gör att man i ’Vad’ behöver tĂ€nka igenom vilka nivĂ„er man verkligen behöver adressera. En annan iakttagelse Ă€r att i början av arbetet rör man sig mera pĂ„ 0, A och B för att förstĂ„ verksamheten och i senare skeden mera mot lösning pĂ„ C, D-nivĂ„erna. Dock, det Ă€r viktigt att hela tiden ha syfte och behov i Ă„tanke, att toucha in pĂ„ A/B, Y/X-nivĂ„erna. Samt att hela tiden adressera tjĂ€nsten pĂ„ Y
V-nivĂ„erna. Man kan ocksĂ„ med fördel ta vara pĂ„ kombinationer och mönster av hur man rör sig, och Ă„teranvĂ€nda inom verksamheten.

I ett sammanhang

Det arbetssĂ€tt som beskrivs hĂ€r Ă€r generellt men i det hĂ€r sammanhanget rörde det avveckling av en molntjĂ€nst. Det visar hur detta inte bara handlar om information och hur den lagras och överförs eller teknisk implementation utan ocksĂ„ om vad anvĂ€ndare behöver, hur verksamheten fungerar och livscykeln nĂ€r man anvĂ€nder en molntjĂ€nst eller annan produkt. 
Detta arbete befinner sig ocksĂ„ i ett sammanhang av bestĂ€llare och behöver samverka med projektledning kring hur arbetet bedrivs. ArbetssĂ€ttet passar bra in i agila former men fungerar Ă€ven i mera traditionella, linjĂ€ra projekt. Att adressera en helhet i nivĂ„er och pĂ„ ett utforskande sĂ€tt fungerar ocksĂ„ för att stötta i att ta fram underlag för planering och riskbedömning, sĂ€rskilt scenariobaserad sĂ„dan. 
Beskrivningen i denna artikel visar den mera strategiska nivÄn. Hur man utför de olika delarna, analys, beskrivningar, att prova beror pÄ typ av arbete och hur man gör i den verksamhet man arbetar och framför allt andra roller som arkitekter, tjÀnstedesigners och kompetenser inom sÀkerhet och systemutveckling.

Verktyg och resurser

De olika verktyg och resurser som behövs för ett sÄdant hÀr arbete Àr vad som beskrivs pÄ andra stÀllen pÄ denna site. Verktyg och sÀtt som att organisera enligt Liquid Canvas, att tÀnka utifrÄn 'Validerat lÀrande' och leda detta arbete via Inkrement, Moment och olika verktyg.

GenomgĂ„ende för detta sĂ€tt att arbeta Ă€r att anvĂ€nda sig av prototyper och modeller och sĂ„ fort det gĂ„r anvĂ€nda dessa som del av tidig, iterativ och inkrementell produktutveckling. Även att anvĂ€nda visuella och pĂ„tagliga leverabler, som whiteboards, utskrivna modeller och Post-its som man kan gĂ„ runt, enkelt samarbeta kring, eller prototyper i kartong, foamboard eller andra material och sĂ€tt. Modellerna fungerar ocksĂ„ bra i digitala verktyg som Visio, Miro, Milanote, draw.io och andra.

Modellerna ovan (för utskrift a3 landscape, canvasen portrait): tbd jpg och kommer Àven svg