Specialeafhandling: Cloud Computing I et teknisk og stratgisk perspektiv. Cloud computing - i et teknisk og strategisk perspektiv 7

Størrelse: px
Starte visningen fra side:

Download "Specialeafhandling: Cloud Computing I et teknisk og stratgisk perspektiv. Cloud computing - i et teknisk og strategisk perspektiv 7"

Transkript

1

2 Abstract The thesis explores the unique opportunities that cloud computing has brought to the delivery of IT-services, both from a technical point of view and as a new business model. Very few businesses use Cloud Computing today, and those that do are mostly the small and medium sized. Three businesses who uses Cloud Computing, have agreed to share their experiences and motives for doing so. These experiences, combined with theories within the fields of computer science, ITstrategy, business and Enterprise Architecture is used in an in depth analysis of Cloud Computing. The analysis is divided into four areas; Scalability, technical anatomy, economy and strategy. The number of larger enterprises that use Cloud Computing is very limited. This does not mean that it is not relevant to analyze how these enterprises can gain advantages from Cloud Computing. Many enterprises use Enterprise Architecture, to document and develop their use of IT to support the business needs. The initial steps of mapping the documentation of Enterprise Architecture and Cloud Computing, shows that the two are compatible. There are even areas, such as standardization and looser coupling between layers, where Cloud Computing and Enterprise Architecture gain mutual benefits. This means that new artifacts, describing virtual resources, will appear in the Enterprise Architecture documentation. The thesis finds that Cloud Computing enables the businesses to differentiate their use of IT, to focus on those parts that give a competitive advantage. A maturity model for Cloud Computing is presented. This model is divided into five phases with different characteristics, arguing that Cloud Computing often has a bottom-up effect in the businesses, which slowly gets more accepted as advantages are exposed. In later phases businesses use a hybrid between Cloud Computing and internal IT, where new systems often are established on cloud services, up to the total Cloud enablement phase, where all those IT-systems that can use Cloud services with advantage does so, no matter how business critical they are. The later phases are based upon, how we think the future for Cloud Computing will shape. In today s IT landscape, both Cloud Computing vendors and the potential customers are lacking readiness and maturity in some areas. This means that not only the vendors have to mature their services for the enterprise market, but also that the enterprises must qualify themselves and get ready to harvest the advantages of Cloud Computing.

3 Indholdsfortegnelse Cloud computing - i et teknisk og strategisk perspektiv 7 I. Indledning 7 Læsere og forudsætninger 9 Aktiviteter og medieomtale 9 II. Motivation og relevans 11 III. Hypen omkring cloud computing 13 IV. Problemformulering 16 V. Læsevejledning 17 Oversigt over specialets indhold 18 VI. Metode 19 Videnskabsteoretiske overvejelser 19 Arbejdsmetode 20 Empiri 20 Valg af teori 22 Kapitel 1 Baggrund og begreber Baggrund IT-udviklingen Computerindustrien opstår Time-sharing Fra mainframe til decentraliseret overforbrug Vision om en computer utility Fokus på infrastruktur Forretnings-IT i dag Enterprise arkitektur EA-modenhed Service-orienteret arkitektur Begrebsafklaring Definition af cloud computing Definition af utility computing Utility computing som forretningsmodel 39 Side 1

4 Utility computing som arkitekturdisciplin Traditionel IT-infrastruktur 42 Kapitel 2 Hvad er Cloud computing? Fra grid til utility computing Grid Computing Cloud Computing Hvorfor er cloud computing relevant? Realisering af cloud computing Virtualisering og load-balancing Cloud services Cloud service markedet Utility computing Software as a Service SaaS-arkitekturen Platform as a Service Cloud Computing overblik 61 Kapitel 3 Praktiske erfaringer med Cloud computing Empiri Sammenfatning af empiri Surftown PolarRose PodcastMachine Opsummering Analyse af cloud computing i praksis Kapacitetsplanlægning og skalerbarhed Hvad er skalerbarhed? Hvorfor har virksomheder brug for at skalere? Dynamisk skalerbarhed med cloud computing Opsummering Teknisk Anatomi Logik Filer 83 Side 2

5 Database Intern og ekstern kommunikation i systemet Opsumering Økonomi Overforbrug minimeres Lavere opstartsomkostninger Billig adgang til avanceret teknologi Billig adgang til kapacitet og regnekraft efter behov Opsumering Strategi Kontrol over miljø vs besparrelser igennem Economies of scale Lock-in Kan cloud computing sammenlignes med outsourcing? Make or Buy? Udbydernes udfordringer Cloud Computing i praksis - opsummering 104 Kapitel 4 Enterprise Cloud Computing Cloud computing og enterprise arkitektur? Cloud computing og EA 3 -kuben Løs kobling til services Dokumentation af cloud computing i arkitekturen Cloud computing og fremtidig arkitektur Threads Sikkerhed Standardisering Workforce Cloud Computing og enterprise arkitektur modenhed Opsummering 121 Kapitel 5 Cloud computing enablement Er cloud computing klar til masserne? Technology adoption Cloud computing som en disruptive technology Definition af cloud computing enablement 126 Side 3

6 5.3 Er virksomhederne klar til cloud computing? Cloud computing modenhed Modenhedsmodellen Fase 1 Ukendt behov Fase 2 Eksperimentel Fase 3 Forankring Fase 4 Hybrid Fase 5 Cloud-enablet Evaluering af modenhedsmodellen Cloud Computing for beslutningstagere Business case for cloud computing Survival of the fittest 134 Konklusion 136 Perspektivering 142 Litteratur 144 Bøger: 144 Artikler 145 Ikke brugt? 146 Bilag 148 Bilagsoversigt 148 Bilag 1 Oprindelig problemformulering 149 Bilag 2 - Interview med driftschef for Cohaesio, torsdag d. 14. August 150 Bilag 3 Interview med Jan Erik Solem fra Polar Rose 153 Bilag 4 Interview med Magnus fra Podcastmachine.com 156 Bilag 4 Interview med Magnus fra Podcastmachine.com 156 Bilag 5 Cloud Computing Taxonomi Bilag 6 Kronik om Cloud Computing 161 Bilag 7 Artikel i Prosabladet, august Side 4

7 Figuroversigt FIGUR 1 - EMERGING TECHNOLOGY HYPE CYCLE [GARTNER, JULI 2007] 14 FIGUR 2 - EMERGING TECHNOLOGY HYPE CYCLE [GARTNER, 2008] 15 FIGUR 3 CURRENT AND FUTURE ARCHITECHTURE [BERNARDS, 2006:37] 32 FIGUR 4 MATURITY MODEL [ROSS, 2003] 34 FIGUR 5 KOMPONENTER I ET DATACENTER, FRIT EFTER MENDOZA [MENDOZA, 2007: 80] 44 FIGUR 6 FRA GRID TIL UTILITY COMPUTING (EGEN UDARBEJDELSE) 46 FIGUR 7 GRID COMPUTING OVERVIEW [IBM, 2002:13] 47 FIGUR 8 CLOUD COMPUTING OVERVIEW [FORRESTER RESEARCH, 2008] 52 FIGUR 9 CLOUD COMPUTING TAKSONOMI, FRIT EFTER LAIRD [LAIRD, 2008] 54 FIGUR 10 SOFTWARE AS A SERVICE (EGEN UDARBEJDELSE) 58 FIGUR 11 PLATFORM AS A SERVICE [CLOUDFEED.NET, 2008] 60 FIGUR 12 CLOUD COMPUTING-OVERBLIK (EGEN UDARBEJDELSE) 61 FIGUR 13 - SAMMENFATNING AF EMPIRI (EGEN UDARBEJDELSE) 63 FIGUR 14 - SURFTOWN SETUP (EGEN UDARBEJDELSE) 65 FIGUR 15 - POLARROSE SETUP (EGEN UDARBEJDELSE) 67 FIGUR 16 - PODCASTMACHINE SETUP (EGEN UDARBEJDELSE) 69 FIGUR 17 FORBRUG VS. KAPACITET (EGEN UDARBEJDELSE) 72 FIGUR 18 CAPACITY USE I [MENDOZA, 2007: 59] 73 FIGUR 19 CAPACITY USE II [MENDOZA, 2007: 60] 74 FIGUR 20 - KONSOLIDERING AF KAPACITETSBEHOV (EGEN UDARBEJDELSE) 77 FIGUR 21 - SERIEL BEREGNING [BARNEY, 2007] 78 FIGUR 22 - PARALLELISEREDE BEREGNINGER [BARNEY, 2007] 79 FIGUR 23 DYNAMISK SKALERING AF WEBSITE [TEMME, 2006] 79 FIGUR 24 ECONOMIES OF SCALE (KR/GIGAFLOP) (EGEN UDARBEJDELSE) 89 FIGUR 25A CC VS. IN-HOUSE IT/OUTSOURCING (EGEN UDARBEJDELSE) 91 FIGUR 25B FORKLARING TIL 25A 92 Side 5

8 FIGUR 26 KAPACTITET OVER TID (EGEN UDARBEJDELSE) 93 FIGUR 27 CORE VS. CONTEXT [MOORE, 200X] 96 FIGUR 28 FUNKTIONALITET OG SERVICEKVALITET (EGEN UDARBEJDELSE) 99 FIGUR 29 INCITAMENTER FOR OUTSOURCING (EGEN UDARBEJDELSE) 100 FIGUR 30 INTERNAL VERSUS EXTERNAL SERVICE DELIVERY. [APPLEGATE, 2007: 339] 102 FIGUR 31 EA 3 -KUBEN [BERNARD, 2005: 38] 107 FIGUR 32 DRIVERE FOR FREMTIDIG ARKITEKTUR [BERNARD, 2006: 41] 108 FIGUR 33 CLOUD COMPUTING I AE 3 KUBEN (EGEN UDARBEJDELSE) 112 FIGUR 34 CHARACTERISTICS OF THE ARCHITECTURE STAGES [ROSS 2003: 13] 119 FIGUR 35 - TECHNOLOGY ADOPTION LIFECYCLE [WIKIPEDIA.ORG, 2008X] 124 FIGUR 36 MODENHEDSMODEL FOR CLOUD COMPUTING (EGEN UDARBEJDELSE) 128 FIGUR 37 INDEHOLD I BUSINESS CASE [BIERING-SØRENSEN, 2007: 47-48] 132 FIGUR 38 - BUSINESS CASE FOR DIGITALISERINGSPROJEKTER [MODERNISERING.DK, 2008] 133 Side 6

9 Cloud computing - i et teknisk og strategisk perspektiv I. Indledning Virksomheder har været afhængige af IT til at opnå deres forretningsmål stort set siden opfindelsen af den moderne digitale computer. Den teknologiske udvikling påvirker konstant forretningsprocesser, hvorfor det ofte også er virksomhederne der stiller de største krav til teknologien. En virksomhed har behov for en fleksibel IT-infrastruktur, som skal understøtte eksisterende forretningsmæssige og tekniske behov, men samtidig er virksomheder tvunget til at være fremsynede, så infrastrukturen også fremadrettet vil kunne understøtte forretningsbehovene. Derfor har virksomheder gennem tiden konstant været tvunget til at udforske nye muligheder for at opnå forretningsmæssige fordele gennem IT. Forretning og IT har derfor fulgtes ad gennem de sidste 50 år, som den moderne computer har på bagen. Der er gennem tiden investeret store beløb i hardware og software for at opnå strategiske fordele og en infrastruktur der kan opfylde de nye forretningsbehov. Jagten på den ideelle infrastruktur har dog for mange vist sig at resultere i en ufleksibel og tung organisering af virksomheders samlede ITinfrastruktur [Mendoza, 2007: 1][Carr, 2008a: 56-57]. Særligt omkring år 2000 hvor dot-com-krakket indtraf, blev mange virksomheder ramt af, at deres ressourcemæssige forbrug på indkøb og håndtering af IT langt havde oversteget det forretningsmæssige og strategiske udbytte. Som følge af en kompleks infrastruktur, viste det sig at mange virksomheder besad langt større kapacitet i form af hardware, software og regnekraft end de havde brug for. Denne overkapacitet af computerressourcer, applikationer og indkøbte softwarelicenser var resultatet af års spontane indkøb og forbrug i takt med den eksplosive vækst i IT branchen frem mod år Det gjorde virksomhedernes infrastruktur kompleks og ufleksibel, fordi man ikke havde sikret sig en infrastruktur gearet til forandringer. Virksomheder lærer af egne og andres fejl. Derfor fulgte i årene efter og frem til i dag en større påpasselighed og omtanke med hensyn til investering i infrastruktur og IT generelt. Derfor står mange virksomheders IT-afdelinger i dag stadig overfor krav om besparelser, rationalisering samt effektivisering, og en langt større omtanke og påpasselighed præger virksomheders IT-strategiske beslutninger. Virksomheder er også blevet opmærksomme på, at kernen til de fleste forretningsrelaterede problemer er ufleksibilitet. Fleksibilitet øger mulighederne for at justere produkter og services til nye kundebehov og teknologier, opnå kortere time-to-market, øge produktiviteten ved at udnytte sin medarbejderkapacitet effektivt osv. Change is the only constant, sagde den græske filosof Heraklit (535 f. kr. 475 f. kr.)[wikiquote.org, 2008]. Dette beskriver ganske godt den situation virksomheder står Side 7

10 overfor i dag. Forretningsledelsen skal tage beslutninger som skaber besparelser, samtidig med at virksomheden med eksisterende ressourcer skal yde bedre service samt være mere konkurrencedygtig og innovativ på et globalt marked. Realiteten er dermed, at virksomheder skal gøre mere med mindre både nu og i fremtiden. Målet er derfor stadig en omstillingsparat og fleksibel infrastruktur. På baggrund af dot-com ernes fejlagtige IT-strategiske satsninger står det i dag klart, at virksomheder der formår at drage fordel af innovationer og samtidig kan reducere omkostninger, risici, kompleksitet og overkapacitet, er dem, som kan skabe stabil og holdbar vækst. Hvordan kan virksomheder forberede sig på ukendte og konstante forandringer? Svaret er gennem forretningsagilitet. Agilitet gør virksomheder i stand til at reagere og indrette sig efter nye situationer samtidig med at de kan opnå og udnytte konkurrencemæssige fordele. Det vil sige, jo hurtigere og jo mere effektivt en virksomhed kan tilpasse sig nye situationer og præmisser, jo mere agil er den og jo bedre er den gearet til den konstante forandrings præmisser [Bloomberg & Schmelzer, 2006: 11]. The challenge for companies both large and small, then, is to develop a culture, infrastructure, and resources that enable them to change on a dime as changing needs emerge [Bloomberg & Schmelzer, 2006: 14]. Agilitet vedrører både virksomhedskultur, planlægning af infrastruktur og tilgængelighed af ressourcer - kort sagt hele virksomheden. Kendte og udbredte metoder til at arbejde mod agilitet er discipliner som Enterprise Arkitektur (EA) og Service Orienteret Arkitektur (SOA). Formålet med disse discipliner er at opnå en mere integreret og smidig IT-udnyttelse, som skaber overensstemmelse mellem forretningsbehov og IT-ressourcer. Men også nye og mere dynamiske metoder til at opnå en fleksibel IT-infrastruktur er lige nu ved at vinde frem på markedet. Ifølge eksperter og analyseinstitutter, vil udbredelsen af disse modeller få vidtrækkende konsekvenser for måden virksomheder i dag planlægger og udnytter forretnings-it. De nye modeller hedder cloud computing og utility computing og bygger på teknologi der lover at gøre virksomheder i stand til at forbruge IT-ressourcer efter behov. Det grundlæggende er at teknologien nu er moden til at et bredt spektrum af IT-ressourcer, kan leveres i stor skala over internettet som en service. Cloud computing har hen over sommeren 2008 været et meget hypet begreb. Fordele og ulemper har været genstand for stor debat og udveksling af synspunkter. Omfanget af virksomheder der har udbredte erfaringer med cloud computing er dog endnu sparsomt og dokumentation af hvordan det i praksis tages i brug kan langt fra siges at bygge på best practice. Der må derfor være behov for en redegørelse for hvordan virksomheder skal evaluere, planlægge og implementere cloud computing som en del af deres IT-arkitektur, så de reelle forretningsmæssige og tekniske fordele kommer til udtryk. Side 8

11 Læsere og forudsætninger Specialet henvender sig til en bred vifte af interessenter. Fra folk med generel interesse for ITarkitektur, infrastruktur og nye teknologier, til virksomheder, der, som alternativ til internetartikler og spredte rygter og holdninger til emnet, ønsker et mere praktisk og fagligt fundament for at kunne forholde sig til, om cloud computing er en IT-leverancemodel der har reel forretningsværdi, og som kan bibringe fornyet fleksibilitet i infrastrukturen. Vi søger undervejs i specialets kapitler at forklare de begreber, som vurderes ikke at være alment kendte, så forudgående kendskab til fagspecifikke terminologier er ikke en forudsætning for læseren. Aktiviteter og medieomtale Netop fordi specialets emne er genstand for stor hype lige nu, har vi forud for specialet oprettet en blog på WordPress.com (saasninjas.wordpress.com, 2008). Bloggen som vi også har brugt i forbindelse med tidligere projekter, er dels blevet brugt til at samle og dele tanker og interessante emner, dels til at skabe kontakt til interessenter for hvem cloud computing er relevant. Bloggens indhold har vist sig at være genstand for interesse fra såvel virksomheder som danske medier. Vores primære motivation for at blogge om cloud computing har været, i lighed med dette speciale, at skabe konsensus omkring hvad cloud computing er og hvilke fordele og ulemper anvendelse af modellen har. Dette har blandt andet medvirket til at vi i august blev kontaktet af redaktør Anders Høeg Nissen fra radioprogrammet Harddisken på P1, som inviterede os i studiet for netop at kommentere på hvad cloud computing er og hvad de teknologiske fremtidsudsigter er for modellen. Ud over at besøget var en oplevelse i sig selv, fik vi her mulighed for at dele vores interesse for cloud computing og samtidig begrunde relevansen af at foretage en redegørelse for de reelle forretningsmæssige og teknologiske fordele. I juni måned valgte vi at rejse til San Francisco med formål at få et grundlæggende kendskab til på hvilket stadie cloud computing lige nu befinder sig samt hvilke initiativer og overvejelser IT-branchen lige nu gør sig om emnet. Hvad angår teknologi og IT, er der ofte tendens til at man finder de nyeste og kommende trends i USA, hvilket begrunder at vi netop kiggede i denne retning, da vi søgte indblik i cloud computings betydning lige nu og i fremtiden. I San Francisco deltog vi i konferencerne, Cloud- Camp og Structure08, om cloud computing og infrastruktur. Dette gav dels et indtryk af hvilke interessenter der er på banen, hvad teknologien tilbyder og hvilke udfordringer og fordele cloud computing skaber for virksomheder, der har været blandt de første til henholdsvis at udbyde og udnytte cloud computing. Ud over konferencerne, foretog vi nogle virksomhedsbesøg og gennemførte interviews med blandt andet virksomheden OpSource i Silicon Valley. Side 9

12 Opholdet i San Francisco har givet et fagligt og praktisk fundament for vores evne til at redegøre for hvad cloud computing er og hvordan det kan bruges. Selvom der siden foråret 2008 er skrevet meget om cloud computing og beslægtede emner, anser vi udbyttet af vore aktiviteter i San Francisco som unikt i forhold til at vi, udelukkende gennem blogs og nyhedsartikler på internettet, skulle have tilegnet os det nødvendige fundament for specialet. Det har været afgørende for vores forståelse af begrebet og interessenterne i branchen, at vi har haft mulighed for at samtale med interessenter og herigennem komme om bag selve nyhedsværdien og hypen, som stadig omspinder emnet i Danmark såvel som resten af verden. Efter opholdet i San Francisco, besluttede vi at skrive en artikel om cloud computing og hvilken betydning det lige nu og i fremtiden vil have for virksomheders infrastruktur. Artiklen med titlen Cloud Computing infrastrukturen flytter op i skyen, blev i august måned udgivet i fagbladet PROSA-bladet, som fagforeningen PROSA står bag. Artiklen er vedlagt i Bilag 7. Senest er vi i ugen inden aflevering blevet kontaktet af en journalist fra Computer World, der skriver en artikel om cloud computing i danske virksomheder, hvor vi indgår som ekspertkilder på området. Artiklen ventes trykt i slutningen af november. Side 10

13 II. Motivation og relevans Vi har i tidligere projekter gennem uddannelsen på IT-Universitetet beskæftiget os med Software as a Service (SaaS), som mange virksomheder i øjeblikket er ved at tage til sig som en del af deres iitportefølje. Et aktuelt eksempel er den danske transportkoncern DSV, som i løbet af sommeren har nedlukket 10 forskellige CRM-systemer til fordel for én SaaS-baseret CRM-løsning. Løsningen skal bruges af mere end 4000 sælgere og salgssupportere verden over. Det har været DSV s erklærede mål at komme isolerede øer af information, som de forskellige systemer har udgjort, til livs. Satsningen på den nye software-leverancemodel SaaS, er for DSV s vedkommende båret frem af ønsket om at foretage en rationalisering og ensretning af virksomhedens portefølje af systemer og applikationer samt at frigøre ressourcer [Computerworld.dk, 2008a]. IT-analysehuset Gartner forventer desuden, at SaaSmarkedet vil vokse med over 22 procent årligt frem til 2011, hvilket er dobbelt så meget som markedet for enterprise-software generelt [ibid.]. Vi har i opgaven Software as a Service strategiske overvejelser i et kundeperspektiv beskæftiget os med software-leverancemodellen SaaS med formål at kunne påpege hvilke udfordringer og muligheder det skaber for virksomheder og for softwarebranchen. Hovedkonklusionerne i opgaven var blandt andet at SaaS-modellen giver større forretningsagilitet idet applikationer og services kan vælges efter forretningsbehov. Desuden kom vi frem til at SaaS giver bedre muligheder for at fokusere på kernekompetencer og aktiviteter med strategisk betydning. Udfordringerne for SaaS påpegede vi i forhold til lovgivning om opbevaring og distribuering af følsomme data, samt i forhold til arkitekturmæssige problemstillinger og integration, når data og applikationer er placeret uden for virksomhedens egen arkitektur. Efterfølgende er vi blevet opmærksomme på behovet for et bredere perspektiv end blot de forandringer SaaS medfører. Det skyldes at SaaS bygger på teknologi foranlediget af cloud computing-teknologi, som spås at være fundament for en kommende revolution i forhold til hvordan virksomheder planlægger deres IT-arkitektur. I USA fik vi indtrykket at cloud computing kan skabe markante besparelser på omkostninger til IT og re-allokering af ressourcer til vedligehold af servere, klienter og systemer. Gennem konferencer og de folk vi talte med i San Francisco, kom det også til udtryk, at der er endnu større forventninger til cloud computing end til SaaS. Det blev dog også klart for os, at selvom alle taler om clouds, er der stadig stor uenighed og usikkerhed omkring måden virksomheder bør og kan håndtere de muligheder det åbner op for. Dette har været en stor motivations- og inspirationskilde for os til at undersøge emnet til bunds og få indblik i de muligheder og udfordringer cloud computing reelt byder virksomheder. Men samtidig har hypen omkring emnet været det, der har fået os til at stoppe op i ønsket om at tilgå emnet akademisk frem for kommercielt. Indtrykkene fra San Francisco har desuden skærpet vores motivati- Side 11

14 on for at skabe konsensus om hvad teknologien reelt tilbyder, hvordan den kan bruges og hvordan virksomheder skal forholde sig til de forventede forandringer. Vores tilgang til emnet er derfor, at virksomheder generelt bør kunne forholde sig til om cloud computing kan skabe øget agilitet og fleksibilitet for netop deres virksomhed, og ikke mindst kunne lægge en strategi for hvordan og i hvilket omfang modellen finder anvendelse i forhold til virksomhedens behov for computerressourcer og services. Vores indledende undersøgelse af emnet samt vores aktiviteter i San Francisco har netop vist, at der i IT-branchen er uenighed om definitionen, anvendelsesmulighederne og relevansen af cloud computing. Derfor må der være behov for en redegørelse der forholder sig til hvor de forretningsmæssige fordele ligger og hvilke tekniske og strategiske faktorer der er afgørende for at man kan benytte cloud computing. Hvis virksomheder stilles en sådan redegørelse til rådighed, kan de samtidig guides til at tage de rigtige beslutninger. Med disse bevæggrunde som fundament for specialet, vurderer vi, at indholdet vil have stor relevans for virksomheder af enhver størrelse samt for en bred vifte af øvrige interessenter. Selv for virksomheder der, ikke finder cloud computing anvendeligt, vil udbyttet være et bredt kendskab til hvad teknologien kan og hvordan andre virksomheder drager fordel af den. Da emnet endnu er meget nyt og uudforsket, forventer vi at specialet vil finde relevans i IT-branchen og forhåbentlig motivere andre til at tage emnet op i takt med at den akademiske anciennitet forøges. Side 12

15 III. Hypen omkring cloud computing Når man lige nu støder på begrebet cloud computing (CC), er det sjældent med udgangspunkt i hvordan modellen praktisk benyttes eller hvordan den implementeres i en virksomhed. Hvad der har størst opmærksomhed, er selve fordelene ved at bruge nye IT-leverancemodeller som SaaS og CC. Selvom CC og særligt det beslægtede begreb utility computing (UC) har været i manges bevidsthed nogle år, hersker der til stadighed en vis hype omkring dem en hype som vi mener, primært skabes af heftig marketing og mediers fremhævning af de største succeser og initiativer i computerbranchen. I denne sammenhæng bør Nickolas Carr også nævnes, som en af de store bidragere til både formidling og hype omkring emnet, med sin bog The Big Switch [Carr, 2008a]. Men hvad er det for forventninger der stilles til IT leveret som en service? Reducerer omkostninger til IT-ressourcer [Mendoza, 2007: 1][Carr, 2008a: 112][Ross & Westerman, 2004: 14]. Udnyttelse af on-demand computerressourcer betyder at virksomheder, uanset størrelse, vil kunne reducere sine omkostninger til IT og infrastruktur. Flere tilgængelige serviceydelser [Carr, 2008a: 112]. Ikke kun software (SaaS), men også storage, databehandling og transmission af data kan deles op i mindre ydelser, som kan leveres fra forskellige lokaliteter og af forskellige virksomheder. Denne modularitet vil gøre det muligt på sigt at opfylde ethvert forretningsbehov som en utility service i stil med eksempelvis at få leveret el, gas og vand. Reducerer overkapacitet [Mendoza, 2007: 1] Muligheden for at købe skalerbar serverkapacitet som en metervare, vil kraftigt reducere overkapacitet af servere og anden infrastruktur. Fleksibel og modulerbar infrastruktur [Carr, 2008a: 113,117]. CC vil give virksomheder mulighed for at skifte mellem leverandører af eksempelvis storage, sikkerhed, regnekraft mv. På den måde kan infrastruktur sammensættes af de mest fordelagtige ydelser på markedet. Giver enhver virksomhed adgang til nyeste teknologi og infrastruktur [Hoover & Martin, 2008: 34]. CC og UC vil, grundet nye pris- og leverancemodeller, gøre det muligt for enhver virksomhed at benytte Bleading-edge technology. Skalerbarhed og strategisk agilitet [Ross & Westerman, 2004: 15]. CC giver mulighed for at benytte computerressourcer og services på forbrugsbasis og efter behov. Fokus på kernekompetencer [Ross & Westerman, 2004: 15]. CC medfører mindre opmærksomhed på commodity IT og standardiserede forretningsprocesser. I stedet kan virksomheder fokusere på det, der gør dem konkurrencedygtige og unikke. Side 13

16 Economies of scale for alle parter [Carr, 2008a: 134]. Leverance og forbrug af computerressourcer som en utility, betyder deling af ressourcer mellem flere brugere. Dette betyder lavere/ingen omkostninger til vedligeholdelse af ressourcerne og dermed economies og scale for både leverandør og modtager. Som det fremgår af eksemplerne ovenfor, er der forventninger om at CC og UC vil skabe nye forandringer og muligheder for virksomheder og deres infrastruktur, herunder også nye muligheder for at opnå fleksibilitet og agilitet. Umiddelbart ser det ud til at virksomheder straks bør gå i gang med implementeringen af de nye IT-leverancemodeller. Dette har også fået en række analysevirksomheder, herunder Gartner og Forrester Research, til at spå om teknologien og fremhæve fordele og ulemper. Til at skitsere hvor en given teknologi befinder sig med hensyn til adoption og markedsudbredelse, er Gartners Hype Cycle for Emerging Technologies en af de mest anvendte. På Hype cycle for Emerging Technologies, 2007 (figur 1) findes hverken CC eller UC. Dog findes begrebet, Web Platforms, som er en teknologi der bygger på CC og UC. CC s manglende tilstedeværelse, mener vi er udtryk for en vis usikkerhed i Gartners udlægning af hype. Vores litteraturstudie har vist, at CC har været hyppigt omtalt siden Figur 1 - Emerging Technology Hype Cycle [CMSwire.com, 2008] Figur 1 viser at web platforms i 2007 var en Technology Trigger. Da denne Hype Cycle er et år gammel, kunne det forventes at teknologien i år vil nærme sig Peak of Inflated Expectations. I juli 2008 har Gartner offentliggjort sin seneste Hype Cycle over emerging technology: Side 14

17 Figur 2 - Emerging Technology Hype Cycle [CMSwire.com, 2008] Her er Web Platforms ikke længere på hype cyclen, hvilket kan undre og alt andet lige understrege at hype cycles skal anvendes og evalueres med forbehold. Det er værd at bemærke at cloud computing er kommet med og blevet placeret samme sted som web platforms var placeret for et år siden, dvs. på grænsen mellem Technology Trigger og Peak of Inflated Expectations. Dette indikerer at hypen og forventningerne til teknologien snart vil nå sit højeste, hvilket generelt stemmer godt overens med den opfattelse vi selv har af hvor CC befinder sig lige nu. Mange, inklusive os selv, er begyndt at stille spørgsmålstegn ved teknologiens anvendelsesmuligheder og brugbarhed, hvilket formentlig vil placere CC på den anden side af peak-området på næste års hype cycle. Dette er naturligvis kun gisninger, men på baggrund af de erfaringer og indtryk vi tilegnede os i San Francisco og de mange forventninger der fremgår af litteraturen, kommer det til udtryk, at medierne og IT-industrien længe primært har haft fokus på de problemer teknologien forventes at kunne løse. Meget tyder dog på at teknologien alene ikke skaber agilitet, fleksibilitet og løser problemer. Eksempelvis har mange virksomheder i forvejen en infrastruktur, som måske ikke er gearet til at integrere med eksterne services. Sådanne problematikker må forventes at føre CC længe mod Trough of Disillusionment, i takt med at flere problematikker opstår. Hype omkring IT har tidligere i historien vist sig at være forårsaget af overeksponering i medier og følgelig heraf fejlinvesteringer i infrastruktur og teknologi. Spørgsmålet, som lige nu bør få mest opmærksomhed, er, hvordan virksomheder bør forholde sig til de nye muligheder og forandringer CC medfører, for at undgå fejlagtige satsninger i stil med dem der blev taget frem mod år Der må derfor være behov for en redegørelse, der gør virksomheder i stand til at forholde sig til, hvad CC kan anvendes til for netop dem, og hvilke potentielle strategiske og tekniske forandringer der skal bygges agilitet og fleksibilitet op omkring. En sådan redegørelse er hvad vi ønsker at udarbejde med dette speciale. Side 15

18 IV. Problemformulering At understøtte forretningen har altid været formålet med IT i virksomheder. Men i en tid hvor økonomien og globaliseringen får stigende indflydelse på markedskræfter og konkurrenceevne, er forandringsparathed blevet et begreb med stigende relevans. Forventningerne til cloud computing er mange men fælles for disse forventninger er at de forudser en revolution af hvordan virksomheder anvender IT i dag. Det er sandsynligt at Google og andre internetgiganter med deres gigantiske datacenter, placeret strategisk fordelagtige steder rundt om i verden, kan udføre og distribuere en computerberegning for 1/10-del af hvad det ville koste for en gennemsnitlig virksomhed. Men afhængig af størrelse og industri, er der også stor forskel på hvilke IT-behov virksomheder har. Derfor må det første skridt i retning mod at klarlægge en strategi for anvendelse af CC være, at undersøge hvor og i hvilket omfang cloud computing appellerer til virksomheders tekniske og forretningsmæssige behov. Til grund herfor må ligge en undersøgelse af, hvad det er for generelle IT-relaterede problemer og opgaver virksomheder i dag kan bruge CC til. Desuden er det relevant at undersøge hvordan CC passer ind i virksomheders eksisterende ITarkitektur. Vi ønsker at undersøge hvilke faktorer der har betydning for anvendelsen af CC og dermed gøre beslutningstagere i stand til at tage kvalificerede beslutninger herudfra. Formålet med specialet er derfor at besvare følgende: Hvad er cloud computing set i et teknisk og strategisk perspektiv? Hvordan anvendes cloud computing lige nu og hvilke faktorer har betydning for cloud computing i en anvendelsesorienteret kontekst? Hvordan kan cloud computing tænkes ind i en arkitekturproces og integreres i en større ITarkitektur? Endelig ønskes at foretage en diskussion af de barrierer der ligger forude for cloud computing på det brede marked og følgelig heraf fremsætte en model, som kan skitsere processen med at implementere cloud computing på en måde, som forholder sig til tekniske og strategiske faktorer. Side 16

19 V. Læsevejledning Engelske ord Stort set al litteratur der i forvejen eksisterer om cloud computing er udgivet på engelsk. Det danske sprog kommer i mange tilfælde til kort overfor engelske begreber og betegnelser som anvendes inden for forskningsfeltet. Derfor har vi kun oversat begreber og citater, som vi mener, på dansk har samme indhold som på engelsk. Til trods for at specialet skrives på dansk, anvendes derfor i mange sammenhænge engelske betegnelser for at sikre kompatibilitet til den eksisterende litteratur på området. Der hvor engelske ord bruges blandt danske, er disse ord skrevet med kursiv. Fremhævede sætninger Pointer der skal fremhæves, og formuleringer vi mener, er særligt vigtige, er fremhævet i tekstbokse med en lys blå baggrund Vigtig eller fremhævet pointe Kilder Alle kildehenvisninger, er markeret med kantede parenteser, med forfatterens efternavn efterfulgt af årstal for udgivelse af kilde, samt et sidetal hvis der refereres til en side i kilden. Kilder angives altså således: [Forfatter, årstal:sidetal]. Side 17

20 Oversigt over specialets indhold Specialet er, udover indledning, konklusion og perspektivering, indelt i følgende 5 kapitler: Kapitel 1 Baggrund og begreber er en kort introduktion til IT-udviklingen fra computerindustriens opståen og frem til i dag. Kapitlet fremhæver væsentlige begivenheder og teknologiske innovationer med betydning for hvor forretnings-it befinder sig i dag. Herefter redegøres for to af de mest udbredte discipliner, som virksomheder i dag anvender til at optimere udbyttet af forretnings-it. Endelig redegøres for definitioner af specialets væsentligste begreber. Kapitel 2 Hvad er cloud computing? har til formål at opstille en teoretisk og tekniske forståelsesramme for specialets hovedemne, cloud computing. De centrale begreber behandles ud fra et teknisk og forretningsmæssigt synspunkt og begreberne sættes i forhold til hinanden. Kapitel 3 Praktiske erfaringer med cloud computing er opdelt i to overordnede afsnit. Det første afsnit er en præsentation af empirien, samt behandling af empiriens væsentligste resultater, hvilket ligger til grund for den videre analyse. Det andet afsnit er en analyse af empirisk udledte faktorer med betydning for praktisk anvendelse af cloud computing. Kapitel 4 Enterprise cloud computing er en bredere men mere teoretisk funderet analyse af cloud computings indpas i disciplinen enterprise arkitektur. Undervejs præsenteres teoretiske iagttagelser og resultaterne flettes sammen med de i Kapitel 3 udledte resultater om praktisk anvendelse af cloud computing. Kapitel 5 Cloud computing enablement er et diskuterende kapitel hvor der, på baggrund af anerkendte innovations- og forretningsstrategiske teorier, føres en diskussion af forskellige perspektiver på cloud computings fremtidsudsigter og udbredelse i forskellige markedssegmenter. Endelig præsenteres, på baggrund af de forrige kapitler, en model som forholder sig til cloud computings indpas i dagens virksomheder. Side 18

21 VI. Metode Specialet er inddelt i to overordnede områder: praktisk anvendelse af CC og teoretisk implementering af CC. Hverken praktisk eller teoretisk anvendelse af CC er funderet i akademisk litteratur, men som vist, er der især en del hype omkring den praktiske anvendelse og fordelene herved. Vi er dog ikke bekendt med dokumenterede praktiske eksempler på virksomheder der har lavet en komplet implementering af CC i deres infrastruktur. Videnskabsteoretiske overvejelser Specialet befinder sig i et spændingsfelt mellem flere videnskabelige retninger. I klassisk forstand har IT primært været genstandsfelt for naturvidenskaben og kaldes i dag Datalogi (Computer Science), indeholdende programmering, algoritmik, kunstig intelligens og datalingvistik. Valget af betegnelsen datalogi, som i øvrigt første gang blev foreslået at den danske forsker Peter Naur, begrundes i ønsket om at lægge vægt på, at studiet ikke er et studie af IT, men af data generelt [Wikipedia.org, 2008a]. I dag er såvel hardware som software blevet mere avanceret, og internettet har været medvirkende til at computeren nu har fået status som et (interaktivt) medie på lige fod med TV, radio osv. Netop derfor tilskrives computeren også at høre ind under de humanistiske og samfundsvidenskabelige retninger, hvor der søges forklaringer på den menneskelige aktivitet og produktivitet forbundet med IT. At IT har fået stor betydning for økonomien i virksomheder såvel som i samfundet generelt, er desuden årsag til at man inden for samfundsvidenskaben taler om information economics og economics of information technology. Disse områder beskæftiger sig primært med mikro-økonomi og studiet af hvordan information påvirker en økonomi og økonomiske beslutninger [Wikipedia.org, 2008b]. Information er overalt, og information er nemt at skabe og sprede, men svær at kontrollere. Samtidig har information indflydelse på stort set alle beslutninger der tages i en virksomhed. På baggrund af disse særlige karakteristika, er det naturligt at information og teknologi i samfundsvidenskaben har fået sine egne videnskabelige paradigmer, da traditionelle økonomiske teorier ville komme til kort over for kompleksiteten omkring IT og information [ibid.]. At vi befinder os i et spændingsfelt mellem flere videnskabsteoretiske retninger, anses som en oplagt mulighed for at udvælge anvendelige teorier for herigennem at opnå et anvendeligt analyseapparat. Men samtidig opstår der risiko for at vi inddrager teorier eller synspunkter som er modstridende eller som, grundet emnernes karakter eller natur, ikke kan inddrages på samme præmisser. Da specialetss faglige område i meget begrænset omfang tidligere er behandlet ud fra netop vores tilgang, forholder vi os pragmatisk til denne risiko. Dette betyder, at hvis det samlede analyseapparat kan bidrage til en analyse, som vi mener, giver mening for så vel os selv som for læseren, anser vi hver enkelt teori for Side 19

22 brugbar i sammenhængen. I forlængelse heraf, gør vi os undervejs overvejelser om teoriernes anvendelighed og reflekterer over de arbejdsmetoder der er valgt. Specialets beskrivende og analyserende afsnit bliver til i takt med inddragelsen af teori og empiri som fortolkes. Inspireret af socialkonstruktivismen og hermeneutikken erkender vi, at vi ikke kan opnå en objektiv fortolkning. Som forsker vil man altid være med til at konstruere det sociale fænomen man undersøger. Man vil derfor altid påvirke situationen og de personer man interviewer. Arbejdsmetode Vi har valgt en eksplorativ tilgang baseret dels på resultatet af interviews, dels på vores egen tilegnede viden om emnet. Desuden er generelt valgt en hermeneutisk tilgang til udarbejdelse af specialet. Det skyldes, som tidligere nævnt, at emnet i begrænset omfang tidligere er behandlet på videnskabeligt niveau og ud fra påviste teorier. En af de store udfordringer, som vi mener bedst angribes med en eksplorativ tilgang, er derfor at sætte CC ind i større sammenhæng og desuden at komme med bud på hvordan virksomheder skal forholde sig til emnet. Hermeneutikken har samtidig det til fælles med naturvidenskaben, at den søger at opstille hypoteser om det foreliggende materiale. Dette er særdeles relevant for vores eksplorative tilgang, da det giver mulighed for at opstille hypoteser og problemstillinger som kan være genstand for nærmere analyse. For at resultaterne af vores fortolkninger og analyser ikke bliver subjektive, stræbes hvor det er muligt efter intersubjektivitet, det vil sige at fortolke og erkende ud fra synspunkter og teori som giver mening og er erkendt af flere personer. Dette søges tilstræbt gennem argumentation og dokumentation af fortolkninger, samt verifikation af resultaterne hos de interviewede personer og i litteraturen. At kunne fortolke og analysere kræver en forforståelse for det, man skal undersøge. Denne forforståelse har vi opnået gennem et litteraturstudie, virksomhedsbesøg, en studierejse til San Francisco samt gennem tidligere opgaver om beslægtede emner. For at kunne fortolke et begreb, er man nødt til præcist at vide, hvad det er, man ønsker at undersøge. Det er netop det, forforståelsen bidrager med. At sætte CC ind i en kontekst og fortolke på andres udsagn og teorier inden for emnet, er derfor de primære aktiviteter i udarbejdelsen af specialet. Denne proces er ikke trinvis og fastlagt fra start til slut. Heri ligger den eksplorative tilgang. I takt med at vi opnår ny viden om emnet, er det fortløbende med til at udvikle en nærmere forståelse. Dette er også hvad man inden for hermeneutikken kalder den hermeneutiske cirkel.[langergaard et. al., 2006: ] Empiri Da der kun i begrænset omfang findes akademisk litteratur om emnet, har vi valgt selv at indsamle empiri i form af interviews med virksomheder som har praktisk erfaring med CC. Det empiriske arbej- Side 20

23 de bygger på case-study metoden, som den er beskrevet af Robert K. Yin [Yin, 2003]. Metoden egner sig til emner der bedst lader sig afdække gennem kvalitative data. Desuden har metoden, sammenlignet med andre metoder, en fordel i at den giver mulighed for at undersøge en case i dybden i sin reallife kontekst [Yin, 2003: 1]. Vi har valgt at følge Yin s anbefalinger og dermed valgt hvad han kalder multiple case-studies [Yin, 2003: 5]. Derfor består vores empiri af flere mindre cases. Med en enkelt case kunne vi behandle emnet i dybden. Vi mener dog at emnet, som er nyt, delvist uprøvet og endnu ikke genstand for anerkendte teorier, fordrer behandling gennem flere forskellige cases, således at det er muligt at sige noget mere generelt. I forhold til emnets lave aktuelle anciennitet i virksomheder og som akademisk område, synes det desuden korrekt og begrundet at udtrække generelle karakteristika og tendenser frem for at forsøge at generalisere ud fra en enkelt analyseenhed. Som det netop fremgår af problemformuleringen, ønsker vi at kunne udtale os mere generelt om hvordan virksomheder skal planlægge og implementere CC. Vi har valgt at gennemføre kvalitative interviews med virksomhederne PolarRose, Surftown og PodcastMachine. Disse tre virksomheder er udvalgt idet de alle bruger cloud computing i en grad som gør dem interessante at undersøge i konteksten. Det har generelt været vanskeligt at finde virksomheder med erfaringer inden for cloud computing, især hvad angår større virksomheder. Vi har derfor ikke haft frihed til at vælge mellem cases, men derimod har det været en krævende proces at finde frem til mulige cases. Det havde naturligvis været ønskværdigt og optimalt at kunne udvælge cases efter størst relevans, efter virksomhedsstørrelse eller andre karakteristika. Vi anser dog vores cases som et godt empirisk grundlag og udbyttet af de kvalitative interviews lever op til de forventninger vi opstillede fra start. Referater af interviewene findes i Bilag 2 Surftown, 3 Polar Rose og 4 - PodcastMachine.com. Som guide for vore interviews har vi opdelt vores interviewoplæg i 3 hoveddele: (1) Hvilke problemer/opgaver bruger virksomhederne cloud computing til og hvordan lader dette sig gøre. (2) Hvilken indflydelse har anvendelsen heraf på virksomhedens forretning og økonomi, herunder, kan der siges noget specifikt om hvilken betydning cloud computing har haft på konkrete opgaver? (3) Hvilke begrænsninger og udfordringer har virksomheden oplevet med cloud computing og ser de evt. nogle fremtidige problemstillinger? I de gennemførte interviews forsøger vi at forholde os åbent til informanternes synspunkter og informationer. Interviewene kan karakteriseres som fokuserede interviews, som Yin beskriver således: a respondent is interviewed for a short period of time an hour, for example. In such cases, the interviews may still remain open-ended and assume a conversational manner, but you are more likely to be following a certain set of questions [Yin, 2003: 90]. Som interviewere forholder vi os derfor lyttende Side 21

24 og forsøger at få informanterne til at tale frit om emnet, selvom vi til hvert interview på forhånd har udarbejdet en interviewguide. Vanskelighederne med at finde relevante cases ser vi som udtryk for at cloud computing stadig er i en tidlig fase og at mange derfor endnu ikke har erfaringer med brugen heraf. Dette gør det mere krævende at afdække emnet, men samtidig skærper det vores motivation og specialets relevans generelt. Valg af teori Emnet er ikke teoritungt men bærer derimod præg af, at der generelt mangler akademisk forskning på området. Akademisk litteratur er desværre bagud i forhold til praksis, og den bedste litteratur findes i rapporter og analyser foretaget af konsulenthuse og analyseinstitutter, som generelt har gode tekniske beskrivelser og definitioner. Det er dog nødvendigt at tilgå sådan litteratur med kritisk sans, da meget er farvet af kommercielle bevæggrunde. Endelig er der bøger og videnskabelige artikler som i mange tilfælde har en historisk vinkel på CC aktuelle betydning. Kan man i så fald tale om teori? Vi opfatter en teori som et begrebsapparat og forståelsesapparat, som man kan iagttage verden og fænomener med. Med teorier opstilles rammer for fremgangsmåden når man indsamler og behandler empiri. I specialet betegner vi teori som de modeller, tekniske dokumentationer og eksisterende forskning, som inddrages i analysen. Teorier anvendes både for at kunne sætte CC i kontekst og i relation til andre begreber, og for at kunne referere til anerkendt forskning og dermed skabe intersubjektivitet. Side 22

25 Kapitel 1 Baggrund og begreber Som det ofte er tilfældet med tekniske begreber, formes og betydningstilskrives de over tid og gennem forskellige kanaler. Begreberne er mange og det samme gælder definitionerne. På et tidspunkt bliver der behov for en entydig definition, en bred og alment anerkendt betydningstilskrivning af begrebet, som kan finde anvendelse andre steder end i diskussionsfora og blogs for eksempel i forbindelse med behandling i akademisk litteratur og i forbindelse med at teknikken/produktet bag hypen modnes og får teknisk og forretningsmæssig anciennitet. Med andre ord må begreber løsrives fra deres egenskab af at være buzzwords til i stedet at blive jargon med en veldefineret betydning. Det sker ikke før en samlende definition af et begreb er alment kendt. Cloud computing (CC) anses for at varsle en kommende revolution i forhold til den måde hvorpå virksomheder anvender IT. For at forstå denne revolution, må man dog kunne redegøre nærmere for hvad det er der ændrer sig, og hvad det skal ses i forhold til. CC er et begreb mange forsøger at betydningstilskrive lige nu, og meningerne er mange om hvad virksomheder skal forvente. 1.1 Baggrund Vi mener, at en fornuftig redegørelse for hvorfor CC er relevant lige nu bør tage udgangspunkt i hvordan virksomheder har anvendt IT gennem historien. Computerens historie er allerede gengivet i stort omfang, hvorfor et egentligt bidrag hertil ikke er formålet. I stedet ønskes at fremhæve måder man i samfundet og i den industrielle sektor har betydningstilskrevet computeren som teknologi og ressource frem til i dag. Dette vil dels bidrage til at opnå en bredere forståelse af hvor vi rent teknologisk befinder os i dag og hvorfor, dels undgås herved at bidrage til begrebsforvirringen, buzzword-snakken og hypen IT-udviklingen Der eksisterer mange kilder som kunne inddrages til at afdække IT-udviklingen. Der er dog til formålet udvalgt to af de mere anerkendte computerhistorikeres værker samt et nyere bidrag. Inden for deres felt er James W. Cortada med sin bog Information Technology as Business History [Cortada, 1996] og Paul E. Ceruzzi med bogen A History of Modern Computing [Ceruzzi, 1998] blandt de mere anerkendte. Desuden er udvalgt Nicholas Carrs seneste bog The Big Switch [Carr, 2008a]. Ud over at have beskæftiget sig med informationsteknologiens strategiske og forretningsmæssige betydning gennem de seneste årtier, er Carr også en dedikeret computerhistoriker. Carr har i sin seneste bog kombineret Side 23

26 sin computerhistoriske viden med aktuelle strategiske overvejelser og fremtidsvisioner for computerindustrien. Desuden refereres der i The Big Switch flittigt til blandt andet Ceruzzi [Ceruzzi, 1998]. Der er forskel på hvordan og med hvilket detaljeniveau computerens historie er gengivet. Fagligt og videnskabeligt er der enighed om, at den digitale computers historie begynder omkring 2. Verdenskrig og at den teknologiske udvikling for alvor tager fart i efterkrigsårene og under den kolde krig [Cortada, 1996][Ceruzzi, 1998][Carr, 2008a]. Andre kilder beskæftiger sig mere specifikt med forskeres arbejder med opfindelse af den første computer eller hvordan computeren i 1950 erne blev omdrejningspunkt for en industriel revolution og tilblivelsen af en ny industri, Computerindustrien [Pugh, 1995] [Herken, 1995] Computerindustrien opstår Efter 2. Verdenskrig blev computerteknologiens anvendelsesmuligheder udbredt og forfinet, så nye markeder kunne drage nytte af den. Virksomheder som International Business Machines Corporation (IBM) og General Electric (GE) arbejdede på at forfine computerteknologien, som hidtil primært var blevet udviklet til forskningsmæssige og militære formål [Cortada, 1996: 46]. Kun få troede at computere overhovedet ville få en fremtid på det kommercielle marked og i virksomheder. Det var svært at forestille sig et behov for så kompleks og omfangsrig regnekraft, at det ville kræve en computer [Carr, 2008a: 48]. En lille gruppe af virksomheder tog dog chancen og satsede på at udvikle computere som skulle erstatte hulkort-teknologien. Hvad der drev disse virksomheder var, at de havde indset at når en elektronisk computer kunne gemme instruktioner og input i sin egen hukommelse, ville den kunne programmeres til at varetage mange forskellige funktioner. Eckert og Mauchlys UNIVAC-computer var den første af sin slags [Ceruzzi, 1998: 27-33]. Dermed kom de før Watsons IBM 701, som dog senere skulle vise sig at få størst succes. UNIVAC en og IBMs 701 indviede en æra for kommerciel computing i 1950 erne. Særligt det faktum at en af de første købere, U.S. Census Bureau, opnåede langt større besparelser end forventet ved at anvende UNVAC en var med til at sætte gang i industrien. I starten af 1950 erne afløstes virksomhedernes skepsis derfor af entusiasme og generel accept af computeren som en forretningsmæssig ressource der var kommet for at blive. Med computerindustrien fulgte endnu en ny industri, nemlig software-programmering. I slutningen af 1950 erne var der ca. 40 mindre softwarevirksomheder, som specialiserede sig i at skrive programmer til mainframe-computere. Denne industris opståen fik en markant betydning for virksomheder: It wasn t long before businesses were competing not only on the quality of their products but on the capabilities of their hardware and software [Carr, 2008a: 50]. Når én virksomhed introducerede et nyt system til at automatisere processer, fulgte andre efter af frygt for at sakke bagud. Fænomenet blev på kort tid spredt til enhver industri hvor virksomheder forsøgte at matche hinandens investeringer i ny computerteknologi. Side 24

27 Time-sharing Op gennem 1960 erne og 70 erne steg virksomhedernes investeringer i informationsteknologi drastisk. I starten af Mainframe-æraen (ca ), var mainframes så dyre, at en virksomhed var nødt til konstant at udnytte computerkraften fuldt ud for at retfærdiggøre investeringen [Ceruzzi, 1998: 154]. En typisk mainframe brugte i denne periode ca. 90 procent af sin maksimale kapacitet [Carr, 2008a: 52]. Men konsekvensen af denne fokus på at udnytte mainframen optimalt gik ud over anvendelsesmulighederne. Det var en besværlig og tidskrævende måde at anvende computerkraft på. Skismaet mellem den besværlige men samtidig økonomisk nødvendige måde man anvendte mainframes på, fik i 1960 erne den amerikanske professor John McCarthy, en computer videnskabsmand fra MIT i USA, til at udtænke et system som kunne dele mainframens ressourcer mellem flere brugere. Man kaldte systemet for Time-sharing [Ceruzzi, 1998: ]. Da en mainframe, selv ved almindelig brug, i kortere perioder var ubeskæftiget mens den afventede input fra brugeren, arbejdede McCarthy på et system som kunne allokere computerens idle-time mellem flere brugere. McCarthy var ikke den eneste der forskede i time-sharing. Flere forskere og virksomheder som GE og IBM arbejdede ud fra at man i teorien ville kunne dele computerressourcer mellem flere brugere samtidig, så hver bruger havde oplevelsen af at have sin egen computer til rådighed [Ceruzzi, 1998: 154]. De første eksempler på time sharing-systemer demonstrerede realiserbarheden af et sådan system. Time-sharing blev dog overhalet inden om af den teknologiske udvikling. Computere blev mindre og billigere, så det efterhånden var muligt at placere og tilegne en såkaldt minicomputer til hver enkelt medarbejder. Derfor blev time-sharing, og arbejdet med at udnytte mainframe-computerens ressourcer maksimalt, stort set overflødigt. Minicomputere gjorde dog ikke selve mainframen overflødig, men supplerede den ved at flytte anvendelsen af mindre computerressourcer ud blandt medarbejderne, mens mainframen blev brugt til tungere og mere krævende opgaver. De faldende priser på hardware og software samt det pladsbesparende design betød, at hver medarbejder efterhånden fik sin egen minicomputer til rådighed Fra mainframe til decentraliseret overforbrug Nøjagtig som da mainframen blev introduceret, kunne eksperterne ikke se potentialet i at hver enkelt medarbejder skulle have sin egen personlige computer (PC). Der var dog den forskel, at hvor mainframes blev betragtet som værende for kraftfulde til at afvikle forretningsapplikationer, blev PC en betragtet som det modsatte. Det førte til at førende virksomheder, herunder IBM, endnu en tid kun satsede på at forbedre deres mainframes efter virksomhedernes behov. Alligevel blev PC en i løbet af 1970 erne omdrejningspunktet for computerens videre udvikling. Som Carr formulerer det: It took a Side 25

28 college dropout named Bill Gates[ ]to see the potential of personal computers in business [Carr, 2008a: 54]. Gates udviklede i samarbejde med en studiekammerat det første styresystem til computeren, DOS (Disk Operating System)[Ceruzzi, 1998: 237] Dette demokratiserede computeranvendelsen og gjorde computeren til et universelt værktøj som tjente mange forskellige formål i virksomheden. Ud over at hver medarbejder kunne afvikle sine egne programmer, begyndte man at koble computerne sammen i et datanetværk som for eksempel muliggjorde fil- og printerdeling. Dette betød samtidig, at virksomhedens mainframe(s) fik en ny funktion. Mainframen blev brugt til at opbevare de vigtigste data på servere som også var koblet til datanetværket. På denne måde kunne hver enkelt medarbejder råde over sin egen PC og samtidig tilgå virksomhedens vigtigste data via netværket. Da PC erne således fungerede som klienter, der kunne tilgå den centrale server, blev denne IT-infrastruktur kendt som Client/Server-Computing [Carr, 2008a: 55]. I 1980 erne hvor PC en for alvor fik sit indtog i virksomhederne, var man begyndt at bruge mainframecomputeren som en stor server hvorpå der var installeret de programmer, som brugerne havde brug for, on-demand [Greschler & Mangan, 2002: 317]. Med denne model havde man fuldstændig kontrol over hvilke programmer der var tilgængelige og hvem der havde adgang til hvad. Virksomhedens ITafdeling stod for installation af de indkøbte programmer samt opdatering og vedligehold af systemerne. Ikke overraskende fik medarbejdere i IT-afdelingerne høj status og bestred på mange områder en uundværlig jobfunktion. Det største problem, som formentlig er årsagen til at mange senere er gået væk fra denne model, er svingende performance. Mainframen blev et knudepunkt i virksomhedens data-flow, og der kunne let opstå flaskehalsproblemer, hvis mange arbejdede samtidig [ibid.]. Fra fortiden havde man lært at initiativer som time-sharing ikke var den bedste løsning, hvorfor man i stedet gik over til en mere decentraliseret administration af computerbrug. Muligheden for tilpasning af såvel udseende som funktionalitet bevirkede, at man gik væk fra at styre system- og programadgang centralt. Datacentrene er blevet driftet og vedligeholdt internt og i takt med større krav om IT-understøttelse, hvorfor udgifterne til IT-personale er vokset tilsvarende. Med andre ord har virksomheder op gennem 1980 erne og 90 erne, nøjagtig som i 1950 erne, i stigende grad konkurreret på at udnytte IT på den mest sofistikerede måde - en udvikling som, ifølge Carr, efter år 2000 helt eller delvist er gået i stå [ibid.]. Denne udvikling tilskrives som bekendt dot-com-krakket omkring år Producenter og udbydere fra IBM til Microsoft har forsøgt at promovere deres egne proprietære produkter, som ikke kan interagere med konkurrenternes. Derfor har man også været nødt til at etablere sin infrastruktur således, at hver applikation eller hvert system har sin egen dedikerede server. Det betyder at hver gang der indkøbes et nyt system eller en ny applikation, skal der tilsvarende investeres Side 26

29 i nye servere. Ydermere skal hver enkelt server være i stand til at klare høj belastning, selvom belastningen kun indtræffer få gange om året. Ikke overraskende har dette bevirket lav udnyttelse af den tilgængelige kapacitet. Hvis man kigger på en hel industri, hvor virksomheder benytter stort set samme hardware og software, sættes den lave udnyttelse af de indkøbte ressourcer i et tankevækkende perspektiv. Det er blandt andet set i dette lys, at Nicholas Carr i 2003 skrev artiklen IT Doesn t Matter [Carr, 2003]. Heri begrundes at computere, netværksudstyr og software er blevet commodities, det vil sige produkter, som er allemandseje og dermed ikke længere midler til at opnå konkurrencemæssige eller økonomiske fordele. Det samme må i relation hertil gælde de medarbejdere hvis job er at vedligeholde og opdatere computere og datacentre. Disse medarbejdere udfører præcis samme (rutine)opgaver som deres kolleger hos konkurrenterne. Overforbruget af ressourcer, som ikke er konkurrenceparametre, har ifølge Carr [Carr, 2008a : 57] haft betydelig negativ indflydelse på økonomien og den produktivitet, som ellers prægede og styrkede computerens indtog i forretningsverdenen Vision om en computer utility Why has computing progressed in such a seemingly dysfunctional way?, spørger Carr [Carr, 2008a]. Lad os gemme svaret lidt og i stedet først kigge på hvorfor Carr stiller spørgsmålet. Siden man begyndte at anvende Client/Server-modellen, har software været designet til at køre lokalt på computere og servere [Carr, 2008a: 57-58]. Men hvorfor medførte personliggørelsen af computere så høj grad af kompleksitet og overkapacitet? Svaret er Moore s lov og Grove s lov. Gordon Moore s lov siger at processorkraften i mikroprocessorer fordobles hvert eller hvert andet år. Grove s lov siger at: telecommunications bandwidth doubles only every century. [Carr, 2008a: 58]. Ifølge Carr er denne lov primært udtryk for computerbranchens daværende kritik af telekommunikationsudbydernes manglende vilje til at anvende ny teknologi og dermed imødekomme computerbranchens behov. At båndbredden kun fordobles hvert 100 år er selvsagt ikke et faktum i dag. Alligevel kan det konkluderes, at den teknologiske udvikling af processorkraft langt overgår den inden for kommunikationsnetværk. Det har hidtil betydet, at virksomheder der ønskede at udnytte avanceret computerkraft, var tvunget til selv at huse den nødvendige computerteknologi. Problematikken var den samme før distribution af elektricitet blev opfundet og udbredt. Der manglede en praktisk mulig måde at transportere elektricitet over længere afstande. Denne problematik er netop hvad Moore s og Grove s love tilsammen skitserer. I 1961 brugte John McCarthy for første gang betegnelsen computer utility. McCarthy sagde i en tale ved MIT s hundredeårsdag at: Computing may someday be organized as a public utility just as the telephone system is a public utility[...] The computer utility could become the basis of a new and important industry. [Wikipedia.org, 2008c]. McCarthys hypotese antyder at en enkelt computer i prin- Side 27

30 cippet kan programmeres til at varetage alle computerberegninger der måtte være brug for verden over. Han havde således allerede før internettets udbredelse en ide om, at anvendelse af computere ville kunne organiseres på samme måde som et forsyningsværk til distribution af elektricitet eller telefonsamtaler. Hvordan og i hvilket omfang computer-utilities kunne realiseres, har McCarthy formentlig ikke kunne redegøre nærmere for, men på baggrund af 50 års konstant teknologisk evolution, synes McCarthys teori i dag mere realistisk end da han fremlagde den første gang. Fremskridtet inden for netværksteknologi har løbende medført bølger af entreprenørers forsøg på at realisere en computer utility. I begyndelsen af mainframe-æraen var det time-sharing man forsøgte at realisere, i 1970 erne begyndte et mindre antal virksomheder at tilbyde løsning af basale computerbaserede funktioner såsom lønadministration og lignende. I 1990 erne skød en lang række application service providers (ASP) op og nød frem mod dot-com-krakket godt af enorme summer fra venturekapital. Dette medførte en bølge af ASP ere som alle forsøgte at levere software over internettet. Fælles for disse forsøg på at tilbyde computerressourcer og software som en utility er, at de alle har ligget under for manglende båndbredde [Carr, 2008a: 59]. Derfor har virksomheder frem til i dag været tvunget til at drive deres egne datacentre med fortsat overforbrug og stigende kompleksitet. En problematik som mange virksomheder i dag stadig står overfor, men som teknologien og båndbredden nu begynder at kunne løse Fokus på infrastruktur I det forrige er brugt betegnelsen virksomheder, når vi for eksempel har haft fokus på den stigende kompleksitet af systemer og data der i dag skaber udfordringer. Men det er nok mere korrekt at bruge betegnelsen IT-afdelinger for at præcisere hvor udfordringerne skal adresseres. Det vil naturligvis påvirke en virksomhed som helhed, at der er infrastrukturmæssige udfordringer der skal adresseres, men bruger man betegnelsen virksomhed, vedrører det også medarbejdere som måske ikke direkte berøres af infrastrukturen eller de økonomiske konsekvenser som en kompleks infrastruktur eventuelt vil kunne få. Da IT-afdelinger generelt har fået langt større beføjelser og indvirkning på virksomheders øvrige afdelinger i dag, kan man netop tale om IT som en selvstændig afdeling. Bloomberg giver i Service Orient or be Doomed [Bloomberg & Schmelzer, 2006] en karakteristika af hvordan virksomheder og deres IT-afdelinger er organiseret og styret i dag. IT-afdelinger har gradvist vokset sig ind i den komplekse og hierarkiske organisationsstruktur, som i dag præger mange virksomheder, In the early days, IT was an extension of the finance, manufacturing, or operations part of the business, depending on the industry. As IT grew into a strategic corporate asset, companies formed IT departments to focus on emerging business needs. [Bloomberg & Schmelzer, 2006:69]. IT har som ressource gradvist vokset sig større og dermed skabt forøget kompleksitet. Et af problemerne med måden IT- Side 28

31 afdelinger har udviklet sig gennem tiden er, at hvert nyt IT-projekt har krævet større budget og større behov for håndtering og drift af hardware og software Forretnings-IT i dag Redegørelsen for hvordan forretnings-it har udviklet sig, danner grundlaget for at beskrive hvordan der arbejdes med forretnings-it i dag. Vi har valgt at fokusere på på Enterprise Arkitektur og Serviceorienteret arkitektur, som repræsenterer de to mest udbredte discipliner virksomheder i dag benytter til at øge udbyttet af forretnings-it. I det følgende forholder vi os til disciplinernes relevans for forretnings-it såvel som for CC. Når der i specialet omtales Enterprise, i forskellige sammenhænge (for eksempel enterprise-it, enterprise-niveau og enterprisemarkedet), refererer Enterprise til virksomheder, myndigheder eller organisationer. Disse enheder hører til de større, og har i kraft heraf en etableret IT-strategi og arkitektur, samt et beslutningsorgan der sikrer forretningens behov ved IT indkøb og drift. Hermed skelnes i forhold til start-ups samt små og mellemstore virksomheder. Forretnings-IT forholder sig til profesionel brug af IT og IT-systemer i alle typer af virksomheder Enterprise arkitektur Enterprise Arkitektur (EA) er en disciplin, som er særdeles veldokumenteret og som har eksisteret siden slutningen af 1980 erne. Begrebet EA blev formodentligt anvendt første gang af Steven Spewak i bogen Enterprise Architecture Planning. Efterfølgende er begrebet oftest sat i sammenhæng med John Zachman. Efterhånden er anvendelsen af begrebet vokset ganske kraftigt, og i dag eksisterer mange dokumenterede tilgange til EA. EA handler i bredeste forstand om at integrere IT med forretningen. Et af målene med EA er at komme væk fra den systemtankegang som har præget udviklingen af IT-ressourcer. I stedet ønsker EA at fremme en mere holistisk tilgang gennem udvikling af en overordnet arkitektur, hvor man kommer væk fra IT-siloerne og forbedrer mulighed for genbrug af ITressourcer. Til trods for søgninger efter litteratur og generel research, har vi ikke fået kendskab til litteratur om forholdet mellem EA og CC. Vi arbejder derfor ud fra en hypotese om at det primært er mindre virksomheder der benytter CC og i forlængelse heraf er det ikke overraskende at akademisk litteratur om netop EA og CC ikke foreligger. Da der ikke eksisterer et litterært fundament for denne sammenkædning af begreberne, bygger vores inddragelse af EA alene på egne teoretiske overvejelser og ønske om at kunne formidle et realistisk billede af samspillet mellem EA og CC. Man kan sige at vi ved at inddrage EA kan forholde os til og behandle CC på enterprise-niveau. Side 29

32 For at kunne sætte begreberne i forhold til hinanden, må vi dog redegøre for det teoretiske fundament for EA, ligesom vi må foretage en afgrænsning i henhold til hvilken teori der inddrages. Det er ikke intentionen at foretage en komplet redegørelse for samtlige aspekter af EA, men derimod at inddrage tilstrækkelig teori til med rette at kunne undersøge forholdet mellem EA og CC. Hvad er EA? Formålet med EA er at skabe alignment mellem IT og forretning, det vil sige at få skabt sammenhæng mellem IT-ressourcer, forretningsbehov og strategi. EA betegnes som det grundlæggende arbejde med [EA Fellows.com, 2006]: At få koblet forretning og IT sammen i én strategi At vælge de rigtige standarder og teknologier At styre udviklingen med simple regler/principper EA er en proces, som skal lukke gabet mellem forretningsprocesser og IT-løsninger. Derfor er EA også mere end blot at arbejde med IT-arkitektur. Det er en proces som kræver mange forskellige kompetencer, da planlægningsprocessen omfatter nogle vidtrækkende beslutninger. Man kan sige at EA er en forretningsmæssig og strategisk tilgang til IT og derfor er EA ikke udelukkende en teknisk disciplin, men derimod en disciplin som beskæftiger sig med de strategiske og arkitekturmæssige aspekter af IT i virksomheden. Hvorfor arbejder man med EA? Strategisk anvendelse af virksomhedens ressourcer har fået stor betydning for offentlige og private virksomheder. EA er en af de mest udbredte metoder til at forbedre ressourceplanlægning og ressourceudnyttelse samt grundlaget for IT-beslutninger og den interne kommunikation mellem afdelinger, EA is[.] devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flow, and technology resources. [Bernard, 2005: 32]. Derfor er arbejdet med EA en naturlig udvikling og proces for virksomheder at ty til, for at komme kompleksitet i infrastrukturen til livs. Målet er netop at gøre virksomheden mere agil og i stand til at reagere på interne og eksterne forandringer ved blandt andet at nedbryde IT-siloer [Bernard, 2005: 63]. Arkitekturarbejdet skal munde ud i at få formuleret og udvalgt nogle standarder og principper som skal operationaliseres i forretningsprocesser, beslutnings- og arbejdsprocesser samt på datamæssigt- og teknisk niveau. Ønsket om at få mest muligt ud af forretning, IT og medarbejder-ressourcer tvinger virksomheder til at tænke i IT-løsninger og systemer som breder sig over større områder og flere behov, frem for løsninger, der kun varetager behov inden Side 30

33 for afgrænsede områder og projekter [Bernard, 2005: 32]. EA er også opstået ud af dette behov som en tilgang til planlægning og udvikling af nye IT-løsninger, hvor det ikke kun handler om at kunne gøre det rigtige og tage de rigtige beslutninger, men i endnu højere grad at blive i stand til konsekvent at tage de rigtige beslutninger ud fra dokumenterede og standardiserede metoder og principper. Derudover kan årsager til arbejdet med EA være [Gurpreet, 2004]: IT costs too much Costs of managing complexity Eliminate redundancy Growing IT ecosystem Demanding rate of change Need for info sharing Outsourcing (BPO) Future-proofing Der er dog forskellige drivere for EA alt efter hvilken industri eller sektor man kigger på. In the private sector, profits drives most planning and discision-making, and EA is an optional activity. In the public sector, service delivery is the primary driver, money is a use-or-lose resource, and EA may be an activity mandated by law. [Bernard, 2005: 246]. Der kan altså være forskellige indgangsvinkler og formål med at arbejde med EA alt efter hvilken sektor man betragter. Generelt kan man dog sige at de nævnte motiver bunder i ønsket om at skabe (økonomisk) vækst, hvad end dette udmøntes i at skære ned på omkostninger eller opnå større konkurrenceevne [Bernard, 2005: 247]. EA-processen Der er ikke et enkelt svar på hvordan en EA-process gennemføres. Det er virksomheders organisation og kompleksitet for differentieret til at kunne fremsætte. Derfor må arkitekturprocessen tilpasses den enkelte virksomhed, hvorfor der i dag også eksisterer forskellige rammeværk, som hver især fremsætter en metodisk tilgang til EA-processen. Vi har valgt at tage udgangspunkt i den teoretiske tilgang som Scott A. Bernard introducerer i An Introduction to Enterprise Architecture Linking Business and Technology [Bernard, 2005], da vi mener den med fordel kan anvendes i kraft af at være både en praktisk tilgang og en akademisk tilgang til EA. Desuden repræsenterer Bernard den mest klassiske tilgang til arkitekturprocessen, og hans teori kan med rette tilskrives at være en af de mest anvendte. Overordnet set beskriver Bernard EA-processen ud fra current architecture (As-is) og target architecture (To-be), som henholdsvis er en virksomheds dokumenterede eksisterende arkitektur og fremti- Side 31

34 dige arkitektur. As-is: Dokumentering af as-is har til formål at skabe overblik over de IT-ressourcer som ved udgangspunktet er til stede i virksomheden og hvor der eventuelt er overlap mellem ITressourcerne [Bernard, 2005: 135]. To-be: Udviklingen af den fremtidige arkitektur er vigtig for en virksomhed, da det er med til at understøtte såvel ressourceplanlægning som strategiske beslutninger. Det kan samtidig være med til at indikere behov for nye prioriteringer af processer og ressourcer [Bernard, 2005: 160]. EA-processen tager efterfølgende udgangspunkt i at identificere hvordan man transformerer arkitekturen fra as-is til to-be, dokumenteret og udmyntet i en Architecture Management & Transition plan. Dokumentationen og arkitekturprocessen skitserer Bernard med følgende framework: Figur 3 Current and future Architechture [Bernard, 2005: 37] Frameworket er anvendeligt idet det giver et holistisk billede af hvordan en virksomhed ser ud. De fem levels er opdelt hierarkisk, således at strategi og mål er placeret øverst, produkter, services og information er placeret i midten og nederst ligger den infrastruktur som ligger til grund for de øvrige områder, eksemplificeret med blandt andet systemer, applikationer og netværk [Bernard, 2005: 105]. Segmenterne er delt op i Lines of Business (LOB). Det vil sige en opdeling af virksomheden efter forskellige aktiviteter, produkter/services der produceres eller administrative funktioner. Et segment dokumenterer en eller flere LOB s på alle levels [Bernard, 2005: 108]. Artefakterne er beskrivelser af komponenter, som på hvert niveau (level) i arkitekturen kan være vertikale og horisontale alt efter hvor i virksomheden de anvendes. Eksempler på komponenter er ITstrategiske mål, sikkerhedsløsninger, applikationer, systemer og data [Bernard, 2005: ]. Vertikale komponenter anvendes kun på én LOB, mens horisontale komponenter anvendes på tværs af flere LOB s. Side 32

35 Bernards rammeværk er således en tredimensionel kube som kan udfyldes i takt med at man dokumenterer hvilke ressourcer, strategier og mål der eksister og hvilke områder i virksomheden de servicerer. Dette kan give et billede af hvor der eventuelt skal udfyldes med supplerende komponenter og hvor der er redundans i de eksisterende komponenter. Transformeringen stiller store krav til planlægning og ledelsesmæssige kompetencer, særligt når IT-ressourcer der understøtter kerneforretningen skal udskiftes eller opdateres. Da et af formålene med arkitekturprocessen er at gøre virksomheden mere agil og fleksibel, må man tænke områderne sikkerhed, standarder og medarbejderressourcer ind i managementplanen [Bernard, 2005: 42]. Dermed kan man sikre at sikkerhed integreres på alle levels og alle LOB s. Standarder for arkitekturens komponenter bør være åbne og internationalt anerkendte standarder, så arkitekturen bliver mere fleksibel og komponenter kan udskiftes med nye efter behov. Endelig skal man sikre at medarbejderressourcer indgår i managementplanen, så ressourcerne fordeles optimalt i forhold til den fremtidige arkitektur. [Bernard, 2005: 109] EA-modenhed Et væsentligt aspekt af arbejdet med arkitektur er modenhed. Der eksisterer flere forskellige modenhedsmodeller for IT-arkitektur. Vi har dog valgt modenhedsmodellen som Jeanne W. Ross præsenterer i artiklen Creating a Strategic IT Architecture Competency: Learning in Stages [Ross, 2003]. Modenhedsmodellen for IT-arkitektur viser fire overordnede stadier i en arkitekturmodningsproces. På hvert stadie argumenteres for at specifikke organisatoriske kompetencer må være til stede for at en virksomhed gradvist kan implementere en IT-arkitektur. IT architecture er ifølge Ross et begreb som i højere grad end EA tager højde for samspillet mellem teknologi og kritiske forretningsprocesser [Ross, 2003: 2]. IT-arkitektur defineres af Ross således: an IT architecture is the organizing logic for applications, data and infrastructure technologies, as captured in a set of policies and technical choices, intended to enable the firm s business strategy. Side 33

36 Figur 4 Maturity model [Ross, 2003] Ross modenhedsmodel består af fire faser som går fra Application Silo (Applikationssiloer) til Modular (modulerbar). Modellen viser både hvad der karakteriserer de enkelte faser samt ressourcefordelingen. I det følgende referes kort hvad de enkelte faser indeholder: Application silo architecture [Ross, 2003: 5] The application silo architecture stage consists of IT architectures of individual applications. Standardized technology architecture [Ross, 2003: 6] The standardized technology architecture stage has an enterprise-wide IT architecture that provides efficiencies through technology standardization. Rationalized data architecture [Ross, 2003: 8] The rationalized data architecture stage extends the enterprise-wide IT standards to data and processes. Modular architecture [Ross, 2003: 11] The modular architecture stage builds onto enterprise-wide global standards with loosely coupled IT components to preserve the global standards while enabling local differences. Hver fase i modenhedsmodellen kræver organisatoriske kompetencer for at kunne implementere arkitekturen og for at der kan avanceres til den næste modenhedsfase. Ross s modenhedsmodel anskue- Side 34

37 liggør, at den højeste og mest ønskværdige infrastruktur består af moduler som kan udskiftes og tilpasses forskellige behov Service-orienteret arkitektur Service-orienteret arkitektur (SOA) er en anden disciplin og et tilstræbt middel til at skabe agilitet i forretningens udnyttelse af IT. SOA, indeles ofte i to kategorier. Enten defineres SOA som en teknisk relateret disciplin eller som en forretningsmæssig disciplin. Der kan dog argumenteres for at der med denne opdeling mistes noget af pointen med at arbejde med SOA, der netop kan ses om et praktisk værktøj til at adresere kløften mellem IT og forretning. SOA berører næsten samtlige aspekter og abstraktionsniveauer af IT, fra strategiske arkitekturovervejelser til teknisk implementering af eksempelvis Web Services. Derfor er en entydig og holistisk definition af SOA sværere end som så, da man ofte må tage udgangspunkt i ét abstraktionsniveau, alt efter hvem man taler til. Det har også ført til forslag om at opdele SOA i SOBA, som betegner selve forretningsdelen, og SOTA, som beskæftiger sig med teknikken [Version2.dk, 2007]. Et eksempel på en forretningsorienteret definition findes i Arsanjanis artikel Service-oriented modeling and architecture [Arsanjani, 2004], som definerer SOA således: SOA is not a product it s about bridging the gap between business and IT through a set of business-aligned IT services using a set of design principles, patterns and techniques [Arsanjani, 2004]. Det er her værd at bemærke at denne definition minder meget om definitionen på EA og om hvad der karakteriserer 4. fase i Ross modenhedsmodel for IT-arkitektur. Der er derfor stor overensstemmelse mellem den forretningsmæssige motivation for EA og den for SOA. En mere teknisk definition af SOA har Mendoza fremstillet: SOA is a component model that interrelates the different functional units of an application, called services, through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language the service is implemented in. This allows services, built on a variety of such systems, to interact with each other in a uniform and universal manner. [Mendoza, 2007: 17]. SOA er altså også at forbinde funktionalitet i applikationer gennem veldefinerede grænseflader som er uafhængige af platforme, operativsystem og hardware. Denne forbindelse skabes ofte gennem web services som interagerer ud fra standardiserede og universelle protokoller (XML over HTTP). Formålet med at indarbejde SOA er, at kunne skabe koblinger mellem forskellige systemer og applikationer på en standardiseret måde. Dermed er SOA et bud på hvordan et basalt behov for at kunne få Side 35

38 systemer til at tale sammen kan opfyldes. I stedet for at lave implementeringsprojekter der binder hvert enkelt system sammen efter behov, skabes der med en SOA en fælles ramme for hvordan integrationen foregår, og dermed opfordres der til genbrug og standardisering. At realisere dette kræver ikke alene en teknisk platform, men også en forretningsmæssig omstilling og anvarsfordeling samt organisatoriske tilpasninger. Ligesom der gør sig gældende for EA, har vi ikke fundet litteratur der omhandler samspillet mellen SOA og CC. 1.2 Begrebsafklaring I dette afsnit redegøres for begreberne CC og utility computing. Begge begreber er tilskrevet flere forskellige definitioner. Derfor må vi redegøre nærmere for hvilken definition der refereres til. I de efterfølgende kapitler vil betegnelsen traditionel infrastruktur blive anvendt flere steder. Derfor ses desuden behov for at redegøre for, hvad der ligger i denne betegnelse Definition af cloud computing CC er et at de mest omtalte IT-relaterede begreber i år, og mange har fremsat definitioner heraf. CC er ikke én men flere ting, og definitionen vil afhænge af hvem der fremsætter den. Derfor tilskrives CC mange forskellige definitioner. Her ønskes at udlede den definition som finder anvendelse i de efterfølgende kapitler. I en rapport fra marts 2008 definerer analysefirmaet Forrester Research CC på følgende måde: A pool of abstracted, highly scalable, and managed compute infrastructure capable of hosting end-customer applications and billed by consumption. [Staten, 2008: 3] Modellen er ved at vinde frem i takt med at hosting-firmaer og andre udbydere af internetservices opdager at de kan udbyde services med de fordele, deres unikke kompetencer inden for håndtering af infrastruktur, medfører. Forrester refererer eksemplificerende til det første kommercielle eksempel på modellen, Amazon Elastic Compute Cloud (Amazon EC2). Der er altså tale om en skalerbar hostingmodel hvor udbyderen håndterer og vedligeholder infrastruktur og dermed gør det muligt for kunden at afvikle og udvikle applikationer i infrastrukturen efter behov. Nicholas Carr omtaler denne model som an external computing grid [Carr, 2008b: 4]. Vi mener dog man generelt kan tale om en infrastruktur, da det som hostes og måden det gøres på, svarer til og erstatter infrastrukturen hos aftageren. Side 36

39 Et whitepaper fra Amazon Web Services beskriver CC som en arkitektur der håndteres af udbyderen i skyen : The usage of resources in Cloud Architectures is as needed, sometimes ephemeral or seasonal, thereby providing the highest utilization and optimum bang for the buck. [AmazonWebServices.com, 2008a] Whitepaper et forholder sig primært til hvordan CC kan anvendes til at udvikle og afvikle applikationer på arkitekturen: Applications built on Cloud Architectures run in-the-cloud where the physical location of the infrastructure is determined by the provider. [AmazonWebServices.com, 2008a] I rapporten Demystifying The Cloud fra InformationWeek [Hoover & Martin, 2008: 32], nævnes tre karakteristika som kendetegner CC: (1) IT resources provisioned outside of the corporate data center, (2) those resources accessed over the Internet, (3) and variable costs. [Hoover & Martin, 2008: 32] Af rapporten fremgår også, at CC giver adgang til develop and deliver applications and capacity without having to deploy on-premises software and servers. CC giver ifølge denne definition adgang til kapacitet og applikationer, uden forudgående investering, opsætning og administrering af servere og software. Som i andre af de definitioner vi har inddraget, defineres CC ud fra sine fortrin og det forventede udbytte, herunder variable omkostninger og minimering af overkapacitet. I Wired-artiklen The Information Factories af George Gilder [Gilder, 2006], beskrives hvordan internetpionerer såsom Google, Amazon og Microsoft, gennem længere tid har opbygget og administreret enorme datacentre bestående af commodity hardware. Datacentre som hver især udgør supercomputere, der kan levere computerkraft og lagerplads nok til ethvert formål. Her beskrives CC således: In this architecture, the data is mostly resided on servers somewhere on the internet and the application runs on both the cloud servers and the user s browser. CC anskues som en arkitektur hvor såvel data som applikationer tilgås som services over internettet. Denne arkitektur medfører desuden, at man ikke kan bestemme og lokalisere hvor såvel data som applikationer ligger fysisk. George Gilder [ibid.] bruger også betegnelsen In the cloud for arkitekturen. I modsætning til Forresters, Amazons og InformationWeeks definitioner, mener vi ikke at en definition af CC kan begrænses til kun at vedrøre applikationer. Man bør i stedet tale om services, herunder applikationer og software generelt, som leverer en ydelse. Dette tages der højde for i en artikel fra Gi- Side 37

40 gaom [Perry, 2008]. Artiklen beskriver blandt andet forskellen mellem CC og det beslægtede begreb utility computing således: Cloud computing is a broader concept than utility computing and relates to the underlying architecture in which the services are designed. It may be applied equally to utility computing services and internal corporate data centers. [ ] Wall Street firms have been implementing internal clouds for years. They call it grid computing, but the concepts are the same. [Perry, 2008] CC beskrives hér som en arkitektur hvorpå services kan udvikles og udbydes. Definitionen anskueliggør samtidig, at arkitekturen ikke er unik, proprietær eller revolutionerende, idet den kan relateres til grid computing, som virksomheder gennem flere år har benyttet til at etablere interne clouds. Mange flere definitioner af CC kunne medtages. Vi har anskueliggjort at flere definitioner begrænser sig til at tale om applikationer in the cloud, hvilket vi mener, kan defineres som Software-as-a- Service (SaaS) og dermed er en forkert udlægning og afgrænsning af CC. CC er mere end SaaS, idet der er tale om en arkitektur, hvorpå enhver service kan distribueres og forbruges over internettet. På baggrund af den skitserede begrebssammenblanding, finder vi det nødvendigt at fremstille vores egen definition, som delvist tager udgangspunkt i flere af de definitioner vi allerede har refereret til. Denne definition er dækkende for vores opfattelse og anvendelse af begrebet i specialet: Cloud computing er en underliggende arkitektur for netværksoptimerede, skalerbare og forbrugsafregnede IT-ressourcer der kan distribueres og forbruges via internettet som services. Cloud services kan alene eller i samspil med andre services være supplerende eller erstattende for dele af en traditionel infrastruktur. Vi har bevidst undladt en definition som forholder sig til potentielle fordele ved CC. Dette skyldes, som tidligere nævnt, at dokumentation herfor ikke er tilgængelig i tilstrækkelig grad. Da det samtidig er formålet med specialet at vurdere hvilke fordele der reelt kan opnås gennem CC og hvordan det udnyttes, synes ovenstående definition at være et hensigtsmæssigt udgangspunkt Definition af utility computing Som nævnt i afsnit 1.1 kan begrebet utility spores tilbage til starten af 1960 erne, hvor John McCarthy fremstillede en hypotese om, at computerressourcer vil kunne distribueres over et netværk, i stil med telefonsamtaler. Internettets udbredelse betyder at denne hypotese i dag har fået nyt liv. Nicholas Carr har desuden sammenlignet computerteknologiens og netværksteknologiens udvikling og begrunder hermed hvorfor distribution af computerressourcer over større netværk først er blevet en realitet inden for de sidste 10 år [Carr, 2008a]. Side 38

41 Virksomheder har gennem mange år skabt titusindvis af uafhængige datacentre verden over. Datacentre som stort set bruger den samme hardware og software. Dette har betydet ikke uvæsentlige økonomiske omkostninger [Carr, 2005: 70][Mendoza, 2007: 77]. Samtidig har det resulteret i et overforbrug af IT-ressourcer men samtidig underforbrug af den samlede kapacitet. When overcapacity is combined with redundant functionality, the conditions are ripe for at shift to central supply [Carr, 2005: 70]. Carr refererer til at man gik fra selv at drive generatorer og andre forsyningskilder, til i stedet at benytte den offentlige forsyning af såvel el, gas og vand. Som Carr udlægger det, er det i høj grad det økonomiske argument, der taler for at utility computing netop nu begynder at vinde frem i virksomheders strategiske bevidsthed. Der er dog imidlertid behov for at dette begreb defineres nærmere da det, på samme måde som CC, er genstand for flere divergerende definitioner og samtidig anvendes i forskellige kontekster. Der kan udpeges to kontekster hvori utility computing anvendes: Som en forretningsmodel Som en arkitekturdisciplin Vi har udvalgt eksempler på definitioner som illustrerer anvendelsen i begge kontekster og til sidst fremhæves den definition som finder anvendelse i specialet Utility computing som forretningsmodel Virksomheden Sun Microsystems udbyder utility computing og beskriver hvad ideen bag og ikke mindst fordelene ved utility computing som forretningsmodel er: Utility computing is a business model for computing in which resources (CPU power, storage space, etc.) are made available to the user on an as-needed basis. The goal of the UC model is to maximize the efficient use of computing resources and minimize user costs. Users are able to dial up or dial down usage in real time, to meet the varying demands of business. [Sun.com, 2008] Sun definerer UC som en forretningsmodel for computing, hvor CPU og storage (data lagerplads) stilles til rådighed på forbrugsbasis. Sun fremhæver desuden, at modellen øger effektiviteten og nyttevirkningen ved brug af computerressourcer og at modellen har en bedre økonomisk struktur end tidligere IT-leverancemodeller. Endelig lægger Sun vægt på, at modellen tilbyder skalerbarhed der både følger med op og ned alt efter det aktuelle forbrug. Side 39

42 En anden og mere akademisk funderet definition af utility computing som forretningsmodel findes i [Ross & Westerman, 2004] som definerer UC således:.a collection of technologies and business practices that enable computing to be delivered seamlessly and reliably across multiple computers. Moreover computing capacity is available as needed and billed according to usage, much like water and electricity are today. In the promised UC model, firms will be able to purchase as much IT Service as they need, whenever they need it. In time, they may even be able to access over the network components of business processes inside and outside the firm, If this occurs, it could profoundly change the nature of IT. [Ross & Westerman, 2004: 6] Ross og Westerman beskriver UC som en række teknologier og forretningsmæssige praksisser, som gør det muligt at levere computerressourcer mellem computere. Ross og Westerman er enige i, at der tales om ubegrænsede og skalerbare computerressourcer afregnet på forbrugsbasis. Definitionen er fra 2004 og viser at man på daværende tidspunkt endnu ikke kunne forudsige om sådanne ressourcer, i stor skala, kunne leveres over længere afstande, men at det vil få betydelige konsekvenser for forretnings-it. Det sidste eksempel på definition af utility computing som en forretningsmodel er fra Wikipedia.org: Utility computing is the packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility (such as electricity, water, natural gas, or telephone network). This system has the advantage of a low or no initial cost to acquire hardware; instead, computational resources are essentially rented. Customers with very large computations or a sudden peak in demand can also avoid the delays that would result from physically acquiring and assembling a large number of computers. [Wikipedia.org, 2008c] UC er ifølge denne definition computerressourcer såsom databehandling (CPU-kraft) og storage, leveret på forbrugsbasis. Den økonomiske betragtning er desuden at modellen ikke kræver forudgående investeringer, da hardwaren lejes af aftageren. Endelig indeholder definitionen forskellen i forhold til tidligere IT-leverancemodeller, dvs. skalerbarhed uden forudgående indkøb og opsætning af hardware og software Utility computing som arkitekturdisciplin Den anden kontekst hvori utility computing anvendes, relaterer sig til hvordan virksomheder organiserer og opbygger deres infrastrukturer, dvs. ud fra en arkitekturmæssig betragtning. Fra aftagerens (kundens) synspunkt, er målet med utility computing i denne kontekst det samme som med forret- Side 40

43 ningsmodellen. Men forskellen er her, at utility computing tilstræbes implementeret som en intern ITleverancemodel. De eneste fagbøger som selvstændigt behandler utility computing i denne kontekst er Mendoza [Mendoza, 2007] samt Bunker & Thomson [Bunker & Thomson, 2006]. Mendoza ser utility computing som en infrastruktur, som enten udelukkende implementeres internt eller outsources: a utility infrastructure whose purpose is to provide IT infrastructure services as needed when needed. A utility infrastructure can be implemented in-house or by an outsourcing provider. Mendoza beskæftiger sig også med hvordan utility computing kan være en hybrid mellem interne og eksterne ressourcer. Han nævner eksempelvis public utilities og hybrid utilities, men fokus i hans behandling af utility computing er i konteksten infrastruktur-design og transformering af et datacenter [Mendoza, 2007: 79] Bunkter & Thomson definerer formålet med utility computing således: The end-game is to put in place an infrastructure that provides IT as a service or a number of services. The services are made up from all aspects of IT, servers, storage and networking and need to be able to scale dynamically based on real-time fluctuations in demand. [Bunker & Thomson, 2006: 10-11]. Følgende citat udtrykker at utility computing betragtes som en arkitekturdisciplin: Efficient use of technology is a business differentiator, utility computing as a process and an architecture can offer the competitive edge. [Bunker & Thomson, 2006: 17]. Mendoza samt Bunker & Thomson definerer altså utility computing som en arkitekturdisciplin og en infrastruktur, der skal øge effektiviteten og ressourceudnyttelsen af virksomhedens interne ressourcer. Herved opstår et modsætningsforhold. Utility computing som forretningsmodel er baseret på at kunden lejer IT-ressourcer og betaler efter forbrug, mens utility computing som arkitekturdisciplin stræber efter at transformere virksomhedens infrastruktur til en utility infrastruktur. Hvordan hænger dette sammen? Jo, som nævnt er målet med utility computing i de to kontekster det samme. Vi mener dog at forskellen ligger i at Mendozas og Bunker & Thomsons tilgange til utility computing udspringer af en klassisk arkitektur-tilgang, hvor man på organisationsniveau stræber efter at optimere infrastrukturen til bedst muligt at imødekomme forretningsmæssige behov. Der er utvivlsomt gevinster og målbare fordele ved at arbejde med utility computing i denne kontekst. Der kan dog udpeges væsentlige begrundelser for, at utility computing som forretningsmodel er den definition, der bedst kommer til sin ret. Om utility computing siger Nicholas Carr [Carr, 2005]: True utility computing will have arrived only when an outside supplier takes responsibility for delivering all of a company s IT requirements, from data processing to storage to applications. Side 41

44 The utility model requires that ownership of the assets that have traditionally resided inside widely dispersed data centers be consolidated and transferred to utilities. [Carr, 2005: 70] Dette efterlader ingen tvivl om at Carr mener at utility computing er en model hvor IT-ressourcer distribueres fra centraliserede utilities og ikke fra private datacentre. Carr lægger vægt på, at der er tale om konsoliderede ressourcer som, netop når de er konsoliderede, kan distribueres som en utility. Det økonomiske og ressourcemæssige argument for utility computing er centralisering af IT-ressourcer. Når Mendoza og Bunker & Thomson taler om utility infrastructure, mener vi ikke det stemmer overens med argumentet om centralisering. Godt nok er det centralisering og optimering på organisationsniveau, men følges eksempelvis Carrs el-analogi, må det svarer til at tilføje nye forbedrede komponenter til traditionelle generatorer eller vandkraftværker, snarere end til at tilslutte sig det offentlige el-net. Begrundelsen for centralisering er, at der opnås en kritisk masse og tilstrækkelig volumen til at opnå besparelser. Dette kan ikke i samme grad henføres til utility computing i en arkitekturkontekst. En væsentlig begrundelse for utility computing er, at modellen er omkostningsbesparende og gør en virksomhed i stand til at fokusere på sine kernekompetencer, idet en tredjepart varetager leverance af en række infrastrukturkomponenter. Arbejdet med at opbygge en utility infrastruktur må i sig selv have betydelige omkostninger og er en tids- og ressourcekrævende proces. På baggrund af virksomheders aktuelle ønske om at mindske kompleksitet og samtidig opnå økonomiske besparelser, ser vi ikke utility-infrastrukturen som en model, der på kort sigt vil kunne modsvare dette behov. Hermed er det begrundet hvorfor vi mener utility computing bør defineres som en forretningsmodel der bygger på at udbyde skalerbare IT-ressourcer afregnet efter forbrug. På baggrund af ovenstående defineres utility computing således: Utility computing er en forretningsmodel, som bygger oven på cloud computing-arkitekturen. Utility computing er en udbyders leverance af skalerbare IT-ressourcer, afregnet på forbrugsbasis og distribueret over et eller flere netværk Traditionel IT-infrastruktur I de efterfølgende kapitler får vi brug for at påpege hvor CC adskiller sig fra hvordan virksomheder førhen og i dag strukturerer deres IT- infrastruktur. Mendoza [Mendoza, 2007] har kategoriseret tre typer af IT-infrastruktur, som anses at have været toneangivende gennem de sidste årtier: Side 42

45 Types of managed infrastructures: Type 1 is an IT infrastructure that is privately managed by the internal company s IT department and that resides within the company firewalls. The infrastructure is privately owned and consumed by the corporation. Type 2 is a dedicated outsourced infrastructure that is solely for back-office use. It is managed by outsourcing providers. The IT resources, like servers and storage, are owned and consumed by the client company. Type 3 is a shared hosting infrastructure used by companies with Internet facing requirements. It is managed by ISP s. Data center facilities, including Internet connectivity, are owned by the provider. The IT resources, like servers and storage, are owned by the client company. [Mendoza, 2007: 2] Disse tre typer af IT-infrastruktur spænder fra komplet håndtering af samtlige IT-ressourcer internt, til at være en blanding af intern og ekstern leverance af IT-ressourcer. Skiftet mod outsourcing begrundes af Mendoza med den stigende kompleksitet omkring at håndtere og vedligeholde et datacenter og samspillet mellem de komponenter, som udgør en IT-infrastruktur. I takt med at kompleksiteten er øget frem til i dag, er tendensen til at outsource flere og flere IT-behov øget tilsvarende [Applegate et. al, 2007: 437]. Derfor består langt de fleste større virksomheders infrastruktur i dag af en kombination af interne og eksterne ressourcer. En IT-infrastruktur ser vi som opbygget omkring et datacenter, og samspillet mellem datacentret og interne og eksterne komponenter afhænger af IT-infrastrukturen. Et datacenter vil have differentieret størrelse og kompleksitet alt efter hvilken virksomhed man kigger på. Før der kan siges noget generelt om den indflydelse CC har på en IT-infrastruktur, må det derfor være nødvendigt at skabe konsensus omkring den definition og generaliserede opfattelse, som ligger til grund for vores anvendelse af betegnelse af en IT-infrastruktur. Med ønsket om at kunne generalisere betegnelsen, har vi opstillet en simpel model, som i hovedtræk skitserer de komponenter, som udgør et datacenter og en traditionel IT-infrastruktur. Side 43

46 Data og information Specialeafhandling: Cloud Computing I et teknisk og stratgisk perspektiv Systemadministratorer og brugere Processer og workflow Software og applikationer Hardware Figur 5 komponenter i et datacenter, frit efter Mendoza [Mendoza, 2007: 80] Figuren tager ikke højde for hvor komponenterne fysisk er placeret og hvem der i praksis varetager driften og vedligeholdelsen af dem. Håndteringen af visse komponenter kan være outsourcet, men samlet set indgår de stadig i IT-infrastrukturen. Derfor har vi valgt ikke at skelne mellem de tre infrastrukturtyper Mendoza har opstillet, men ser dem som indeholdt i figuren ovenfor trods deres forskelligheder. Fordelingen af og de fysiske rammer for komponenterne i IT-infrastrukturen vil også variere. Men de skitserede komponenter vil altid være til stede og have hver deres behov med indflydelse på hvordan datacenteret er organiseret: Hardware er karakteriseret ved at skulle være funktionel 24x7x365 og have en maksimal oppetid. Samtidig skal hardwaren være i stand til at yde de nødvendige ressourcer. Derfor må hardwaren i datacenteret være i stand til at opretholde stabil drift selv i peak-perioder, hvor der er markant øget pres på hardwarekomponenterne og hvor ressourcebehovet er højt. Dette kræver effektiviseret overvågning af hardwaren, så der konstant kan ydes de nødvendige ressourcer. Software og applikationer er essentielle for den daglige produktion, og derfor er det vigtigt at de altid er tilgængelige. Applikationernes funktionalitet kan være tilpasset specifikke forretningsbehov og derfor have en høj kompleksitet. Derfor kræves konstant vedligeholdelse og overvågning for at sikre maksimal oppetid og performance. Processer og workflow er de processer som bl.a. gennemføres i forbindelse med vedligeholdelse og opgradering af hardware og software, backup og tests samt udrulning af ny software og hardware. Disse processer vil oftest bygge på best practice som sikrer at der er en kobling til forretningsprocesserne. Systemadministratorer og brugere skal henholdsvis levere og modtage høj kvalitet gennem de services der leveres. Systemadministratorerne skal have et samlet overblik over datacenteret og har brug for Side 44

47 effektive processer til at levere den forventede kvalitet og service. Brugerne forventer at have adgang til applikationer og ressourcer hvor som helst og når som helst. Data og information skal være tilgængelige på alle tidspunkter og skal være opdaterede og ikkeredundante. Datamængderne kan antage meget store mængder og forskellige former. Med denne redegørelse for hvordan en traditionel IT-infrastruktur og et datacenter er opbygget, har vi lagt et fundament for at kunne tale om en IT-infrastruktur ud fra et generaliseret billede og dermed være i stand til at pege på hvor CC ændrer en traditionel IT-infrastruktur. Side 45

48 Kapitel 2 Hvad er Cloud computing? I dette afsnit redegøres for hvad CC er i en teknisk og anvendelsesorienteret kontekst. Tidligere er nævnt at CC kan relateres til begreberne utility computing og grid computing. Der er ligheder og overlap mellem begreberne, men også områder, hvor der eksisterer vigtige forskelle med stor betydning for begrebernes praktiske anvendelse. I forrige kapitel har vi defineret CC ud fra et akademisk synspunkt. Næste skridt er at behandle hvordan CC kan anvendes i praksis hvilket fordrer behandling på et mere teknisk- og implementeringsnært plan. Dette afsnit har desuden til formål at redegøre for sammenhængen mellem grid, cloud og utility. 2.1 Fra grid til utility computing Som introduktion til de følgende afsnit er opstillet en figur, som både viser strukturen for kapitlet og den tekniske og forretningsmæssige sammenhæng mellem begreberne som behandles. Teknikken Produktet Forretningsmodellen Hardware Software Cloud Computing Grid Computing Cloud Computing Utility Computing Services Figur 6 Fra grid til utility computing (egen udarbejdelse) Med figuren er skitseret at grid- og CC er begreber som referer til det tekniske fundament ved henholdsvis at repræsentere hardware og software. Cloud services er de produkter og services som bygger ovenpå CC-arkitekturen. Produkterne er forskellige indgange til at udnytte CC. Hvad end der er tale om rå computerkraft eller komplette applikationer, vil en cloud-service have en form for brugergrænseflade hvorigennem aftageren anvender servicen. Utility computing er forretningsmodellen som bygger på at distribuere services svarende til forskellige IT-behov. Side 46

49 2.2 Grid Computing Et grid er en samling af hardwarekomponenter der agerer som én samlet ressource hvortil der kan allokeres forskellige opgaver. Dette defineres også således: Grid computing allows large numbers of hardware components, such as servers or disk drives, to effectively act as a single device, pooling their capacity and allocating it automatically to different jobs. [Carr, 2005: 71]. Som også skitseret med figuren i afsnit 2.1, er grid computing fundamentet for både CC og utility computing, idet grid et er selve miljøet hvor hardwarekomponenterne opererer som en samlet ressource. Et grid defineres desuden af Mendoza [Mendoza, 2007] som: A grid computing environment is made up of clusters of physical servers connected through a variety of network connections. Servers within the grid are utilized in a manner that harnesses unused processing capacity to complete varying workloads [Mendoza, 2007: 39]. Et grid er en arkitektur der anvendes for at forbedre og optimere udnyttelsen af computerressourcer. Tidligere er grid computing primært blevet anvendt som en intern ressource tilgængelig i en virksomheds infrastruktur. I et Redpaper fra IBM [Berstis, 2002] illustreres et simpelt grid med følgende model: Figur 7 Grid Computing overview [Berstis, 2002:13] Dette simple grid består af nogle få servere som er identiske (homogene) med hensyn til hardware og operativsystem. Serverne er indbyrdes forbundne i et netværk ligesom såvel brugerne og administratorerne er forbundet til det samlede grid. Et grid styres af en job scheduler, det vil sige software der fordeler arbejdsopgaverne ud på grid et [Mendoza, 2007: 39]. På figuren herover er denne software skitseret med en sky og betegnet Grid Mgt. Job scheduler en kan evt. fordele opgaverne efter priori- Side 47

50 teret relevans eller efter hvor mange ressourcer de enkelte opgaver kræver. Desuden kan der i en job scheduler være indbygget regler om at tunge og krævende opgaver ikke må afvikles i et givent tidsrum. Dette kan på mange måder minde om ideen bag time-sharing og måden hvorpå mainframecomputing er blevet anvendt. Forskellen i forhold hertil er at grid et kan udvides og anvendes langt mere fleksibelt end en mainframe-computer og desuden er det langt mere effektivt at en job scheduler kan fordele opgaverne, i stedet for at en dedikeret person skal prioritere andres arbejdsopgaver. Fordelene ved anvendelse af et grid er: Hvis en applikation afvikles på en server der er udsat for særligt højt workload, kan job scheduler en automatisk distribuere afviklingen af applikationen ud på grid et, hvor én eller flere servere vil sørge for at applikationen afvikles. På denne måde kan den normale og forventede performance opretholdes [Berstis, 2002: 1]. Ved særligt krævende computeroperationer, der kræver ekstra meget regnekraft, kan regnekraften distribueres ud på grid et som paralleliserede CPU-beregninger. Derfor kan resultatet returneres til brugeren langt hurtigere end hvis kun en enkelt maskine skulle beregne [ibid.]. Grid computing er hidtil primært blevet brugt i to sammenhænge, hvor der i begge tilfælde er tale om at opgaverne en grid-computer kan løse, skal egne sig til at være distribuerede, dvs. kunne deles op i opgaver der kan løses parallelt [ibid.: 3]. De to typer af grid computing er beskrevet nedenfor: Computerkraft eller lagerplads, udbudt fra et datacenter. Grid-teknologi bruges til at håndtere hardwaren og dele den op i enheder der kan sælges som IT-ydelser, for eksempel opdelt i storage og regnekraft. Denne type grid kan både anvendes som et intragrid (som en intern arkitektur) eller som et intergrid (sammenkobling af grids med forskellige geografiske lokationer) [ibid.: 12-14]. En virtuel supercomputer, hvor løst koblede computere af forskellige slags arbejder sammen på at løse problemer der kan distribueres og paralleliseres. Computerne kan eksempelvis være almindelige desktop-computere hos privatpersoner. Denne form for grid ses ofte anvendt til at løse videnskabelige problemer. Eksempler herpå er 1 der beregner proteinkæder til brug for medicinsk forskning, og 2 der søger efter mønstre i data indsamlet fra antenner, som opfanger radiobølger fra rummet. Denne form for grid kan også kaldes for et intergrid, men anvendes ofte til ikke-kommercielle formål [ibid.: 14]. 1 Læs mere om 2 Læs mere om Side 48

51 Som antydet ovenfor, er det at knytte mange hardwarekomponenter sammen til én stor supercomputer ikke nyt. Det har været anvendt i mange år, f.eks. i forbindelse med at lave cluster-computers [ibid.: 16]. Forskellen mellem grid computing og cluster computing er, at der i et grid er en løsere kobling mellem nodes (computere der er medlemmer af grid et), samt at grid et i den sidstnævnte form har tendens til at være mere heterogent. Heterogeniteten gør sig især gældende i forbindelse med krav til den hardware og den lokation der benyttes. Intergrids kan være spredt geografisk over mange lokationer og bestå af mange forskellige typer hardwarekomponenter. Ensartethed i et heterogent grid kan i stedet opnås gennem ensartet operativsystem eller i nogle tilfælde på applikationsniveau (såsom og Grid computing er altså en arkitektur og en metode til at samle ressourcer i en fælles pulje. Der er i dette afsnit ikke redegjort for samtlige anvendelsesmuligheder for grid computere. Derimod kan vi efterfølgende gå i dybden med den kommercielle udnyttelse af grid computing til at løse forretningsrelaterede opgaver, herunder i form af CC. 2.3 Cloud Computing Vores definition af CC er som tidligere nævnt, at det er IT-ressourcer der kan distribueres og forbruges via internettet som services. CC er derfor grundlæggende teknologi der gør det muligt at skabe services og produkter der eksekveres på en gridbaseret platform og distribueres over netværk. Før vi nærmere beskriver hvordan CC realiseres, må det anskuesliggøres hvorfor en virksomhed skulle vælge at benytte CC Hvorfor er cloud computing relevant? Forrester Research påpeger tre områder, som især skaber udfordringer for dagens IT-afdelinger [Staten, 2008: 2]: Kapacitetsplanlægning er besværligt: En IT-afdeling må konstant føre tilsyn med at ITinfrastrukturen kan modsvare kapacitets- og ressourcebehovet i forretningen. Med pludseligt opstående behov for serverkapacitet eller regnekraft, må der derfor tages stilling til om den eksisterende kapacitet kan opfylde behovet, eller om der skal indkøbes supplerende ressourcer. Det gælder både hardware, software og medarbejderressourcer. Denne overvågning og planlægning i forhold til ressourceforbruget er en tidskrævende proces. Dårlig planlægning kan have negative konsekvenser for produktion, konkurrenceevne og forretningen generelt. Balancegang mellem forretningsbehov og ressourceudnyttelse: IT-afdelinger er fastlåste i forhold til konstant at skulle have kontrol med IT-udgifterne samtidig med at der hurtigt skal le- Side 49

52 veres ressourcer og funktionalitet til forretningen. The old answer of just give them a server doesn t fly anymore [ibid.: 2]. Testmiljøer: Forretningen kommer ofte til IT-afdelingen med ønsker om at få kapacitet og ressourcer til tests og andre projekter, som ikke direkte er funderet i en business case eller indgår i øvrige budgetter. IT can t afford to set up and manage an outside-facing play area - especially with today s security imperatives [ibid.]. De fleste IT-afdelinger er ikke organiseret til at kunne tilbyde kapacitet on-demand. Ønsker om testmiljøer og lignende giver derfor både økonomiske- og IT-sikkerhedsmæssige udfordringer i en traditionel IT-infrastruktur. Grunden til at CC er blevet relevant er at internetgiganter, som gennem mange år har bygget deres forretning på innovative former for infrastruktur og samtidig optimeret håndteringen, udnyttelsen og effektiviteten i deres datacentre, nu er begyndt at bygge en forretningsmodel på at distribuere deres infrastruktur som services. Amazon er et eksempel på en sådan virksomhed og CTO Werner Vogels, formulerede og begrundede Amazon Web Service s (AWS) eksistens på følgende måde på i sit foredrag på konferencen Structure 08: If managing a massive data center isn t a core competency of your business, then maybe you should get out of this business and pass the responsibility to someone who has. All you need is a credit card (Werner Vogels, citat fra hans indlæg på konferencen Structure juni 2008 i San Francisco). Ud over at besidde unikke kompetencer inden for håndtering af infrastruktur, drager virksomheder som Amazon følgende fordele: [Staten, 2008: 2-3] Økonomi og forhandlingskraft: Med gigantiske ordrer på infrastrukturkomponenter, har AWS stor forhandlingskraft i forbindelse med indkøb af servere, software og datacenter-support. Det giver samtidig mulighed for at drage store fordele af scale economies. Derfor kan serverkapacitet udbydes af AWS til en langt lavere pris end hvis serveren blev indkøbt af en gennemsnitlig IT-afdeling. Skalerbarhed: Amazon har ikke blot opbygget unikke kompetencer i håndtering og automatisering af infrastruktur, men har også udviklet interne værktøjer til at skalere og fordele ressourceforbruget over tusindvis af servere. Ekspertise i dynamisk håndtering af kapacitet: For virksomheder som AWS er ressourceudnyttelsen af deres infrastruktur altafgørende, idet prisen for AWS s services er proportional med prisen for driften og håndteringen af deres datacentre. Jo højere udnyttelse af ressourcerne, desto mere profitable vil AWS services derfor være. Derfor fører Amazon nært tilsyn med ressourceudnyttelsen for de enkelte services. Side 50

53 På baggrund heraf har CC karakter af at være en IT-leverancemodel, der vil kunne komme mange ITafdelinger til undsætning med de eksisterende udfordringer Realisering af cloud computing CC gør det blandt andet muligt at benytte fordelene ved grid computing uden at have hverken kendskab til, viden om eller ekspertise i at håndtere arkitekturen der ligger bag. Forskellen mellem CC og grid computing er, at CC benytter virtualisering og load-balancing til at håndtere og distribuere de ressourcer, som grid et repræsenterer. For at skabe sammenhæng og forståelse for forskellen mellem grid og cloud, kan man sige at grid computing er hardwarestrukturen der i praksis ligger til grund for CC: Cloud computing realiseres gennem et grid, men ikke alle grids indgår i cloud computing (jf. intra og intergrid). Hvor grid computing realiseres af hardwarestrukturen, realiseres cloud computing gennem software-teknologier som virtualisering og load-balancing, hvilket udvider anvendelsesmulighederne Virtualisering og load-balancing System/360, den første virtuelle computer, blev fremvist af IBM i 1960 erne. Det var første gang hardware påviseligt blev virtualiseret og opdelt i virtuelle instanser. Det betød eksempelvis at applikationer, som tidligere krævede dedikeret hardware, nu kunne afvikles parallelt på den samme hardware. I dag er virtualisering og partitionering af servere, processorer (CPU), lagerkapacitet og netværk blevet mere udbredt og implementeret i mange datacentre [Mendoza, 2007: 37]. Virtualisering kan implementeres på flere forskellige lag i en infrastruktur: (1) Server virtualisering, hvor en server med flere CPU er opdeles i mindre logiske partitioner (virtuelle instanser), som hver afvikler et selvstændigt operativsystem. (2) CPU-virtualisering afhænger af processortype. Et eksempel er en CPU virtualiseret som 1/10 processor. CPU ens ressourcer kan derfor allokeres til forskellige opgaver eller instanser. (3) Storage virtualisering, hvor fysiske harddiske opdeles i mindre logiske dele (partitioner). (4) Netværks-virtualisering, hvor tilgængelig båndbredde virtualiseres og allokeres til forskellige kanaler eller enheder. Eksempler er et Virtual Private Network (VPN), en firewall eller en load-balancer. (5) Grid virtualisering er virtualisering på serverniveau, hvor de virtuelle servere kan agere som én samlet ressource hvortil der kan allokeres mange forskellige computeropgaver [Mendoza, 2007: 37-40]. Side 51

54 Figuren herunder illustrerer en simpel arkitektur for CC hvor virtualisering anvendes: Figur 8 Cloud Computing Overview [Staten, 2008] Nederst ligger grid et, her illustreret med Commodity hardware infrastructure, hvilket vil sige almindelige computere/servere med en standardopsætning. Oven på grid et eksisterer de virtuelle servere, også kaldet skyen, som tildeles opgaver af én eller flere load-balancers (jf. grid engine). Fordelen ved en load-balancer er, at den fordeler opgaverne ud på de tilgængelige ressourcer, så der opnås en optimal udnyttelse af ressourcerne. Både virtuelle servere og load-balancers er i realiteten software, som giver mulighed for intelligent og automatiseret styring af de enkelte instanser og fordelingen af opgaver. Øverst i figuren er placeret de applikationer, som anvender skyen. Forespørgslerne fra applikationer sendes til en eller flere load-balancers, som herefter fordeler opgaverne på de virtuelle instanser. Virtualisering af servere har tre overordnede fordele: 1. En virtuel server opfører sig præcist som en hvilken som helst anden server. I et virtualiseret grid er ressourcerne frakoblet den underliggende hardware. Ressourcerne deles op i mindre stykker der kan arbejde på vidt forskellige opgaver på en standardiseret måde. 2. Når en server er virtuel, eksisterer den reelt i en fil. Derfor kan en virtuel server flyttes til et nyt sted, lige så let som det er at flytte en fil fra én mappe til en anden. Da CPU en, harddisken Side 52

55 og alt andet hardware også kan virtualiseres, kan disse ressourcer anvendes og omrokeres dynamisk uden at skifte fysisk hardware. 3. På samme måde som virtuelle servere kan flyttes, kan de også kopieres. Det at kunne kopiere en server gør det enkelt at skalere en applikation ud på mange servere efter behov. Ændringerne fra grid til cloud har nogle kapacitets- og performancemæssige omkostninger i form af overhead fra virtualisering. Overhead skyldes at der for at håndtere virtuelle ressourcer kræves ekstra computerkraft til at allokere og re-allokere ressourcerne [Wang et. al, 2007]. Som tidligere nævnt, kan ressourcer tildeles dynamisk, men også hér støder man på et loft. Ressourcerne der kan tildeles en enkelt virtuel server, kan ikke overskride de ressourcer der er til stede på værtscomputeren (fratrukket overhead ved virtualisering). Problematikken omkring overhead ved virtualisering er i øjeblikket en uundgåelig omstændighed, men fordelen er at det bliver muligt at bryde et grid op i målbare og brugbare instanser, som kan sælges og aftages som kommercielle services. En af de største spillere inden for virtualiserings-teknologi, VMware, forventer at kunne eliminiere dette overhead inden for 3 år [Barrett, 2007]. Dette vil gøre CC endnu mere atraktivt og besparende, da det spild der var forbundet med overhead altså påstås at forsvinde Cloud services En lang række virksomheder specialiseret sig i at kunne håndtere og vedligeholde CC-arkitektur på et niveau, så andre virksomheder kan gøre brug af arkitekturen og teknologien til at afvikle deres egne applikationer, opbevare data og i det hele taget basere en infrastruktur eller afgrænsede processer på. Udmøntningen er en række services, dvs. produkter, som kan være forskellige indgangsvinkler til at benytte CC Cloud service markedet CC kan inddeles i mange kategorier og adskilte services. Markedet er stort og der eksisterer et utal af virksomheder, som hver især bidrager med produkter der giver adgang til forskellige former for CC. CC kan siges at indeholde en hel taksonomi af forskellige servicetyper. En sådan taksonomi er anskueliggjort af Peter Laird [Laird, 2008]. Taksonomien findes i Bilag 5 og nedenfor er refereret de overordnede begreber, som eksisterer indenfor CC: Side 53

56 Type Funktion Leverandører Infrastructure public/private cloud Skalerbare computerressourcer on-demand. Håndtering af store datamængder og krævende beregninger. Amazon EC2, GoGrid, Joyent, Rackspace Services - Storage, Integration, Value-add Skalerbar storage af data/filer. Integrationsservices som skaber integration mellem cloud services. Supplerende services der integrerer billing og sikkerhed. Amazon S3+SQS, Microsoft, Google BigTable, Opsource Application-services - Applikationer udviklet til og hostet på en skalerbar cloud computing-infrastruktur. Også kendt som Software as a Service (SaaS) Salesforce.com, ZOHO, e- conomic, Google Apps, Netsuite Platform - Open/custom/tools Værktøjer der forenkler håndteringen af cloud computing. 3Tera, RightScale, Hadoop Figur 9 Cloud computing taksonomi, frit efter Laird [Laird, 2008] Disse services er ikke nødvendigvis adskilte, men kan integreres og anvendes i sammenhæng hos én og samme udbyder. Amazon er et eksempel på en CC-udbyder, som stiller flere typer af services til rådighed og er for nuværende den mest omtale udbyder af CC. Det skyldes formentlig at Amazon var blandt de første på markedet og samtidig har den bredeste vifte af tilgængelige services. Amazon er derfor også den udbyder vi ofte kommer til at referere til i de følgende kapitler. Derfor findes det relevant at give et leverandøroverblik møntet på Amazon Web Services: Side 54

57 Amazon Web Services (AWS) er et eksempel på en af de virksomheder der var først til at udbyde cloud computing. Amazon opbyggede fra starten sin forretning omkring traditionel e-business i kraft af at være en online-boghandel. Senere er Amazons sortiment udvidet til også at omfatte en lang række andre produktkategorier, herunder forbrugerelektronik. Gennem tiden er Amazon blevet omtalt som en af de største og mest succesfulde inden for e-business, med specialiseret teknisk ekspertise i håndtering af infrastruktur. AWS tilbyder både storage, rå computerkraft, message queuing og databasehåndtering som en service leveret over internettet. Disse services kræver en enorm IT-infrastruktur at kunne levere i stor skala. Amazon har i kraft af sin e-business gennem mange år etableret store datacentre til at servicere virksomhedens interne IT-behov. Disse datacentre er nu åbnet op for kommerciel anvendelse gennem AWS. Amazons cloud services går under den samlede betegnelse Amazon Web Services og består i dag af fem kerneservices: Simple Storage Service (S3), Elastic Compute Cloud (EC2), Simple Queuing Service (SQS), SimpleDB og Elastic Block Store (EBS). S3 som var den første service, tilbyder ubegrænset storage af eksempelvis billeder, dokumenter, video mv. S3 blev i 2007 suppleret af EC2, som tilbyder computerkraft og serverkapacitet på forbrugsbasis. De forskellige services er primært henvendt til enterprise-brug, men intet forhindrer private i også at anvende AWS. Som kunde betaler man kun for de services man reelt bruger. Eksempelvis er prisen pr. GB data man har opbevaret på S3 ca. $0,15 pr. måned. Desuden koster det mellem $0,10 og $1,20 i timen at anvende en virtuel instans på EC2 alt efter hvilken type man vælger. Både Linux og Windows kan afvikles på EC2. Tidspunktet hvor Amazon har taget skridtet og åbnet for adgang til anvendelse af deres ITinfrastruktur må siges at være strategisk fordelagtigt. Virksomheder står overfor at skulle gøre mere med mindre, og derfor ser mange sig netop nu om efter alternativer til at poste flere penge i deres egen infrastruktur. AWS giver mulighed for at virksomheder kan udvikle og afvikle deres applikationer på EC2 kombineret med data opbevaret hos S3. Og dette uden selv at indkøbe, installere og håndtere software, servere og harddiske. For at optimere AWS til enterprise-brug, har AWS etableret telefonsupport døgnet rundt og er i oktober gået fra Beta-version til endelig produktion. Derfor stilles nu både Service level agreements (SLA) på EC2 og S3 hvor der garanteres 99,95 % oppetid [Hoover & Martin, 2008]. Side 55

58 Som det fremgår af taksonomien, er Amazon langt fra enestående som udbyder af CC. Hvad taksonomien yderligere visualiserer, er at når man taler om CC, er der ikke tale om én sky. Der er nærmere tale om at hver udbyder har sin egen sky, hvorpå der tilbydes en række services. Når man køber en CCservice, har man ikke fysisk adgang til hardwaren eller de øvrige ressourcer der ligger bag. I stedet får man leveret en service over internettet uden at man behøver forholde sig til hvad der ligger bag. En misforståelse som stadig kommer til udtryk er, at internettet er skyen. Det er ikke tilfældet, men internettet er med sin enorme kapacitet det som foranlediger udvekslingen af enhver cloud service. Hvad der yderligere adskiller udbyderne er eksempelvis hvilken platform (linux, windows, solaris) deres sky er baseret på. Formuleringen at en service ligger i skyen, kan derfor ikke opfattes entydigt grundet leverandørernes forskelligheder. Der vil derfor være forskel på hvordan leverandørernes infrastruktur kan anvendes, hvilke standarder der understøttes, hvilken performance der tilbydes samt hvilke sikkerhedsstandarder der er tilknyttet. 2.4 Utility computing Utility computing er forretningsmodellen baseret på at sælge skalerbare computerressourcer som afmålte services. Der er grundlæggende tre faktorer som gør at denne forretningsmodel har vundet frem: Internettet; kan transportere data pålideligt over lange afstande Fordele ved konsolidering af IT-ressourcer; economies of scale taler for centralisering Cloud computing; virtuelle ressourcer kan distribueres og fordeles mellem mange samtidigt Det ligger i begrebet utility computing, at det er computerydelser leveret som en forbrugsafregnet vare i stil med el, vand, gas etc. Hvad angår elektricitet, kan man i dag sætte ethvert apparat til en stikkontakt og forvente at apparatet virker. Derfor kan el kaldes en General Purpose Technology (GPT) [Carr, 2008a: 15]. På samme måde er internettet i dag blevet en GPT hvorpå data uanset oprindelse, mængde og anvendelsesformål kan transporteres. En GPT har udgangspunkt i økonomiske betragtninger, da den opstår i kraft af at kunne konsolidere og distribuere forskellige anvendelsesformål og dermed være baseret på economies of scale, hvilket fragmenteret og lokal distribution ikke kan modsvare. Carr [Carr, 2008a] sammenligner skiftet mod utility computing med overgangen fra at bruge generatorer og vandkraftværker som forsyningskilder, til i stedet at bruge elektricitet fra centrale elværker. Lighederne mellem elektricitet og computing bliver tydelige når man kigger på hvem der udbyder og hvem der aftager og betaler for ydelserne. Når stikkontakter tændes og slukkes, tænker vi som forbrugere ikke over hvordan ydelsen er kommet dertil. Man stoler på at elværker har ekspertise til at levere en konstant forsyning i den forventede kvalitet. Side 56

59 Ideen med og argumentet for utility computing er det samme, nemlig at udbyde computerressourcer som services, uden at aftageren skal bekymre sig om hvordan disse ressourcer produceres og hvordan datacenteret bagved håndteres. Derfor bygger utility computing på CC. En generel kritik af Carrs el-analogi kan henføres til at elektroner er standardiserede, hvilket virksomheders data ikke er. Rækkefølgen hvori elektroner leveres er underordnet, men virksomheder vil stille høje krav til distribution af deres data og den rækkefølge de modtages og afsendes i. Der er givetvis flere kritikpunkter at nævne om Carrs analogi, men analogien indikerer logikken i udviklingen mod centraliseret distribution af computerressourcer. Internettet kan distribuere store mængder data og konsolidering af enhver type ressourcer har ofte vist sig økonomisk rentabelt. Den sidstankommende faktor, CC, er det, som har realiseret forretningsmodellen utility computing og leverance af cloud services. 2.5 Software as a Service Software as a service (SaaS) er et mere og mere populært alternativ til den traditionelle måde at anskaffe og benytte software, dvs. licens-baseret og lokalt installeret software. SaaS kan defineres som.software deployed as a hosted service and accessed over the internet [Carraro & Chong, 2006: 2]. I stedet for at købe softwarelicenser, som installeres på en eller flere klienter, abonnerer en SaaS-kunde på en applikation, som hostes af en SaaS-udbyder. SaaS-kunden behøver derfor ikke eje software for at kunne benytte den. Man lejer så at sige softwaren, og SaaS-modellen er baseret på betaling på abonnements-basis, det vil sige forbrugsafregnet. SaaS kan dermed anses som værende noget der kører ude i skyen. Dermed er SaaS-modellen én af de forretningsmodeller der kan bygge på CC. SaaS behøver dog ikke at være bygget på en CC-infrastruktur, og kan være hostet på normale webservere hos udbyderen eller udbyderens hosting-partner. Aftageren af SaaS-løsninger betaler efter forbrug og der afregnes enten pr. transaktion/forespørgsel eller pr. bruger der anvender applikationen. Dermed slipper aftageren for selv at vedligeholde, opdatere og drifte såvel selve softwaren, som den hardware, der kræves for at kunne afvikle applikationen. Side 57

60 2.5.1 SaaS-arkitekturen Nedenfor har vi opstillet en figur som illustrerer forholdet mellem SaaS-udbyderen og SaaS-kunden. SaaS udbydere SaaS - Udbyder SaaS - Udbyder SaaS kunder SaaS - Kunde SaaS - Kunde Internet Backend Databases Webserver http / https Firewall Firewall Users Figur 10 Software as a Service (egen udarbejdelse) Lagene under udbydere og kunder visualiserer, at der er flere kunder og flere udbydere. Det vil sige, at en udbyder kan udbyde SaaS til flere kunder, ligesom en kunde kan abonnere på applikationer hos forskellige SaaS-udbydere samtidigt. Derudover viser figuren at kunderne tilgår applikationer via internettet og at applikationerne kører på udbyderens infrastruktur. Det fremgår også af figuren, at SaaS-modellen åbner op for at flere virksomheder kan abonnere på samme applikation, hos samme udbyder. Antallet af kunder som kan anvende den samme applikation er den vigtigste forskel mellem tidligere software-modeller og SaaS-modellen. Deling af software og hardware mellem kunder kaldes multi-tenancy i modsætning til single-tenancy som er karakteristisk for C/S-modellen, hvor software kun afvikles på dedikeret hardware. Fordelene ved at være i et multi-tennant SaaS-miljø, kan forstærkes ved at opperere på en dynamisk og skalerbar CC-platform. SaaS kan betegnes som den mest benyttede og udbredte indgangsvinkel til at udnytte cloud services lige nu. Dette kom også til udtryk gennem de interviews vi gennemførte på studierejsen til San Francisco. Rejsen foregik i juni måned, og på daværende tidspunkt blev emnet CC konsekvent henført til hvordan SaaS fungerer og hvordan det gør brug af CC-arkitekturen. Side 58

61 2.6 Platform as a Service Platform as a Service (PaaS) er en af de nyere forretningsmodeller der bygger på CC. Med PaaS stilles en udviklings-, hosting- og drifts-platform til rådighed i én service. Brugeren af PaaS bekymrer sig ikke om skalering, kapacitet og allokering af ressourcer, da udbyderen står for dette, og leverer en komplet platform til webapplikationer. Skalerbarheden som udbydere af PaaS-produkter realiserer, opnås gennem en ensartet platform der kan benyttes af mange. Dvs. at der kan tildeles mange ressourcer til et multi-tennant-miljø med ressourcefordeling og load-balancing. PaaS er altså en hel stak af ITydelser, som tilsammen kan bruges til at udvikle (web)løsninger og applikationer. Koden der skrives til afvikling på en PaaS-platform skrives i mange tilfælde specifikt til én platform, og kan dermed være besværlig at flytte mellem forskellige udbydere. Da platformen benyttes af mange, har brugeren af PaaS ikke mulighed for at ændre eller tilpasse platformen. Udbyderen skal også sikre at platformen performer godt for alle kunder, og der er derfor begrænsinger i hvilke muligheder udviklere har på en PaaS-platform. Fordelene ved at have adgang til et vedligeholdt miljø der håndterer skalering, skal altså opvejes mod mindre kontrol over miljøet og begrænsning i de muligheder der er som udvikler og bruger af platformen. Virksomheder benytter allerede velafprøvede teknologier og platforme. Teknologier som JAVA (tomcat/jakarta),.net(iis, ASP og MSSQL) og såkaldte LAMP-stacks 3 er blandt mange andre blevet defacto-standarder i IT-miljøer. PaaS er altså oppe imod disse velafprøvede, robuste og udbredte teknologiplatforme, som virksomheder har opbygget betydelige kompetencer inden for gennem årene. PaaS er også en stak af komponenter, der stilles til rådighed for brugeren. Denne stak stak består af et miljø til afvikling af kode, et underliggende filsystem til at håndtere brugerens filer, en database og ofte pre-defineret funktionalitet og services, som gør det lettere at interagere med platformen. Følgende figur giver et enkelt overblik over PaaS, og hvordan det hænger sammen med den underliggende infrastruktur, og applikationen der udvikles på platformen. 3 LAMP-stacs er en kombination opperativsystemet af Linux, Apache webservere, MySQL database-serveren og PHP programerings sproget. LAMP stack en består af opensource eller gratis komponenter, og er en af de mest brugte sammensætninger af teknologier til web-miljøer.(http://en.wikipedia.org/wiki/lamp_stack) Side 59

62 Figur 11 Platform as a Service [Cloudfeed.net, 2008] Brugeren af et PaaS-produkt, udvikler selv applikationen, og resten (infrastuktruren og platformen) leveres af PaaS-udbyderen. PaaS er en komplet service, der søger at imødekomme alle udviklerens behov og samtidig sørge for skalering og ressourceallokering. På mange måder er det en elegant og ideel måde at tilgå CC, da friheden til selv at udvikle applikationer og systemer ligger hos aftageren, mens drift af platform ligger hos udbyderen. Forretningsmæssigt giver det nye muligheder for afregning mellem udbyder og aftager. Der opereres med flere forskellige revenue-modeller, hvoraf følgende er eksempler: Forbrugsafregning af CPU-cycles. Transaction-fees på kommercielle services At vælge en PaaS-udbyder kan som nævnt skabe en lock-in effekt for aftageren, da applikationer skrevet til en platform ikke kan flyttes til andre platforme. PaaS mangler stadigt at få det store kommercielle gennembrud, og vores erfaringer fra studierejsen til USA, og fra vores empiri-indsamling peger også på, at virksomhederne ikke ser PaaS som et reelt alternativ til deres IT-miljø. PaaS har derfor ikke vundet den samme accept i det profesionelle IT-marked som for eksempelvis SaaS har. Side 60

63 2.7 Cloud Computing overblik Kapitlet har behandlet mange tekiske begreber med relevans for CC. Som en opsummering af kapitlet er derfor opstillet en grafisk oversigt som samler og visualiserer begrebernes samhørighed. SaaS PaaS Cloud Computing Services Cloud Computing Grid Computing Hardware Figur 12 Cloud Computing-overblik (egen udarbejdelse) Der er tre indgangsvinkler til at udnytte CC. SaaS og PaaS er produkter som bygger på CC, men kunden har ikke direkte adgang til de bagvedliggende ressourcer. Cloud services er anvendelse af de rå computerressourcer, som stilles til rådighed gennem CC. Sammenhængen mellem begreberne kan bedst forklares med en analogi. Hvis man forestiller sig et hus, kan SaaS betragtes som det at leje et hus der er fuldt møbleret og som man ikke selv skal vedligeholde. For at kunne bygge et hus, skal man blandt andet bruge musten og mørtel. Disse elementer indgår i alle huse der bygges og husets størrelse afgør hvor mange musten der skal anvendes. Disse elementer kan skitsere cloud services. Byggeelementerne kan også bruges til at etablere et fundament. Oven på fundamentet bestemmer man selv hvad der skal bygges. Dette kan skitseres som PaaS. Som det fremgår, er CC ikke et fysisk produkt. CC instantieres derimod gennem forskellige produkter og services. I figuren er dette netop skitseret som de tre forskellige indgangsvinkler. Vi har hermed skabt klarhed over hvad begrebet CC dækker over. Vores fokus ligger i resten af specialet ligger på cloud services. Side 61

64 Kapitel 3 Praktiske erfaringer med Cloud computing Til at vurdere den praktiske anvendelse af CC, har vi udført interviews med 3 virksomheder. Disse virksomheder har givet en indsigt i hvordan CC benyttes i faktiske IT-miljøer og indgår i virksomheders produktion. Først behandles og udledes vigtige resultater fra denne empiri, for sidenhen at analysere resultaterne i kombination med teorier vi mener gør sig gældende for CC. 3.1 Empiri For at afdække hvordan CC anvendes i praksis, har vi indsamlet nogle erfaringer gennem interviews med tre forskellige virksomheder. De anvender alle CC i en eller anden form som en del af deres forretning Sammenfatning af empiri Nedenfor er opstillet et skema som sammenfatter resultaterne fra empirien. Sammenfatningen er opstillet ud fra generelle områder, der tilsammen skitserer hvor og hvordan de tre virksomheder anvender CC. P Produkt/Service Webhotel, mailbokse. Håndterer 5-6 mio. mails dagligt Browser-plugin. Ansigtsgenkendelse på billeder fra internettet. System til hosting/håndtering af podcasts. Hvorfor anvendes cloud computing? Driftsproblemer. Kritiske leveringstider på e- mails grundet stigende mængder spam. Har oplevet at miste mails sendt over en 3- timers periode. Billigt alternativ til selv at varetage en krævende infrastruktur der kan skalere i stor skala. Aldrig haft intentioner om eget datacenter. Produkt afhænger af stor regnekraft. For dyrt at drifte services internt. CC er mere rentabelt og fleksibelt. Ønske om få medarbejdere. Skalering meget vigtigt. Hvad anvendes cloud computing til? Bekæmpelse af spam. Automatisering af spamhåndtering og filtrering. Lagring af billedmateriale (S3). Test-miljø: EC2 anvendes til at teste før udrulning i eget datacenter. Bearbejdning af billeder ved forbedring af algoritme Alle services afvikles i skyen (AWS). EC2OnRails håndterer EC2- instanser. Backup af MySQLdatabaser på S3. Side 62

65 (EC2). Web-crawler til indeksering af billeder fra internettet (EC2). Cloud services - Virtuelle instanser, storage. Virtuelle instanser, storage, Kø-system. Teknisk setup Egen interne sky med horisontal skalering. Elastisk mail-server setup. Kapacitet afspejler forbrug og behov. Udviklings- og driftscenter i Polen, hvorfra også kerneproduktet og websitet hostes. Intern infrastruktur Suppleret med storage på S3. Samtlige services + website afvikles via AWS. Kombination af EC2, S3 og SQS. Load-balancing der bygger på 90% CPU-loadgrænse. Udbyder Egen sky Amazon Web Services Amazon Web Services Andre udbydere overvejet PaaS hos Google Google, virtuelle servere - Virtualisering Nej Ja Ja Indflydelse på forretning og økonomi? Minimerer overforbrug af servere. Kan opretholde serviceniveau og dermed holde på eksisterende kunder. Betaler i dag ca. $ pr. md. for AWS-forbrug. Egen implementering af tilsvarende kapacitet urealistisk og for dyrt. Forbrug efter behov er strategisk vigtigt. Opnår hurtigt ønskede resultater. Vigtigt at kunne skalere ned igen. CC er grundlaget for PCMs forretningsmodel. PCM kan ved at bruge AWS fokusere på sine kerneservices og på at forbedre disse. Begrænsninger og udfordringer IT der understøtter kerneforretningen ønskes pt. ikke placeret eksternt. Begrænset forhandlingskraft over for leverandører. Ønsker ikke at bruge AWS til real-time-kritiske processer. Servicen afhænger af korte svartider. Kræver relationel database-setup. Har oplevet nedbrud på S3, men ser det ikke som et større problem. Erkender at fejl også ville ske internt. Meget af PCM s kode læner sig op ad SQS. Dette skaber lock-in. Ser ikke begrænsede SLA er som et problem. Figur 13 - Sammenfatning af empiri (egen udarbejdelse) Side 63

66 Referater af interviewene med Surftown, Polar Rose og PodcastMachine.com kan desuden findes i hendholdsvis Bilag 2, 3 og 4. Ved en nærmere opdeling, skiller Surftown sig ud ved at bruge CC som en intern arkitektur, idet virksomheden har etableret sin egen interne sky. Surftown bruger altså ikke cloud services fra en udbyder, men står selv for driften, om end med en række fordele, som vi kommer nærmere ind på. PolarRose bruger en række cloud services som en del af deres produkt, men samtidig har PolarRose nogle forbehold af teknisk og strategisk karakter, som gør, at de har udvalgt områder af forretningen som bruger CC. Endelig har PodcastMachine, som både er den mindste og yngste virksomhed af dem vi har interviewet, valgt at etablere stort set hele sit produkt og sin infrastruktur på CC. PodcastMachine er derfor den virksomhed som har de største erfaringer med at anvende CC, og samtidig udtrykker vores informant fra PodcastMachine holdninger, som adskiller sig radikalt fra hvordan man traditionelt set har tænkt i infrastruktur. Dette kommer vi nærmere ind på i forbindelse med behandlingen af de enkelte interviews Surftown Surftown behandler dagligt 5-6 millioner mails. Over 90 % af disse mails er ifølge driftschefen spam, som Surftowns spam-filter skal analysere og filtrere fra. Surftown har valgt at etablere en cloudlignende arkitektur for netop at blive i stand til bedre at håndtere spam-bekæmpelse. Mængden af spam har længe udgjort et problem for Surftowns driftsstabilitet, da der konstant stilles større krav til kapacitet i forbindelse med filtrering af spam. Det har i en af de mest problematiske perioder betydet at Surftown har mistet samtlige mails sendt over en 3-timers periode - en hændelse som driftschefen naturligvis erkender aldrig må ske. I erkendelse af at udfordringerne og de økonomiske komplikationer ved konstant at skulle udvide kapaciteten af mailservere, har Surftown valgt at etablere sin egen sky. Driftschefen beskriver setup et som et elastisk mail-server setup, hvor kapaciteten konstant følger ressourceforbruget og behovet. Setup et er illustreret nedenfor. Side 64

67 Mail afsendere Surftown kunder Internet Surftown Load-balancer Spam Spam filter nodes Surftown kunders inbox Figur 14 - Surftown setup (Egen udarbejdelse) Vi har valgt at kalde Surftowns setup for en cloud-agtig arkitektur. Det skyldes at Surftown ikke bruger virtualisering af deres mailservere, men nærmere et grid, hvor en load-balancer dynamisk eksekverer mail-filtreringen på det antal servere der er behov for. Surftown har fravalgt virtualisering af mailserverne for at undgå det overhead, som en virtualiserings-engine medfører. Som driftschefen selv tilkendegiver, er det i det konkrete computerproblem ikke hensigtsmæssigt først at dele ressourcerne op i mindre dele, for derefter at samle dem igen til et homogent formål som spam-filtrering. Setup et er yderligere organiseret efter at en server i gennemsnit skal have 90 % cpu-load. Når gennemsnittet når 90 %, startes en ny spamfilter-server automatisk op. Surftown bruger altså muligheden for dynamisk skalering og automatisk load-balancing, som er væsentlige teknologier i CC. At grid et ikke er virtualiseret er dog årsag til, at vi ikke vil kalde Surftowns setup for en cloud-arkitektur. Det mest interessante ud over et grid et af servere er load-balanceren, som distribuerer forbruget ud på mange servere og automatisk tilføjer flere servere efter behov. I praksis er det som Surftown har gjort at fokusere på at skalere ud, dvs. tilføje flere nodes, i stedet for at skalere op, dvs. tilføje mere kapacitet i eksisterende nodes. Driftschefen bruger selv begrebet best bang for the buck, refererende til en undersøgelse foretaget af processorgiganten Intel. Undersøgelsen viser at den bedste ressourceudnyttelse af en server opnås, når serveren ligger på ca. 90 % i CPU-load (utilization). Surftowns setup er derfor bygget op omkring dynamisk skalerbarhed, hvor der altid kun er startet det antal servere der Side 65

68 reelt er behov for. Udover at give bedre driftsstabilitet, opnås hermed bedre udnyttelse af kapaciteten, ligesom strømforbruget og udgifterne til eksempelvis køling i datacenteret minimeres. Surftown har overvejet at benytte Googles enterprise cloud til at eksekvere filtreringen. Men det at kunne tilbyde et intelligent spamfilter, anskues som et konkurrenceparameter i branchen, hvorfor Surftown anser det for at være risikabelt at lægge så vigtig en del af kerneforretningen ud til en udbyder. Andre parametre, som ligger til grund for beslutningen, er begrænset forhandlingskraft overfor udbyderen, og driftschefen er heller ikke overbevist om, at det rent økonomisk vil være fordelagtigt. Surftown har gennem mange år opbygget eget datacenter og ser det som oplagt at udvide dette datacenter efter nye behov, frem for at købe sig til services PolarRose Kerneproduktet for PolarRose er en algoritme der kan identificere og genkende ansigter på billeder. Funktionaliteten anvendes blandt andet i et browser-plugin, som brugeren installerer og som efterfølgende eksekveres automatisk i browseren. PolarRose har desuden også udviklet sin egen web-crawler til at gennemsøge nettet for billeder som lagres til efterfølgende analyse. De billeder brugeren af plugin et får vist i browseren, sendes til analyse hos PolarRose og returneres med resultatet. Er der match mellem ansigterne på billederne, placeres en lille rose på billedet og med mouse-over får man vist hvem personen på billedet er. Funktionaliteten kræver at data analyseres i real-time. Derfor kan der i perioder være behov for stor kapacitet, mens der i andre perioder er et begrænset kapacitetsbehov. Behovet for at skalere kraftigt i perioder er den primære årsag til at PolarRose har valgt at bruge CC. Herunder er opstillet en figur, som viser setup et samt en forenklet skitsering af flowet mellem de anvendte services: Side 66

69 Polar Rose Datacenter S3 Storage EC2 Polar Rose brugere (med browser plugin) Real time processering Internet Website (Search engine) Internet brugere Billed data On demand processering af privat data Reprocessering af billedmateriale Testmiljø Indeksering og behandling B2B kunder Webcrawler Figur 15 - PolarRose setup (Egen udarbejdelse) Setup et er svært at visualisere på enkel vis. Figuren forklares i det følgende nedefra. EC2 anvendes til flere formål. Web-crawleren afvikles på EC2-instanser og indsamler store mængder billedmateriale, som lagres på S3. Indeksering og behandling (processeringen af billedmateriale og skalering af billeder) eksekveres også på EC2-instanser. Reelt ligger alt PolarRose s billedmateriale på S3. Endelig arbejdes konstant på at forbedre algoritmen der analyserer billederne. Når der er behov for at teste algoritmen på billedmaterialet, kan PolarRose på få minutter etablere et testmiljø på EC2 og teste algoritmen i stor skala for at se om den er klar til at gå i produktion. Denne mulighed gør det enkelt og hurtigt for PolarRose at opnå resultater, som det under andre omstændigheder ville være dyrt og tidskrævende at opnå. S3 bruges også til mellemlagring af billeder der skal re-processeres. Derfor er der i perioder behov for høj skalerbarhed med hensyn til storage. Web-sitet med en billedesøgemaskine hostes i eget datacenter og henter billeddataene fra S3. Selve real-time-processeringen, dvs. input til plug-in et, sker i PolarRose s eget datacenter i Warsava. Til grund herfor ligger at analysen er en tidskritisk faktor, som er afgørende for plugin ets performance. Selvom EC2 ville være oplagt at bruge til dette formål, mener PolarRose ikke svartiden ved brug af AWS er tilstrækkelig lav. CC bruges altså ikke i real-time, men primært til at teste optimering af algoritmens funktionalitet og processering af billeder. Desuden indgår der i PolarRose s setup en relationel database, som det pt. ikke er muligt at hoste på AWS (AWS tilbyder kun SimpelDB som er en ikke-relationel database). Side 67

70 Jan Erik Solem (stifter og CTO) giver tilkende at det er strategisk vigtigt for PolarRose at kunne forbruge efter behov og at det samtidig er muligt at kunne skalere ned igen. Eksempelvis betyder denne faktor at PolarRose på få minutter kan have et komplet testmiljø kørende, som efterfølgende blot kan lukkes ned igen. Udgifterne til AWS ligger typisk mellem $ pr. md. og det ville for PolarRose være helt urealistisk selv at drifte den anvendte kapacitet. Det er en rigtig stor fordel for os, at vi ikke skal bekymre os om redundans, backup og drift af et sikkert og professionelt datacenter, men blot bruge efter behov. Det ville være nærmest umuligt at indkøbe ressourcer til at kunne skalere i samme grad som EC2 og S3 giver mulighed for. En interessant iagttagelse er, at EC2-instanserne er mindre effektive end dedikeret hardware. Jan Erik påpeger at det, udregnet i Gigaflop pr. dollar, bedre kan betale sig at bruge dedikeret hardware. Derfor er PolarRose opmærksomme på fordelen i at udnytte ressourcerne der betales for fuldt ud. Her er det i stedet skaleringsmulighederne der er argumentet for at bruge CC. Dele af PolarRose s systemarkitektur er så tæt forbundet at responstiden er en kritisk faktor. Derfor ses pt. ikke mulighed for at benytte CC i yderligere sammenhænge. Det vil for mange lyde risikabelt at basere så vigtig en del af kerneproduktet, billederne, på en cloud service. PolarRose har også oplevet kortere perioder med nedetid på S3, men har ikke oplevet det som kritisk for kerneproduktet PodcastMachine Samtlige PodcastMachines (PCM) produkter er baseret på CC og udbyderen er AWS. Egen hosting og drift af services har aldrig været overvejet af PCM. CC er ideelt da PCM fra starten har haft et ønske om at begrænse virksomhedens størrelse så meget som muligt, men samtidig have stor kapacitet og regnekraft til rådighed. Magnus Andersen (medstifter af PCM) tilkendegiver at det at være frigjort fra de hardwaremæssige overvejelser, gør PCM i stand til udelukkende at fokusere på kernekompetencerne og på at forbedre de eksisterende produkter. PCM bruger EC2, S3 og SQS, dvs. de tre mest udbredte services fra AWS. Desuden benytter PCM EC2OnRails 4 til styring og automatisering af deployment på sine EC2-instanser. I EC2OnRails er også indbygget backup-funktionalitet til S3, hvilket har gjort det let for PCM at holde styr på sine data. Figuren herunder skitserer det setup PCM bruger. Desuden indeholder figuren en simpel skitsering af de overordnede processer hvor CC anvendes. 4 For mere information om EC2OnRail se: Side 68

71 Internet brugere B2B kunder Podcast Machine Services Website og søgning Podcast feeds og download Transcoding af lyd EC2 Virtuelle instanser Processering og database SQS Kø service Internet Kø og prioritering S3 storage Lydfiler og backup af database Figur 16 - PodcastMachine setup (Egen udarbejdelse) Setup et bygger på en høj grad af automatisering i fremstillingen af det som er kerneprodukterne for PCM. Magnus (medstifter) mener generelt at hardware er for dyrt og tungt selv at håndtere. Han udtrykker sin holdning således: Med en åben indstilling og fornuftig arkitektur på de services en virksomhed laver, opnås store fordele ved at tænke i internetservices, både interne services forbundet med infrastruktur såvel som eksterne services. I lighed med holdningen hos PolarRose, mener Magnus at det at opbygge og drifte et datacenter er en krævende disciplin, som skal mestres for at få et tilstrækkeligt udbytte. Magnus, som tidligere har været driftschef hos Krak, uddyber yderligere sin holdning idet han siger det leder til en beslutning, hvor virksomheder må prioritere hvad de vil smide deres tid, penge og energi efter, om det så er teknik eller produktet. Skalering og automatisering er vigtige områder for PCM og er reelt det som realiserer produktet. Ved at lade en udbyder som AWS tage sig af teknikken bag, kan PCM i stedet koncentrere sig om kerneprodukterne. Med hensyn til strategiske overvejelser, lægges ikke skjul på at CC alene for PCM er en enorm fordel. Anvendelsen af SQS (AWS s kø-system) skaber dog en risiko for lock-in. Meget af den kode som PCM s services bygger på, er tilpasset SQS, hvorfor det vil være krævende og omfattende at skifte til en anden Side 69

72 udbyder. Det potentielle lock-in, mener Magnus dog opvejes af de ressourcemæssige besparelser ved ikke selv at skulle udvikle sit eget komplekse system. PCM ser det ikke som et større problem at der i nogle tilfælde ikke gives SLA er på cloud services. Ifølge Magnus kræver SLA er en stor indsats at følge op på. Han mener endda der er bedre chancer for at få penge tilbage i forbindelse med brudte SLA er hos Amazon, end at få traditionelle udbydere som IBM og CSC til at overholde de garantier der stilles i SLA er Opsummering Vores empiri tegner et billede af tre virksomheder som er meget forskellige i deres måde at benytte CC. Man kan placere virksomhederne på en skala i forhold til måden de anvender CC på. Yderst til venstre ligger Surftown, som bruger princippet om en cloud-lignende arkitektur. Surftown er ikke interesseret i at lægge forretningskritiske systemer i skyen, men eksperimenterer primært med teknologien internt. PolarRose ligger nogenlunde i midten, idet de har udvalgt områder og processer som passer godt til CC. PolarRose har ligesom Surftown gjort sig nogle arkitekturmæssige, økonomiske og strategiske overvejelser om hvad der egner sig til at ligge i skyen og hvad de bedst selv kan drifte. Yderst til højre ligger PCM, som har valgt at basere hele sin infrastruktur på cloud services. Som det kommer til udtryk gennem interviewet med PCM, har Magnus en række holdninger, der adskiller sig radikalt fra hvordan andre virksomheder opbygger deres infrastruktur og services. Anatomien i PCM s IT-behov egner sig desuden godt til CC, hvilket har styrket grundlaget. Vi har altså at gøre med virksomheder, som bevæger sig over et bredt spektrum i forhold til deres anvendelse af CC. Af empirien kan udledes nogle faktorer som har betydning for hvordan CC kan anvendes i praksis. Analysen i næste afsnit vil gå i dybden med at redegøre for disse faktorer. Side 70

73 3.2 Analyse af cloud computing i praksis Der kan identificeres nogle faktorer i empirien som vi ønsker at analysere og dokumentere nærmere. Desuden ønsker vi at forholde os kritisk til den måde virksomhederne allerede anvender CC på, og vi ønsker gennem analyse af deres infrastrukturmæssige og strategiske overvejelser, at danne et billede af hvor og hvordan CC bedst finder anvendelse. I analysen inddrages løbende tekniske og strategiske teorier og begreber, som gør det muligt at reflektere over den praktiske anvendelse af CC, som empirien har afdækket. Analysen er struktureret således: Skalerbarhed er for de tre virksomheder et af de primære incitamenter for anvendelse af cloud services. Derfor vil analysen af dette områdes betydning fokusere på at afdække hvad skalerbarhed er, hvor det har relevans samt hvad det ændrer i forhold til en traditionel infrastruktur. Teknisk anatomi dækker over hvordan et system er opbygget. Anatomien i et system har gennem empirien vist sig at have betydning for den arkitektur og det setup virksomhederne har lagt sig fast på. Analysen går i dybden med at behandle hvilke systemer og computerproblemer der egner sig til cloud computing. Økonomi er et område som for to af virksomhederne nærmest er en afgørende faktor for, at de er i stand til at udbyde de produkter og services de gør. Analysen fokuserer på, ud fra en økonomisk betragtning, at redegøre for hvorfor cloud computing kan være en fordel både for små og større virksomheder. Strategi og outsourcing er en analyse af de strategiske faktorer som virksomhederne giver udtryk for har betydning for de trufne valg vedrørende anvendelse af cloud computing. Her er eksempelvis emner som lock-in, fokus på kernekompetencer og overvejelser om outsourcing som alternativ til cloud computing emner, som behandles nærmere for at skitsere strategiske fordele og ulemper forbundet med cloud computing. Side 71

74 3.2.1 Kapacitetsplanlægning og skalerbarhed Behov for skalerbarhed kan ses som udtryk for at et kapacitetsbehov ændres over tid. Muligheden for at kunne skalere både op og ned med kort varsel er også et af de primære incitamenter for vores tre virksomheder til at benytte CC. Ofte holdes CC op mod at drive et in-house datacenter, og det er derfor relevant at kigge på hvordan der planlægges med kapacitet in-house versus med CC. I en traditionel infrastruktur vil skalerbarhed ofte være forbundet med enten under- eller overkapacitet. Man må derfor foretage kapacitetsplanlægning for at sikre overensstemmelse mellem ressourcebehov og tilgængelig kapacitet. Kapacitetsplanlægningen kan for eksempel tage udgangspunkt i analyse af forventede belastninger, statistiske data over tidligere forbrug eller en konstant tilføjelse af ressourcer til et konstant stigende behov. Fælles for kapacitetsplanlægningsmetoderne er, at man mere eller mindre kvalificeret gætter sig frem til hvor meget kapacitet der skal tilføjes. Derfor må man sikre sig ved at tilføje lidt mere kapacitet end der forventes anvendt, for at undgå en situation, hvor der er for lidt kapacitet. Udnyttelsen af den samlede kapacitet søges altid at være så høj som muligt, for selvom nogle udgifter er variable alt efter belastning (slitage, strømforbrug, køling mv.), er langt de fleste og største udgifter de samme, uanset om systemer og netværk arbejder på fuld eller på halv kraft. Kapacitet og forbrug i et traditionelt datacenter med spidsbelastninger i visse perioder, kunne se ud som følger: 250% 200% 150% 100% Forbrug Kapacitet 50% 0% jan feb mar apr maj jun jul aug sep okt nov dec Figur 17 Forbrug vs. Kapacitet (egen udarbejdelse) Som det fremgår, er udnyttelsesgraden i datacentret lav det meste af tiden. Til trods herfor har datacenteret stadig uændrede vedligeholdelsesudgifter. Undersøgelser viser, at den gennemsnitlige serverbelastning i mange datacentre ligger på mellem 5 % og 20 % [Mendoza, 2007: 58]. Disse ekstraudgif- Side 72

75 ter er der en stor interesse i at holde så lave som muligt for at opnå den mindste margin mellem maksimum-forbrug og tilgængelig kapacitet. Er denne margin sat urealistisk lavt, eller opstår uventet højt ressourceforbrug, kan en situation med en belastning større end kapaciteten opstå. Figuren herunder viser en situation hvor kapacitetsbehovet ikke mødes: Figur 18 Capacity use I [Mendoza, 2007: 59] Figuren viser forskellen mellem det reelle forbrug, de uudnyttede ressourcer samt et tilfælde hvor kapaciteten ikke modsvarer behovet. Denne situation er kritisk for en virksomhed og for datacenteret, som netop skal stille den nødvendige kapacitet til rådighed, og tilfældet kan eksemplificeres med de driftsproblemer Surftown oplevede, hvor mailserverne ikke kunne følge med belastningen. Det er selvsagt et uønsket scenarie for virksomheder at operere med overkapacitet, men samtidig en løsning det har været svært at finde alternativer til(jf. afsnit 1.1). Selv ved traditionel outsourcing forbruges og betales der i mange tilfælde for overkapacitet, og fordelene ved outsourcing er nærmere stordriftsfordele ved konsolidering af IT-behov og begrænsede omkostninger til vedligeholdelse og drift. Den ideelle kapacitetsplanlægning må derfor være et scenarie hvor kapaciteten tilnærmelsesvist konstant følger ressourceforbruget: Side 73

76 Figur 19 Capacity use II [Mendoza, 2007: 60] I figuren herover følger kapaciteten tilnærmelsesvist behovet, hvorfor overkapaciteten minimeres. Der er dog hér tale om en ideel situation, som vil være vanskelig at opnå med en traditionel infrastruktur. Det understreger blandt andre Magnus fra PodcastMachine. Magnus har tidligere arbejdet som udviklingschef og driftschef i Krak og Unwire og har gennem disse jobs oplevet hvor svært planlægningen af kapacitet til tider kan være samt hvor tunge processer der ofte er omkring at få tilføjet ny hardware til eksisterende infrastruktur. Processen fra bestilling til udrulning af serverudstyr tog i mange tilfælde over en måned. Ovenstående illustrerer at kapacitetsplanlægning er svært og at behovet for at kunne udvide kapaciteten i perioder oftest fører til en uundgåelig overkapacitet i en traditionel infrastruktur Hvad er skalerbarhed? Mange overkapacitets- og driftsproblemer kan undgås med en skalerbar IT-arkitektur. Skalerbarhed er en egenskab, der bør indbygges i et system fra starten. Hvis systemerne ikke kan følge med den faktiske brug af dem, bliver hverken serviceniveau eller effektivitet god nok. Ingen kæde er stærkere end det svageste led og i komplekse IT-løsninger er det vigtigt at alle elementer understøtter den nødvendige og tilstrækkelige skalering til at sikre robusthed. [MVTU, 2003: 59]. Skalerbarhed skal altså sikres for at undgå flaskehalsproblemer, hvor systemerne ikke kan følge med forbruget. Skalerbarhed er ikke krav om en bestemt kapacitet, men et princip man kan arbejde ud fra og sikre at et system kan udbygges (eller begrænses), så det konstant dækker det aktuelle behov. Skalerbarhed har ikke relevans i forhold til et statisk behov, men må i stedet tilrettelægges efter hvor forudsigeligt et miljø givne Side 74

77 systemer, produkter og services opererer i. Derfor afhænger et systems behov for skalerbarhed i høj grad af systemets størrelse, rolle og anvendelse [MVTU, 2003: 60]. I klassisk forstand øges et skalerbart systems nyttevirkning proportionalt med de tilgængelige ressourcer. Det vil sige at hvis en given server har en responstid på 30 sekunder, vil tilføjelse af endnu en server resultere i en responstid på 15 sekunder. Selvom dette pr. intuition virker logisk, er det langt fra en realitet i alle IT-arkitekturer [Plaszczak, 2008: 2]. Nye muligheder for skalerbarhed er blevet tilgængelige i forbindelse med udbredelsen af CC. En model svarende til Figur 19 er blevet en realitet og tilbyder i dag ubegrænset skalerbarhed, som tilmed følger med ned når forbruget falder. Det kaldes dynamic scalability [ibid.] og vil i praksis sige, at hvis ressourcebehovet overstiger kapaciteten i den eksisterende hardware, vil et skalerbart system dynamisk få allokeret ekstra ressourcer til at opretholde den ønskede responstid og performance. Resultatet er at en applikation eller et system altid vil kunne opretholde den ønskede servicekvalitet. I praksis tjener klasisk og dynamisk skalerbarhed samme formål, nemlig at minimere IT-omkostninger og øge fleksibiliteten og evnen til at modsvare efterspørgslen fra brugere, kunder og markedet generelt [Plaszczak, 2008: 2]. Skalering kan i grove træk opnås på to måder [Wikipedia.org, 2008d]: Vertikal skalering Vertikal skalering (at skalere op) betyder at tilføje flere ressourcer til de(n) enkelte node(s), enten gennem hardwaremæssig opgradering eller ved optimering/tuning af kode. Horisontal skalering (dynamisk) Horisontal skalering (at skalere ud) betyder at der tilføjes flere nodes De to typer skalering kan bruges i kombination, men bygger i praksis på forskellige principper. På et tidspunkt vil man støde på en begrænsning med vertikal skalering, eksempelvis hvis en server ikke bliver hurtigere inden for økonomisk retfærdiggørelse ved at tilføje ressourcer. Her vil det i stedet give mening at benytte horisontal skalering for at opnå højere grad af proportionalitet mellem kapacitetsudvidelse og de øgede omkostninger. Horisontal skalering kaldes også dynamisk skalering, da det er den af de to skaleringsteknikker, som kan automatiseres og dermed være forbundet med lavere omkostninger samtidig med at behovet for kapacitetsplanlægning minimeres. Horisontal skalering er kun begrænset af hvor mange nodes der er tilkoblet. Det vil for enhver virksomhed have en naturlig økonomisk begrænsning hvor mange servere (nodes) der kan retfærdiggøres at indkøbe. Det er her CC- Side 75

78 udbydere som Amazon og Google kommer ind i billedet og tilbyder nær-ubegrænset skalerbarhed i deres datacentre, hvor forbruget kan konsolideres og spredes over mange brugere Hvorfor har virksomheder brug for at skalere? Behovet for skalerbarhed hænger uløseligt sammen med øget kapacitetsbehov. Vi befinder os i en transitionsfase hvor mange virksomheder kæmper for at optimere deres traditionelle infrastruktur til at kunne håndtere stigende og periodiske kapacitetsbehov [Plaszczak, 2008: 3]. Men kigger man på den eksplosive vækst i mængden af data og systemer, ser det ikke just lysere ud for disse virksomheder. Virksomheder er for længst begyndt at udnytte at virtuelle og digitale enheder er langt lettere at reproducere, distribuere og teste end fysiske. Plaszczak bruger eksemplet at det for en bilproducent er langt billigere at crash-teste en virtuel bilmodel end en fysisk. Transitionen betyder yderligere vækst af kapacitetsbehov og periodisk skalerbarhed. Vores empiri indeholder ligeledes eksempler på at periodiske kapacitetsbehov kan give udfordringer i forbindelse med kapacitetsplanlægning. Vi er i stand til at udpege følgende kategorier af kapacitetsbehov: Interne behov: PolarRose har i perioder behov for stor kapacitet i et testmiljø. Kapacitetsplanlægning eller skalerbarhed i en traditionel infrastruktur ville i dette scenarie kræve planlægning med en konstant overkapacitet, så testmiljøet ikke ville influere på øvrige systemers behov for kapacitet. Peak-perioder: PodcastMachine oplever store udsving i belastninger ved specielle events der podcastes. Dette bunder i selve produktets natur, som nødvendigvis må kunne skalere ved sådanne udsving alt efter interessen for givne podcasts. Da det på forhånd ville være svært at planlægge efter sådanne peak-perioder, ville PodcastMachine med en traditionel infrastruktur skulle operere med konstant overkapacitet af ressourcer for at kunne opretholde forventet service-kvalitet. Ydre påvirkninger: Surftown har haft driftsproblemer i perioder hvor bot-netværk 5 har skabt spam-storme mod Surftowns mail-servere. Dette er en udefrakommende påvirkning, som Surftown hidtil kun har kunnet planlæge sig ud af ved at tilføje yderligere mailservere for hver gang en spidsbelastning er opstået. I perioder hvor spam-belastning ikke har været problematisk, har Surftown haft en overkapacitet af servere, som alligevel skulle vedligeholdes og som 5 Bot-netværk: Netværk af computere der styres af hacker-grupper. Ofte er disse netværk enorme, og består af normale privatpersoners computere. Spredningen af computeren over geografiske lokationer og forskellige udbydere, gør det svært at dæmme for angreb mod bot-netværk. Side 76

79 jan feb mar apr maj jun jul aug sep okt nov dec Specialeafhandling: Cloud Computing I et teknisk og stratgisk perspektiv brugte strøm. Ydre påvirkninger af denne karakter, vil enhver virksomhed kun kunne planlægge efter ved at operere med en tilstrækkelig overkapacitet. Systemer med mere statiske behov vil det være nemmere at planlægge kapaciteten for, men som eksemplificeret ovenfor, opstår ydre og uforudsigelige påvirkninger og behov kan opstå og forsvinde med kort varsel. Som det også konkluderes af Plaszczak [Plaszczak, 2008], vil systemer som i dag har begrænset evne til at skalere kun møde større udfordringer fremover The question of IT system scalability is enevitable for any business in search of a successful and sustainable market presence [Plaszczak, 2008: 3] Dynamisk skalerbarhed med cloud computing Vores empiri viser at et væsentligt incitament for anvendelse af cloud services netop er den bekymringsfrie adgang til ubegrænset kapacitet, der kan skalere op og ned efter virksomhedens behov. Den form for skalering man opererer med i CC er dynamisk skalerbarhed, altså horisontal skalering. Fordelen herved er at CC-udbydere kan automatisere skaleringen og dermed spare en masse ressource- og vedligeholdelsesmæssige omkostninger. Realisering af dynamisk skalerbarhed igennem cloud services opnås fra udbyderens side ved at samle flere behov ét sted, og dermed dele den totale kapacitet mellem mange brugere. Når mange behov konsolideres, er der stor sandsynlighed for at behovene vil opstå på forskellige tidspunkter. Dermed behøver den totale kapacitet ikke være lig summen af alle kapacitetsbehovene ved spidsbelastning, men nærmere summen af gennemsnittet af alle behovene (plus lidt ekstra for at sikre konstant kvalitet). Scenariet kunne se ud som følger: 160% 140% 120% 100% 80% 60% 40% 20% 0% Forbrug A Forbrug B Forbrug C Forbrug D Forbrug E Samlet forbrug Samlet gennemsnit Figur 20 - Konsolidering af kapacitetsbehov (Egen udarbejdelse) Side 77

80 Figuren viser fem forskellige forbrug samt det samlede og gennemsnitlige forbrug. Når forskellige forbrug kan konsolideres og aftages fra samme sted egner forbruget sig til centralisering og udbud som en utility, hvilket vi tidligere har defineret. Skalering gennem cloud services realiseres ved at forbrugerne deler kapacitet med andre i et virtuelt miljø. Dette kan udelukkende lade sig gøre fordi den software der kører på serverne er afkoblet hardwaren og operer i et virtuelt miljø. Det er netop virtualisering som forenkler processen idet virtuelle instanser er nemme at re-allokere. Når datacenterressourcer er virtuelle og udbudt af en CC-udbyder, opstår der, som vist med figur 20, en naturlig spredning af forbruget. Ovenstående figur er en kraftig forenkling og et optimalt scenarium, men illustrerer den dynamik som giver store besparelser for udbyderen og nær-ubegrænset skalerbarhed for aftagerens systemer. CC-udbydere udsættes selvfølgelig også for svingende kapacitetsbehov, eksempelvis efter årstid, brancheaktivitetsperioder og tidspunkt på døgnet, men den større spredning og automatiske tilføjelse af kapacitet, giver fordele der er svære at opnå i en traditionel infrastruktur. Dynamisk skalering kræver distribueret problemløsning Software er traditionelt kodet til seriel eksekvering. Det vil sige afviklet på en enkelt computer med én CPU, hvor et problem opdeles i en serie af instruktioner som udføres én efter én [Barney, 2007]. Dette er skitseret nedenfor. Figur 21 - seriel beregning [Barney, 2007] For at kunne drage fordel af dynamisk skalering, er det imidlertid en forudsætning at computerproblemer kan løses med parallel computing. In the simplest sense, parallel computing is the simultaneous use of multiple compute resources to solve a computational problem [ibid.]. Når der benyttes virtuelle ressourcer leveret som en service, er det selve platformen der er skalerbar, og blot ved at bygge oven på platformen, er der ikke nødvendigvis opnået skalerbarhed. Virtuelle instanser er stadig begrænsede enheder med en maksimal kapacitet der er lig værtssystemets. Den dynamiske skalerbarhed opnås derfor ved at samle flere virtuelle instanser til at arbejde parallelt på den samme opgave. Side 78

81 Parallelisering af computerproblemer kaldes også distribueret computing og er skitseret med figuren nedenfor. Figur 22 - Paralleliserede beregninger [Barney, 2007] Dynamisk skalering (med eller uden anvendelse af CC) stiller operationelle krav til den type af opgaver som skal løses, da ikke alle opgaver egner sig til at blive løst med parallelisering. Ikke-egnede opgaver er afhængige af en seriel eksekvering. Nogle problemer er af natur distribuerbare og kan uden videre splittes op og fordeles på mange instanser. Et eksempel på dynamisk skalering hvor en opgave kan løses parallelt er visninger af et website, som figuren herunder illustrerer: Figur 23 Dynamisk skalering af website [Temme, 2006] Visning af et website egner sig særdeles godt til dynamisk skalering, da de enkelte sidevisninger har lav indbyrdes relation og der er intet krav om realtime-synkronisering mellem to brugere. Desuden er der gennem arv og begrænsninger i http-protokollen ikke gemt info der er relevant for den enkelte Side 79

82 session på serveren. Det betyder at eksekveringen af koden startes forfra hver eneste gang en bruger klikker og får en ny sidevisning. Et andet eksempel er batch jobs, som for eksempel kunne være Polar- Rose s behov for at nedskalere 1000 billeder, så de egner sig til webvisning. Dette computerproblem kan let fordeles på mange instanser, da nedskaleringen af ét billede ikke har indflydelse på skalering af de øvrige billeder. Et sådan problem kaldes inden for teori om parallel computing for Embarrassingly parallel - Some types of problems can be decomposed and executed in parallel with virtually no need for tasks to share data. For example, imagine an image processing operation where every pixel in a black and white image needs to have its color reversed. The image data can easily be distributed to multiple tasks that then act independently of each other to do their portion of the work. These types of problems are often called embarrassingly parallel because they are so straight-forward. Very little inter-task communication is required [Barney, 2007] Opsummering Computerproblemer skal kunne distribueres parallelt for at kunne løses med CC. Før man kan benytte CC, er det altså nødvendigt at undersøge om de systemer der skal være skalerbare understøtter dynamisk skalerbarhed og paralleliseret problemløsning. Vi har identificeret tre hovedscenarier hvor CC kan anvendes med stor fordel for at opnå skalerbarhed: 1. Distribueret problemløsning af komplekse opgaver Nogle opgaver er af natur for store til at kunne løses af en enkelt server. Når man bruger en søgemaskine og modtager resultaterne indenfor en brøkdel af et sekund, er det kun muligt fordi man i den brøkdel af et sekund har flere hundrede computere der arbejder på ens forespørgsel. Google har gjort det i mange år og Yahoo har været en stor og aktiv spiller i Hadoop-projektet 6, som er et open source-framework til at distribuere behandling af store datamængder på mange instanser (søgemaskiner). 2. Batch jobs (ikke-realtime bearbejdning af mange små eller store opgaver) I nogle sammenhænge er det acceptabelt at der kun arbejdes på én opgave ad gangen og at beregningen tager længere tid. Men er der for mange opgaver til at én server kan følge med, kan der skaleres ud ved at have flere servere til at tage opgaver fra en kø og arbejde på dem. Det er typisk ved analyse, konvertering eller bearbejdning af data at denne model er anvendelig. Spam-processering og billedkonvertering er eksempler på opgaver der kan løses som batch jobs. 6 Mere information om Hadoop: Side 80

83 3. Web-server workload-fordeling Websites der i perioder er udsat for høj belastning, kan med fordel afvikles i skyen, hvor de egner sig perfekt til dynamisk skalering og parallelisering. En ting er at være klar til og villig til at benytte cloud services, noget andet er at realisere udnyttelsen, og høste fordelene. Med tunge legacy-systemer, store investeringer i eksisterende systemer og teknologier, er CC ikke svaret på alle IT-opgaver. Der er dog, som skitseret i analysen, nogle oplagte områder hvor CC kan benyttes. Med en redegørelse for at skalerbarhed stiller krav til typen af computerproblemer og med udpegning af at skalerbarhed er et af de primære incitamenter for at anvende CC, må der være belæg for at sige at skalerbarhed er en dominerende faktor for anvendelse af CC. Når nye ITløsninger udvikles eller etableres løbende, bør en virksomhed derfor tage stilling til om givne systemer og computerproblemer egner sig til paralleliseret computing og dermed at skalere dynamisk i en cloud-arkitektur Teknisk Anatomi Teknisk anatomi dækker over hvordan et system er opbygget og hvordan det egner sig til specifikke formål. Anatomien i et system har gennem empirien vist sig at have stor betydning for den arkitektur og det setup virksomhederne har lagt sig fast på. Den fortsatte analyse søger at gå i dybden med at behandle hvilke karakteristika der er for IT-systemer samt undersøge om der ud fra disse karakteristika kan udpeges områder som egner sig særligt godt til CC. For at kunne undersøge hvorvidt CC kan benyttes til en given problemstilling/case, skal problemstillingens krav til computing evalueres. Vi har valgt at bruge betegnelsen teknisk anatomi for det at analysere på hvor egnet et system, eller en applikation er til CC. IT-Systemer kan være opbygget på vidt forskellige måder, og stille forskellige performance-krav til den underliggende infrastruktur der opereres på. Et eksempel fra vores empiri er PolarRose s arkitektur som gør det svært at lægge billedanalyse-servere til realtime behandling ud på AWS. Vi vil i det følgende analysere hvad der ligger til grund for disse problemstillinger. Ud fra empirien og egne erfaringer med IT-systemer, kan vi udpege nogle komponenter, som vil indgå i ethvert system. For at finde ud af hvor, hvordan og i hvilket omfang CC kan bruges i specifikke sammenhænge, mener vi der må være behov for en generisk kortlægning af de behov et IT-system har. Dette omfatter at kunne beskrive et systems overordnede tekniske og systemmæssige krav og fordeling af ressourcebehov. Med IT-system menes hér et website, en selvbetjeningsportal, en mailserver, et ERP-system eller lignende. IT-systemer kan analyseres med forskellige detaljeniveauer, helt ned til Side 81

84 binære problemstillinger. Vi ønsker dog at kigge på et lidt højere abstraktionsniveau, som giver et enkelt, men anvendeligt dokumentations- og evalueringsgrundlag for at analysere et givent system. Opdelingen af systemet i delkomponenter reflekterer den logiske og hardwaremæssige opdeling der eksisterer i mange systemer og addressere dermed de flaskehalse og udfordringer der kan opstå. Komponenterne vi har identificeret og arbejder videre med er: Logik (kode, beregninger, output etc.) Logik er selve kodeeksekveringen. Det vil sige de logiske opperationer og beregninger computeren laver, når en applikation afvikles. Applikationen kan have forskellige facader udad til. Filer (Grafik, dokumenter, HTML etc.) Filer er selve lagerpladsen, håndtering og organisering af filer. Nøgleordene inden for filhåndtering er kapacitet. Kapacitet kan deles op i lagerpladsen og båndbredden til omverdenen. Database (Opslag, sortering, udtræk etc.) Databasen giver en struktureret håndtering af store datamængder. Databasen bygger på de to andre lag (logik og filer), men isoleres alligevel, da relationelle databaser udgør en stor del af virksomheders IT-behov og er ofte en komponent for sig selv, adskilt på fysiske servere og platforme i mange systemer. Som tidligere behandlet, udfordres mange virksomheder af ønsket eller krav til at deres IT-systemer kan skalere. For at et system som helhed kan skalere, skal hver af disse komponenter kunne skalere, så der ikke opstår flaskehalse i systemet. I det følgende beskrives de tre komponenters indhold, og hvilken relevans og indflydelse CC har på disse, og deres evne til at kunne skalere Logik Logikken forholder sig til den beregningstunge del af systemet og er altså der hvor proccesorevalueringen af kode kommer ind i billedet. Det vil sige de logiske operationer og beregninger computeren laver, når et program eksekveres. Proccessorkraft måles i mange sammenhænge i gigaflops (bitoperationer pr sekund). Afregning efter gigaflops er dog ikke altid mulig eller tilstrækkelig. Der er også andre faktorer som RAM, svartider og IO-performance (Input/output til drev, hukommelse og netværk) der har indflydelse på ydelsen. Side 82

85 Når computerkraft skal købes som en service, er det altså en lidt abstrakt størrelse at købe. IBM og HP har forsøgt sig med at afregne computerforbrug efter gigaflops i sine datacentre. Med CC har udbyderne gjort op med denne måde at afregne for regnekraft, og giver forskellige bud på hvordan computing kan udbydes, aftages og afregnes som en service. Skalering af logik-komponenten realiseres med CC ved at der automatisk kan tilføjes flere virtuelle nodes. Dog er skalerbarhed ikke er en indbygget feature når et IT-system bygges på en CCinfrastruktur. Systemet skalerer ikke vel på en CC-infrastruktur, med mindre det i forvejen egner sig til distribuering og dermed dynamisk skalering Filer Hvor logikken er kernen i eksekvering af selve systemet, er filerne fundamentet for konsistens og lagring af de informationer der opereres med. Der stilles høje krav til sikkerhed og tilgængelighed af filsystemet, da det lægger fundament for lagring af både systemets logik, men også den data der arbejdes med i systemet. Et filsystems performance måles ofte i kapacitet i form af lagerplads, båndbredde (datamængde pr. sekkund) og oppetid. Mange IT-systemer har allerede et filsystem der er afkoblet fra den hardware resten af systemet afvikles på, gennem storagesystemer såsom Storage area network (SAN 7 ) og network attached storage (NAS 8 ). Med SAN og NAS er tanken om at tilslutte storage virtuelt til servere allerede udbredt og indarbejdet i mange virksomheder (om end ofte de større). Det er altså ikke nyt for virksomheder at indarbejde mere løstkoblede filsystemer i løsninger. Storage tilgået som en cloud service afregnes som en ekstern service, hvor skalerbarhed, sikkerhed, vedligeholdelse og availability er en del af servicen. I modsætning til logik-komponenten, er skalerbarhed på storage services en feature der følger med. Udfordringen i at implementere storage gennem en cloud service er i stedet at håndtere et filsystem virtuelt via et interface (f.eks. som en web service). 7 Definition af SAN: storage area network (SAN) is an architecture to attach remote computer storage devices to servers in such a way that, to the operating system, the devices appear as locally attached (http://en.wikipedia.org/wiki/storage_area_network) 8 Definition af NAS: Network-attached storage (NAS) is file-level computer data storage connected to a computer network providing data access to heterogeneous network clients. (http://en.wikipedia.org/wiki/network_attached_storage Side 83

86 Database Databaser er vitale dele af IT-systemer. Databasen bidrager med struktureret og generisk håndtering af store mængder data på en mere eller mindre standardiseret måde. Dermed kan databaser give en løsere kobling mellem selve logikken der udgør systemets funktionalitet, og den underliggende håndtering af datamængderne der arbejdes med i systemet. Relationelle databaser er blevet en defaktostandard for lagring af data i overvægten af virksomheders IT-systemer. Databaser benyttes som en selvstændig komponent i systemerne og kører ofte på fysisk adskilt hardware, og er som software leveret af en trediepart (så som Oracle, Mysql fra SUN, MSSQL fra Microsoft). Så selv om databaser opererer oven på rå regnekraft, hukommelse og lagerplads i et filsystem, hører den hjemme i en komponent for sig, da den er en isoleret, kompleks og konfigurerbar del af systemet. En udbredt tendens i dag er at datamængderne stiger kraftigt, hvorfor der skal håndteres stigende mængder data i databaser. Derfor er der brug for databaser som skalerer godt. Tendensen udfordrer brugen af relationelle databaser, da de teknisk set er sværere at skalere ud. Mange steder har det resulteret i unikke og specielt tilpassede computere eller mainframes som tager sig af databasen. Skalering af databaser foregår altså ofte ved at der skaleres op og tilføjes flere ressourcer til databasen. Men som tidligere nævnt, kan der kun skaleres op til en hvis grænse, og derefter skal der benyttes distribution for at kunne opnå større kapacitet (skalere ud). Når der skal skaleres ud, er der væsentlig forskel på hvor velegnede databaser er. Generelt er relationelle databaser sværere at skalere ud, da de ofte er afhængige af at have data samlet, så der kan laves sammenføringer på tværs af dataset (joins af tables). Dette løses dog mange steder med database-clusters, der replikerer hinanden og dermed får distribueret databaserne, så flere nodes kan løse de samme problemer. Denne form for skalering af databaser er yderst velegnet til databaser der enten skrives meget data til eller læses meget data fra. I tilfældet hvor der både skal kunne skrives og læses meget til den samme database, opstår der problemer med at synkronisere mellem de enkelte nodes. Denne synkronisering medfører ringe skaleringsvillighed, da hver eneste node der tilføjes skal synkroniseres med alle de andre. Dermed stiger datamængden der skal synkroniseres eksponentielt. Som en konsekvens af de relationelle databasers højere kompleksitet, har mange datatunge virksomheder taget konsekvensen og benytter ikke-relationelle database-setups. Søgemaskiner og større websites realiserer at kunne imødekomme det enorme antal forespørgsler de håndterer, ved at have udviklet en platform der er bygget til at kunne distribueres ud på billig standardhardware. Kvaliteten opnås altså gennem distribuering, og prisen holdes nede ved at operere med en arkitektur der håndterer fejl, og dermed mindsker behovet for dyre servere. Netop dette realiseres gennem grid computing og i mange tilfælde også gennem CC. Side 84

87 Konsekvensen af at benytte distribuerede ikke-relationelle databaser er, at dataene ikke er normaliserede og dermed fylder mere. Optimering af data gennem normalisering har længe været en vigtig faktor for databaseadministratorer og mange systemer er altså udviklet med relationelle databaser som fundament. Færdige datababase-services udbydes af CC-udbydere, men udelukkende som ikke-relationelle databaser. Til gengæld udbydes de ligesom storage services med indbygget skalerbarhed, vedligeholdelse og availability Intern og ekstern kommunikation i systemet De interviewede virksomheder har ikke en alt eller intet -tilgang til CC. CC giver mulighed for at købe sig til services i både stor og lille skala. Det er ikke nødvendigt at køre alle systemer eller komponenter i systemet ud i skyen, da systemer kan deles og flyttes i fragmenter. CC-services kan implementeres og indgå i løsninger der hostes i eget datacenter og dermed supplere hvor der er behov for ekstra kapacitet og skalering. I denne sammenhæng bliver afhængigheden af relationer og kommunikation mellem komponenter og eksterne systemer endnu vigtigere. Komponenterne kan altså indbyrdes være forbundet via internetforbindelse, og behøver ikke nødvendigvis at være placeret i samme serverskab. Ud over den indbyrdes kommunikation komponeterne imellem, er der også et behov for komunikation fra systemet og til omverdenen. Kommunikationen kan altså ses som enten internt i systemet eller eksternt: Internt i systemet er der komponenterne imellem relationer og et kommunikationsbehov, også kaldet båndbredde-behov. Vi mener ikke at krav til et system alene kan afdækkes ved at kigge på de tre komponenter isoleret, da deres indbyrdes relationer og krav til performance har indlydelse på det samlede systems ydelse. Dette gør sig især gældende når dele af et system eller dele af infrastrukturen i et system leveres som en ekstern service. Eksternt er der også krav til kommunikation til systemet i form af båndbredde og responstid til omverdenen. Det være sig over nettet, gennem en service-bus eller andet. Modeller hvor IT-services leveres over internettet stiller ekstra krav til denne båndbredde og tilgængeligthed. Med anvendelse af cloud services bliver kommunikationen mellem komponenterne en mere eksponeret faktor, da systemer kan sammensættes på tværs af udbydere. Som eksempel kan Polar Rose s setup nævnes, hvor de logiske beregninger udføres i eget datacenter, men filer lagres på S3 hos AWS. Forbindelserne mellem komponenterne, som før kun eksisterede internt i datacenteret, etableres nu over internettet til AWS. Netop komunikationen mellem komponenterne er også en afgørende faktor for at PolarRose s komplette system til produktion ikke kan baseres på cloud services. Krav til responstid og Side 85

88 båndbredde mellem den relationelle database og serverene der står for algortimen, gør for PolarRose s vedkommende yderligere brug af CC uegnet Opsumering Når et systems tekniske sammensætning skal analyseres, er det nærliggende at dele systemet op i komponenter der repræsenterer forskellige funktioner i systemet. Denne opdeling har resulteret i tre overordnede komponenter; Logik, Filer og Database. Disse komponenter repræsenterer ikke alene logiske forskelligheder, men også egentlige opdelinger i mange systemer. Med opdelingen i de tre komponenter, kan der fokuseres på performance og skalleringsvillighed hver for sig. Opdelingen synligører også nogle kontaktflader mellem komponenterne, hvorigennem systemet er afhængigt af at kunne kommunikere. Ved anvendelse af CC, er det oplagt at benytte opdelingen i komponenter til at differentiere hvor CC kan benyttes med fordel eller ej. Denne vurdering bør tages på baggrund af krav til de enkelte komponenter, men i høj grad også med hensyntagen til kommunikationen mellem komponenterne. Denne kommunikation ændrer karakter når dele af systemets fundament leveres som en service over internettet. Side 86

89 3.2.3 Økonomi Empirien afdækker at økonomiske argumenter hos de tre virksomheder vejer tungt ved beslutningen om at anvende CC. Der er overordnet fire argumenter, som gør sig gældende i forhold til virksomhedernes økonomiske incitamenter: Cloud computing: minimerer overforbrug af IT / servere / medarbejderressourcer medfører begrænsede up-front omkostninger er en billig og nem adgang til avanceret teknologi er en billig vej til stor kapacitet og regnekraft efter behov I analysen af de økonomiske faktorer der gør sig gældende for CC, tager vi udgangspunkt i disse incitamenter og søger akademiske argumenter for disse Overforbrug minimeres For at sammenligne de økonomiske fordele og ulemper ved anvendelse af CC mener vi, at det skal gøres klart hvad der sammenlignes med. CC er på mange områder så markant anderledes, at det kan være svært at sammenligne på lige fod med andrer former for IT-drift. Men ses CC som et alternativ til intern IT og outsourcet IT, mener vi dog at kunne udpeje nogle forskelle som bevirker at de økonomiske faktorer ændrer sig ved anvendelse af CC. Sammenligningsgrundlaget vi arbejder med kan inddeles ind i tre ærketyper: 1. Egen hosting af al infrastruktur. Virksomheden etablerer selv serverrum, køleanlæg, backup og personaleressourcer. 2. Outsourcing til partner. Virksomheden varetager selv dele af IT og infrastrukturen, men outsourcer andre dele som kræver specialiseret håndtering til en outsourcing-partner (jf. incremental outsourcing) [Applegate et. al., 2007: 338]. 3. Cloud Computing. Virksomheden køber cloud services, der kan benyttes isoleret eller i samspil med anden IT-infrastruktur. Hele eller dele af virksomhedens infrastruktur købes som færdige services, men kontrollen med systemer er stadig virksomhedens eget ansvar. I det første tilfælde varetager virksomheden selv al IT-drift, og er derfor afhængig af at besidde alle de kompentencer der skal til for at vedligeholde og udvikle datacenteret. Side 87

90 Outsourcing kan enten foregå ved at outsourcing-partneren varetager infrastrukturen på kundens lokation(er), eller via sit eget datacenter. I begge tilfælde er fordelen for kunden at problemer med drift og skalering sendes videre til partneren, der har IT-drift som sin kernekompetence og forretningsgrundlag. I modsætning til egen hosting, giver outsourcing adgang til stordriftsfordele for begge parter og samtidig mulighed for at fokusere på kernekompetencer og opnåelse af en mere gennemsigtig prisstruktur. [Applegate et. al., 2007: ] Med CC aftages vedligeholdte cloud services som brikker i virksomhedens infrasturktur. CCudbyderen gør dette i en så stor skala at meget få outspurcing partnere eller interne datacentre kan følge med. Men hvad betyder dette for økonomien i at anvende de forskellige typer IT-drift? Skalering og fokus på forretningens kernekompetencer er argumenter der ofte bruges for både outsourcing og CC. Derfor forsætter behandlingen med at analysere hvordan hver af ærketyperne performer i forhold til en economies of scale-betragtning. Economies of scale (EoS) kan defineres som følger: As a firm doubles output, the total cost of inputs less than doubles [Wikipedia.org, 2008e]. Vi analyserer ikke virksomhedens samlede output, da det er uden for scopet, men vi mener, at EoS kan bruges parallelt på andre faktorer. Den definition af EoS vi arbejdere videre med er dermed: Hvis en virksomhed fordobler sit behov for IT-ressourcer, og dette medfører mindre end en fordobling i de samlede omkostninger, skalerer virksomhedens IT-miljø økonomisk. Vi mener at kunne argumentere for at alle tre scenarier (intern IT, outsourcet IT og CC) skalerer økonomisk, da de alle eksponeres for fordele i forhold til: indkøb (gennem større forhandlingskraft), på infrastruktur (omkostninger pr. server bliver mindre), medarbejderressourcer (mindre overlap og overkapacitet) og automatisering (automatiseringspolitikker er mere effektive på et større setup). Men anskues de forskellige scenarier i forhold til hinanden, er der stor forskel på omfanget af besparelserne. Vi arbejder derfor videre med en hypotese om, at der for hvert af de tre scenarier er forskellige faktorer, som betyder at de skalerer fra forskellige udgangspunkter. Figuren herunder illustrerer hypotesen i form af forskellen på omkostnigner pr. kapacitetsenhed for hvert af de tre scenarier. Side 88

91 Kr. per Gigaflop Gigaflops Intern IT Outsourcet IT CC mega datacentre Figur 24 Economies of Scale (kr/gigaflop) (Egen udarbejdelse) Hver af kurverne viser, at der for alle tre scenarier skaleres godt, men også at de er forskudt på y- aksen, og dermed skalerer fra forskellige udgangspunkter. I det følgende argumenteres for denne forskydning ved at kigge på de økonomiske fordele og ulemper, der eksisterer for hvert af de tre scenarier. Faktorer der har indflydelse (positiv såvel som negativ) på den økonomiske skalerbarhed: Intern IT o Køb af begrænsede mængder udstyr giver lav forhandlingskraft. o Infrastruktur og investeringer der ikke øger kapacitet er en forholdsmæssigt stor del af de samlede omkostninger. o Personale til overvågning er dyrt. o Mindre krav til ekstern kommunikation. o Den højest mulige operationelle kapacitet og den maksimale kapacitet er identiske, hvilket medfører høje udgifter til overkapacitet og potentiel lav udnyttelsesgrad. Outsourcet IT o Der opnås stordriftsfordele når omkostninger til professionel infrastruktur og driftsprocesser deles med andre kunder. Side 89

92 o Heterogent miljø. Kunders forskellige systemer, forskellige hardware-typer og vekslende kapacitetsbehov fordyrer og komplicerer standardisering og genbrug. o Centralisering af kompetencer og medarbejderressourcer giver mindre udgifter til overhead. o Outsourcing-partneren skal have en del af kagen for at kunne skabe en forretning. Cloud computing i mega-datacentre o Afregning efter forbrug (ingen overkapacitet). o CC-udbyderens store forhandlingskraft overfor hardwareleverandører giver lave priser på hardware og infrastruktur. o Kapacitet og infrastruktur fordeles blandt kunder. Dermed mindskes udgifter til overkapacitet. o Automatisering sikrer lave udgifter til processer og arbejdsgange. o Skalerer op og ned, hvilket begrænser faste høje omkostninger for kunden. På baggrund af ovennævnte økonomiske argumenter for og imod de tre scenarier, kan scenarierne opsummeres med følgende: Intern IT skalerer økonomisk og rentabiliteten øges i takt med størrelsen Outsourcing skalerer bedre end intern IT på grund af stordriftsfordele, delt infrastruktur og centralisering af kompetencer Cloud computing skalerer bedre end outsourcet IT, da fordelene ved outsourcing suppleres med større centralisering af IT og kompetencer. Homogeniteten muliggør virtualisering og automatisering af drift og dermed lavere omkostninger. Samtidigt sikrer et multitennant miljø minimering af overforbrug Lavere opstartsomkostninger Det andet økonomiske incitatment, er forskellen på hvordan der betales for ydelserne. Med intern IT er der store opstartsomkostninger ved at etablere infrastruktur i et professionelt datacenter, hvilket også kan gøre sig gældende med outsourcet IT. Høje priser på udstyr og den omkringliggende infrastruktur der skal til for at drive et datacenter, medfører store opstartsomkostninger. Ved at anvende CC eller visse former for outsourcing (f.eks. managed hosting), lejer man sig til udstyr og infrastruktur. Ud over opstartsomkostningerne er det også relevant at kigge på de løbende omkostninger og sammenholde disse på tværs af de tre scenarier. Side 90

93 Til denne analyse benyttes teori om sunk costs 9 og marginal costs 10. Vi har i projektet Software as a Service I et strategisk kundeperspektiv, opstillet og argumenteret for to hovedscenarier for rentabiliteten ved at benytte SaaS. Disse hovedscenarier er i høj grad også gældende for CC, og kan ligeledes bidrage til at dokumentere økonomiske og strategiske faktorer. Figuren herunder viser to scenarier som i praksis vil gøre sig gældende: Udgifter A In-house IT/ outsourcing B Indkøb Cloud Computing C Tid Figur 25a CC vs. In-house IT/outsourcing (Egen udarbejdelse) Benyttes CC er der ingen eller meget lave opstartsomkostninger og mange udbydere opererer med månedlig bagudbetaling (marginal costs). Derfor er der forbundet meget få sunk costs. De to viste scenarier A-B og B-C kan beskrives således: 9 In economics and business decision-making, sunk costs are costs which cannot be recovered once they have been incurred.(http://en.wikipedia.org/wiki/sunk_costs) 10 In economics and finance, marginal cost is the change in total cost that arises when the quantity produced changes by one unit.(http://en.wikipedia.org/wiki/marginal_cost) Side 91

94 Scenarie A-B Scenarie B-C De løbende omkostninger ved at benytte CC er højere end omkostningerne ved at benytte inhouse eller outsourcet IT. Den forventede levetid for systemerne, såvel hardware som software, får en vigtig rolle i vurderingen af rentabiliteten. Størrelsen af sunk costs forbundet med indkøb af IT afhænger af indkøbenes værdi som et aktiv i virksomheden. Investeringer i IT er generelt ikke tabt i det øjeblik der er indkøbt, men visse investeringer er (sunk costs). Resten vil være bundet i aktiver der har en vis levetid og nedskrivningsrate. De løbende omkostninger ved at benytte CC er lavere end de ville være ved in-house IT eller outsourcing. Taget i betragtning at opstartsomkostningerne også er lavere ved at benytte CC, er CC klart mere rentabelt. Set fra en økonomisk betragtning taler dette klart for at vælge CC, men strategiske faktorer kan have indflydelse på det endelige valg. Figur 25b Forklaring til 25a Alt efter hvilket af de to scenarier der passer bedst på en virksomheds situation, kan det vurderes i hvor høj grad CC er en økonomisk attraktiv løsning for virksomheden. At opdele de økonomiske fordele i to scenarier er en overforsimpling, der ikke tager højde for andre facetter (fordele og ulemper), såsom strategiske og teknikse faktorer. Vurderingen af hvor CC bedst passer ind, er derfor mere ment som en af flere faktorer, der kan medtages når rentabiliteten af CC vurderes. Vi ser det som meget sansynligt at opstartsomkostningerne ved CC er langt lavere end ved indkøb af egen infrastruktur eller outsourscing. Dette skyldes den måde CC-udbyderens forretningsmodel hænger sammen (forbrugsafregning), hvor udbyderen dækker sine økonomiske udgifter gennem de løbende indtægter. Dermed er det udbyderen der har ansvaret og bekymringerne om life-cycle management på hardware og software, hvilket er endnu en faktor der giver aftageren en mere bekymringsfri tilgang til IT-ressourcer Billig adgang til avanceret teknologi Tredje incitament er adgang til avanceret teknologi til en langt lavere pris en tidligere muligt, der kan opnås gennem CC. Side 92

95 Denne faktor grænser til mere strategiske overvejelser, end dem af økonomisk karakter. Værdien i at kunne benytte et mega-datacenter, afhænger af det behov aftageren har, og hvorledes muligheden udnyttes. Polar Rose drager fordel af at kunne etablere et komplet testmiljø efter behov og PodcastMachine påpejede hvor komplekst det er at lave og vedligeholde et kø-system der er både sikkert og som skalerer. Dette kø-system stiller AWS til rådighed som en cloud service, afregnet efter forbrug. Køsystemet koster 1$ for kø-forespørgsler, og desuden ekstra for data ind og ud (samme pris som på AWS storage-service S3). For PCM medfører det masive økonomiske besparelser at kunne benytte og betale for denne service efter behov Billig adgang til kapacitet og regnekraft efter behov Fjerde incitament udledt af empirien er at kunne tilgå stor kapacitet og regnekraft efter behov. Hvor der ved egen drift af IT og ofte også ved outsourcing, betales for den maksimale kapacitet der er til rådighed, er CC meget fleksibelt. Som behandlet tidligere, har CC-udbydere muligheden for at koble kunders data og servere mere løst til hardwaren, og dermed fastlåses der ikke mere kapacitet til én kunde end der er behov for. Disse fordele kan udbyderne give videre til kunderne, og derigennem skabe et billigere produkt. Det kan illustreres som følger: Fleksibel kapacitet Fast kapacitet Kapacitet Kapacitet Tid Tid Figur 26 Kapactitet over tid (Egen udarbejdelse) Forskellen i omkostningerne ved at kunne aftage kapacitet på hhv. fast og fleksibelt grundlag, kan illustreres som det blå areal i graferne herover. Ved en fast og ufleksibel kapacitet, er der konstant kapacitet til rådighed, og der betales konstant for denne kapacitet. Ved en fleksibel tilgang til kapaciteten gennem CC, følger forbruget behovet og arealet er væsentligt mindre. Besparelserne forbundet med dette incitament afhænger af hvor store udsving der er i behovet og om anvendelsen understøtter dynamisk skalering. Side 93

96 Kan den kapacitet, der er behov for, følge den kapacitet der indkøbes bedre, er der potentielt store besparrelser at opnå. Dette gør sig især gældende i scenarier hvor kapacitetsbehov varierer meget, og dermed vanskeligører kapacitetsplanlægningen samt medfører overkapacitet ved en fast kapacitetsmodel (figur 26). Ud over at spare på kapaciteten i perioder med lav belastning, kan der også følges med ved en belastning der er større end det forventede maksimale forbrug. Alt efter konsekvensen af kapacitetsbehov der ikke mødes, kan dette også have økonomiske indflydelse. Uanset scenariet, er fleksibel adgang til kapacitet en tilstræbt egenskab, der i mange tilfælde kan give økonomiske besparrelser samt andre tekniske og strategisk fordele Opsumering Økonomien i at benytte CC blev brugt som et af hovedargumenterne i de virksomheder vi har interviewet. De økonomiske incitamenter mener vi, kan bakkes op af teorier om strategi og virksomhedsøkonomi, såsom Economies of scale, sunk costs og marginal costs. Derudover muliggør CC minimering af den margin der er mellem det faktiske behov og den kapacitet der betales for. Dermed opnås resursebesparelse og fleksibilitet. I det hele taget er der mange faktorer som er vanskelige at vurdere ud fra en ren økonomisk betragtning. Strategiske og tekniske faktorer har stor indflydelse; Om der opnås økonomiske besparelser eller ej, ændrer CC på de muligheder virksomheden besidder med hensyn til drift af IT. Benyttes økonomiske faktorer alene, kan henynstagen til andre vigtige faktorer derfor mistes, hvorfor en bredere vurdering er nødvendig. Økonomiske fordele der opnås er forskellige fra virksomhed til virksomhed. Mindre virksomheder har taget CC til sig, og mange bygger deres produkter og strategi på at kunne tilgå kapaciteten efter behov. Således er CC blevet en vital økonomisk parameter for disse mindre virksomheder, da de med CC opnår billig adgang med få opstartsomkostninger til avanceret teknologi og et skalerbart miljø. Gevinst proportionel med udgifter På konferencen Structure08 i San Francisco nævnte CIO en for en af de mindre virksomheder at virksomhedens indtjening, som dels var baseret på betalte abonnementer, dels på reklamevisninger, var stort set proportional med virksomhedens forbrug af cloud services. For denne virksomhed betød det således meget at kunne betale efter forbrug, da de var sikre på at øget forbrug vil kunne matches af øgede indtægter. For den slags virksomheder, er forventningerne til ROI på et system af en helt anden vigtighed. At benytte IT på forbrugsbasis kan give en langt lavere time-to-market, og endnu mere vigtigt en lavere time-to-scale. Side 94

97 De besparrelser, som er altafgørende for de små virksomheder, eksisterer også for de større. I større virksomheder er store investeringer i IT-infrastruktur blevet til en fast del af budgettet. I den aktuelle finanskrise kan det dog tænkes, at selv de større virksomheder begynder at fokusere mere på at minimere store investeringer i ny IT-infrastruktur for at holde likviditeten oppe. Hvis IT samtidigt bruges strategisk som en konkurrenceparamenter, må virksomhederne kigge sig om efter andre måder at realisere dette. Den økonomiske krise kan derfor være en vigtig faktor for en fortsat udbredelse af CC Strategi Empirien viser at strategi i høj grad er med i virksomhedernes overvejelser i forhold til hvordan de benytter CC. Vi er i stand til at udpege følgende områder som, af virksomhederne, omtales at have strategisk betydning: Fokus på kernekompetencer: For PCM, der er en lille virksomhed med fire ansatte, er det vigtigt og altafgørende at kunne fokusere på sine kernekompetencer. Det er en stor fordel for PCM, at de ikke skal tænke på hardware og infrastruktur, men udelukkende kan koncentrere sig om sine kernekompetencer ved at overlade resten til en cloud-udbyder. Stabilt serviceniveau: Det har haft afgørende betydning for Surftown, at de har implementeret en intern sky. Skyen har gjort det muligt at opretholde et højt serviceniveau og undgå nedbrud som følge af uforudsete belastninger. Surftown har mange konkurrenter, hvorfor det ville være kritisk hvis kunderne grundet et lavt serviceniveau ville skifte til et andet hosting-firma. For både PolarRose og PCM er CC også med til at sikre et stabilt serviceniveau, da cloud services giver dem adgang til den skalerbarhed deres produkter kræver, både realtime og i forbindelse med tests. Øget strategisk fleksibilitet: For alle tre virksomheder har anvendelsen af CC betydet at de har opnået større fleksibilitet i deres infrastruktur og i forhold til eksterne faktorer. For PolarRose har det eksempelvis betydet at de har fået mulighed for at gennemføre krævende tests i et miljø, som kan opsættes og nedlukkes på kort tid. Både Jan-Erik fra PolarRose og Magnus fra PCM understreger desuden det strategisk fordelagtige i at kunne forbruge IT efter behov. Lock-in: PCM s systemer er optimerede til at benytte SQS-servicen hos AWS. Derfor erkender Magnus at der på dette område er et stort lock-in, som gør det svært for PCM at skifte til en anden udbyder. PCM har opvejet potentielle risici ved dette lock-in mod selv at udvikle et tilsvarende kø-system. Her var der ingen tvivl om, at SQS var den bedste løsning. Surftown har valgt en intern implementering, da det ses som en stor risiko at lade en ekstern leverandør varetage vigtige dele af kerneforretningen, herunder spam-filtrering. Årsagen er primært, at Surftown forventer mindre forhandlingskraft overfor en stor udbyder. Surftowns overvejelser om lock-in Side 95

98 tager desuden udgangspunkt i devisen om ikke at lægge alle sine æg i én kurv, hvilket nok er meget karakteristisk for måden virksomheder tænker strategisk i forhold til CC. Empirien viser på den ene side at risikoen i nogle tilfælde er for stor til at virksomhedene tør være afhængige af skyen. På den anden side har PCM valgt at basere hele sin forretning på cloud services, ligesom PolarRose i dag har al billedmateriale liggende på S3. Som man også kunne forvente, er der delte opfattelser af den strategiske betydning og de potentielle risici ved cloud services. Der er derfor behov for at virksomheder i tilfælde forbundet med en risiko kan forholde sig til hvordan denne risiko skal håndteres og opvejes mod strategiske fordele. Vores virksomheder bemærker også at cloud services i mange tilfælde placerer både ansvar og risici hos dem selv. Virksomheder bør derfor være opmærksomme på at vurdere denne risiko i forhold til hvor og hvornår CC kan være en effektiv løsning. Desuden viser empirien at risici og fordele varierer alt efter hvilken type virksomhed man spørger. At opgive dele af kontrollen med sine data, kan af én type virksomheder ses som en byttehandel hvor man får mere fordelagtige prisstrukturer og skalerbarhed til gengæld. For andre virksomheder vil det være kritisk eller helt utænkeligt at placere data uden for virksomhedens firewall. Risici bør i det enkelte tilfælde være noget man opvejer mod fordelagtigheden i byttehandelen. En mindre virksomhed vil eksempelvis kunne opnå langt bedre sikkerhedsforanstaltninger hos en CC-udbyder, end den selv inden for økonomisk retfærdiggørelse ville kunne implementere. Der er derfor ikke ét svar på hvad der er den rigtige strategi med CC. En teori som på et strategisk plan kan være et redskab til at vurdere hvor og hvornår CC vil være en strategisk fordel eller ulempe er Gerffrey Moore s core vs. context. Figur 27 Core vs. Context [Moore, 2002] Side 96

99 Modellen skitserer teoriens anvendelse på software-applikationer og viser hvor der med fordel kan anvendes SaaS som alternativ til traditionel lokalt-installeret software. Der er altså tale om software leveret som en service vs. traditionel (licensbaseret) software. Det er derfor nærliggende at undersøge om figureren ligeledes kan benyttes når der kigges på CC som alternativ til egen IT infrastruktur. Da CC kan anvendes i mange forskellige sammenhænge, vil det ikke være muligt at sammenligne direkte med hvilke interne ressourcer det kan stå i forhold til. Vi skelner derfor ikke mellem typer af CC. Moore tager tilsvarende ikke højde for at der vil være forskel på SaaS-applikationer. Pointen er at vi er nødt til at se CC mere overordnet. Derfor vælger vi at bruge betegnelsen komponenter, så vi har at gøre med enheder der vil kunne sidestilles med betegnelsen applikationer i Moores model. Core vs. context-modellen kan i korte træk opsummeres med følgende: Core-komponenter ligger til grund for strategisk differentiering Context-komponenter giver ikke strategisk differentiering, men er nærmere komponenter som skal være til stede for at resten af virksomheden fungerer optimalt. Core- og context-komponenter kan inddeles i mission-critical komponenter og non-missioncritical komponenter. Hvis en non-mission-critical komponent i en periode ikke fungerer, har det ikke kritisk betydning for virksomhedens overlevelse. En core-komponent der er mission-critical bør til enhver tid varetages internt. Hvis komponenten omvendt er context og non-mission-critical, er det til enhver tid strategisk fordelagtigt at den lægges i skyen. Opsummerende viser modellen at komponenter der ikke er core og mission-critical bør overvejes placeret i skyen. I vores empiri kommer vi frem til resultater som er forskellige fra Moores teori. PCM er et eksempel på at selv core + mission-critical-komponenter i realiteten kan baseres på cloud services med en række strategiske fordele. På trods af at PolarRose s kerneprodukt og kernekompetence er algoritmen til billedgenkendelse, afvikles dele af denne algoritme på AWS. Teorien har dermed ikke tilstrækkelig forklaringsmæssig værdi, da især mindre virksomheder ikke skelner mellem hvilke komponenter der leveres som en service og hvilke der ikke gør. Det giver en indikation af, at der kan ligge væsentlige forskelle i hvordan hhv. store og små virksomheder ser på CC. Vores generelle indtryk er at der lige nu sker ændringer i den mentalitet hvormed virksomheder tilgår serviceleverancer. Denne nye mentalitet udtrykkes tydeligt af Magnus fra PCM, der taler om en mere åben indstilling til cloud services. Hvor de givne komponenter fysisk varetages er af mindre betydning, så længe de er tilgængelige. Mentaliteten mener vi tager afsæt i virksomheders afvejning af: Hvad er det vi bidrager med? Teknik eller services?. Side 97

100 Kontrol over miljø vs besparrelser igennem Economies of scale Det vil altid være sådan at de dele virksomheden selv varetager, har den høj grad af kontrol over. Denne kontrol kan der argumenteres for bibeholdes på bekostning af at fordelene ved EoS har et andet udgangspunkt end ved at benytte CC (jf. de økonimiske scenarier i forrige afsnit). Når virksomheden er komplet selvforsynende af IT, har den høj grad af kontrol, men lider under lav EoS. Omvendt ser det ud ved valg af med cloud services, som vil være forbundet med lavere kontrol men bedre afsæt for EoS. Skismaet mellem interne og eksterne arkitekturer kan altså ses som et forhold mellem kontrol og EoS. Der er altså fordele og ulemper der skal opvejes mod hinanden, i valget mellem at holde IT internt eller opnå besparrelser ved at benytte cloud services. En vigtig pointe der gør sig gældende ved CC er dog, at der kan differentieres mellem hvilke dele af IT der afgives kontrol med. Drift af IT kan lettere adskilles fra selve applikationen/systemet med CC som en mulighed. Opdeles en applikation i forhold til: 1. Hvem udvikler applikationen? 2. Hvor afvikles/driftes applikationen? Kan disse faktorer addreseres hvert for sig. Således differentieres der, i valget om at bevare kontrol vs. at opnå besparrelser i form af økonomisk skalerbarhed, mellem udvikling og drift. Den første dimension er det klassiske skisma mellem selv at udvikle eller at købe en færdig applikation. Forholdet mellem disse har betydning for kontrollen med og tilpasningen af funktionalitet. Udvikler man selv applikationer, har man selv kontrol med funktionaliteten. Købes applikationen, fx på licens-basis eller som SaaS, får man den funktionalitet producenten har lagt i applikationen. Den anden dimension har betydning for sikring driften af applikationen, gennem kontrol over den infrastruktur der lægger fundament for applikationen. Lad os for at simplificere dette bruge betegnelsen servicekvalitet. Afvikles applikationen on-premise, har man fuld kontrol over servicekvaliteten. Det betyder at man selv kan bestemme hvad applikationen skal leve op til og hvor ejerskabet placeres. Afvikles applikationen i skyen, ændres kontrollen over servicekvaliteten (på godt og ondt). De to dimensioner er udtryk for hvordan der kan differentieres i det eksisterende skisma mellem kontrol og EoS, således at indkøb og udvikling af systemet kan adskilles fra drift og vedligehold af infrastrukturen. Formålet med denne opdeling er, at kunne redegøre for de valgmuligheder virksomheder står overfor at skulle vægte, når fremtidige løsninger skal vælges og implementeres. For at gøre dette mere klart, er forholdet mellem dimensionerne visualiseret i nedenstående figur: Side 98

101 EoS Udvikle Købe Specialeafhandling: Cloud Computing I et teknisk og stratgisk perspektiv Lav Kontrol over funktionalitet Høj On-premise Cloud computing Høj Kontrol over servicekvalitet Lav EoS Figur 28 Funktionalitet og Servicekvalitet (Egen udarbejdelse) Det er muligt at forholde sig til hvor der er behov for kontrol over funktionalitet og/eller servicekvalitet på bekostning af EoS. Den vigtige pointe er, at funktionalitet og servicekvalitet er to forskellige dimensioner, og dermed kan differentieres. CC giver mulighed for at have valgfrihed når det kommer til at differentiere sig mht. funktionaliteten et system består af, og valg af driftsplatform. Dermed betyder valget af specialiseret software ikke at drift i at multitennant- og skalerbart miljø umuliggøres Lock-in Empirien har vist store forskelle på hvordan virksomhederne ser på risici ved lock-in. PCM er mest optimistisk og har fokuseret på at høste de umiddelbare fordele ved ikke selv at skulle udvikle dele af systemet. Surftown er omvendt meget opmærksom på at have fuld kontrol over sin infrastruktur. Driftchefen udtrykker bekymring over ikke at have tilstrækkelig forhandlingskraft over for en stor udbyder som Google eller Amazon. Formålet med CC er at fritage virksomheder fra selv af drifte kompleks og dyr infrastruktur. Det vil til enhver tid være i udbyderens interesse at stille de nødvendige ressourcer til rådighed, da det er hér udbyderens kernekompetence ligger og hér forretningen tjener penge. Da der derfor kun i mindre grad eksisterer modstridende interesser mellem udbyder og aftager, er der alt andet lige mindre at forhandle om. Behovet for forhandlingskraft overfor en udbyder er mindre, hvis der er større sammenhæng mellem udbyders og aftagers interesser. Der vil dog som i de fleste andre sammenhænge være økonomien at forhandle om. Side 99

102 På baggrund heraf må core vs. context-teorien siges primært at finde anvendelse på virksomheder af en vis størrelse. Det er naturligt at større virksomheder udviser mere påpasselighed og strategisk konservatisme, men omvendt er der væsentlige områder med relevans for CC, som teorien ikke tager højde for. Moores teori bør derfor betragtes som en overordnet skitsering af strategiske valg. Men som antydet er der behov for at anskue strategiske beslutninger vedrørende cloud services mere nuanceret Kan cloud computing sammenlignes med outsourcing? Strategi bygger på erfaringer og i bedste fald på erfaringer gjort uden nederlag eller tab. Som tidligere omtalt, har virksomheder også taget ved lære at fejlslagne strategiske beslutninger omkring dot-comkrakket. Erfaringerne med cloud services er stadig sparsomme, og CC må desuden betegnes at være på et meget tidligt modenhedsstadie. Vi mener at de divergerende meninger om CC s strategiske betydning kan skyldes et manglende sammenligningsgrundlag og det mest oplagte vil imidlertid være at se på virksomheders strategiske overvejelser omkring outsourcing. Derfor vil erfaringer fra outsourcing måske kunne overføres og give et bredere billede af strategiske fordele og ulemper ved CC. I opgaven Software as a Service i et strategisk kundeperspektiv, har vi redegjort for hvorfor der siden 1990 erne har været en stigende tendens til at virksomheder outsourcer håndteringen af IT samt hvilke udfordringer outsourcing er genstand for [Albertsen & Kann, 2008: 20-22]. Herunder er opstillet en opsummering af denne redegørelse: Hvorfor outsource IT? Udfordringer ved IT-outsourcing Konkurrencemæssige fordele Fokus på kernekompetencer Opnå strategisk net-værk/værdikæde tilpasset globalisering og partnerskaber Økonomiske og kompetencemæssige for- Ufleksible kontrakter Modstridende interesser mellem kunde og leverandør Vurdering af hvad der kan/skal outsources dele Figur 29 Incitamenter for outsourcing (Egen udarbejdelse) CC kan umiddelbart og på et rent strategisk plan anses for at minde om outsourcing. En af forskellene ligger i at outsourcing primært vedrører hvor IT-ressourcerne fysisk er placeret og hvem der varetager dem. CC vedrører derimod hvordan ressourcerne varetages, forbruges og udnyttes [Mendoza, 2007:4]. Side 100

103 Nedenfor redegøres for hvilke øvrige områder der adskiller CC fra outsourcing. Flere af incitamenterne for IT-outsourcing i tabellen herover, svarer til incitamenterne for at vælge CC. Det er eksempelvis tilfældet i forhold til konkurrencemæssige og økonomiske fordele samt fokus på kernekompetencer. En forskel er der imidlertid i forhold til incitamentet der bygger på at opnå et strategisk netværk. Det er ikke tilsvarende et incitament vi har hørt anvendt i forbindelse med CC. Der indgås i mindre grad samarbejde og strategiske alliancer mellem udbyder og aftager af CC, men derimod et mere enkelt forhold mellem parterne. På dette område holder analogien om CC som en forbrugsvare(utility) særdeles godt. Vi vurderer derfor at CC ikke ses af hverken aftager eller udbyder som kilde til at opnå eller indgå i et strategisk netværk. Dette understøttes af at der sjældent er en egentlig kontrakt mellem udbyder og aftager, hvorfor kunden kan afbryde forholdet uden varsel. Med den rette løse kobling til de underliggende cloud services, der taler for lettere leverandørskift, må det dermed også give aftageren større forhandlingskraft. På netop dette område er CC dog meget umodent, og mangler standarder der giver mulighed for denne løse kobling. Modstridende interesser mellem kunde og leverandør bygger i forhold til outsourcing på at kunden ønsker en så fleksibel kontrakt som muligt, mens det oftest vil være i udbyderens interesse at opnå en så statisk aftale som muligt, da det vil være mest økonomisk rentabelt. CC handler i bund og grund om at udbyderens ressourcer skal være tilgængelige (høj availability) og altid funktionelle, samtidig med at kunden selv kan bestemme hvor mange ressourcer der skal anvendes og hvornår. CC-udbyderens forretningsmodel baserer sig på at kunderne anvender de ressourcer der stilles til rådighed. Så hvis ressourcerne er utilgængelige, tjener udbyderen ingen penge, da der afregnes efter forbrug. Da udbyderen desuden selv ejer al infrastruktur, og dermed har enorme sunk costs, har udbyderen en stor interesse i at skabe gunstige forhold for aftagere af ydelser, og dermed sikre en konstant fyldt pipeline. Hele ideen med at benytte CC bygger på skalerbarhed, og aftaler om minimumforbrug og lange kontrakter passer ikke ind i dette setup. Loyalitet mellem udbyder og aftager er i modsætning til outsourcing ikke noget der opnås gennem kontrakter, men nærmere noget der opnås gennem kvalitet og priser der matcher behov. Vi vurderer på baggrund heraf at udbyders og aftagers interesser i høj grad er ens, hvorfor CC også på dette område adskiller sig markant fra outsourcing, hvor der ofte er divergerende interesser mellem udbyder og aftager. CC gør desuden en virksomhed langt mindre sårbar i forbindelse med teknologiske forandringer, da det er nemmere og mere økonomisk rentabelt for en udbyder at optimere en komplet cloud service som mange bruger, end det er for en outsourcing-leverandør at forbedre sin leverance til én kunde i et heterogent miljø. Side 101

104 Make or Buy? Endelig er der udfordringen i at udpege hvad der skal outsources. Core vs. context-teorien giver en indikation, men kun på et meget overordnet niveau. En teori som kunne sidestilles med Moores core vs. context-teori er Applegates model for internal versus external service delivery : Figur 30 Internal versus external service delivery. [Applegate et. al, 2007: 339] Modellen giver en indikation af hvilken strategi virksomheder bør vælge i forbindelse med outsourcing. De to faktorer der lægges vægt på er om en service differentierer konkurrenceevnen (core vs. context) og om ekstern serviceleverance er pålideligt og forbundet med lavere omkostninger. Behandlingen af core vs. context viser, at det ikke entydigt er en fordel selv af drifte services som er core. Vores empiri viser samtidig eksempler på at services som giver virksomhederne konkurrencemæssige fordele, med CC kan skabe yderligere fordele, både driftsmæssigt og økonomisk. Derfor mener vi at det første led i figur 30 er det, som adskiller strategiske afvejninger af CC fra outsourcing. CC kan være et vigtigt værktøj til at differentiere mellem hvilke dele der lægges ud af huset, til håndtering af trejepart. Meget få virksomheder har drift af IT og datacentre som deres kernekompetence, men utroligt mange virksomheder gør der alligevel selv. Dette kan skyldes at outsourcing ofte har været et alt-eller-intet scenarie, hvor udvikling, drift og vedligeholdelse følges ad. Dermed kan der argumenteres for at kernekompetencer inden for IT optimering af forretningen og forståelse heraf også outsources som en uønsket sideeffekt. CC giver her mulighed for at differentiere med højere detaljeniveau, hvilke dele der skal varetages internt og hvilke der skal varetages eksternt. Dette har selvfølgelig kunnet lade sig gøre med managed-hosting og drifstpartnere, men i en mere rigid, omkostingstung og uskalerbar form. CC øger altså mulighederne for at lave strategiske valg med større fleksibilitet, holde de vigtigste kompentencer internt og stadigt have adgang til en top-professionel IT-driftsplatform. Side 102

105 Udbydernes udfordringer Dele af vores empiri, samt generelle tilkendegivelser i erhvervslivet, udtrykker skepsis overfor at lægge væsentlige dele af infrastrukturen i hænderne på en CC-udbyder. Man må have for øje at der kan ligge mange relevante begrundelser til grund herfor. Eksempelvis kan lovgivning om fysisk placering af data have afgørende betydning for hvor og hvordan en infrastruktur etableres. Vi har samtidig været inde på tekniske faktorer, som begrænser anvendelsen af CC. Virksomheder er i forvejen vant til at integrere sine systemer med kunder og partnere. Så hér adskiller CC sig vel ikke på et teknisk plan? Nej, men CC kan i mange sammenhænge betragtes som den ideelle IT-leverancemodel, da der ikke er krav om kontrakter der skal administreres. Lægges hertil den umiddelbare adgang til ubegrænsede ressourcer samt minimering af behovet for selv at varetage infrastruktur, tilføjer CC helt nye strategiske muligheder. En stopklods for at udnytte mulighederne, er den mentalitet som, af flere årsager, præger mange virksomheders beslutninger. Christophe Bisciglia, Senior Engineer i Google, nævnte på konferencen Structure08, at virksomheder generelt helst vil skrive kontrakter og vide hvad de kan forvente af leverandøren. Som Christophe udtrykte det, handler det om change of thought, hvilket er en bemærkning vi tilsvarende hørte hos Magnus fra PCM. Outsourcing går også galt og blot fordi der er en kontrakt eller en SLA, er ingen sikret mod nedbrud. Desuden er menneskelige fejl årsag til ca. halvdelen af alle nedbrud i datacentre [Schwartz, 2004]. For at opnå dette skift i holdningen til CC, er der brikker der mangler at falde på plads. For CIO s eller CTO s der har det formelle ansvar for virksomhedens IT, kan CC ses som det vilde vest med kontraktløse services, vag ansvarsplacering ved problemer og totalt fravær af standarder. For at CC for alvor kan komme ud over stepperne, har udbyderne dermed også nogle vigtige opgaver foran sig. Det mere løse forhold mellem aftager og udbyder mener vi, er en fordel for begge parter, og dermed er det ikke den del der skal addreseres for at modne brugen af CC. Derimod kan standardisering af CC-services betyde at virksomhederne vil have lettere ved at bevæge sig ud i at benytte CC. Standardisering kan afhjælpe frygten for lock-in hos udbydere og samtidig hjælpe virksomhederne til at lave fornuftige systemarkitekturvalg. Vi har redegjort for at strategiske overvejelser om CC ikke bør tage afsæt i teorier for outsourcing. Der er væsentlige forskelle og helt andre rammer gør sig gældende for CC. Side 103

106 3.3 Cloud Computing i praksis - opsummering Praktisk anvendelse af CC påvirkes af flere faktorer. De tre virksomheder vi har interviewet bruger CC i vidt forskellige sammenhænge, men grundlæggende har vi kunnet udpege fire faktorer som i større eller mindre grad har haft relevans for praktisk anvendelse af CC. Faktorerne er skalerbarhed/kapacitetsplanlægning, teknisk anatomi, økonomi og strategi. Kapaciteten til at holde en infrastruktur kørende er en konstant skiftende størrelse, hvorfor kapacitetsplanlægning er en svær disciplin. Ønsket om konstant høj kvalitet på systemer medfører sikring ved hjælp af overkapacitet, hvilket fordyrer IT-og driftsomkostninger og giver en ufleksibel anvendelse. Ved fejlvurdering af den nødvendige kapacitet, kan der opstå perioder med for lidt kapacitet til at møde behovet. Dermed er umiddelbar villighed til at skalere en tilstræbt egenskab for alle ITsystemer. Skalerbarhed giver mulighed for at følge med forretningens behov uden at skulle foretage uforholdsmæssige ekstra investeringer. Skalebarhed kan foregår på flere måder, men ved en fortsat stigende belastning af IT-systemer, ender mange med behovet for at skalere ud. Ikke alle systemer er velegnede til distribuering, men dem der er, egner sig godt til at benytte CC som platform. At benytte cloud services betyder ikke nødvendigvis at skalering er til stede, men at platformen understøtter skalering ved at stille enorme ressourcer til rådighed for aftageren. Den tekniske anatomi for et IT system dækker over sammensætningen af komponenter i et system, samt hvilke eksterne afhængigheder der skal tages højde for. Denne anatomi har vi opdelt i komponenterne logik, filer og database samt kommunikationskrav til indbyrdes og ekstern performance. Sidstnævnte kan være en udfordring for anvendelse af CC, men som vi har anskueliggjort, kan der med fordel etableres et system bestående af både interne og eksterne komponenter. For at lave en egentlig økonomisk vurdering af CC, er det vigtigt at have for øje hvad der sammenlignes med som alternativ. Vi har argumenteret for forskelle mellem CC og in-house såvel som outsourcet IT. IT bliver billigere af at operere i stor skala, hvilket gør sige gælende for både intern IT, outsourcet IT og CC. Argumentet for CC ligger i at CC skalerer fra et lavere (billigere) niveau gennem mere heterogene og automatiserede miljøer. Dermed kan CC drives billigere end andre IT-scenarier. Desuden kan der påpeges visse ligheder med fordelene ved at benytte SaaS og fordele ved CC, nemlig at kunder lejer sig ind i et multi-tennant miljø, og dermed drager fordel af at dele både infrastruktur og hardwareplatform. Hvor investeringer i intern IT-infrastruktur medfører store omkostninger, kræver CC ingen opstartsomkostninger, men kun betaling efter forbrug. Dette gør at aftager af cloud services opnår en mere gennemsigtig omkostningsstruktur. Aftagerne betaler ikke for at have stor kapacitet til rådighed, men kun for det faktiske forbrug. Side 104

107 Et andet stærkt incitament for at anvende CC er strategiske faktorer. Få virksomheder kan sige at teknisk drift er en del af deres kernekompetencer, men alligevel er behovet for IT en konkurrenceparameter. Selvom IT ofte ses som en commodity, der ikke skaber konkurrencemæssige fordele, ser vi hér et behov for at skelne mellem drift af IT og udvikling af IT til at forbedre produkter og optimere processer. Vi argumenterer for at CC kan benyttes af virksomheder til at fokusere på netop de parametre, der giver en konkurrencemæssig fordel og derved undgå at håndtere drift af datacentre. På flere områder kan CC sammenlignes med outsourcing og især kan der sammenlignes med de fordele outsourcing giver i forhold til intern IT. Problemet med denne sammenligning er, at CC netop er et alternativ til blandt andet outsourcet IT, og der derfor let kan opstå sammenblanding af begreberne. Konklusionen på dette skisma er, at strategiske fordele ved CC på mange måder kan sammenlignes med fordele ved outsourcing, men at CC giver virksomhederne bedre mulighed for at vælge hvilke IT-behov der ønskes varetaget eksternt og hvilke der fortsat skal fokuseres på som kernekonkurrenceparameter. Kort opsummeret mener vi at CC i praksis skaber: Skalerbarhed af IT miljø til at matche forretningsbehov til enhver tid Fokus på konkurrenceskabende IT frem for drift Økonomiske besparelser og økonomisk gennemsigtighed på IT-budgettet Højere kvalitet og fleksibilitet i forhold til mere rigide interne IT-systemer eller outsourcet IT pga. større overensstemmelse mellem udbyders og aftagers interesser Side 105

108 Kapitel 4 Enterprise Cloud Computing Analysen har indtil nu været baseret på mindre virksomheders IT-behov og på enkelte systemer eller services. Dermed er ikke taget højde for at større virksomheder oftest har en langt større og mere kompleks IT-arkitektur samt flere behov og krav til den arkitektur som IT-løsninger skal operere i. Derfor fortsættes analysen med at udvide perspektivet til også at omfatte større virksomheder. Med større virksomheder menes (enterprisemarkedet) Når CC skal ses i et bredere anvendelsesperspektiv end blot for mindre virksomheders behov og isolerede systemer, er det oplagt at benytte enterprise arkitektur (EA) som udgangspunkt. EA skaber et holistisk billede af hvordan en virksomhed ser ud og EA-metoden er en tilgang til dokumentation, planlægning og styring af en virksomheds arkitektur [Bernard, 2005: 15]. EA er ikke et projekt med en defineret start og slutning, men en konstant proces der søger at følge eksterne forandringer og nye strategiske tiltag og samtidigt øge modenheden og samspillet mellem forretning og teknologi i virksomheden. Netop det at EA skaber et holistisk billede af en virksomhed gør det til en anvendelig metodisk fremgang, når vi ønsker at undersøge hvordan CC passer ind i større virksomheders perspektiv. Ved at kombinere erfaringerne med praktisk anvendelse af CC med teori omkring EA og EA-processen, søges at give en bredere og bedre dækkende analyse af om CC kan anvendes i større virksomheder og hvordan. 4.1 Cloud computing og enterprise arkitektur? Tilgange til EA kan opdeles i to kategorier. De mere teoretiske tilgange er meget frameworkorienterede. Her kan eksempelvis nævnes Zachman. Den anden kategori er mere procesorienterede tilgange, som opererer med før og efter -scenarier for virksomhedens arkitektur samt forandringsplaner og principper for transformationen mellem disse. Det er den sidstnævnte tilgang vi tager afsæt i og har valgt at afgrænse os til at anvende Scott A. Bernards procesorienterede tilgang; EA 3 -Cube Documentation Framework [Bernard, 2005: 38]. Frameworket er valgt fordi det har et godt akademisk dokumentationsgrundlag og samtidig et tilpas praktisk orienteret fundament. Et typisk (og forsimplet) flow for arbejde med en procesorienteret EA-tilgang, kan opsummeres således: 1. Dokumentér nuværende arkitektur 2. Identificér og dokumentér ønsket fremtidig arkitektur 3. Udarbejd forandringsplan og dokumentér denne 4. Iværksæt forandringsplan funderet i principper og standarder Side 106

109 5. Iværksæt vedligeholdelses- og driftsplan 6. Evaluér arkitekturen Ud over at undersøge hvordan CC vinder indpas i Bernards EA3-kube, ligger vores fokus på den del af EA som beskæftiger sig med dokumentationen af den fremtidige arkitektur, da det må være i denne kontekst og på dette plan større virksomheder vil tilgå CC. I de fleste tilfælde betyder det hovedsageligt punkt 2, som er anført ovenfor. Vi har ikke været i stand til at identificere større virksomheder der allerede har indarbejdet CC i deres arkitekturplaner. Det ville være oplagt at benytte punkt 1 ud fra hvilket det kunne analyseres hvordan CC er indarbejdet i en større arkitektur. Med dokumentation for en eksisterende arkitektur, indeholdende elementer af CC, ville vi kunne analysere på hvor og hvordan det benyttes på enterprise-niveau. Da det ikke er tilfældet, arbejder vi ud fra en generel forudsætning om, at CC endnu ikke anvendes i stor skala på enterprise-niveau. Derfor må vores fokus naturligt ligge på hvordan det kan indarbejdes i en større arkitektur, og i planlægningen af en fremtidig arkitektur hvor CC inddrages på lige fod med andre arkitekturmæssige muligheder og beslutninger. Formålet med EA er at skabe et holistisk billede at en virksomhed og dens arkitektur. Bernard arbejder med As-is og To-be-scenarierne, og har dokumentation af forandring og forandringsledelse med som en nøglefaktor, for at arbejde med EA 3 -kuben. Framework et ser således ud: Figur 31 EA 3 -kuben [Bernard, 2005: 38] De mest interessante elementer i Bernards EA-tilgang er de lag-inddelte komponenter (components) og den fremtidige arkitektur. EA komponenter er the active elements of the enterprise s business Side 107

110 and technology environment [Bernard, 2005: 112]. Det er altså disse komponenter som ligger til grund for at forretningsprocesser kan udføres som ønsket og forventet. Fordelen ved at visualisere en virksomhed ud fra komponenter er, at dokumentationen og beskrivelsen af komponenterne gør det muligt at anskue virksomheden ud fra forskellige hierarkier og fra forskellige vinkler. Bernard opstiller en række krav til EA-komponenterne. De skal fungere i samspil og skabe en robust og smidig ITarkitektur, som understøtter virksomhedens behov. Desuden skal komponenterne leve op til: Availability, reliability, security, scalability, and cost effectiveness are key performance measurement areas for the general IT operating environment. These areas apply to each EA component, along with measures for integration and reuse. [Bernard, 2005: 112]. Med udgangspunkt i vores definition af CC og redegørelse for den praktiske anvendelse af cloud services, mener vi, at det giver mening at undersøge hvor CC passer ind i EA 3 -kuben og hvordan CC sættes i forhold til komponenterne, når man planlægger den fremtidige arkitektur. Hvis CC i teorien skal kunne anvendes i frameworkets komponenter, er der i første omgang behov for en undersøgelse af om frameworket på dokumentationsniveau kan rumme sådanne services. Desuden må det undersøges om cloud services kan leve op til de arkitekturmæssige krav om integration og genbrug af systemer og data. Ved at undersøge hvor CC passer ind blandt de eksisterende komponenter, er det muligt at foretage en vurdering af om CC lever op til de krav der stilles til EA-komponenter. Ellers må der kunne argumenteres for hvorfor kravene til CC ikke nødvendigvis bør være de samme. Den fremtidige arkitektur dokumenterer those new or modified EA components that are needed by the enterprise to close an existing performance gap or support a new strategic initiative, operational requirement, or technology solution [Bernard, 2005: 41]. Driverne for den fremtidige arkitektur kan være nye strategiske målsætninger, ændrede prioriteringer og nye teknologier, hvilket Bernard visualiserer med følgende figur: Figur 32 Drivere for fremtidig arkitektur [Bernard, 2005: 41] Vores empiri har vist at de mindre virksomheders incitamenter for at benytte CC både har strategiske og taktiske bevæggrunde. Blandt andet strategiske fordele, prioriteringer i forhold til at fokusere på kernekompetencer, samt den lette og bekymringsfrie adgang til anvendelse af ny teknologi er nogle af Side 108

111 de incitamenter vi har kunnet påpege. I større virksomheder, hvor langt flere faktorer har betydning for at IT-arkitekturen fungerer optimalt, må der imidlertid kræves en nøjere planlægning af hvor og hvordan eksterne komponenter og ressourcer anvendes, så der også i den fremtidige arkitektur sikres det nødvendige samspil mellem IT og forretning Cloud computing og EA 3 -kuben Vi har tidligere defineret cloud services som netværksoptimerede, skalerbare og forbrugsafregnede IT-ressourcer der kan distribueres og forbruges via internettet som services. Cloud services kan alene eller i samspil med andre services være supplerende eller erstattende for dele af en traditionel infrastruktur. Definitionen kan generelt siges at rumme as a service -begrebet, der i praksis gør det muligt at anvende IT-ressourcer leveret som en service. EA-komponenter defineres også som: those plug-and-play chargeable resources that provide capabilities at each level of the framework [Bernard, 2005: 111]. Indholdet i komponenterne er afgørende for hvilke kapabiliteter (capabilities) virksomheden besidder. Komponenterne og koblingen mellem dem kan udskiftes eller omstruktureres i takt med ændringer i strategi, forretningsprocesser, applikationer eller anden infrastruktur. Derfor mener vi i høj grad at as a service -begrebet kan forenes med den plug-and-play-tankegang som ligger bag komponenterne. Antages at komponenterne tilsammen udgør en traditionel infrastruktur, er påstanden ifølge vores definition, at en cloud service alene eller i samspil med andre services kan være erstattende for dele af indhold i disse komponenter. Forskellen ligger i at as-a-service bygger på eksterne IT-ressourcer tilgået via internettet på forbrugsbasis, i modsætning til at IT-ressourcerne stilles til rådighed i virksomhedens egen infrastruktur. Dette er gældende hvad end der er tale om hardwareeller softwareservices. Men på et praktisk plan vil services, i kraft af at de ikke stiller krav til virksomhedens egen infrastruktur, kunne tilgås som om de var indeholdt i frameworkets komponenter og dermed bidrage til de kapabiliteter virksomheden behøver. Derfor må de også kunne dokumenteres som sådan. At komponenterne i EA 3 -kuben bør være plug-and-play, må også betyde at der skal være en tilpas løs kobling mellem komponenterne. Men hvordan dokumenteres anvendelsen af ressourcer som tilgås on-demand via internettet og efter forbrug? Med virtualisering frakobles software fra den underliggende hardware og når en given cloud service tilgås on-demand på udbyderens infrastruktur, må det betyde at koblingen til de andre komponenter i virksomhedens arkitektur har en mere løs karakter. EA 3 -kuben er opdelt i logisk afgrænsede lag og sammenhængen mellem dem er det som dokumentationsarbejdet skal hjælpe med at tydeliggøre. Cloud services vil i teorien kunne erstatte komponenter eller dele heraf i det nederste lag Network & Infrastructure. Da disse services, der tidligere var fysiske ressourcer i datacentret, tilgås virtuelt, opstår der en løsere kobling op imod de overliggende lag, altså mellem Network & infrastru- Side 109

112 ture og Systems & applications. Med as-a-service kunne eksempelvis optræde en kobling direkte mellem en ekstern og virtuel arkitektur og en eller flere af de fire øverste lag i EA 3 -kuben. Årsagen er netop at både CC og forskellige cloud services ikke er afhængige af virksomhedens egen infrastruktur. Når der i praksis er en løs kobling mellem komponenterne, må det ændre nogle ting i forhold til hvordan man dokumenterer arkitekturen. Hvordan data transmitteres mellem systemer, databaser og applikationer dokumenteres på det komponentlaget Networks & infrastructure, som dokumenterer den tekniske infrastruktur. Bernard kalder dette for the network backbone, som primært består af kommercielle produkter såsom servere, routere, harddiske og andet hardwareudstyr [Bernard, 2005: 129]. Anvendes CC og cloud services, vil det i praksis betyde at denne backbone forbigås/omgås. Hermed underbygges vores pointe om at as-a-service skaber en løsere kobling mellem den tekniske infrastruktur og de anvendte systemer og applikationer Løs kobling til services Service-orienteret arkitektur er en udbredt disciplin til at opnå en dynamisk, komponentbaseret og løst koblet arkitektur. SOA binder forskellige systemer, afdelinger og komponenter i virksomheden sammen med en standardiseret og åben grænseflade. En vigtig pointe omkring SOA er dog, at der også tages ansvar og ejerskab over services fra forretningens side, da der ellers vil opstå en udefinerbar og uorganiseret kobling mellem systemerne. Dermed er SOA en disciplin som spænder meget bredt fra implementering af web services, til indarbejdning af processer der sikrer ansvar for SOA i organisationen. Vi mener at CC kan benyttes til skabe et virtuelt link til de tekniske ressourcer, så services ikke bliver for fragmenterede på blandede platforme, og dermed sikre genbrug og mindske overforbrug af tekniske ressourcer. CC vil ikke kunne sikre succes med SOA, men går godt i spænd med den distribuerede natur som SOA bygger på. Løs kobling mellem systemer er bare én af de ting som kendetegner SOA. SOA og CC har også visse andre ligheder, som kan fremhæves for at tydeliggøre koblingen mellem en virksomheds egen arkitektur og eksterne ressourcer. I den tekniske del af SOA opereres med web services som udveksles via standardiserede protokoller mellem en udbyder og en aftager. På samme måde kan man betragte anvendelsen af CC og cloud services. I stedet for web services, har man at gøre med IT-ressourcer og kapabiliteter, der i bund og grund er funktionalitet, som aftageren kan vælge at anvende i en kortere eller længere periode. Ligesom med SOA, er der med CC en løs kobling mellem udbyder og aftager Dokumentation af cloud computing i arkitekturen En løs kobling af infrastrukturen vil give nye muligheder i forbindelse med arkitekturplanlægning. Hvis forretningen ikke skal have adgang til teknologi gennem egen IT driftsafdeling, får den lettere ved Side 110

113 at tage nye teknologier og applikationer i brug. Kapaciteten i eget datacenter er ikke længere en faktor for om nye IT-projekter kan søsættes, og der kan dermed fokuseres mere på de forretningsmæssige omkostninger og gevinster som argumentation for nye projekter. Men disse nye muligheder må samtidig fordre at der sikres og dokumenteres ejerskab over de anvendte services. Værdien af cloud services må, på samme måde som EA-komponenter, øges hvis de genbruges på tværs af LOBs og forretningsprocesser. I planlægningen af en fremtidig arkitektur, vil et af kravene være at sikre integration mellem komponenter og derved undgå redundans i systemer, funktionalitet og data. For at sikre dette, vil det være optimalt at dokumentation og håndtering af CC samt distributionen at data, foregår på Network & infrastructure -laget. På dette lag dokumenteres i forvejen netværk samt den øvrige infrastruktur virksomhedens systemer og applikationer bygger på. Man kunne derfor argumentere for at CC bør dokumenteres som en del af denne arkitektur. Men hvordan dokumenteres eksterne kapabiliteter i arkitekturen? Behovet for at skelne mellem internt og eksternt indhold i komponenterne, er ikke noget EA 3 -kuben tager højde for. Men da forskellen har betydning for koblingen arkitekturlagene imellem, må det være relevant at kunne dokumentere dels hvor kontaktfladerne mellem intern og ekstern arkitektur er placeret, dels hvortil ejerskabet henføres. Forholdet mellem cloud -udbyder og aftager vil være sådan, at udbyderens infrastruktur, som tilvejebringer ressourcerne, er virtualiseret og dermed skjult for aftageren. Det er vigtigt at funktionaliteten er tilgængelig, funktionel og kan genbruges i arkitekturen, men for at sikre dette, er der behov for at eksternt tilgåede ressourcer kan dokumenteres på lige fod med interne. Når der opstår en løsere kobling mellem de nederste lag i EA 3 -kuben, opstår der potentielt en dokumentationsmæssig grå-zone for CC, fordi dokumentationen ikke kan følge den traditionelle måde at dokumentere indholdet i komponenter. Modsat kan der argumenteres for at ressourcerne der tilgås som virtuelle filsystemer, serverinstanser eller andet, kan dokumenteres og aftages som sådan, og at den underliggende arkitektur hos udbyderen er af mindre vigtighed. Hvis ressourcerne er til rådighed, af høj kvalitet, har den rette pris og aftages kompatibelt af de komponenter de er koblet til, vil dokumentationen af hvordan udbyderen realiserer dette, være af mindre vigtighed. Her kræves der, som tidligere nævnt, et mentalt skift i forhold til hvor kontrollen med virksomheders IT ligger. Andre områder såsom kontorforsyninger, renovation og i nogen grad forsyninger (som strøm og vand), er allerede uden for det der indgår i virksomhedens arkitektur, og ses som en del af den forventede eksterne infrastruktur der opereres i. Der er endnu et stykke vej før IT kan aftages bekymringsfrit fra udbydere, og derfor er der stadig et behov for at have det indarbejdet i arkitekturen. Men CC kan ses som det første skridt til at aftage IT på en mere standardiseret måde, ved at integrere et virtuelt tilgået datacenter i arkitekturen. Side 111

114 Hvis CC skal mappes ind i kuben, kan der på den ene side argumenteres for at cloud services aftages som virtuelle erstatninger for deres fysiske modparter (f.eks. virtuelle instanser for fysiske servere), og dermed bør dokumenteres som virtuel infrastruktur i Network & Infrastructure -laget. Dette kunne illustreres med små skyer i network & infrastructure -laget, der symboliserer hvor eksterne og virtuelle ressourcer aftages og benyttes, som om de var en del af infrastrukturen (figur 33 A). På den anden side kan man sige at cloud services, i kraft af at være virtuelle, ikke passer ind iblandt dokumentation af fysisk infrastruktur, da disse services i praksis vil aftages i både Network & Infrastructure - laget og de andre lag (oftest Systems & Applications -laget). Der kan altså argumenteres for at ITressourcerne, der før blev leveret fra Network & Infrastructure -laget, erstattes med services der kommer ind fra siden, direkte til de lag hvor der er behov for ressourcerne (figur 33 B): A Goals & Initiatives B Goals & Initiatives Products & Services Products & Services Data & Information Data & Information CC-Services Systems & Applications Systems & Applications Network & Infrastructure Network & Infrastructure CC-Services Figur 33 Cloud Computing i AE 3 Kuben (Egen udarbejdelse) Ovenstående illustrerer to måde at anskue CCs indpas i EA 3 -kuben. I forhold til figuren til venstre mener vi, at der vil være behov for nye dokumentationsværktøjer som kan dokumentere forbindelsen mellem forretningsarkitekturen og de virtuelle ressourcer. Det samme vil gøre sig gældende for figuren til højre, da der som skitseret vælges helt at adskille dokumentationen af den interne og den eksterne arkitektur. Dokumentationsværktøjder der kan dokumentere samspillet og kontaktfladerne mellem den interne arkitektur og cloud services vil gøre det muligt at se CC indpasset i en af overnstående figurer Cloud computing og fremtidig arkitektur En arkitektur som ikke kan ændres er svær at have kontrol over. Derfor vil der være mindre kontrol over de dele af infrastrukturen som lægges i skyen. Det må generelt være vigtigt at virksomheden har Side 112

115 opnået en fornuftig og dokumenteret eksisterende arkitektur, før CC tages i brug. CC er ikke en universel løsning på IT-problemer og en silo-lignende arkitektur optimeres ikke ved at den lægges i skyen. Er der for eksempel ikke en fornuftig dataarkitektur, vil man opnå endnu mindre kontrol over isolerede datasiloer. Konsekvensen vil være at integration og konsolidering skaber komplikationer, hvilket strategisk set kan få negative konsekvenser for virksomheden. Løs kobling kan være en stor fordel men kan også have negative konsekvenser, hvis kontaktfladerne ikke er dokumenterede i arkitekturen. Derfor må det anbefales at den eksisterende arkitektur er dokumenteret så der skabes gennemsigtighed på områder hvor arkitekturen skal optimeres eller hvor der er gab mellem ressourcemæssig formåen og behov. Hér har EA-tilgangen til dokumentation af CC i arkitekturen stor værdi, da den, med et holistisk billede af virksomheden, fokuserer på en fornuftig arkitektur i forhold til de services og kapabiliteter virksomheden ønsker at besidde. Vi har i kapitel 3 redegjort for fire faktorer der er relevante at tage med i overvejelserne omkring anvendelse af CC. Faktorerne vil også kunne anvendes, som afsæt i udvidelsen af dokumentationsværktøjerne, når den fremtidige arkitektur skal dokumenteres. Affødt af såvel strategiske som taktiske incitamenter, vil EA-processen typisk tage afsæt i ønsket om at lukke gabet mellem IT og forretning. Hvis vi kigger på figur 32 kan faktorerne skalerbarhed og teknisk anatomi ses som taktiske incitamenter og økonomi samt strategi falder naturligt ind under strategiske incitamenter. Ved at tænke disse faktorer med ind i planlægningen af den fremtidige arkitektur, vil det i højere grad komme til udtryk hvor CC med fordel kan anvendes i arkitekturen, og dermed gøre det tydeligere hvor dokumentationen af CC og cloud services skal placeres i en løst koblet infrastruktur. Endelig er det vores påstand at man ved at tage højde for disse faktorer, vil være bedre rustet til at opnå en arkitektur, som kan håndtere og integrere CC og samtidig opnå strategiske og taktiske fordele. Der er hermed samtidig lagt op til at ikke alle faktorer nødvendigvis skal tænkes med ind i arkitekturen på én gang. For eksempel kunne der i den fremtidige arkitektur fokuseres på at opnå skalerbarhed inden for specifikke områder. Forandringsprocessen kunne afsæt i at migrere givne systemer eller applikationer til en skalerbar platform, for derigennem at opnår økonomiske og strategiske fordele. Dette stemmer godt overens med formålet med at arbejde med EA (jf. afsnit ). Når en virksomhed vælger en given cloud-udbyders services, vælges samtidig en arkitektur, som virksomheden ikke selv har kontrol over eller kan ændre. Arkitekturen er, nøjagtig som virksomhedens egen arkitektur, afgørende for hvilke kapabiliteter der kan opnås. Dette lægger op til at arkitekturen skal kunne dokumenteres som kontaktflader til cloud services, snarere end til egentlige komponenter. Samtidig understreger denne pointe at faktorerne skalerbarhed, teknisk anatomi, økonomi og strategi bør tænkes med ind i den fremtidige arkitektur, således at de kan evalueres i forhold til de kapabiliteter udbyderens arkitektur giver mulighed for. Side 113

116 4.1.5 Threads Det sidste område i EA 3 -kuben vi mangler at berøre er de såkaldte Threads IT-sikkerhed, standarder samt medarbejderstaben [Bernard, 2005: 109]. Threads kan oversættes til tråde, hvilket billedligt talt indikere at de tre nævnte områder skal flettes ind i samtlige lag i arkitekturen. Tidligere er omtalt udfordringer i forhold til at integrere sikkerhedsløsninger, standarder samt at allokere medarbejderressourcer i en arkitektur der er løst koblet. De tre threads omtales hver for sig i det følgende Sikkerhed Sikkerhedsforanstaltninger, -løsninger og -politikker har størst effekt når de er integreret i hele virksomheden. Som en del af EA skal sikkerhed derfor være integreret både i de tekniske, forretningsmæssige og strategiske lag af EA 3 -kuben. Et IT-sikkerhedsprogram vil typisk starte med at samtlige EAkomponenter evalueres for at undersøge om den nødvendige sikkerhed er til stede. Til grund for sikkerhedsprogrammet vil ofte ligge en risk-adjustment som evaluerer the trade-off between how much security is desired versus the cost and effort required to implement it [ibid.]. Det er altså en teknisk og økonomisk afvejning der ligger til grund for graden af sikkerhed der implementeres på specifikke områder. Alle sikkerhedsforanstaltningerne bygger på at virksomheden har adgang til og komplet kontrol over arkitekturen. Alt efter branche, kan der være specifikke krav til områder som dataintegritiet, fysisk sikkerhed mv. Her kan eksempelvis nævnes finansbranchen, hvor der stilles høje krav til IT-sikkerhedspolitikker, beredskabsplaner, logning- og opbevaing af data samt forhold omkring outsourcing af IT-funktioner. I Vejledning om kontrol- og sikringsforanstaltninger på it-området, som vi har fået udleveret af en større finansiel virksomhed, fremgår at Ved outsourcing af ITfunktioner skal virksomheden sikre sig, at leverandøren overholder dens it-sikkerhedspolitik og sikkerhedsregler. Der skal endvidere aftales procedurer, hvorefter virksomheden regelmæssigt kan kontrollere dette [Lovweb, 2004]. CC er en udfordring for sådanne formulerede sikkerhedskrav. Sikkerhed i skyen er uden sammenligning det område som vækker størst bekymring hos virksomheder lige nu. Af [Staten, 2008], fremgår det, at mange virksomheder ikke overvejer CC fordi de tilgængelige services på markedet ikke er sikre nok. Dette skyldes primært bekymringen om ikke at vide hvor servere og data fysisk er placeret. Forrester erfarer dog at realiteten for sikkerhed med CC kan være en anden. En stor del af de virksomheder som i dag udbyder CC er gået fra at være traditionelle hostingvirksomheder til at være cloududbydere. Mange af disse virksomheder har sikkerhed som deres kernekompetence, hvorimod det i mange virksomheder vil være et nødvendigt onde at implementere omfangsrige sikkerhedsforanstaltninger. Sun Microsystems CTO, Greg Papadopoulos, har desuden overfor Forrester tilkendegivet at Side 114

117 Over time, people will start to view an external service provider as more compliant than internal. They are a disinterested third party. Their job is to hold your data but it involves you and me to collude. As a third party provider I would have no motive to muck with your data. [Staten, 2008: 9] Der er grundlæggende to områder en virksomhed skal gøre sig overvejelser indenfor: Det første område er at en fornuftig overliggende sikkerhed nedarves i arkitekturen. Derfor er Bernards syn på sikkerhed som en tråd der skal flettes ind i alle processer og komponenter en fornuftig tilgang til sikkerhed, også i forhold til CC. I praksis må virksomheder foretage parallelle sikkerhedsvurderinger af udbyderens sikkerhedspolitikker, vurderinger i stil med dem der anbefales af Finanstilsynet. Det kan anskueliggøre om udbyderens sikkerhed lever op til virksomhedens krav. For at imødekomme virksomhedernes bekymringer, har blandt andre Amazon Web Services taget en meget åben tilgang til sikkerhedsspørgsmålet, nok også for egen vindings skyld, og har publiceret et whitepaper om sikkerheden i og omkring Amazons datacentre. Af dette whitepaper fremgår følgende: AWS is working with a public accounting firm to ensure continued Sarbanes Oxley (SOX) compliance and attain certifications such as recurring Statement on Auditing Standards No. 70: Service Organizations, Type II (SAS70 Type II) certification. These certifications provide outside affirmation that AWS has established adequate internal controls and that those controls are operating efficiently [AmazonWeb- Services.com, 2008b]. Certificeringer er en måde at skilte med at man overholder forskellige (sikkerheds)standarder. AWS nævner desuden at: The AWS platform also permits the deployment of solutions which meet industry-specific certification requirements. For instance, AWS customers have built HIPAA-compliant healthcare applications using S3 and other components. [ibid.]. Dette taler for at udbyderne af CC har et stort ønske om at kunne leve op til selv de mest krævende sikkerhedskrav. Det første område leder frem til det andet. Det andet område er at virksomheder bør spørge sig selv: Hvem er bedst til sikkerhed? os eller dem? Whitepaperet fra AWS viser at skyen slet ikke er så tåget og usikker en størrelse. Amazon har blandt andet integreret komplette sikkerhedsforanstaltninger indenfor fysisk sikkerhed, dataintegritet, indbyggede firewalls, SSL-kryptering på udveksling af data samt mulighed for integrering af egen krypteringsstandard på data opbevaret i S3. Amazon garanterer desuden at: Data stored in Amazon S3, Amazon SimpleDB, or Amazon Elastic Block Store is redundantly stored in multiple physical locations as a normal part of those services and at no additional charge [ibid.]. Amazon sikrer dermed redundans af både hardware, software og data. Decideret backup er dog op til kunden selv at sikre. Virksomheder bør også overveje Hvem er billigst til sikkerhed? os eller dem?. Det er klart at når eksempelvis AWS skal etablere sikkerhedsforanstaltninger, arbejdes der med et langt større budget end hver enkelt virksomhed vil kunne mønstre. Ud fra denne betragt- Side 115

118 ning vil CC kunne tilbyde sikkerhedsløsninger der skalerer ikke alene med infrastrukturen, men også økonomisk. Sikkerhed har et bredt spænd fra sikring på bit-niveau og valg af kryptering, over personalepolitikker til fysisk sikring af virksomhedens faciliteter. På samme måde som i et outsourcing-scenarie, slippes noget af denne kontrol med sikkerheden når dele af virksomhedens data og kapactitet lægges i udbyderens hænder. Når datas fysiske placering ikke er statisk, er det umuligt for en virksomhed at føre direkte kontrol med sikkerhedsforanstaltningerne. Dette må snarere bero på tillid mellem udbyder og aftager, hvilket i princippet ikke adskiller sig fra at der internt i virksomheder er tillid til personalet der fører tilsyn med sikkerheden. Overvejelserne om hvem der er bedst til sikkerhed kommer blandt andet til udtryk ved at kigge på bankernes udvikling. I starten havde vi ikke tillid til at sætte vores penge i banken, mod at få et stykke papir som bevis. I stedet fortsatte vi med at sy pengene ind i madrassen. I dag anses det for alt for usikkert at ligge inde med større beløb. Bankerne er blevet vores foretrukne opbevaringssted, hvilket er forbundet med stor tillid, ikke mindst til at banken har de nødvendige sikkerhedsforanstaltninger 11. På et tidspunkt vil virksomheder på samme måde indse at cloud-udbyderne, som er specialister i at håndtere data og logik på en sikker måde, kan gøre dette langt bedre og billigere end virksomhederne selv. Samtidig vil det uden tvivl være i cloud-udbydernes interesse at stille de nødvendige sikkerhedsforanstaltninger til rådighed, også i forhold til branchespecifikke krav Standardisering One of the most important functions of the architecture is that it provides technology-related standards at all levels of the EA framework [Bernard, 2005: 109]. Hvor det er muligt, bør der i arkitekturen anvendes åbne standarder som øger muligheden for integration mellem komponenter i og samtidig gøre det muligt at udskifte komponenter når behovet opstår. Standardisering skal sikre genbrug og muligheden for at udskifte komponenter, applikationer eller udbyder. CC bringer helt nye produkter, services og metodikker ind i arkitekturen, og kan dermed udfordre standardiseringsprocessen. Der findes endnu hverken defacto eller formulerede standarder inden for CC. Ønsket om at have standarder til rådighed, bunder dels i behovet for at have kontrol og valgmuligheder med hensyn til valg og skift af udbyder, dels i forhold til at kunne skifte komponenter ud efter behov. Men hvor ofte vil en virksomhed for eksempel overveje at skifte udbyder? Sammenlignes med 11 Der kan argumenteres for at analogien til bankerne har lidt mindre gennemslagskraft i reltation til den aktuelle finanskrise, men pointen burde ikke være til at overse. Side 116

119 outsourcing, findes der heller ingen standarder hér, som gør det enkelt eller billigt at skifte fra f.eks. CSC til IBM. Så standardisering i forhold til CC skal nok mest adresseres i forhold til integrationen og anvendelsen af de specifikke cloud services. Standarder tager afsæt i mange forskellige lag i arkitekturen. Det kan eksempelvis være i forhold til dataintegration, web-baserede services eller netværk, som det for eksempel omtales i Hvidbogen for IT-arkitektur [MVTU, 2003: 71]. Et andet område kunne være udviklingsplatforme. Standardisering af platforme har især relevans for anvendelse af PaaS, som stiller en komplet skalerbar udviklingsplatform til rådighed. Der mangler dog stadig åbne standarder inden for PaaS-produkter, da koden der skrives til afvikling på en PaaS-platform i mange tilfælde bygger på proprietære standarder hvilket kan medføre et markant leverandørmæssigt lock-in. De første cloud services var udelukkende baseret på Linux- og Unix-baserede systemer. Amazon har nu annonceret at de i løbet af 2008 vil begynde at tilbyde afvikling af Microsoft Windows Server og SQL-server på EC2 [AWS blog 2008] i lighed med virksomheder som GoGrid og 3Tera, der allerede udbyder virtuelle Windows-servere (Se Bilag 5 Taksonomi). Udbredelsen af denne platform vil uden tvivl gøre det mere attraktivt for virksomheder, set i forhold til standardisering, at benytte CC også som udviklingsplatform. Som tidligere beskrevet, kan CC bidrage med en løs kobling mellem de to nederste lag i EA 3 -kuben. Denne løse kobling betyder at kontrollen med den tekniske infrastruktur mindskes og kan ses som et skridt tilbage i standardiseringsarbejdet. På den anden side kan man sige at cloud services leveres som virtuelle produkter, og al kontrol med hvordan services bruges ligger i aftagerens hænder, mens kontrollen med at realisere ydelsen ligger hos udbyderen. Så behøver aftageren overhovedet bekymre sig om hvilken hardware og softwareplatform der ligger til grund for en storage-service, når den tilgås gennem et web service interface? I en EA tilstræbes at de standardiseringsmæssige valg der tages øverst i EA 3 -kuben, nedarves i resten af arkitekturen. En cloud service skaber imidlertid et virtuelt link til de ressourcer og services der aftages. En storage-service udbydes eksempelvis ikke som et filsystem, men som en service. Kontaktfladen mellem udbyder og aftager er derfor selve web-interfacet. Derfor kan valg i forhold til fælles hardware- og softwareplatform i virksomhedens arkitektur ikke videreføres til platformen for cloud services. Men har dette betydning for virksomhedens arkitektur? Det betyder, at der opstår en løsere kobling ikke kun af infrastrukturen, men også mellem de standardiseringsmæssige krav der stilles til arkitekturen og til CC. Med andre ord udfordres arkitekturmæssige standarder ikke ved at bringe cloud services ind i virksomheden. I forhold til cloud services er der i stedet behov for at etablere standardiserede og dokumenterede facader mellem udbyder og aftager for at styrke fleksibiliteten samt den løse kobling mellem arkitekturens nederste lag. Side 117

120 Workforce CC går mod at færre og færre ressourcer skal varetages internt. Det vil derfor have indflydelse på de opgaver IT- og driftspersonale har i dag. Når flere og flere kapabiliteter tilegnes gennem services, bliver der mindre behov for ressourcer til at varetage den hardwaremæssige infrastruktur. Det vil medføre et skifte fra at varetage maskiner til i stedet at varetage anvendelsen af applikationer [3Tera blog, 2008]. Denne situation må i høj grad være ønskværdig for virksomheder der ikke har IT-drift som deres kernekompetence hvilket omfatter hovedparten af alle virksomheder. Vi har ladet os inspirere af en vision om datacentrenes fremtid, som den er formuleret af Barry Lynn fra virksomheden 3Tera. Han mener at datacentre i takt med udviklingen vil komme til kun at indeholde data og dermed have indflydelse på medarbejdere som i dag varetager IT-drift. Finally, a data center will be what its name implies. All of their functionality all the non-data tiers of their services, will be in Clouds connected to the data center s data[.] Over time, the corporate data will move to the Cloud just as many smaller businesses without data centers are using storage services in Clouds today [ibid.]. Konsekvensen vil være overflødiggørelse af mange af de processer IT- og driftspersonale varetager i dag. Der kan derfor ventes at opstå modstridende interesser og modstand fra driftspersonalet, der bliver overflødige. Dette kan sammenlignes med overflødiggørrelsen af arkivpersonale ved omlægning og digitalisering af arkiver til databaser. CC bygger på skalerbart design, og for at opretholde skalerbarheden og få maksimalt udbytte, skal der også tænkes skalerbarhed ind når der udvikles på en CC-platform. CC kræver derfor også omstilling for udviklernes vedkommende, da IT- og systemarkitektur skal tænkes på en helt anden måde. 4.2 Cloud Computing og enterprise arkitektur modenhed EA-modenhed er en forudsætning for en succesfuld EA-proces. Modenheden giver en indikation af hvor langt en virksomhed er i arkitekturprocessen. Det handler i bund og grund om at skabe komplet sammenhæng mellem IT og forretning samt at indarbejde værktøjer til at understøtte alle ITaktiviteter. Generelt kan man sige at EA-modehedsmodellers faser går fra, at der ikke er erkendt et behov for at arbejde med arkitektur, til at hele IT-porteføljen er indarbejdet i diverse IT-strategier, således at givne forretningsmål kan spores helt ned i de enkelte systemers funktionalitet. I Ross modenhedsmodel (Se figur 4 på side 35) for IT-arkitektur er en modulær arkitektur det højeste modenhedsniveau. Modellen anskueliggør derfor at den højeste og mest ønskværdige arkitektur består af moduler der kan udskiftes og tilpasses forskellige forretningsbehov. Side 118

121 Formålet med at bringe EA-modenhed op er, at der heri kan ligge nogle betragtninger som giver en indikation af hvor i en modenhedsproces CC vil passe ind. Ross har i en anden fremstilling af sin modenhedsmodel opstillet betegnelser der karakterisere de forskellige faser. Vi er ud fra denne i stand til at udpege karakteristika ved faserne som vil kunne understøtte, begrænse eller være en forudsætning for implementeringen af CC. Figur 34 Characteristics of the architecture stages [Ross, 2003: 13] 1. Application Silo Lokal optimering af applikationssiloer giver en rigid og uigennemsigtig arkitektur. Business casen for IT-aktiviteter berører primært at opnå et større Return on investment (ROI) gennem de anvendte applikationer. Derfor kan cloud services og SaaS-applikationer være tillokkende services at bringe ind i forretningen i denne fase. Da cloud services er billige og lette at komme i gang med, vil det umiddelbart ses som en ideel løsning i denne fase. Og så længe ansvaret for IT er placeret lokalt, vil sådanne services være lette løsninger til at opnå resultater. 2. Standardized technology Udbredelsen af tekniske standarder vil begrænse de lokale optimeringer ved at foreskrive en række standarder, som skal sikre større interoperabilitet mellem systemer. Til stede er desuden et ønske om at nedbringe udgifterne til IT. Her kan CC ses som en oplagt mulighed for at nedbringe virksomhedens udgifter til intern IT og drift. Men ønsket om standardisering vil gi- Side 119

122 vetvis lægge begrænsninger på anvendelsen af teknologi som ikke lever op til vedtagne standarder. 3. Rationalized data Fokus ligger på at opnå kontrol med data gennem konsolidering og integration mellem virksomhedens kerneprocesser, databaser og IT-systemer. En forudsætning herfor er at ansvaret er forankret på et højt ledelsesmæssigt niveau. Desuden er der fokus på at forbedre forretningens performance inden for det, som er virksomhedens kernekompetencer. Med fokus på at integrere kerneprocesser, vil CC formentlig ikke være inde i billedet, da det vil skabe yderligere udfordringer for integration og konsolidering af data. Derfor vil en virksomhed i denne fase nok mest kigge indad med fokus på optimering af kerneprocesser. 4. Modular Når der er opnået konsolidering af kerneprocesser, IT-systemer og data, er der skabt fuldt overblik over hvilke systemer der understøtter hvilke forretningsbehov. Netop konsolideringen gør det muligt at genbruge og udskifte moduler i takt med at nye forretningsbehov opstår. Business casen herfor er at opnå et kortere time-to-market samt større forretningsagilitet. Cloud services kan i høj grad betragtes som moduler der kan tages i brug præcist hvor der er brug for det. I denne fase hvor arkitekturen kan håndtere løs kobling mellem systemer vil CC derfor kunne tages i brug på lige fod med andre moduler uden at forretningen mister kontrollen. Udfordringerne er i denne forbindelse at opstille tekniske, organisatoriske og strategiske grænser og politikker op for eksperimenter med CC, såvel som anden IT. Opstilles ikke sådanne grænser, risikeres at modenhedsniveauet falder, i takt med at lokal optimering tager over. I ovenstående er det belyst, at arkitekturmodenhed har betydning for hvordan og hvornår CC med størst fordelagtighed bør tages i brug. Selvom CC i de to første modenhedsfaser vil være en attraktiv løsning på virksomhedens problemer, vil det ikke være med til at øge arkitekturmodenheden, men derimod forværre de IT-siloer som eksisterer rundt om i virksomheden. Hermed er det også pointeret, at business casen for IT har betydning for hvor ideel CC vil være for arkitekturen. Hvis business casen alene er at opnå større ROI eller at reducere de overordnede udgifter til IT, glemmes vigtigheden af at tænke de eksterne services med ind i arkitekturen. Ved at benytte CC som et supplement til virksomhedens øvrige moduler i 4. fase, kan ønsket om mere teknisk og strategisk agilitet opnås samtidig med at kontrollen opretholdes. Det er også i 4. modenhedsfase virksomheden er i stand til at genbruge moduler og sikre ejerskab på tværs af forretningsområder, hvilket vi tidligere har pointeret er vigtige egenskaber i en løst koblet arkitektur. Side 120

123 4.3 Opsummering Vi er ikke bekendt med større danske virksomheder som i praksis har indarbejdet CC i deres arkitekturplaner. Formålet med at analysere CCs indpas i en større arkitektur er, at gøre det mere klart hvordan virksomheder kan planlægge med at integrere CC i deres arkitektur. Idet vi har forholdt os til EA 3 - kuben, har vi været i stand til at udlede nogle teoretiske perspektiver på hvordan CC kan implementeres i en arkitektur. Til trods for at der ikke er tale om praktisk fundering af vores argumentation mener vi, at perspektiverne i andre sammenhænge vil kunne agere som fundament for såvel praktiske som teoretiske overvejelser om implementering af CC. Følgende er hovedpointerne i argumentationen om CCs indpas i en arkitektur: Når CC implementeres i en arkitektur er det vigtigt at der tages højde for arkitekturmæssige krav om integration, genbrug og ejerskab, da der med implementeringen opstår en løsere kobling af infrastrukturen. Cloud services stiller ikke krav til infrastrukturen, men CC bør enten dokumenteres som en virtuel del af Network & infrastructure eller som koblet direkte til lagene som eksterne ressourcer. I begge dokumentationsscenarier vil nye dokumentationsværktøjer dog være påkrævet for at kunne dokumentere forbindelsen mellem forretningsarkitektur og virtuelle ressourcer. En løs kobling af infrastrukturen gør det lettere at tage nye teknologier og applikationer i brug, samtidig med at mulighederne for at anvende services vertikalt og horizontalt i EAkomponenterne øges. CC fordrer prioritering af en dokumentationsmæssig indsats for at sikre ejerskab over de anvendte services. Ejerskab over cloud services er vigtigt for dokumentation af arkitekturen så der sikres kontrol med indholdet i alle EA-komponenterne. Dokumentation af den eksisterende aritektur tydeliggør hvor der er gab mellem IT og forretning. Dokumentation af den eksisterende arkitektur vil derfor kunne påpege hvor CC bedst vil kunne optimere den fremtidige arkitektur. Valg af en CC-udbyder betyder samtigt delvist valg af en arkitektur. Da arkitekturen er afgørende for hvilke kapabiliteter der kan opnås, anbefales at faktorerne skalerbarhed, teknisk anatomi, økonomi og strategi tænkes med ind i planlægningen af en fremtidig arkitektur, før der vælges cloud compting-udbyder. Integrerede sikkerhedsløsninger, åbne standarder og allokering af IT-personale udfordres når der skal dokumenteres et samspil mellem en intern og en ekstern arkitektur. Parallelle sikkerhedsvurderinger vil være et middel til at vurdere hvor i arkitekturen CC vil kunne anvendes. Side 121

124 I arkitekturplanlægningen bør medtages overvejelser om at CC-udbyderes sikkerhedsløsninger skalerer både økonomisk og teknisk Etablering af standardiserede facader mellem en arkitektur og en CC-udbyder vil styrke fleksibiliteten og den løse kobling af infrastrukturen. Anskuet i forhold til Ross modenhedsmodel vil CC med størst fordel kunne integreres som et supplement til øvrige moduler i fasen Modular. Business casen for IT har stor betydning for hvordan CC tages i brug og i Modular er virksomheden moden til at opnå strategisk og teknisk agilitet samtidig med at kontrollen over arkitekturen bevares. Side 122

125 Kapitel 5 Cloud computing enablement Én ting er at være i stand til at dokumentere CC i arkitekturen. Noget andet er hvordan det udbredes, forankres og styres. Endelig er der spørgmålet om hvornår CC vil finde bred udbredelse på enterprisemarkedet, hvilke barrierer der eksisterer og hvad der skal til for at CC realiseres i en virksomhed. Betragtes det at indarbejde CC i en virksomhed som en process, må virksomheden gennemgå forskellige faser hvorigennem CC forankres og etableres bedre og bedre. CC udfordrer mange områder i virksomheden, hvilket vi har skitseret med en række faktorer der bør indgå i vurderingen. I det følgende diskuteres hvilke faktorer der har indflydelse på denne proces, både fra et udbyder- og aftagersynspunkt. Derudover ønskes at præsentere konkrete bud på hvordan CC kan indarbejdes i virksomheder. I erkendelse af at der til stadighed eksisterer barrierer for CC på enterprisemarkedet, er det relevant at spørge, om det er CC der ikke er klar til virksomhederne, eller om det er virksomhederne der ikke er klar til CC. For at adressere disse spørgsmål, har vi opdelt dette kapitel i to dele. Den første del diskuterer om CC er klar til masserne, mens den anden del diskuterer om virksomheder er klar til CC. 5.1 Er cloud computing klar til masserne? CC er uden tvivl et nyt og ukendt område for mange virksomheder. De fleste nye teknologier er forbundet med en hvis skepsis og tilbageholdenhed fra virksomheders side, selv om løfterne for at benytte teknologierne er lovende. Som beskrevet i de forrige kapitler, har mindre virksomheder med primært fokus på IT og internetudvikling især været dem, der har taget CC til sig. De små virksomheder har færre bekymringer omkring anvendelsen af cloud services, og har i flere tilfælde bygget en forretning på at anvende services for at undgå store investeringer up-front. For de små virksomheder, der ikke har veletablerede omsætningskanaler, har det at skulle budgettere 5 år frem mindre relevans. Når disse teknisk krævende opstartsvirksomheder, der er afhængige af at udnytte teknologier til det yderste, vokser sig større, er der dog også en chance for at de vokser ud af brugen af CC. For disse virksomheder er IT-drift en forholdsmæssig stor del af deres forretning og kan ses som en kernekompetence og differentiator. Et eksempel herpå er Flickr (online billeddelings-site), som startede med at benytte CC til at håndtere de voksende datamængder på en on-demand basis. På et tidspunkt besluttede Flickr at in-source driften af sitet, og etablerede derfor eget datacenter. Beslutningsgrundlaget for dette må have været at opnå besparelser og / eller større teknisk fleksibilitet. Flickr kan derfor være et eksempel på den slags virksomheder som typisk vil benytte cloud services, i kraft af at være en start-up internetvirksomhed med eksplosiv vækst. Samtidigt er Flickr også en virksomhed der har så enormt Side 123

126 datacenterbehov og hvor udgifter til kapacitet er en kæmpe del af den samlede omsætning, at et specialtunet IT-miljø der matcher lige netop deres behov kan medføre store besparelser. Den del af markedet som CC-udbydere lige nu har allerbedst fat i, er også den del af markedet der har størst behov for at differentiere sig på IT-drift, og dermed skifter til in-house drift. Udbyderne er altså afhængige af konstant at kunne fodre deres pipelines med nye kunder fra den del af markedet. Måske er det derfor Amazon er så succesfuld med sin CC-platform. Den såkaldte entry barrier er særdeles lav, ressourcerne er lette at aftage og det kræver ingen involvering af salgspersonale og support fra Amazons side Technology adoption I større virksomheder hvor IT og især IT-drift er støttefunktioner og nødvendige brikker i en større infrastruktur, kan man bruge CC som en enabler til at kunne fokusere på kerneforretningen. Men i modsætning til små, arbejder større virksomheder med mere langsigtede investeringer og der budgetteres længere frem. Derfor er der ofte etableret IT-arkitekturplaner med tilhørende dokumentation. Legacy-systemer sluger ressourcer og ligger til grund for virksomheders IT-relaterede beslutninger. CC som alternativ til in-house IT, er altså oppe mod investeringer som er foretaget med store forventninger om afkast. Disse større virksomheder har også et langt mere konservativt syn på IT, og holder sig til sikre valg med omkostninger der passer ind i den måde hvorpå man plejer at estimere og budgettere. Pointen med at bringe både små og store IT-virksomheder op, er at skitsere hvordan CC mangler at få fodfæste i det område hvor de største og længerevarende gevinster kan opnås, nemlig inden for enterprise-it. I kraft af at være en ny teknologisk mulighed, kan CC vurderes i forhold til Technology Adoption Lifecycle (TAL)[Moore, 1999]. Figur 35 - Technology Adoption Lifecycle [Wikipedia.org, 2008f] Modellen skitserer hvordan nye teknologier går gennem flere faser før de vinder udbredt accept. Vores syn på CC i sin nuværende form er, at det ligger mellem Innovators og Early Adopters, da det stadig pimært er startups, som har taget CC i til sig. Det store make-or-break-punkt for CC er hvorvidt tekno- Side 124

127 logien bliver bredt accepteret og kommer op i fasen Early Majority. Skridtet mellem Early Adopters og Early Majority er det som Moore beskriver med udtrykket crossing the chasm [Moore, 1999]. Oversat til at lukke gabet, eller at krydse kløften mellem de to faser, argumenterer teorien for at der for ny teknologi altid vil være en kløft mellem de to faser - en kløft, som skal adresseres for at opnå adoption på det brede marked. Hvori består denne kløft i forhold til CC? Kløften kan relateres til manglende accept af CC i større virksomheder og virksomheder der ikke har IT som kernekompetence. Disse virksomheder benytter primært IT til at understøtte forretningsprocesser. Kløften består derfor i at CCudbyderne endnu ikke har adgang til enterprise-it markedet. Denne kløft er netop hvad vi har adresseret ved dels at redegøre for hvordan CC med fordel benyttes i små virksomheder og dels analyseret os frem til udfordringerne ved at anvende CC i en kompleks arkitektur. TAL-modellen og den barriere som altså ligger forude, leder os frem til spørgsmålet om hvorvidt CC er for umodent til at opnå adoption i enterprisemarkedet. Mange større og veletablerede virksomheder ser formentlig lige nu på fra sidelinjen mens Early Adopters eksperimenterer og gør sig erfaringer med CC på for eksempel Amazons og Googles CC-platforme. Grunden til at større virksomheder ikke har kastet sig over disse platforme skal formentlig tilskrives at Amazon og Google ikke appellerer tilstrækkeligt til enterprisemarkedet. Mange større virksomheder må lige nu forventes at kigge skævt til at internetboghandelen Amazon er begyndt at udbyde regnekraft som en forbrugsafregnet service og at søgemaskinen Google tilbyder at hoste virksomheders applikationer. Så hvad er det CC mangler for at komme til fasen Early Majority? Virksomhederne i denne fase må tilskrives at være pragmatikere i den forstand, at de gerne vil se resultater i praksis, ikke kun i teorien. CC skal derfor i praksis kunne løse de problemer som interesserer pragmatikerne og som gør sig gældende i en række forskellige brancher. CC har brug for branchespecifikke applikationer og løsninger ligesom partnerskaber mellem CCudbydere og andre øvrige leverandører til markedet vil være afgørende for pragmatikernes syn på CC. Endelige mangler CC endnu et positivt omdømme for servicekvalitet, hvilket for pragmatikerne er en altafgørende faktor. Kløften CC-udbydere står over for at skulle krydse, er at at opnå adgang gennem accept i enterprise-it markedet Cloud computing som en disruptive technology Anskuet ud fra Clayton Christensens teori om disruptive innovations, [Christensen, 2003] kan der argumenteres for at CC følger den typiske udvikling for en ny teknologi der ændrer såvel tekniske, strategiske og forretningsmæssige muligheder inden for et marked. Christensen definerer disruptive innovations således Disruptive innovations don t attempt to bring better products to established customers in existing markets. Rather, they disrupt and redefine that trajectory by introducing products and services that are not as good as currently available products. But disruptive technologies offer Side 125

128 other benefits typically, they are simpler, more convenient, and less expensive products that appeal to new or less-demanding customers [Christensen, 2003: 34]. Teorien bygger på at når disruptive products får fodfæste på et mindre marked, begynder en konstant forbedring og optimering af produktet, så det på et tidspunkt også opfylder behovene på større markeder. CC er netop startet som en teknologisk innovation der appellerer til en ny forretningsmodel, som især mindre virksomheder og start-ups har taget til sig. It is the strategy or business model that the technology enables that creates the disruptive impact [Wikipedia.org, 2008g]. Dette marked er innovativt i måden der drives forretning på, ved at udnytte de umiddelbare gevinster ved en IT-leverancemodel som er billig, let at komme i gang og som opfylder basale behov. Disruptive innovation har ofte en paralyserende effekt på de største og førende virksomheder inden for en industri. Disse virksomheder er ikke i stand til at reagere instinktivt på innovative teknologier som opstår i et mindre marked [ibid.]. Derfor har teorien høj forklaringsmæssig værdi i forhold til hvor og hvordan CC er vundet frem, hvorfor der til stadighed eksisterer en kløft og hvorfor enterprisemarkedet overordnet set forholder sig afventende. Servicekvalitet er en afgørende faktor for enterprisemarkedet, hvorfor det må forventes at dette marked vil se med større tiltro på CC-services udbudt af anerkendte IT-leverandører som eksempelvis IBM og Microsoft. Det bør ses som en naturlig udvikling at det er små virksomheder der har taget Amazons og Googles tilbud til sig og at de større virksomheder vil følge efter i takt med at IT-leverandører, som måske i forvejen er etableret på enterprisemarkedet, tager CC til sig. På samme måde som større virksomheder har været afventende med at tage CC i brug, har de mere etablerede IT-leverandører også i starten observeret CC udbyderne fra sidelinjen. Men denne tendens er tilsyneladende ikke længere til stede. Blandt andre forsøger IBM og Microsoft at få fodfæste i Early Majority ved at have lanceret cloud services rettet mod det brede marked. Dette indikerer at CC nu er ved at være modent til enterprisemarkedet. Spørgsmålet er om CC også vil kunne overbevise pragmatikerne. 5.2 Definition af cloud computing enablement Processen virksomheder må forventes at gennemgå, når de vurderer og indarbejder CC i virksomheden, er det vi i det følgende vil kalde Cloud Computing enablement. CC enablement er ikke en proces der går mod at virksomheder afskaffer deres egne datacentre. Der er derimod tale om et avancement mod at kunne anvende CC strategisk, taktisk og som en teknisk enabler for forretningen. Ligesom inden for EA og andre forandringsprocesser, er det at implementere CC en løbende proces, der består af mange delmål og niveauer. Derfor vil der være tale om en selvstændig modningsproces for CC, hvorigennem indstillingen til og udnyttelse af CC i virksomheden skif- Side 126

129 ter karaktér. CC enablement forholder sig derfor til hvordan aftageren af CC opnår stadiet hvor det er implementeret på den mest fordelagtige måde. Cloud computing enablement er et begreb som forholder sig til nødvendigheden af at se indarbejdelse af CC som en trinvis proces. I den trinvise proces oparbejder virksomheder løbende de nødvendige erfaringer og kompetencer til at implementere CC. 5.3 Er virksomhederne klar til cloud computing? Spørgsmålet om virksomhederne er klar til CC kan hverken stilles eller besvares entydigt. Eksempelvis har vi redegjort for hvordan tre danske virksomheder allerede anvender CC og drager store fordele heraf. Så hér må svaret være ja. På den anden side har vi i forrige afsnit redegjort for, at der er stor forskel på hvilke markedssegmenter der har taget CC til sig. Stilles spørgsmålet i forhold til enterprisemarkedet, har vi derfor ikke samme belæg for entydigt at svare ja. Vi har tidligere argumenteret for at større virksomheder vil gennemgå en proces, hvor de løbende oparbejder kompetencer og erfaringer til at kunne tage CC i brug på den mest fordelagtige måde. Vi har valgt betegnelsen CC enablement, som er udtryk for den proces virksomheder må forventes at gennemgå, når de vurderer og indarbejder CC i virksomheden. Med begrebet CC enablement, kan vi umiddelbart svare måske, men da der er tale om en proces, vil svaret med størst appel til pragmatikerne nok nærmere være det afhænger af. For at uddybe dette svar, ønsker vi at foretage en redegørelse for hvilke faser virksomheder gennemgår i processen mod at indarbejde CC. Ud fra hvad vi tidligere har behandlet, er vi i stand til at udpege og karakterisere fem modenhedsfaser, som gør sig gældende i denne proces. I det følgende redegøres for vores bud på en modenhedsmodel for CC Cloud computing modenhed En modenhedsmodel forstår vi som en teknik til at måle modenheden af en virksomhed ud fra en række karakteristika. En modenhedsmodel består af elementer der tilsammen beskriver aspekter af modenheden. Modenhed kan blandt andet forholde sig til arkitekturprocesser (EA-modenhed) og systemudviklingsmetoder (CMMI-modellen). Modenhedsmodellen for CC tager udgangspunkt i de processer der eksisterer i en virksomhed omkring implementering og anvendelse af CC frem mod at opnå enablement. Modenhedsmodellen for CC identificerer derfor hvilke faser virksomheder skal gennemgå før de kan betragtes som cloud-enablede. Side 127

130 Modenhedsmodellens placering i forhold til EA-modenhedsmodeller Virksomhedens arkitektur har betydning for hvor modent den vil kunne tage CC i brug, men er ikke afgørende herfor. Dette har vi skitseret i kapitel 4, hvor CC er mappet ind i Ross modenhedsmodel for IT-arkitektur. Samtidig bibringer CC både organisatoriske, strategiske og tekniske ændringer, hvorfor vi mener en modenhedsmodel for CC vil have stor anvendelighed, på samme måde som EAmodenhedsmodeller gør det muligt at identificere hvor langt man er i en arkitekturproces. Da CC ikke umiddelbart stiller krav til en moden arkitektur, vil en modenhedsmodel for CC tage samme udgangspunkt som for eksempel EA-modenhed, dvs. i en fase hvor mulighederne i CC ikke er erkendt eller ikke eksisterer i virksomhedens bevidsthed. Vi har ikke kendskab til andre modenhedsmodeller for CC, og som behandlet i forrige afsnit, befinder CC sig stadig på et tidligt anvendelsesstadie i større virksomheder. Alligevel mener vi at være i stand til at kunne udpege faser, som vil kunne indikere hvor langt en virksomhed er i en enablementprocessen Modenhedsmodellen En generel forudsætning for anvendelse af modenhedsmodellen er at virksomheden har en etableret IT-strategi. I denne forudsætning ligger at modenhedsmodellen henvender sig til virksomheder der ønsker at indarbejde CC i deres IT-strategi, IT-arkitektur og i det hele taget som en integreret del af forretningen. Modellen henvender sig altså i mindre grad til små virksomheder. Modenhedsmodellen skal derimod hjælpe større virksomheder til at opnå forståelse af de faser der eksisterer på vejen mod CC enablement og samtidig kan modellen indikere hvor i processen man befinder sig. Modenhedsmodellen er inddelt i fem faser og er sekventiel i den forstand, at det ikke er muligt at springe faser over. Erfaringer og gevinster opnået i én fase er dermed afgørende for at virksomheden kan opnå den næste fase. Ukendt behov Eksperimentel Forankring Hybrid Cloud-enablet Figur 36 Modenhedsmodel for cloud computing (egen udarbejdelse) De fem modenhedsfaser omtales hver for sig i det følgende: Fase 1 Ukendt behov I den første fase er der ingen erfaringer med CC i virksomheden. Der er heller ingen ambitioner om at tage nye IT-leverancemodeller i brug. Virksomheden har en implementeret IT-strategi som udmøntes i Side 128

Hvor er mine runde hjørner?

Hvor er mine runde hjørner? Hvor er mine runde hjørner? Ofte møder vi fortvivlelse blandt kunder, når de ser deres nye flotte site i deres browser og indser, at det ser anderledes ud, i forhold til det design, de godkendte i starten

Læs mere

Cloud computing. Hvad er fordelene ved Microsoft løsninger - og hvad er begrænsningerne

Cloud computing. Hvad er fordelene ved Microsoft løsninger - og hvad er begrænsningerne Cloud computing Hvad er fordelene ved Microsoft løsninger - og hvad er begrænsningerne Henrik Westergaard Hansen Architect Evangelist henrikwh@microsoft.com PC Era Portal Era Online App Era Web Services

Læs mere

Hvad er cloud computing?

Hvad er cloud computing? Hvad er cloud computing? Carsten Jørgensen cjo@devoteam.dk Devoteam Consulting COPYRIGHT 11/05/2010 Architecture & Information Simplificering af it og effektiv it til forretningen Business Intelligence

Læs mere

Morten Juul Nielsen Produktchef Microsoft Danmark

Morten Juul Nielsen Produktchef Microsoft Danmark Morten Juul Nielsen Produktchef Microsoft Danmark Er du, din organisation og dit datacenter klar til Skyen? Dynamisk Datacenter & Cloud Computing System Center Suiten med fokus på Service Manager Next

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

MÆSSIGE MULIGHEDER GIVER CLOUD COMPUTING

MÆSSIGE MULIGHEDER GIVER CLOUD COMPUTING HVILKE FORRETNINGS- MÆSSIGE MULIGHEDER GIVER CLOUD COMPUTING AGENDA Hvad er Cloud? Hvilke kundebehov forsøger Cloud at løse? Hvad er den samfundsmæssige betydning af Cloud? Hvad tilbyder Microsoft? Hvilke

Læs mere

Skyen der er skræddersyet til din forretning.

Skyen der er skræddersyet til din forretning. Skyen der er skræddersyet til din forretning. Dette er Microsoft Cloud. Alle virksomheder er unikke. Fra sundhedsvæsen til detail, produktion eller finans der er ikke to virksomheder, der opererer på samme

Læs mere

4 sekunder. 20 sekunder. 1-3 timer. 14% hurtigere. 5-6% bagud. 30/70 split. Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea

4 sekunder. 20 sekunder. 1-3 timer. 14% hurtigere. 5-6% bagud. 30/70 split. Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea 4 sekunder 1-3 timer 20 sekunder 14% hurtigere 5-6% bagud 30/70 split Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea Emnerne jeg vil tale om Brændende platforme versus brændende ambitioner

Læs mere

Projektledelse i praksis

Projektledelse i praksis Projektledelse i praksis - Hvordan skaber man (grundlaget) for gode beslutninger? Martin Malis Business Consulting, NNIT mtmi@nnit.com 20. maj, 2010 Agenda Project Governance Portfolio Management Project

Læs mere

Totally Integrated Automation. Totally Integrated Automation sætter standarden for produktivitet.

Totally Integrated Automation. Totally Integrated Automation sætter standarden for produktivitet. Totally Integrated Automation Totally Integrated Automation sætter standarden for produktivitet. Bæredygtighed sikrer konkurrenceevnen på markedet og udnytter potentialerne optimalt. Totally Integrated

Læs mere

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact More than 3500 projects In control of 55 petabyte data 450 certified consultants More than 1.5M euro in training per year 55 PB,

Læs mere

SAXOTECH Cloud Publishing

SAXOTECH Cloud Publishing SAXOTECH Cloud Publishing Fuld hosted infrastruktur til mediebranchen Stol på flere års erfaringer med hosting til mediehuse Fuld tillid til et dedikeret team af hostingeksperter Opnå omkostningsbesparelser

Læs mere

Copyright SaaS-it Consult 2011. Er Cloud Computing blot en hype eller repræsenterer det virkelig værdi? Teknologisk Institut 13.

Copyright SaaS-it Consult 2011. Er Cloud Computing blot en hype eller repræsenterer det virkelig værdi? Teknologisk Institut 13. Er Cloud Computing blot en hype eller repræsenterer det virkelig værdi? Teknologisk Institut 13. september, 2011 Cloud Computing & SaaS Hvor er vi på vej hen? Agenda Definitioner The SaaS-it Evolution

Læs mere

as a Service Dynamisk infrastruktur

as a Service Dynamisk infrastruktur Dynamisk infrastruktur Vi bygger dynamisk infrastruktur...... og holder den kørende Om jeres it-infrastruktur fungerer optimalt, er i bund og grund et spørgsmål om kapacitet. Og så er det et spørgsmål

Læs mere

Kriterie for at bestå: Deltagelse i undervisningstiden, udarbejdelse af e-magasin, deltagelse i fælles fremlægning.

Kriterie for at bestå: Deltagelse i undervisningstiden, udarbejdelse af e-magasin, deltagelse i fælles fremlægning. 1. E-MAGASINER (Herning) Hvem kan deltage: Studerende i Herning Kriterie for at bestå: Deltagelse i undervisningstiden, udarbejdelse af e-magasin, deltagelse i fælles fremlægning. På kurset lærer du at

Læs mere

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites

Læs mere

Markedsføring IV e-business

Markedsføring IV e-business Markedsføring IV e-business Målet for 5. lektionsgang Tilgang til udvikling: strategi & implementering Opbygning Fremtiden for EC Opgaven Dias 1 - Markedsføring IV - 5. Lektionsgang - Andy Skovby Hvorfor

Læs mere

It-delstrategi for administrativ it-anvendelse

It-delstrategi for administrativ it-anvendelse Administrativ DELSTRATEGI 2011-2015 NOTAT It-delstrategi for administrativ it-anvendelse 9. september 2011 Indholdsfortegnelse 1. Formål...2 2. Baggrund...2 3. Vision...3 4. Strategisk retning...3 4.1.

Læs mere

Bilag. Resume. Side 1 af 12

Bilag. Resume. Side 1 af 12 Bilag Resume I denne opgave, lægges der fokus på unge og ensomhed gennem sociale medier. Vi har i denne opgave valgt at benytte Facebook som det sociale medie vi ligger fokus på, da det er det største

Læs mere

NNIT PLAYMAKER. PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer.

NNIT PLAYMAKER. PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer. NNIT PLAYMAKER PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer. FORMÅL NYE PERSPEKTIVER OG MULIGHEDER It-rollen er under stærk forandring, påvirket

Læs mere

VidenForum Fokus på viden Viden i fokus

VidenForum Fokus på viden Viden i fokus VidenForum inviterer til seminarrække - Learn how to improve your intelligence and market analysis capabilities VidenForum har fornøjelsen at præsentere en række spændende seminarer i samarbejde med Novintel

Læs mere

DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING

DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING EN LILLE KONKURRENCE Hvem stiller det bedste spørgsmål på Twitter? #ThorupMajlund AGENDA 1. Quiz med en suveræn præmie 2. Om os 3. Digital Transformation på

Læs mere

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design ? VAD From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design? VEM Skrevet af Liam J. Bannon Director of the IDC and Professor of Computer Science,

Læs mere

CRM-system markedet i overblik. ForretningsSystemer 2013 Peter Ulka, HerbertNathan & Co. A/S

CRM-system markedet i overblik. ForretningsSystemer 2013 Peter Ulka, HerbertNathan & Co. A/S CRM-system markedet i overblik ForretningsSystemer 2013 Peter Ulka, HerbertNathan & Co. A/S Agenda Intro til CRM Trends i CRM-system markedet Markedsoverblik 6 grundlæggende overvejelser ved valg af CRM-system

Læs mere

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation Sådan er fremtidens virtuelle arbejdsplads idag! 5 tendenser der ændrer arbejdspladsen i fremtiden med IT. Giv dine medarbejdere Consumerization adgang til de applikationer af medarbejdere de har brug

Læs mere

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang.

Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Den tekniske platform Af redaktionen Computeren repræsenterer en teknologi, som er tæt knyttet til den naturvidenskabelige tilgang. Teknologisk udvikling går således hånd i hånd med videnskabelig udvikling.

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

Introduktion til NNIT

Introduktion til NNIT Introduktion til NNIT IT-kontraktsnetværk 18. august 2014 PUBLIC Kort fortalt En af Danmarks fire største leverandører af itservices Vi leverer udvikling, implementering og drift til life sciences, finanssektoren,

Læs mere

Kendskabet til converged systems er endnu lavt, da næsten halvdelen af IT beslutningstagerene ikke kender til konceptet.

Kendskabet til converged systems er endnu lavt, da næsten halvdelen af IT beslutningstagerene ikke kender til konceptet. Survey Resumé IDC Nordic, Bredgade 23A 3. 1260 Copenhagen K, Denmark & Upplandsgatan 7, 111 23 Stockholm, Sweden Converged Systems i Danmark Kendskab og præferencer Anders Elbak June 2013 Dette dokument

Læs mere

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Projektledelse Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Ilisimatusarfik HD Dimittender 2011

Ilisimatusarfik HD Dimittender 2011 HD dimittender 2011 Louise Langholz lol@ral.gl Forandringsledelse Fra forståelse til handling en planlagt organisationsforandring En undersøgelse af hvordan Royal Arctic Line A/S gennemfører etablering

Læs mere

Everything-as-a-Service. Afdelingsdirektør, Poul Bærentsen

Everything-as-a-Service. Afdelingsdirektør, Poul Bærentsen Everything-as-a-Service Afdelingsdirektør, Poul Bærentsen Agenda Atea s rejse Hvorfor ændrer IT sig til services? as-a-service tilgangen Den fremtidige it-leverance Markedstrends Atea EaaS vi skaber overblikket

Læs mere

90 erne. Værksted. Håndværker (Specialister) Kunsthåndværk. Applikationer. Isolerede Systemer. Mange leder var biologer. Uddannelsen hed svagstrøm.

90 erne. Værksted. Håndværker (Specialister) Kunsthåndværk. Applikationer. Isolerede Systemer. Mange leder var biologer. Uddannelsen hed svagstrøm. 90 erne Værksted Håndværker (Specialister) Kunsthåndværk Applikationer Isolerede Systemer 2 1 0 '90'erne Mange leder var biologer Moore s Law Uddannelsen hed svagstrøm. ITSM- Tool Mailbox, simpel database

Læs mere

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion Driftskontrakter Hvordan sikrer man sig, at man får en ordentlig driftskontrakt? Hvad skal man være opmærksom på, og hvornår begynder man egentlig at tænke den ind? Velkommen Program: Oplæg om emnet baseret

Læs mere

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Den afsluttende prøve i AT består af tre dele, synopsen, det mundtlige elevoplæg og dialogen med eksaminator og censor. De

Læs mere

Hvis incidents er dyre og besværlige...

Hvis incidents er dyre og besværlige... Hvis incidents er dyre og besværlige... 2013-03 DKKNS Page 1 Transition Management Agenda Hvem er Coloplast? Hvem er jeg? Transition management basics Transition i Coloplast Ifølge Gartner er årsagen til

Læs mere

how to save excel as pdf

how to save excel as pdf 1 how to save excel as pdf This guide will show you how to save your Excel workbook as PDF files. Before you do so, you may want to copy several sheets from several documents into one document. To do so,

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013 Oplæg ved AEA - EA netværk EA i Gentofte Kommune På ITU den 6 marts 2013 CV Sarah Ebler - Enterprise Arkitekt Gentofte Kommune Erhvervserfaring: Enterprise Architect - Gentofte Kommune - 01.10.2011 - nuværende

Læs mere

Test i Danmark. Undersøgelse på. TestExpo

Test i Danmark. Undersøgelse på. TestExpo Test i Danmark Undersøgelse på 2015 TestExpo 1 Indledning Velkommen til anden udgave af Test i Danmark rapporten. Test i Danmark har til formål at undersøge softwaretest og QA tendenser i Danmark og dets

Læs mere

PRODUKTIONSSTYRING OG -PLANLÆGNING

PRODUKTIONSSTYRING OG -PLANLÆGNING PRODUKTIONSSTYRING OG -PLANLÆGNING Introduktion Er det egentlig præcist at tale om produktion når temaet er spiludvikling? For produktion dufter jo af faste procedurer, kendte milepæle, og definerede krav

Læs mere

3.g elevernes tidsplan for eksamensforløbet i AT 2015

3.g elevernes tidsplan for eksamensforløbet i AT 2015 Mandag d. 26.1.15 i 4. modul Mandag d. 2.2.15 i 1. og 2. modul 3.g elevernes tidsplan for eksamensforløbet i AT 2015 AT emnet offentliggøres kl.13.30. Klasserne er fordelt 4 steder se fordeling i Lectio:

Læs mere

Manuskriptvejledning pr. 2015 Bachelorprisen

Manuskriptvejledning pr. 2015 Bachelorprisen Manuskriptvejledning pr. 2015 Bachelorprisen Fremsendelse af artikel Artikler skrevet på baggrund af bachelorprojekter, der er afleveret og bestået på det annoncerede tidspunkt, kan deltage i konkurrencen

Læs mere

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer?

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Christian Eilskov Sales Engineer, christian_eilskov@dell.com +45 40 60 13 92 Dell Cloud Client Computing Dell lever produkter

Læs mere

ERP. Uddrag af artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

ERP. Uddrag af artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. ERP Uddrag af artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.

Læs mere

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

CRM. v. Philip Riis, CRM Team-Lead, EG

CRM. v. Philip Riis, CRM Team-Lead, EG CRM v. Philip Riis, CRM Team-Lead, EG Hvad er CRM, og hvorfor er det vigtigt? Hvordan implementerer man CRM? Hvad kan Microsoft Dynamics CRM? Agenda En CRM-kundecase fra forsyningsbranchen CRM i kontekst

Læs mere

IT-UNIVERSITETET I KØBENHAVN

IT-UNIVERSITETET I KØBENHAVN IT-UNIVERSITETET I KØBENHAVN MASTER I SOFTWARE ENGINEERING itu.dk/master/software MASTER I SOFTWARE ENGINEERING Master i Software Engineering er til dig, som allerede er en erfaren software- og systemudvikler,

Læs mere

Som mentalt og moralsk problem

Som mentalt og moralsk problem Rasmus Vincentz 'Klimaproblemerne - hvad rager det mig?' Rasmus Vincentz - November 2010 - Som mentalt og moralsk problem Som problem for vores videnskablige verdensbillede Som problem med økonomisk system

Læs mere

Introduktion til NemHandel

Introduktion til NemHandel NemHandel i skyen - holdt business casen? Heinrich Clausen HotHouse Cph og Helle Schade-Sørensen IT og Telestyrelsen Introduktion til NemHandel Løftestangen: Bekendtgørelsen fra 2005 om elektronisk regning

Læs mere

To Cloud or not. Myndigheder og virksomheders valg af cloud computing. To Cloud or Not

To Cloud or not. Myndigheder og virksomheders valg af cloud computing. To Cloud or Not To Cloud or Not To Cloud or not Myndigheder og virksomheders valg af cloud computing Bjørn Borre, Chefkonsulent IT-Branchen, bjb@itb.dk Mobil 27522524 1 Om IT-Branchen Om Bjørn Borre 300 it-virksomheder.

Læs mere

OM AT LYKKES MED FORANDRINGSLEDELSE. Roskilde bibliotekerne 2013

OM AT LYKKES MED FORANDRINGSLEDELSE. Roskilde bibliotekerne 2013 OM AT LYKKES MED FORANDRINGSLEDELSE Roskilde bibliotekerne 2013 1 FORSTÅ FORANDRINGSBEHOVET Det nye i opgaven? For mig som leder? krav til ledelse? Kulturen? For medarbejderne Arbejdsmetoderne? Kompetencer?

Læs mere

Statens brug af konsulenter

Statens brug af konsulenter Statens brug af konsulenter Statens indkøb af konsulentydelser er faldet fra 2008 og frem til 2012 med 738 mio. kr. fra 4,5 mio. kr. til 3,7 mio. kr. Statens indkøb har været faldende år for år dog lige

Læs mere

HVOR AUTOMATISERET ER DEN DANSKE FREMSTILLINGSINDUSTRI?

HVOR AUTOMATISERET ER DEN DANSKE FREMSTILLINGSINDUSTRI? Research Note 18. april 2013 Centre for Economic and Business Research (CEBR) Copenhagen Business School Dept. of Economics Porcelænshaven 16A DK-2000 Frederiksberg +45 3815 2575 HVOR AUTOMATISERET ER

Læs mere

Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning

Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning Jørgen Goul Andersen (email: goul@ps.au.dk) & Henrik Lolle (email: lolle@dps.aau.dk) Måling af lykke eksploderer!

Læs mere

På vej mod IP-telefoni. nyttige overvejelser fra A til Z

På vej mod IP-telefoni. nyttige overvejelser fra A til Z På vej mod IP-telefoni nyttige overvejelser fra A til Z Hvorfor vælge IP-telefoni? Der er mange gode grunde til at indføre IP-telefoni. To af dem er, at dagligdagen bliver lettere og mere effektiv. De

Læs mere

Byens Rum. The Meaningful City of Tomorrow

Byens Rum. The Meaningful City of Tomorrow Byens Rum The Meaningful City of Tomorrow The vision of the future is always changing, dependent of the technology and knowledge on all fields: If you design the best building you know to design, that's

Læs mere

Øget konkurrencekraft med Supply Chain Innovation

Øget konkurrencekraft med Supply Chain Innovation Øget konkurrencekraft med Supply Chain Innovation Fredag den 25. september 2015 Jan Stentoft Ekspertviden direkte til dig Landets bedste hoveder klæder dig på. Børsen Ledelse dækker alle de emner, du som

Læs mere

Hvad er fremtiden for internettet?

Hvad er fremtiden for internettet? Hvad er fremtiden for internettet? pcfly.info Den Internettet er blot et par årtier gamle, men i dette korte tidsrum har oplevet væsentlige ændringer. Den voksede ud af et sammensurium af uafhængige netværk

Læs mere

WINDCHILL THE NEXT STEPS

WINDCHILL THE NEXT STEPS WINDCHILL THE NEXT STEPS PTC/user, 4. marts 2015 Jens Christian Jensen, Econocap Agenda Windchill the next steps Bliv opdateret og inspireret til at se hvor Windchill kan hjælpe dig med andet end blot

Læs mere

Innovations- og forandringsledelse

Innovations- og forandringsledelse Innovations- og forandringsledelse Artikel trykt i Innovations- og forandringsledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger

Læs mere

FORBRUGERADFÆRD Metode og resultater i forprojektet

FORBRUGERADFÆRD Metode og resultater i forprojektet FORBRUGERADFÆRD Metode og resultater i forprojektet v./ Mette Skovgaard Frich, seniorkonsulent Retail Institute Scandinavia Baggrund for projektet STIGENDE FORBRUGERKRAV OG MAGT: I takt med en stigende

Læs mere

IT-Universitetet, E-business, forår 2008

IT-Universitetet, E-business, forår 2008 IT-Universitetet, E-business, forår 2008 Forretningsteknisk 8-ugersprojekt Vejleder: John Gøtze Udarbejdet af: Anders Kann & Martin Albertsen Indholdsfortegnelse 1. Indledning... 4 1.1 Problemformulering...

Læs mere

PROGRAM 2010. Erfaring - Inspiration - Network - Idéer - Viden. HP Test Brugergruppe Brugerkonference. 11. november 2010

PROGRAM 2010. Erfaring - Inspiration - Network - Idéer - Viden. HP Test Brugergruppe Brugerkonference. 11. november 2010 PROGRAM Erfaring - Inspiration - Network - Idéer - Viden Hotel Scandic Copenhagen Vester Søgade 6 1601 København 09:00-09:30 Modtagelse og morgenmad 09:30-09:45 Velkomst og præsentation af konferencen

Læs mere

Implementering af evidensbaseret viden lederskab som bærende faktor

Implementering af evidensbaseret viden lederskab som bærende faktor Implementering af evidensbaseret viden lederskab som bærende faktor Bianca Albers Familie og Evidens Center Fokus for oplægget Evidens Ledelse Implementering Outcome Evidensbaseret vs. evidensinformeret

Læs mere

Roadshow: ITIL V3. hvordan træder man ud af børneskoene?

Roadshow: ITIL V3. hvordan træder man ud af børneskoene? Roadshow: ITIL V3 hvordan træder man ud af børneskoene? Westergaard Management A/S Stifter Ole Westegaard Adm. Direktør Steen Sverker Nilsson Direktør Johnny Jensen Westergaard Management stiftedes den

Læs mere

Forretningsorienteret it-governance

Forretningsorienteret it-governance Forretningsorienteret it-governance Midlet til forretningsorienteret it-anvendelse af chefkonsulent Bo Lind, BLI@a-2.dk og chefkonsulent Steen Bruno Hansen, STBH@a-2.dk, A-2 A/S Der hviler i dag et meget

Læs mere

Vejledning i valg af coachuddannelse

Vejledning i valg af coachuddannelse Vejledning i valg af coachuddannelse Coaching er et gråt marked Vi taler med mange forskellige mennesker, der ønsker en uddannelse som coach. De to hyppigste spørgsmål vi får fra potentielle kunder er:

Læs mere

HVOR AUTOMATISERET ER DEN DANSKE FREMSTILLINGSINDUSTRI?

HVOR AUTOMATISERET ER DEN DANSKE FREMSTILLINGSINDUSTRI? Centre for Economic and Business Research, CEBR Copenhagen Business School Dept. of Economics Porcelænshaven 16A DK-2000 Frederiksberg +45 3815 2575 RESEARCH NOTE 18. april 2013 HVOR AUTOMATISERET ER DEN

Læs mere

DET VIDENSKABELIGE PROBLEM og problemformuleringen

DET VIDENSKABELIGE PROBLEM og problemformuleringen Synonym: vidensproblem DET VIDENSKABELIGE PROBLEM og problemformuleringen Lek$on 3 v/ Anne Hvejsel DAGENS PROGRAM 1. Opgaveformalia 2. Pointer fra lek$on 2 3. Fra emne $l problemformulering 4. Hermeneu$k

Læs mere

CSC Innovation Consulting. - Inspiration til innovative løsninger

CSC Innovation Consulting. - Inspiration til innovative løsninger : CSC Innovation Consulting - Inspiration til innovative løsninger INNOVATION Praktisk innovation skal være er et centralt element i vores samarbejde med kunder. Vores metode Vi baserer vores metode på

Læs mere

leverer forventet udbytte Kun 10% af strategiske projekter

leverer forventet udbytte Kun 10% af strategiske projekter leverer forventet udbytte Kun 10% af strategiske projekter Hvem er Crevato Crevato er et professionelt konsulenthus der bistår danske og internationale virksomheder i forbindelse med: Strategi Portefølje

Læs mere

En tur rundt om skyen:

En tur rundt om skyen: En tur rundt om skyen: Hvor skal vi hen? Bjarne B. Dollerup, Evangelist Jens, IT Chef Større dansk virksomhed Jens har et par spørgsmål om skyen Hva er det der mæ skyen? Og hva ka jeg bruge den til? Og

Læs mere

Security & Risk Management Summit

Security & Risk Management Summit Security & Risk Management Summit Hvor og hvornår skaber Managed Security Services værdi? Business Development Manager Martin Jæger Søborg, 6. november 2014 DUBEX SECURITY & RISK MANAGEMENT SUMMIT 2014

Læs mere

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. ERP Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.

Læs mere

Investorpræsentation. Fundamentet for fortsat vækst er styrket. Jørn Larsen, CEO, Founder

Investorpræsentation. Fundamentet for fortsat vækst er styrket. Jørn Larsen, CEO, Founder Investorpræsentation Fundamentet for fortsat vækst er styrket Jørn Larsen, CEO, Founder 9. maj 2011 Trifork En innovativ virksomhed Værdier Passion Performance Dygtighed Team work Gøre en forskel I centrum

Læs mere

Strategi for KORA: Opstartsårene, og årene frem til 2020

Strategi for KORA: Opstartsårene, og årene frem til 2020 3. maj 2013.JRSK/brdi Strategi for KORA: Opstartsårene, og årene frem til 2020 Den samfundsøkonomiske udfordring De demografiske ændringer i befolkningen og den økonomiske krise presser finansieringen

Læs mere

DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet

DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet Sammenfatning Denne vejledning adresserer risikoen for industrispionage fra statssponserede aktører i udlandet mod

Læs mere

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

Fremtidens forskning og forskningsbiblioteket Resumé

Fremtidens forskning og forskningsbiblioteket Resumé Fremtidens forskning og forskningsbiblioteket Resumé Danmarks Elektroniske Fag- og Forskningsbibliotek Fremtidens forskning og forskningsbiblioteket Resumé Massive teknologiske forandringer inden for forskning,

Læs mere

Kvalitetsstyring. Peter Neergaard. Fag : Organisation

Kvalitetsstyring. Peter Neergaard. Fag : Organisation Side 1 af 6 Kvalitetsstyring Peter Neergaard Fag : Organisation Overordnet Bogen har to hovedformål: a) En kortlægning af kvalitetsstyring i danske virksomheder. Resultaterne af denne analyse kan anvendes

Læs mere

Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug. Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011

Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug. Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011 Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011 Formål og agenda Formål Vi vil på denne workshop diskutere:

Læs mere

Forskning i socialpædagogik socialpædagogisk forskning?

Forskning i socialpædagogik socialpædagogisk forskning? Forskning i socialpædagogik socialpædagogisk forskning? eller knudramian.pbwiki.com www.regionmidtjylland.dkc Indhold Professionsforskning til problemløsning eller som slagvåben? Hvad er forskning? Hvad

Læs mere

Aspector v/morten Kamp Andersen. Hvorfor Talent Management? - argumenter og business case

Aspector v/morten Kamp Andersen. Hvorfor Talent Management? - argumenter og business case Aspector v/morten Kamp Andersen Hvorfor Talent Management? - argumenter og business case PROGRAM 1. Hvorfor er der (igen) fokus på Talent Management? 2. Hvad er Talent Management? 3. Hvad er business casen?

Læs mere

QUICK START Updated: 18. Febr. 2014

QUICK START Updated: 18. Febr. 2014 QUICK START Updated: 18. Febr. 2014 For at komme hurtigt og godt igang med dine nye Webstech produkter, anbefales at du downloader den senest opdaterede QuickStart fra vores hjemmeside: In order to get

Læs mere

Skal jeg hyre konsulenter?

Skal jeg hyre konsulenter? Maj 2012 3. årgang, nummer 4 Skal jeg hyre konsulenter? Eller ansætte flere medarbejdere? SAP-koncernen stormer frem. Der er ikke langt imellem virksomhedsopkøb og lancering af ny teknologi. Igen i første

Læs mere

Det centrale emne er mennesket og dets frembringelse Humaniora:

Det centrale emne er mennesket og dets frembringelse Humaniora: HUMANIORA HUMANIORA Det centrale emne er mennesket og dets frembringelse Humaniora: Beskæftiger sig med mennesket som tænkende, følende, handlende og skabende væsen. Omhandler menneskelige forhold udtrykt

Læs mere

Statens strategi for overgang til IPv6

Statens strategi for overgang til IPv6 Notat Statens strategi for overgang til IPv6 Overgangen til en ny version af internetprotokollen skal koordineres såvel internationalt som nationalt. For at sikre en smidig overgang har OECD og EU anbefalet,

Læs mere

René Ingemann Andersen, rene.ingemann@appinux.com

René Ingemann Andersen, rene.ingemann@appinux.com Onsdag 29. april 2009 René Ingemann Andersen, rene.ingemann@appinux.com Jeg kan godt li Beethoven især hans digte Ringo Starr Agenda 1. Principperne bag open source 2. Demo af Open Office 3. Pause 4. On

Læs mere

Forretningsmodeller for mobile applikationer

Forretningsmodeller for mobile applikationer Forretningsmodeller for mobile applikationer Indsigt og strategi Søren Kottal Eskildsen Alexandra Instituttet A/S Skabelon til forretningsmodel for mobile Click to edit Master title style applikationer

Læs mere

Introduktion til fase 1 af program Nye grønne forretningsmodeller

Introduktion til fase 1 af program Nye grønne forretningsmodeller Introduktion til fase 1 af program Nye grønne forretningsmodeller Deadline for ansøgning: 29. oktober 2013 kl.12:00 1. Hvad kan der søges om? Har du en idé til en ny grøn forretningsmodel? Og tror du,

Læs mere

Kompetencestrategi af Poul Mouritsen

Kompetencestrategi af Poul Mouritsen Kompetencestrategi af Poul Mouritsen Indledning Kompetencestrategi er en proces, der hjælper en organisation til at træffe gode langsigtede beslutninger omkring kompetenceudvikling. Umiddelbart er der

Læs mere

Professionel it-drift af din forretningsplatform

Professionel it-drift af din forretningsplatform Professionel it-drift af din forretningsplatform Din billet til it-afdelingens rejse fra costcenter til kraftcenter INVITATION TIL GRATIS KONFERENCE København, 2. juni Aarhus, 3. juni Tag kollegerne med

Læs mere

Kapitalstruktur i Danmark. M. Borberg og J. Motzfeldt

Kapitalstruktur i Danmark. M. Borberg og J. Motzfeldt Kapitalstruktur i Danmark M. Borberg og J. Motzfeldt KORT OM ANALYSEN Omfattende studie i samarbejde med Økonomisk Ugebrev Indblik i ledelsens motiver for valg af kapitalstruktur Er der en optimal kapitalstruktur

Læs mere

White Paper. Application Management Outsourcing blandt danske top-500 virksomheder - sådan prioriterer it-cheferne og sådan udvikler markedet sig

White Paper. Application Management Outsourcing blandt danske top-500 virksomheder - sådan prioriterer it-cheferne og sådan udvikler markedet sig White Paper - sådan prioriterer it-cheferne og sådan udvikler markedet sig Udarbejdet for af Anne-Lise Wang, Phacit, HENRY Fellow I samarbejde med HENRY Corporation 2010 HENRY Corporation Denmark Sammenfatning

Læs mere

Anerkendende, værdiskabende evaluering i organisationer - brugbare distinktioner i etableringen af udbytterig dokumentations- og evalueringspraksis

Anerkendende, værdiskabende evaluering i organisationer - brugbare distinktioner i etableringen af udbytterig dokumentations- og evalueringspraksis Anerkendende, værdiskabende evaluering i organisationer - brugbare distinktioner i etableringen af udbytterig dokumentations- og evalueringspraksis af Eva Damsgaard og Andreas Granhof Juhl, 2007 (c) Indledning

Læs mere

Øget konkurrencekraft med Supply Chain Innovation. Mandag den 28. september 2015 Jan Stentoft stentoft@sam.sdu.dk

Øget konkurrencekraft med Supply Chain Innovation. Mandag den 28. september 2015 Jan Stentoft stentoft@sam.sdu.dk Øget konkurrencekraft med Supply Chain Innovation Mandag den 28. september 2015 Jan Stentoft stentoft@sam.sdu.dk Ekspertviden direkte til dig Landets bedste hoveder klæder dig på. Børsen Ledelse dækker

Læs mere