Voordat je kunt overgaan om de succes­fac­toren te bepalen dienen we eerst kort te omschrijven wat men verstaat onder de term ‘Cloud Computing’

Beschrij­ving van Cloud computing

De beschrij­ving van Cloud computing wordt het best benaderd door het NIST. Hierbij heeft men vijf kenmerken waaraan Cloud computing voldoet. Maar het probleem met dit concept is dat het op enorm veel verschil­lende manieren geïn­ter­pre­teerd kan worden. In ieder zijn belevenis kan Cloud computing totaal anders zijn. Daarom is het belang­rijkste dat men moet onthouden dat het “every­thing-as-a-service” is. Cloud computing is in feite eerder een nieuw business-model, dan een nieuwe tech­no­logie.
Er bestaan drie type aanbie­ders in de Cloud. Je hebt de Cloud-builders, dit zijn fysieke bouwers op de infra­struc­tuur-server. Dan zijn er de Cloud-resellers, deze tweede groep gaat voor­na­me­lijk door­ver­kopen. Net zoals een systeem-inte­grator doet of zoals men printers verkoopt. Als derde groep vinden we de servi­ce­pro­vi­ders. Het verschil tussen de providers en de resellers is dat een provider naast een hele diensten-portfolio de connec­ti­vi­teit gaat beheren. Hierdoor kan de provider een end-to-end oplossing aanbieden aan de klanten, inclusief band­breedte, connec­ti­vi­teit en verbin­dingen.

Voor- en nadelen

Het grootste nadeel is dat je niet alles in de Cloud kan zetten. Daarom moet men op voorhand een assess­ment maken waarbij men de kritische en niet-kritische appli­ca­ties van de onder­ne­ming moet oplijsten en nakijken welke niet-kritische men in de Cloud kan zetten. Er zijn drie redenen waarom men niet alles in de Cloud kan zetten. Ten eerste zijn er de bedrijfs­kri­ti­sche appli­ca­ties, deze appli­ca­ties mag men niet verliezen want anders kan het bedrijf zijn normale bedrijfs­voe­ring niet doen. Ten tweede is sommige infor­matie zeer bedrijfs­ge­voelig. Ook deze data kan men niet zomaar in de Cloud zetten. En ten derde, sommige appli­ca­ties zijn niet klaar om in de Cloud- omgeving te kunnen werken. Een appli­catie in de Cloud moet multi-tenant en multitier zijn. Multi-tier wil zeggen dat de appli­catie intel­li­gent is en dat deze weet waar de gebruiker zich bevindt. Stel dat men vertrekt richting Azië, en men gaat in Azië inloggen op Facebook, dan weet die appli­catie waar men zich exact bevindt en zal zij verbin­ding maken met het dichtst­bij­zijnde data­cen­trum.
De factor kosten­be­spa­ring wordt vaak als één van de hoofd­re­denen gezien voor bedrijven om Cloud computing te gebruiken. Dit is in feite één van de slechtste elementen om iets met Cloud te doen. Natuur­lijk zal men van een CAPEX naar een OPEX-model gaan, dus hierdoor hoef je vooraf geen grote inves­te­ringen te doen. Dit is een goed antwoord op de huidige Belgische economie. IT managers hebben al jaren dezelfde stress, do more with less. En dan is een Cloud-oplossing hierbij ideaal, want dan hoeft men geen hardware aan te schaffen en enkel een ‘per user’-model toe te passen.
Qua algemeen aanvaarde stan­daarden zit men nog een heel eind. Men is er wel mee bezig, zo heeft men binnen de Europese Commissie speciale groepen opgesteld die werken rond dit thema. Het nadeel verbonden aan de Europese Commissie is dat deze groep uit een 80-tal stake­hol­ders bestaat waarbij de grote spelers (Sales­Force, Oracle, Google,…) mee aan tafel zitten. Deze partijen willen het beste voor zichzelf en willen geen Europese regels die in hun nadeel zouden kunnen werken.

Cloud Money

Mogelijke succes­fac­toren

a. Bedrijf

De grootte van de onder­ne­ming speelt bij Cloud computing helemaal geen rol. Dit komt omdat Cloud alles over­koe­pelt. Bij een tradi­ti­o­nele IT is men geneigd om verticale segmenten te maken. Hierbij heeft elke segmen­tatie zijn eigen speci­a­li­sa­ties. Men gaat zich toespitsen op een bepaald type onder­ne­ming waarbij de grootte wel een rol speelt. Terwijl bij Cloud computing geen enkel bedrijf zou zeggen dat ze niets met Cloud computing zouden kunnen doen. Of men nu een bedrijf is van 100 werk­ne­mers of 1000 werk­ne­mers, de Cloud-infra­struc­tuur zal geen impact hebben op de lokale structuur. Het zal wel zo zijn dat het voor een kleiner bedrijf een eenvou­di­gere stap is, terwijl het voor een grote onder­ne­ming een traject is waarbij men een aantal stappen moet zetten.

b. Voor­be­rei­ding

Een groot nadeel van Cloud computing is dat je niet alles in de Cloud kan zetten. Daarom moet men op voorhand een assess­ment maken. Hierbij moet men de bedrijfs­kri­ti­sche en niet- bedrijfs­kri­ti­sche appli­ca­ties die een bedrijf gebruikt gaan oplijsten en gaan kijken of we de niet- kritische appli­ca­ties in de Cloud kunnen zetten. De Cloud is een online omgeving waarbij men overal en altijd bereik­baar moet kunnen zijn. Maar, het is geen simpele opdracht om de connec­ti­vi­teit overal te kunnen garan­deren. In België zijn er nog heel wat black-spots, hele streken, indu­strie­ter­reinen waar nauwe­lijks verbin­ding is.
Deze assess­ment moet ook gedaan worden met de data die men in huis heeft. Hierbij gaat men de gevoelige infor­matie onder­scheiden van de niet-gevoelige infor­matie. Een zieken­huis is bijvoor­beeld verplicht om pati­ën­ten­dos­siers bij te houden. Een patiënt wenst niet dat al zijn persoon­lijke gegevens beschik­baar zouden komen op het internet. Daarom is het belang­rijk dat men eerst en vooral data­clas­si­fi­catie doet. Deze clas­si­fi­catie bestaat uit twee onder­delen, ten eerste ga je dus de gevoelige data onder­scheiden en ten tweede ga je de cold van de hot data onder­scheiden. Hot data zijn data die zeer frequent worden geraad­pleegd, cold data zijn data die amper worden geraad­pleegd. Hierbij gaat men de stor­age­ca­pa­ci­teit herver­delen of offloaden.
De data­clas­si­fi­catie is voor­na­me­lijk belang­rijk om als bedrijf te kijken welke infor­matie men beschik­baar gaat stellen, wie er toegang toe heeft en welke admi­ni­stra­tieve rechten men nodig heeft.
Een exit-plan is belang­rijker dan een imple­men­ta­tie­plan. Een voorbeeld, een Facebook-account aanmaken kan in een aantal tellen gebeuren. Maar het verwij­deren van het account is zeer moeilijk. Dit zien we ook terug binnen Cloud, als bedrijf is het zeer gemak­ke­lijk om Cloud op te starten, dat is ook de troef van de Cloud-servi­ce­pro­vider. Het grootste nadeel hieraan verbonden is dat er vaak een bepaalde lock-in is. Als bedrijf is het belang­rijk dat men dan weet hoe men eruit kan stappen en of men alle data terug krijgt en in welke vorm; moet men daarna alles terug van nul herbe­ginnen of niet? Daarom moet men, voor men in de Cloud stapt, goed nadenken over een Exit-policy en een Exit-strategie. Vaak worden er geen duide­lijke afspraken gemaakt omtrent de Exit-strategie. Het kan dat je alle data terug krijgt, zelfs de virtuele servers, maar dat het enorm veel geld kost om dit terug te krijgen.

c. Project­ma­na­ge­ment

De tradi­ti­o­nele evalu­a­tie­me­thoden zoals NPV, Cashflow, PBP, enz. komt men nog steeds tegen bij projecten rond Cloud computing. Wat opgemerkt kan worden is dat deze methoden eerder als houvast worden gebruikt om een bepaalde methodiek te hebben van hoe men met al die proce­dures omgaat. Bij Cloud computing is het zeer verschil­lend, de ene doet het met de natte vinger en vanuit het buik­ge­voel en er zijn anderen die alles volgens proce­dures laten verlopen (bijvoor­beeld ISO-stan­daarden).
Voor elk project moet er een gepaste project­ma­na­ge­ment methode gebruikt worden. Toch merkt men hier dat het zeer moeilijk is om te gaan bepalen welke methode er gekozen zal worden. De methode die men zal gebruiken hangt af van het type project, van de project leider, van de manager, de processen, proce­dures,…
Proto­types moet men binnen de context van Cloud computing zien als testing & devel­op­ment. SaaS-spelers zijn verplicht om versie­con­trole uit te voeren, de reden hiervoor is dat het hier over een appli­catie gaat die multi-tenant is. Deze appli­catie kan honderden tot duizenden bedrijven bereiken, dus een nieuwe versie bereikt ook al deze bedrijven. Als er dan een fout in een update zit, dan zal deze fout ook al deze bedrijven bereiken. Test en Devel­op­ment wordt dus zeer belang­rijk voor SaaS-spelers. Voor IaaS-spelers is zo’n prototype minder belang­rijk, want indien het een keer werkt, dan zal die infra­struc­tuur blijven werken.

d. Stan­daar­di­satie

De meeste Cloud-diensten zijn gestan­daar­di­seerde producten. Bij de grote publieke spelers is het zeer moeilijk om deze aan te passen en dus werkt men best met een gestan­daar­di­seerd product. Zo is bijvoor­beeld een Gmail-account een zeer standaard product. De func­ti­o­na­li­teiten zijn dezelfde als deze van elk ander Gmail-account, niet meer en niet minder. Als men een aange­paste versie wil, dan gaat dat niet.
Dankzij deze stan­daar­di­satie haalt men ook een econo­misch schaal­voor­deel. Wanneer men werkt met gestan­daar­di­seerde producten, dan is het uitrollen van een platform zeer snel gedaan. Hierdoor kan het bedrijf veel sneller het platform opbouwen en hoeven er geen andere inves­te­ringen gedaan worden.

e. Project-team

Bij het bepalen van de leden van een project­team moet men eerst nagaan of het gaat over een publieke, private of hybride Cloud-oplossing. Binnen dit hybride-stuk heeft men nog twee vormen, namelijk een private-publieke-omgeving en een on-premise-private-omgeving. Na het bepalen van de Cloud-omgeving moet men de scope defi­ni­ëren.
Het is ook belang­rijk te bepalen welke partij welke taken krijgt. Welke zaken doet de servi­ce­pro­vider en wat moet de klant doen. Daarom moet het project­team bestaan uit mensen van de servi­ce­pro­vider en interne mensen van de orga­ni­satie.

f. Mana­ge­ment

Dat controle bij topma­na­ge­ment zou moeten liggen is niet zo belang­rijk binnen Cloud computing. Wat wel belang­rijk is, is dat er buy-in is van het mana­ge­ment zodat ze betrokken zijn bij het project. De controle van een project moet bij het IT-mana­ge­ment liggen en bij het project­team.
Een bestuurs­co­mité is een onderdeel dat bestaat uit managers en leiding­ge­vende functies en dat verant­woor­de­lijk is voor de imple­men­tatie. Het is zeer belang­rijk dat deze organen regel­matig met elkaar verga­deren. Deze opvolging mag wekelijks gebeuren wanneer het over een project gaat dat meerdere weken tot maanden duurt.

g. Aanbieder

Hard-to-imitate producten zijn producten waarmee een orga­ni­satie zich kan onder­scheiden van de concur­rentie. Maar dit speelt geen rol binnen Cloud computing. Het is namelijk zo dat men eerder de algemene zaken zoals bijvoor­beeld email, archi­ve­ring, back-up,… gaat outsourcen naar een Cloud.
Als men wil dat het accep­tatie-niveau van een platform snel en vlot verloopt, dan moet men dat zo wijd en verspreid mogelijk maken. Hierbij mogen er dan geen onder­schei­dende, speciale afwij­kingen op zijn. Als voorbeeld kan men Dropbox nemen. Een paar jaar terug beweerden de meeste IT-afde­lingen dat dit geen goede oplossing was omdat dan alles in de Cloud staat. Ze wilden dit allemaal liever intern houden. Op dat moment begonnen ze eigen oplos­singen te verzinnen. Maar toen wou de gebruiker deze functies op een smartphone kunnen gebruiken en kwam er vraag naar een appli­catie voor deze mobiele telefoon. De uitge­vonden oplos­singen van de bedrijven konden niet in een appli­catie gegoten worden omdat deze veel te inge­wik­keld waren.
Kortom de kunst is niet hard-to-imitate, maar eerder you-better-imitate. Als je Dropbox succesvol wil maken in je orga­ni­satie, zorg dan dat de interface Dropbox-alike is, maak het zo gelijk­aardig dat de gebrui­kers het gemak inzien. In het Cloud-fenomeen is dat zeer belang­rijk want de users kennen het al, dus werk er op voort.

Cloud Hands

Erva­ringen met gefaalde imple­men­ta­ties

Gefaalde Cloud-imple­men­ta­ties komen (nog) niet vaak voor in België, omdat de Cloud-tech­no­logie nog maar in de kinder­schoenen staat. Men is nu pas bezig met de eerste grote imple­men­ta­ties. De meest voor­ko­mende fout bij gefaalde projecten is dat er geen data­clas­si­fi­catie is gedaan, noch een assess­ment van wat alle appli­ca­ties zijn en welke kritisch en niet-kritisch zijn.

Toekomst van Cloud computing

Binnen deze evolutie zijn er een aantal waves. Momenteel zitten we in de eerste wave waarbij de virtu­a­li­satie de eerste stap heeft mogelijk gemaakt. Hierdoor kan men de bestu­rings­soft­ware loskop­pelen van de hardware. De grote uitdaging voor Data­cen­ters en Cloud-servi­ce­pro­vi­ders is dat men steeds meer moet kunnen bereiken met minder middelen. Dus men moet meer opslag­ruimte kunnen aanbieden met steeds minder servers. Dit terwijl men minder elek­tri­ci­teit moet verbruiken en groener moet kunnen werken. De tweede uitdaging is dat bedrijven steeds sneller moeten kunnen reageren op markt­si­tu­a­ties. Hierbij is Cloud een goede oplossing. Het laat toe om flexi­beler om te gaan met de capa­ci­teit die men nodig heeft, waarbij de gebruiker enkel betaalt voor het gebruik. Doordat Cloud zo inte­res­sant wordt, staat de Cloud-servi­ce­pro­vider nu voor de uitdaging om aan de verwach­tingen te kunnen blijven voldoen. Binnen­kort zal de tweede wave ons bereiken. De tweede wave zal ervoor zorgen dat we alles met elkaar kunnen verbinden, Internet of Things. Dit zal een gigan­tisch platform vergen zodat alles verbonden kan worden. Dit platform zal een Cloud-omgeving zijn omdat dit de enige mogelijke manier is. Dus in feite is Cloud maar pas de basis van wat er allemaal nog zal komen.

Interview met de Cloud­Ma­ke­laar na aanlei­ding van het schrijven van mijn thesis voor de faculteit economie en bedrijfs­we­ten­schappen campus Brussel
Auteur: Yannick Devits

Pin It on Pinterest

Share This

Door de site te te blijven gebruiken, gaat u akkoord met het gebruik van cookies. meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten