Molntjänster för verksamhetsnytta: Beslutsträd, del 2

Den här andra delen (av fyra) handlar om formuleringen av en teknikpolicy avseende molnet. Det finns stora skillnader i mognadsgrad för alla våra organisationer. Många är föregångare med formulerade visioner, strategier och policies avseende IT-användning, oavsett vilken part som driftar/leverar tjänsterna. De organisationerna har även avsatt återkommande revisioner av sina styrdokument för att på så vis ständigt skruva till lösa skruvar. Det kostar givetvis att ligga i framkant och ha rigorösa processer, men för föregångarna skulle alternativet kunna vara förödande för fortlevnaden. På andra sidan av skalan finns de organisationer som driver IT mest som en serie slumpvisa konsekvenser, utan någon som helst styrning. Det som jag anser är häftigt med brytpunkten vi står inför med molnen är att alla på skalan har något att hämta hem. Ta bara det senare exemplet: I en miljö som växer slumpvis uppstår förr eller senare ett licenskaos som kostar en massa kronor. Dessutom uppstår en ineffektivitet i informationsbehandlingen och mycket tid/möda läggs på att hitta information, istället för att vara produktiv med den senaste informationen. Säkerhetsriskerna är överhängande. En kort strategisk genomgång av nuläge och en enkel formulering av teknikpolicy kan göra underverk och snabbt ge en kostnadsbesparing som gör hela övningen till en vinst.

Här kommer lite handfasta tips om en mall för en teknikpolicy.

Plattformen först

En bra början på arbetet kan starta med plattformen, eller grunden om så önskas. För att kunna göra några mogna överväganden beror plattformsarbetet på vilka applikationer som organisationen är beroende av. E-post, kundhantering, OLF-system, samarbetsplattformar, webbpublicering/intranät, kontorsapplikationer, arbetsflödeshantering och en hel mängd andra tillämpningsområden kan vara avgörande för organisationen helt beroende på storlek, verksamhet, geografi med mera. Här finns det en poäng att rita upp organisationens informationsflöde för att därefter sätta rätt tillämpning mot relevant funktion. Det behöver inte vara superavancerat och ett enkelt exempel finns i bild 1.

Bild 1. En enkel skiss på flöden och horisontella stödfunktioner.

Nu har du kommit en bra bit på väg och kan då börja med att titta på operativsystemen som ska köras på servrar och klienter. För att skapa dig en automatiserad plattform med dynamisk hantering av resurser blir virtualiseringsmotorn enormt viktig. Därför är det kanske än viktigare att förstå vilken virtualiseringsplattform du vill satsa på och då ger sig valet av operativsystem på serversidan. Klientsidan är beroende av sättet du ska tillhandahålla verksamhetstillämpningar, lagring, nätåtkomst, fjärråtkomst och liknande funktioner. Hittills har debatten handlat om "tjocka" respektive "tunna" klienter, men nu har det utökats med virtualiserade klienter, mobila klienter och helt molnbaserade klienter. Den som har ett systemarv sedan tidigare behöver göra ett grundligt arbete för att satsa på rätt "häst". Den som inte har samma arv behöver ändå tänka igenom valet noggrannt.

Valet av databasmotor faller sig naturligt baserat på de tillämpningar man kör och den eventuellt egna utvecklingsplattformen som man utvecklar tillämpningar på.

Tänka i två led

I en ny och expansiv nisch, som molnen ändå måste anses vara, sker en massiv utveckling som ibland drar åt helt olika håll. I dagsläget sker en del insatser om att enas om vissa grundläggande standarder. Initiativen syftar till att skapa gemensamma gränssnitt för olika molnleverantörers tjänster så att deras kunder enkelt kan flytta information/tillämpningar mellan sig och leverantören, samt även kunna byta leverantör enkelt. Ditt arbete idag är att formulera hur din information hanteras logiskt och hur lagringsformaten ser ut. Syftet är att formulera kraven på dataformat, maskinimages, lagringsnät och applikationslogik så att du har full portabilitet och interoperabilitet. På så vis undviker du inlåsning till en specifik leverantör och säkerställer att din information kan tas hem smidigt och i nästa led på nytt läggas hos en annan leverantör.

Säkerhet i andra dimensioner

Nu har du kommit en så pass god bit på vägen att säkerhetsfrågorna naturligt har väckts i tanken. Den grundläggande säkerhet du kommer att behöva handlar om att förstå vilken information som ska skyddas och i vilka nivåer. Det handlar om personinformation som måste skyddas enligt lagstiftning, information som går under specifika regleringsramverk och organisationskritisk information. Genom din kartläggning av applikationer, datalagring, databas, OS, virtualiseringsplattform, klientplattform och annat som du har tydliggjort finns nu en tydlig säkerhetskarta. Utifrån den skapar du en policybeskrivning och kravställan på skyddsåtgärder.

De tillämpningar och information som du hanterar i egen regi behöver skyddas i flera nivåer, så kallad säkerhets på djupet. Den funktionalitet som du lägger ute i molnet kopplar du ett antal Key Performance Indicators mot och ställer de kraven på leverantören. Allt görs givetvis med ett avtal som tillåter dig att följa upp och revidera hur väl dina KPIer efterlevs. En viktig del är att säkerställa att du får kontinuerlig tillgång till systemloggar på de system som behandlar din information.

Slutligen gäller frågan om hanteringen av behörigheter mellan dina tillämpningar som snurrar i egen regi och de tillämpningar som du kör i molnet. Personligen är jag helt övertygad om att så kallad "claims-based" identity management är enda hållbara vägen framåt. Det hela handlar om att skapa ett auktoritativt system som säkert identifierar en användare (eller applikation) och utfärdar en resehandling liknande ett pass som användaren (applikationen) kan presentera vidare för att få tillträde.

Slutligen vill jag ge dig ett råd: Du kommer att få höra saker som att "molnet är osäkert" och att "du inte kan lita på leverantören". Givetvis är det ytterst viktigt att kolla upp den du ska göra affärer med. Men, när det kommer till osäkerhet är det många gånger så att molnleverantörens system är bättre säkrade än dina egna. De realistiska riskerna ligger på ett annat plan.