anders lisdorf bloghoved

Eksperimenter dig gennem skyerne

For mange er vejen ind i cloudcomputing ikke et spørgsmål om et alt eller intet direkte spring, men nærmere et spørgsmål om sondering af terrænet. Nogle organisationer kan have brug for at gå mere forsigtigt til værks, fordi de har meget specialiserede eller følsomme løsninger med konfidentielle eller følsomme data. Det kan også skyldes, at organisationen bare ikke er så vant til nye måder at arbejde på.

Der kan kort sagt være mange gode grunde til at være forsigtig. Men derfor kan man jo godt stadig have en vis form for interesse for de potentielle fordele ved cloud. Derfor er problemet, hvordan man kan bevæge sig hen imod cloud uden at bruge for store ressourcer og uden for store forpligtelser i investeringer og ressourcer.

Svaret er, at man kan prøve sig frem på forskellige måder. Generelt er det en god ide at etablere en prøvekonto hos en af de store cloududbydere, som man antager kan opfylde de fleste krav. Denne konto og alt, hvad der bygges under den, skal bare være en ø, og alt, hvad der ligger i den, skal have status af testmiljø. Det er vigtigt ikke at blive forledt til at tro, man kan hæve noget til produktion, for det kræver helt andre strukturer omkring infrastruktur, design, brugerstyring og sikkerhed. Disse strukturer kræver en del arbejde at sætte op og konfigurere, hvorfor det er bedre at lade være, hvis man bare vil eksperimentere lidt.

Udfør styrede POC

Måden at gøre det på er ved at etablere Proof of Concepts (POC), det vil sige kørende løsninger, der viser, at et givet set up er funktionsdygtigt. Desværre går mange POC galt af forskellige årsager, blandt andet fordi man ikke får dem gjort færdige, ikke har noget klart mål med, hvad man vil, eller glemmer at dokumentere læringen. Der er ikke nogen fast regel for, hvordan en POC skal forløbe, men jeg har igennem årene udført en del af dem og fundet, at følgende, simple guidelines er gode til at styre ens POC og sikrer, at man får den værdi, man har brug for.

Husk på,, at C’et i POC står for concept, hvilket betyder, at man faktisk skal have en ide om, hvad man prøver at opnå. Det er ikke nok bare at sidde og klikke rundt. Det kan give noget at logge ind og se hvilke knapper der er at skrue på, men man får ikke nogen reel forretningsmæssig effekt, medmindre man opsætter nogle konkrete mål, som man vil opnå. Det hjælper at tænke på en POC som et videnskabeligt eksperiment. Her har man en hypotese, f.eks. “Vi kan flytte vores databaser til cloududbyderen billigere med samme eller bedre Service Leel Agreement og svartider”. Denne hypotese skal så operationaliseres, hvilket typisk kræver flere forskellige skridt.

Det er derfor godt at have en række hovedmål, som man arbejder på at vise, man kan opnå. Her er en simpel liste fin. Hver linje er en beskrivelse af et postulat, som man vil teste. Det kan være, at man gerne vil vise, dels at man kan opsætte en SQL-serverdatabase, og dels etablere forbindelse til den fra firmaets netværk. Det er to fine mål, som ikke er for simple eller komplekse og vil have en reel effekt, hvis man kan vise, at det kan lade sig gøre. Her er det en god ide - ligesom med almindelig test - at man allerede har tænkt over konkrete scenarier, såsom hvilke data, hvilke servere, databaser osv. man vil bruge. Det sænker hastigheden og reducerer succesraten, hvis man først midt i POC’en står og prøver at finde ud af det.

Men udover disse hovedmål er det en god ide at have en liste af “stretch goals”; det vil sige noget ekstra, man gerne vil vise, hvis man får tid dertil, eller det viser sig let at prøve det. Disse har mere karakter af “nice to have”, men er vigtige, fordi hele formålet er at udforske. Man skal selvfølgelig ikke forfølge disse i stedet for hovedmålene.

Forankring i et team

Det er også en god ide at forankre POC-arbejdet i et team af interesserede medarbejdere, helst fra forskellige afdelinger. Teammedlemmerne skal være nogle, som i forvejen er nysgerrige omkring det, fordi der er en vis indlæringskurve, hvor man skal prøve sig frem. Når man har fundet sit fokus, er det bare at prøve at følge leverandørens vejledninger, tutorials. Ofte har leverandørerne også sponserede træningssessioner og webinars, som normalt er af høj kvalitet. Derfor bør man orientere sig i deres udbud. Det er væsentligt hurtigt at finde frem til supportfora, hvor man kan stille spørgsmål. For der kommer spørgsmål, og det er centralt for eksperimentets succes, at disse spørgsmål bliver afklarede.
Derfor kan det også være en ide at hyre en erfaren konsulent med bred erfaring indenfor den valgte cloududbyders platform. Ved at have en erfaren ekstern konsulent til at deltage vil sandsynligheden øges for, at man får gennemført sine eksperimenter og opnår den nødvendige læring og hands-onerfaring med platformen.

Næste skridt

Når man har gennemført de nødvendige eksperimenter, bør man ideelt set lukke kontoen og starte forfra i den retning, man har brug for. Her kan andre mønstre som Lift and Shift, Off Load, Gradvis Ændring komme i betragtning. For at vælge det rigtige mønster skal man huske at bruge sin nyfundne clouderfaring sammen med viden om firmaets situation og strategiske målsætning. Denne har en væsentlig indflydelse på, hvilket mønster det kan blive relevant at forfølge fremover.

Kommentarer (0)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize