Är molnet mer farligt eller mer viktigt för det offentliga Sverige?

Vad är egentligen molnet?

Till att börja med ska vi titta på den definition av moln som jag använder mig av. För mig är molnet nämligen inte främst en plats eller en teknologi, utan ett sätt att förhålla sig till och konsumera IT-tjänster på.

En molntjänst är en väl paketerad funktion som produceras på en delad plattform och som är brett tillgänglig, typiskt över internet. Tjänsten ska kunna styras med självbetjäningsfunktioner, gärna med möjlighet till automation (via API). Tjänsten ska vara elastisk i den bemärkelsen att den ska kunna skalas upp och ned utan att behöva beställa eller investera i ytterligare utrustning. På samma sätt förväntar jag mig även kunna mäta min förbrukning och bara betala för det jag använder.

Det här är inte min definition. Den kommer från det amerikanska standardinstItutet NIST, och fungerar bra för att beskriva de principer som gäller både för tjänster från globala aktörer som AWS och Microsoft, men även mindre lokala och nischade aktörer som exempelvis Telia Cygate själva.

Nu är det kanske givet är min ståndpunkt är att dessa molntjänster är viktiga för vår möjlighet att digitalisera vår offentliga verksamhet. Det är framförallt tre saker som jag vill lyfta fram:

1. Molntjänsterna demokratiserar IT-utvecklingen. Ny teknik och innovation görs tillgänglig så att i princip alla med ett kreditkort och en internetanslutning får tillgång till dem. Tidigare har bara stora företag och organisationer haft råd att investera i kunskap och teknik för att kunna tillgodogöra sig värdet av detta. Men nu kan vem som helst skapa ett konto och få tillgång till maskininlärning, bild- och textanalys, extrem beräkningskapacitet och näst intill oändlig lagring.
2. I förlängningen av demokratiseringen hittar vi fokus. När vi inte längre behöver lägga tid på att få den grundläggande tekniken att fungera, och kan konsumera den som ren funktion, kan vi istället fokusera på vår kärnverksamhet och dess syften och mål. Och visst är det bättre om en lärare kan lägga mer tid på att lära våra barn att läsa och räkna eller nya sätt att inspirera till eget lärande hos barnen istället för att lägga sin tid på att anpassa sig till och administrera sina IT-verktyg.
3. I en värld där vi förväntar oss att få det vi vill ha, när vi vill ha det, behöver vi ha ett högt tempo på vår förändring. Många molnekosystem är i sig en produkt av detta och präglas i många fall av en extremt hög förändringstakt. Jag har sett siffror på att AWS hanterar uppemot 50 miljoner kodsläpp per år. Något som innebär att vi behöver teknik och arbetssätt som tillåter en hög automation och standardisering. Man brukar tala om DevOps och Continous Delivery, som är just principer för att kunna jobba mer agilt och släppa lös innovationskraften i verksamheten.

Men hur går det för oss i Sverige då? Vi är ju ett ingenjörsfolk som trots eller kanske tack vare vårt avsides läge och karga klimat länge har legat i industrialiseringens framkant. 2018 rankade Bloomberg Sverige som nummer två i världen i deras innovationsindex och vi har fler så kallade Unicorns per capita än de flesta andra. Men tittar vi på samma siffra nu, så har vi halkat ner till en inte lika hedrande sjunde plats. Och utan att djupdyka i analys huruvida det är vi som halkar efter eller om det är de andra som kommer ikapp, så kan vi konstatera att Sverige under de senaste åren mött en hel del hinder för hur vi kan ta till oss och skapa värde från den teknikutveckling som sker. Jag brukar bryta ned dessa hinder i tre ”L”:

Latency

Latency är den rent tekniska aspekten av att flytta produktionen av våra IT-tjänster någon annanstans. Det finns en fysisk begränsning i ljusets hastighet som innebär att stora avstånd och många nätverkshopp gör att vi får fördröjningar som kan vara skillnaden mellan en helt ok och en fullständig oacceptabel användarupplevelse. Det här kräver dels att vi bygger om och anpassar våra system, eller håller oss inom ett och samma ekosystem. Men vi ser även att de stora molnaktörerna etablerar sig i Sverige, vilket kommer att göra detta till ett något mindre problem framöver.

Legacy

Legacy, eller vårt arv. IT är inget nytt för de flesta och det finns redan en stor mängd system och information som kanske inte rimmar så väl med den nya tekniken och arbetssätten. För detta handlar inte bara om gammal och inkompatibel teknik. Det handlar minst lika mycket om hur vi arbetar, mäter och fördelar ansvar inom organisationen.

Legal

Legal, eller den legala aspekten är den som kanske har fått mest uppmärksamhet de senaste åren. Nya lagar som GDPR och NIS sätter tuffa ramar för att vad vi får göra. Inte minst i offentliga och samhällsviktiga verksamheter. För att göra det än mer komplext, så är det inte bara vår egen lagstiftning som blir gällande när vi ska flytta ut information i molnet. Den amerikanska lagen CloudAct har skapat mycket osäkerhet. Ska vi hantera uppgifter som röjda i samma ögonblick de landar i en tjänst som har kopplingar till amerikanska bolag, oavsett var i världen de finns? Och det är just den här osäkerheten som skapar problem. Det saknas än så länge konsekvensanalyser och prejudikat som kan guida verksamheter rätt.

Så här långt verkar molnet vara både nödvändigt för att kunna utveckla verksamheten i linje med förväntningar från kunder, medborgare och medarbetare, och samtidigt osäker mark förenat med stora risker. Men det finns saker vi kan göra för att vi ska kunna våga ta små Iterativa steg i rätt riktning.

Att närma sig verksamheten

Det första vi behöver göra är att lära känna verksamheten. Arbetet med It måste genomsyras av det övergripande uppdraget eller målet, och det är detta som ska styra medlen. It behöver gå från att vara reaktivt, granskande och styrande, till att vara en integrerad del i verksamhetsutvecklingen. Det finns många skolor och modeller för detta. Ett mycket inspirerande exempel som jag hört om är Norrköpings Kommun som har gjort ett skifte mot detta sätt att arbeta.

Det andra handlar om att vi behöver se över vilken information vi hanterar. Att bara proklamera att ”molnet inte är säkert” är att göra det lite väl enkelt för sig, eller kanske tom att ”ropa varg”. Vi behöver titta på vilken information som faktiskt hanteras. Inom den offentliga verksamheten finns det absolut information som ska hållas bakom lås och bom för att skydda individer och samhälle. Men vi har även andra uppgifter som kan hanteras mer öppet, om än under kontrollerade former. I många fall ser vi idag dessutom hur allt fler jobbar med att avidentifiera data innan det skickas till en molntjänst för att kunna nyttja exempelvis maskininlärning för att hitta misstänkta bedrägerier i en stor mängd banktransaktioner. Molntjänsten skapar markörer för de transaktioner som verkar suspekta som sedan kan appliceras på grunddatat som aldrig lämnat organisationens trygga famn.

Plocka ner molnet

Skulle det nu vara så att vi står med en verksamhet som inte vill annat än att jobba enligt de principer och tekniska förutsättningar som de stora molntjänsteleverantörerna erbjuder, men att samtidigt informationen som ska hanteras inte på något sätt får släppas utan kontroll.

Då finns möjligheten att plocka ner molnet på marken. Leverantörer som Microsoft (Azure Stack), AWS (Outposts) och Google (GKE On-Prem) erbjuder idag möjligheten att exekvera deras ekosystem av tjänster lokalt i ett eget eller i en driftpartners datacenter. Det är ett effektivt sätt att skydda informationen från utländsk lagstiftning eller högljudda grannar (så kallade noisy nighbours) som kan påverka upplevelsen. Ofta handlar det om en delmängd av tjänsterna (som förvisso löpande blir fler och fler), och givetvis inte i samma skala. Men det är ändå ett sätt att kunna dra nytta av teknologin och arbetssätten.

Dock är det viktigt att börja i rätt ände. Vi pratar inte här om en ny generations virtualiseringsplattform för IaaS. Det finns gott om bättre och mer kostnadseffektiva alternativ för dina VM:ar. Utan det handlar om att kunna erbjuda molnets fördelar som konsumtionssätt och innovationsplattform men i lokal regi. Eller som jag brukar säga: First you Azure, then you Stack

Resan är målet

Man brukar ofta relatera till molnresan, som att det skulle vara en resa som har ett mål och ett slut. Men nu om någonsin gäller den gamla klyschan att ”resan är målet”. När vi förändrar i små och täta iterationer behöver vi bygga för att kunna förändra. Det här brukar refereras till som att ha ett agilt arbetssätt och syftar till att våra vägval ska kunna anpassas beroende på vad som gäller just nu. Vi kanske inte tolkar alla behoven rätt från början, ser oväntade utfall av det vi gör eller så dyker det helt enkelt upp nya behov längs vägen.

Så bygg för förändring och våga förändra. Att riva och bygga upp på nytt gör att vi inte fastnar i gamla lösningar som med tiden blir allt svårare att förändra (ni minns väl det andra L:et?).