Lektion 8: Hvordan kommer man i gang med de første forsøg?

Nogen gør det i stor skala, som f.eks. Bane Danmark med mediedækkede workshops med topchefer og potentielt titusindvis af daglige brugere – andre tager den mere med ro, når de skal i gang med cloud computing. Men hvad er den rigtige måde at gribe det an på? Det er det naturligvis ikke muligt at give et entydigt svar på, men i denne lektion gennemgår vi nogle naturlige trin, man bør eller kan gå igennem i forbindelse med etableringen af et første forsøg.

Som med så meget andet – ikke mindst it-relateret – handler etablering af det første cloud computing-projekt om god forberedelse. Faktisk mener OVUM, at de samlede omkostninger til cloud computing-projekter kan være lige så store, som ved traditionel systemimplementering, bl.a. på grund af de store omkostninger til forberedelse. På den anden side: det koster også pænt med tid, penge og kræfter at etablere en ny driftsaftale hos en af de traditionelle hostingleverandører, så mon ikke, der stadig i mange tilfælde er en positiv business case.

Hvilke konkrete gevinster for vores forretning kan cloud computing give?

Først og fremmest skal en cloud computing-satsning naturligvis give mening forretningsmæssigt – hvad enten man er offentlig eller privat. Man kan f.eks. starte med at se på følgende spørgsmål:

  • Har vi brug for at flytte større eller mindre dele af vores it-portefølje til en web-baseret platform? Dette kan være begrundet i ønsket om at tænke (flere eller bredere) selvbetjeningsløsninger som en del af virksomhedens arbejdsprocesser
  • Har vi brug for den fleksibilitet i forbrugsafregning, som cloud computing kan give? Dette kan være begrundet i, at der er periodevise udsving i belastningen af virksomhedens it-infrastruktur, som gør det uforholdsmæssigt omkostningskrævende at have en løsning stående året rundt, som tager højde for peak perioder i belastningen
  • Har vi brug for driftsaftaler, der muliggør meget hurtig skalering? Horisontal skalerbarhed kan være en forudsætning for hurtig deployering af nye løsninger eller hurtig oprettelse af test- og udviklingsmiljøer, mens vertikal skalering kan være forudsætning for udbygning af eksisterende løsninger, enten med mere funktionalitet eller med udvidet driftsunderstøttelse

Er der udsigt til, at en cloud-satsning kan give forretningsmæssig mening, kan man fortsætte med de efterfølgende spørgsmål.

Er dette et forsøg eller en reel implementering?

Næste spørgsmål, man skal stille sig, er, om der er tale om et forsøg, hvor organisationen skal blive klogere på teknologier, forretningsmodel osv., eller om der er tale om en reel implementering. Dette har stor betydning for, hvilke succeskriterier, der er relevante.

Nogle mulige succeskriterier ved et forsøg:

  • De rette folk er involveret og drager nyttig erfaring af forsøget
  • Som organisation får vi en grundlæggende forståelse af tekniske risici, muligheder og omkostninger
  • På baggrund af forsøget kan vi se, hvor i vores eksisterende systemlandskab, vi skal lave justeringer for bedre at udnytte potentialet
  • Det forretningsmæssige potentiale står tydeligere for organisationens ledelse
  • Evalueringen af forsøget er skarp nok til at kunne danne grundlag for reelle implementeringer

Nogle mulige succeskriterier ved en reel implementering:

  • Implementeringen lever op til vores forventninger vedr. tid, ressourcer og kompetencer
  • Løsningen performer som forventet
  • Leverandøren opfylder de nødvendige krav til sikkerhed, dokumentation og fleksibilitet
  • Cloud platformen (hvad enten, det er infrastruktur, platform eller software, der leveres) er let at justere løbende
  • Løsningen lever op til vores krav til sikkerhed

Dertil kommer naturligvis en stribe konkrete succeskriterier, der er defineret af den faktiske løsning, der skal sættes i drift. Disse succeskriterier ligner meget de ’sædvanlige’ fra mere traditionelle implementeringer, men det er vigtigt at have øje for, på hvilken måde, den anderledes leveranceform spiller ind.

Er vores data og back-end klar til cloud computing?

I mange private som offentlige virksomheder er datakvalitet og it-infrastruktur historisk betingede. Data formeres og anvendes i de konkrete kontekster, de forretningsmæssigt hører hjemme i, og it-arkitekturen afspejler ofte en investeringspolitik over årene, der kan være meget konjunkturbestemt.

Er planen at lægge store systemer eller komplekse datastrukturer i skyen, er det næppe sandsynligt, at organisationen vil tage det, der findes i produktion i dag, og ukritisk transformere det til den nye leveranceform. Derfor er i det mindste en kritisk gennemgang af nedenstående spørgsmål anbefalelsesværdigt:

  • Er kvaliteten af de data, der skal flyttes i skyen, tilstrækkelig god, og hvis ikke, hvordan kan vi så forbedre den?
  • Er dataejerskabet veldefineret, og er dataejerne taget i ed?
  • Er metadata på plads i forhold til den forventede anvendelse af data, og hvis ikke, hvordan kan vi så tilvejebringe de manglende informationer?
  • Hvis der skal gennemføres transaktioner mellem skyen og den eksisterende it-infrastruktur, er backend så robust nok, og kan den skalere tilstrækkeligt og tilstrækkeligt hurtigt?
  • Har vi en tilfredsstillende sikkerhed omkring de dele af it-infrastrukturen, der skal eksponeres overfor skyen?

Dette er spørgsmål, man altid bør stille sig, ikke kun, når der skal introduceres cloud computing, men særligt med åbningen mod internettet bliver sikkerhedsaspektet understreget. Og samtidig vil en lancering af en cloud-satsning formentlig have et bredere formål end blot at afprøve teknologien. Derfor skal data og eksisterende it-infrastruktur naturligvis kunne stå model til en ny eller udvidet anvendelse.

Kan det betale sig?

Ja, også cloud computing-initiativer skal der laves business cases for. Det er klart, at et rent forsøg som nævnt vil have andre succeskriterier, og dermed vil business casen se anderledes ud. Samtidig vil der være væsentlig forskel på business casen for første cloud-projekt og for efterfølgende projekter, ikke mindst på grund af omkostningssiden. Det vil jo ofte være det første projekt, der trækker det helt store læs med forberedelse, analyse af data, drøftelser i forretningen, tilpasninger i it-arkitekturen, forsøg og afprøvninger osv.

Standardskabelonen for en business case kan være en god tjekliste for, hvilke aspekter, man skal huske at komme rundt om:

  1. Løsningsbeskrivelse
    1. Forretningsmæssigt omfang
    2. It-mæssigt omfang
    3. Interessenter
    4. Alternative løsninger
    5. Delprojekter
    6. Afhængigheder til sideordnede projekter
  2. Forretningsmæssige konsekvenser
    1. Økonomiske konsekvenser
    2. Økonomiske nøgletal
    3. Kvalitative gevinster
    4. Risici
  3. Implementering og opfølgning
    1. Implementeringsstrategi
    2. Milepælsplan
    3. KPI’er
  4. Ejerskab
    1. Projektejer og projektleder
    2. Leverandører
    3. Opfølgning på forretningsmilepæle
    4. Sponsorer
    5. Godkendelse

De forhold, der gør business casen for et cloud computing-projekt anderledes og måske sværere at lave, er bl.a. følgende:

  • Det er måske ikke klart, hvor mange brugere, der vil være på løsningen, og hvis afregningen baseres på f.eks. antal transaktioner, kan omkostningssiden være svær at estimere
  • Er der tale om platform-as-a-service, hvor afregningen typisk er baseret på et miks af front-end transaktioner, transaktioner på tværs af platformens komponenter og måske databasekald målt på antal og størrelse, skal man kende sin applikation rigtigt godt, for at kunne prissætte driften
  • Er det en eksisterende applikation, der skal lægges i skyen, behøver det ikke være særlig kompliceret at vurdere tilpasningsopgaven, da de fleste cloud-leverandører anvender kendt teknologi som basis for deres infrastruktur og platform. Men det er ikke givet, at den driftsplatform, der forlades, uden videre kan nedlægges, måske fordi den indgår i andre dele af it-porteføljen, måske fordi der er kontraktuel binding på kapaciteten
  • Der kan være ekstra omkostninger forbundet med at indhente de nødvendige erklæringer om sikkerhed, overholdelse af lovning osv., der involverer revisorer og jurister

Bemærk, at der ikke er nogle af disse usikkerheder, der relaterer sig direkte til de forretningsmæssige gevinster og udfordringer. Dette er hovedsageligt fordi et cloud computing-projekt er en it-infrastruktur-øvelse, mens de forretningsmæssige overvejelser om gevinster, nye muligheder og omkostninger er knyttet til de indledende overvejelser om, hvorvidt organisationen overhovedet skal ’se den vej’.

Hvordan vælger man en leverandør?

Som omtalt i lektionen om sikkerhed i cloud computing, findes der flere rammeværker eller spørgeguider, der kan anvendes til valg af cloud-leverandør. Helt afgørende er det naturligvis, at det er en leverandør, man stoler på. Men tillid er godt – kontrol som bekendt bedre. Derfor bør vurderingen af leverandørerne også tage afsæt i den dokumentation, der kan stilles til rådighed – direkte fra hjemmesiderne, men også leveret fra leverandørernes globale eller danske hovedsæder, som særligt imødekommer virksomhedens behov.

På den anden side: det hjælper ikke meget at have valgt IBM som cloud-leverandør, hvis ens systemer er baseret på C#, som forudsætter en Windowsbaseret driftsplatform. Derfor skal vurderingen af sikkerhed og dokumentation naturligvis være tæt forbundet med analysen af den platform, leverandøren stiller til rådighed.

Men kommer dette ikke i første række? Nej, ikke nødvendigvis: da cloud-leverandørernes platforme varierer, også indenfor den samme grundlæggende teknologi, kan det godt give mening at vælge en leverandør, hvor der kræves lidt mere tilpasning i det system, der skal lægges ud, såfremt netop den leverandør har en særligt overbevisende sikkerhedsmodel – eller f.eks. har et driftscenter i det rigtige land.

En væsentlig overvejelse i ethvert valg af leverandør er, hvordan man kan komme ud af aftalerne igen. Med cloud computing er dette i sig selv ikke vanskeligt. OK, der kan være en bindingsperiode, men hvis ingen bruger systemerne og man tømmer databasen, er omkostningen formentlig beskeden. Derimod kan der være en udfordring med, hvor ‘portabel’, data og systemer er. Har man først fået et system til at køre hos én leverandør, kan det være både tidskrævende og dyrt at skulle flytte det til en anden, også selvom den nye leverandør tilsyneladende tilbyder en identisk platform. Dette kan skyldes både den grundlæggende infrastruktur hos leverandøren, små variationer i, hvordan platformen er implementeret og forskellige subversioner af f.eks. middleware.

Én af de risici, der omtales i lektionen om sikkerhed i cloud computing, er, at cloud-leverandøren kan lukke. Ud over, at det kan være besværligt og dyrt at skifte leverandør, indebærer dette også en risiko for decideret datatab. Nogle iagttagere mener sågar, at man aldrig skal basere sig på blot én cloud-leverandør, men have minimum to i spil. Dette ville man næppe gøre i en traditionel hostingform, så måske er det ikke strengt nødvendigt med cloud-leverandører heller, men under alle omstændigheder kan det være klogt at foretage en modenhedsvurdering af leverandøren. Er det én, man kan forvente at se på markedet om 10 år? Har leverandøren et solidt fodfæste på andre områder af it-markedet? Er leverandørens forretningsprocesser på andre områder anerkendte og måske endda markedsledende?

Som nævnt i indledningen er der intet, der slår god forberedelse. På den anden side kræver det at tage ny teknologi i brug ofte både mod og vilje til at være banebrydende. Dette er ikke nødvendigvis en egenskab, man værdsætter i offentlige institutioner, men i mange virksomheder er det en forudsætning for udvikling og fortsat indtjening. Og dog – i mange offentlige virksomheder har man mulighed for at eksperimentere mere, end i bundlinjefikserede private virksomheder, hvis man kan overbevise ledelsen om, at der er potentielle fordele for arbejdsprocesser og ressourceudnyttelse.

Hvilke argumenter, der er bedst, og hvad der skal til for at få åbnet dørene for cloud computing, er imidlertid helt afhængig af den enkelte institution, dens ledelse, kultur, opgaver, medarbejdere og modenhed. At cloud computing er kommet for at blive – under den ene eller anden form – er der næppe tvivl om. Stort set alle iagttagere er enige om, at det kun er et spørgsmål om, hvor hurtigt det kommer til at gå, og hvilke teknologier, der bliver dagsordenssættende. Og dét kan kunderne – offentlige som private – i høj grad være med til at afgøre.

Dansette