IT Infrastructure Chapter 4 TCO PDF

4 Total Cost of Ownership (TCO)......................................................................................... 1 4.1 Wat is TCO? ............................................................................................................... 1 4.2 Enkele Modellen om TCO te berekenen ......

4 Total Cost of Ownership (TCO)......................................................................................... 1 4.1 Wat is TCO? ............................................................................................................... 1 4.2 Enkele Modellen om TCO te berekenen .................................................................... 3 4.2.1 Het Direct/indirect TCO model van Piedad ....................................................... 3 4.2.2 Acquisitie/administratie TCO model van David, Schuff en St. Louis. .............. 4 4.2.3 Kapitaal/Niet-kapitaal TCO model van Gartner ................................................ 5 4.3 Wat betekent TCO in cloud computing ...................................................................... 6 4.3.1 Cloud pricing ...................................................................................................... 7 4.3.2 Schatting van de cloud TCO .............................................................................. 9 4.3.3 De niet-tastbare voordelen van cloud ............................................................... 10 4.3.4 Vergelijken van een on-premise-TCO met een cloud-TCO ............................. 11 4.4 Clouddiensten monitoren ......................................................................................... 11 4.5 Referenties ................................................................................................................ 13 4 Total Cost of Ownership (TCO) TCO of Total Cost of Ownership is de manier waarop bedrijven proberen om te gaan met de kostprijs gekoppeld aan IT-infrastructuur. Waar bedrijven gewoon zijn om te werken met ROI (Return On Investment), blijkt deze niet toereikend te zijn voor informatiesystemen binnen een organisatie. Wanneer een bedrijf een nieuw product op de markt wil brengen kan het proberen om via een marketing campagne consumenten bewust te maken van dit product. Die campagne zal een bepaald budget vergen en na de campagne kan men meten hoe effectief de campagne was. Zo kunnen bedrijven proberen achterhalen wat de terugwin-waarde is na de investering. Een dergelijke redenering doortrekken naar een investering in IT-infrastructuur blijkt heel wat complexer te zijn. Stel een retailer ontwikkelt een app die klanten toelaat om een boodschappenlijstje op hun GSM bij te houden. Hierin kunnen ze artikels opzoeken in een databank van het bedrijf waarin de voorraad van de artikelen per vestiging worden bijgehouden. Als klanten door de winkel lopen, of thuis nieuwe artikelen willen toevoegen, kunnen ze met de app de barcode scannen en op die manier het boodschappenlijstje beheren. Er zal vrij veel IT-infrastructuur nodig zijn om dergelijk project tot stand te brengen. Een server (al dan niet in de cloud), een team dat de app’s ontwikkelt (liefst beschikbaar voor verschillende platforms: IOS, Android …) … Dergelijke IT-infrastructuur beheren is een totaal nieuwe kost die soms heel moeilijk in te schatten is. Een app toegang verlenen tot een databank resulteert in een veiligheidsprobleem. Servers dienen up-to-date gehouden te worden (men dient te patchen). Wat moet men doen als er morgen een nieuwe update uitkomt van een OS (operating system) waar de app op draait? … etc. ROI is zo goed als niet te bepalen. 4.1 Wat is TCO? In 1986 werd een eerste aanzet gegeven door Gartner rond een algemeen model om de kost van IT overzichtelijk in kaart te brengen. Gartner publiceerde dit model in hun “life cycle cost of PC’s”-studie en legden hiermee de basis voor de TCO-analyse. In 2005 formuleerde Miertitz en Kirwin de volgende definitie voor TCO: “Total Cost of Ownership is the holistic view of cost across enterprise boundaries over time” 1 Deze definitie is een interessante manier om de problematiek te omschrijven. Wanneer de definitie opgesplitst wordt in verschillende kernwoorden komt men tot inzicht in het probleem. Miertitz en Kirwin gingen als volgt te werk : - Total: dit verwijst naar de volledigheid van de analyse. Alle kosten worden in rekening genomen. Tevens probeert men te voorkomen dat bepaalde kosten dubbel geteld worden. Om dit te garanderen wordt gebruik gemaakt van het polijsten van de verschillende kosten. Hiervoor bestaan verschillende raamwerken waar we later op in zullen gaan. - Cost: dit verwijst naar alle uitgaven die gedaan worden tijdens de levensduur van de ITinfrastructuur. Deze kosten kunnen opgedeeld worden in directe en indirecte kosten. - Ownership: deze term refereert naar alle eigendomskosten die gepaard gaan met de volledige IT-infrastructuur. Het gaat hier zowel over de materiële onderdelen van ITinfrastructuur als de niet materiële onderdelen zoals personeelskost, opleidingen … etc. - Holistic view: refereert naar de hele onderneming. IT-kosten kunnen ook aanwezig zijn buiten de grenzen van een IT-dienst. Zo kan bijvoorbeeld een informatiesysteem informatie krijgen door een bediende die werkt op een andere afdeling. Alle kosten in de hele onderneming dienen in rekening worden gebracht - Across enterprise boundaries: refereert naar het feit dat IT-kosten op verschillende manieren beïnvloed worden. Wanneer IT gebruikt wordt en een belangrijk onderdeel van de bedrijfsvoering wordt, dan neemt de kost toe door allerhande factoren die gepaard gaan met gebruik en beïnvloed worden door externe factoren (bijvoorbeeld een systeem update die resulteert in een fout in de gebruikte technologie …) - Over time: dit refereert naar de volledige levenscyclus van de technologie/oplossing die gebruikt wordt. Het gaat hier dus om alle kosten, zowel de front-end als back-end kosten die gemaakt worden. Dankzij deze definitie kan duidelijk gesteld worden dat TCO dus een veel vollediger beeld geeft van de effectieve kost die gepaard gaat met IT-infrastructuur. Figuur 4-1: Verschillende kosten die gebruikt kunnen worden bij een TCO 2 4.2 Enkele Modellen om TCO te berekenen Om TCO te berekenen wordt gebruik gemaakt van een TCO-model. In de literatuur worden veel modellen gedefinieerd. Hier worden de 3 belangrijkste toegelicht. 4.2.1 Het Direct/indirect TCO model van Piedad Het model, opgemaakt door Garten in 1986, en later verfijnd door Piedad in 2001, splitst de kosten op in 2 belangrijke categorieën, namelijk directe en indirecte kosten. De directe kosten zijn de kosten die verband houden met de aankoop van het systeem. De indirecte kosten zijn die kosten die gemaakt worden om het systeem beschikbaar (online) te houden en de kosten die moeten gemaakt worden om dit te garanderen. Tabel 4-1: Overzicht van de verschillende kostenposten binnen het directe/indirecte tco model van piedad (bron Piedad 2001) Directe Kosten Kost Onderzoekskosten Ontwerpkosten Onderhandelingskosten Aankoopkosten Leveringskosten Installatiekosten Ontwikkelingskosten Opleidingskosten Implementatiekosten Indirect kosten Kost Operationeel Management kosten Systeembeheerskosten Omschrijving kost Kosten die gemaakt worden met betrekking tot het onderzoek naar de technologie die misschien zal worden aangekocht. Kosten die gemaakt worden bij het ontwerp van het systeem en de componenten die nodig zijn voor dergelijk systeem. Kosten die gepaard gaan met het onderhandelen over en het zoeken naar de best mogelijke prijs voor een bepaald systee of een bepaalde technologie Aankoopkosten van het systeem of de technologie. Het gaat hier dus over de prijs de betaald wordt aan de leverancier met de mogelijke taksen inbegrepen. Transportkosten of verzendingskosten om de technologie of het systeem tot de plaats van bestelling te krijgen. Kosten die gepaard gaan met het installeren van het systeem of technologie Deze kosten kunnen zowel kosten zijn voor de eigen ontwikkeling van een applicatie als het ontwikkelen of aanpassen van aangekochte technologie De kost die gepaard gaat met het opleiden van werknemers om met de nieuwe technologie te kunnen werken. Kosten die gepaard gaan met het overschakelen op een nieuwe technologie of het implementeren van het nieuwe systeem op eigen technologie. Omschrijving kost Kosten die gemaakt worden om de dagelijkse activiteiten te managen zoals jobcontrole, het maken en bewaren van back-up … etc. Kosten die gemaakt worden om het systeem beschikbaar te houden zoals kosten voor het oplossen van problemen, kosten die gemaakt worden met het oog op performantie management … etc. 3 Onderhoudskosten Licentiekosten Upgrade kosten Ondersteuningskosten Milieukosten Andere kosten 4.2.2 Kosten die gemaakt worden om de hardware en software te onderhouden. Dit gaat zowel over probleem-oplossingen als preventieve kosten. Kosten die gemaakt worden voor het behouden van alle nodige licentie (en eventueel bijkomende licenties) Kosten die gedaan worden om de technologie doorheen te tijd up-to-date te houden. Kosten die gemaakt worden om het systeem of technologie te ondersteunen zoals bijvoorbeeld helpdesk kosten, permanentie, extra opleidingen … etc. Kosten die geassocieerd worden met de externe factoren die nodig zijn het systeem perfect operationeel te houden. Bijvoorbeeld airconditioning (of andere koeling), elektriciteitskosten … etc. Alle kosten die in bovenstaande kostenposten niet werden opgenomen, maar wel geassocieerd kunnen worden met het systeem of de technologie. Acquisitie/administratie TCO model van David, Schuff en St. Louis. Het tweede model dat een overzicht tracht weer te geven rond TCO is het model ontwikkeld door David, Schuff en St Louis (2002). In hun onderzoek wordt een raamwerk opgemaakt dat de kosten opsplitst op basis van acquisitiekosten en administratiekosten. Binnen de administratiekosten wordt vervolgens een opsplitsing gemaakt tussen ‘controle’kosten en operationele kosten. Acquisitiekosten Onder de acquisitiekosten worden de aankoopkosten voor hardware en software gerekend. Het gaat dus om kosten die voor elk systeem / technologie zeker aanwezig zullen zijn. Administratiekosten worden in onderverdeeld in: ‘Controle’kosten De controlekosten die deel uitmaken van de administratieve kosten zijn niet in iedere onderneming aanwezig. Het gaat hier om de kosten die gemaakt worden om de operationele kosten te drukken of de service levels die de onderneming kan aanbieden te verhogen. Deze controlekosten kunnen onderverdeeld worden in de kosten die gemaakt worden om standaardisatie te bekomen of kosten die gemaakt worden om systemen te centraliseren. ‘Centralisatie’kosten worden aanzien als alle kosten die gepaard gaan met het implementeren van een gecentraliseerd systeem (zoals het gebruik van een centrale databank). Daarnaast worden ook alle kosten bedoeld die nodig zijn om dergelijke centralisatie te ondersteunen zoals bijvoorbeeld trainingskosten ten gevolge van de overschakeling, … etc. ‘Standaard’kosten daarentegen zijn de kosten die gemaakt worden bij het overgaan op vooropgestelde standaarden. Deze kosten kunnen gemaakt worden wanneer er overgeschakeld moet worden op andere hardware of software en de bijhorende standaarden. Maar bijvoorbeeld ook de kosten die gepaard gaan met het opleiden van 4 gebruikers om met (nieuwe) standaarden binnen hardware of software om te gaan. Dergelijke controlekosten zijn moeilijk in kaart te brengen, deels door de complexiteit die gepaard gaat met dergelijke controlesystemen. Operationele kosten De laatste categorie kosten in dit model worden omschreven als operationele kosten. Deze kosten zijn inherent aan het gebruik van een technologie of systeem. Voorbeelden van deze kosten zijn onder andere de installatiekosten, opleidingskosten voor medewerkers die het systeem moeten gebruiken, energie kosten, ondersteuningskosten, onderhoudskosten … etc. Tabel 4-2: Overzicht van de verschillende kostenposten binnen het acquisitie/administratie TCO-model van David, Schuff en st Louis (bron David, Schuff en st Louis 2002) Acquisitiekosten - 4.2.3 Hardware Software Administratiekosten Controle kosten Operationele kosten - Implementatie en - Support onderhoudskosten van - Evaluatie centralisatie - Installatie en upgrades - Implementatie en - Opleidingen onderhoud van de - Downtime standaarden - Bedenken van workarounds of andere oplossingen (voor nieuwe operationele problemen) - Auditing / monitoring - Beveiliging - Energieverbruik. Kapitaal/Niet-kapitaal TCO model van Gartner Het laatste TCO-model dat hier besproken wordt, is het capital cost / non-capital cost model van Gartner. Binnen dit model wordt een opsplitsing gemaakt tussen de kapitaalkosten (CapEx) en de nietkapitaalkosten (OpEx). Kapitaalkosten kunnen worden omschreven als de totale uitgaven voor IT gedurende een fiscaal jaar. Hier worden ook de investeringen en ontwikkelingskosten meegerekend. Dat kan zowel gaan om applicaties als IT-infrastructuur. Men rekent in fiscale jaren. Dus wanneer de aankoop van bijvoorbeeld hardware fiscaal wordt afgeschreven op 4 jaar, dan wordt ¼ van de kost in rekening gebracht. Niet-kapitaalkosten worden gedefinieerd als “de dagelijkse werking- en onderhoudskosten gedurende een fiscaal jaar die niet zijn gekapitaliseerd, met uitzondering van de afschrijving en waardeverminderingen” (Gartner 2018). 5 Hier gelden dus duidelijk fiscale en boekhoudkundige regels. TCO benaderen via het OpEx en CapEx systeem heeft dus fiscale gevolgen. In tegenstelling tot de andere modellen wordt hier dus niet noodzakelijk rekening gehouden met de echte levensduur van de IT-infrastructuur. Kapitaalkosten worden veelal opgesplitst in drie verschillende deelgebieden : - Hardware: Dit zijn alle kosten voor de aankoop, implementatie en installatie van de nodige hardware Software: Dit zijn alle kosten die gepaard gaan met de aankoop, implementatie en installatie van software en licenties. Locatie: Dit zijn alle kosten die gepaard gaan met de locatie waar de hardware wordt geplaatst. Bijvoorbeeld het onderhoud van de ruimtes, huur ruimte, koeling … etc. Ook de niet-kapitaalkosten kunnen verder worden opgesplitst in deelgebieden. Het gaat hier veelal om personeelskosten die nodig zijn om de IT-infrastructuur te kunnen garanderen en te laten aansluiten bij de beleidskeuzes van een bedrijf. - - Technische ondersteuning: Dit zijn alle kosten die de dagelijkse activiteiten omvatten. Hier wordt ook rekening gehouden met kosten die vervat zitten om bepaalde beleidsmatige IT-concepten te garanderen. bijvoorbeeld services zoals permanentie, disaster recovery … etc. Database administratie: Dit zijn alle kosten die nodig zijn om administratief databanken te ondersteunen. Planning en procesmanagement: Dit zijn alle kosten die gemaakt worden om projectplanning en procesplanning te doen. Administratie: Dit zijn alle administratieve kosten die worden gemaakt. Contracten, account-management, financiële adminstratie … etc. Volgens dit model wordt TCO van technologie of een systeem bekomen door de som te maken tussen alle kapitaalkosten en niet-kapitaalkosten. . 4.3 Wat betekent TCO in cloud computing TCO bij cloud computing is eigenlijk de totale kost voor de adaptie, operationalisering en beschikbaar maken van cloudinfrastructuur. Wanneer een organisatie denkt om te migreren naar een cloudoplossing kan men dus best ook een cloud-TCO proberen opstellen. Dit is de enige manier om de kost van de huidige TCO te vergelijken met de kost van een cloudoplossing. Aangezien TCO typisch gebruikt wordt om de kostprijs van de volledige levenscyclus van de gebruikte IT-infrastructuur te berekenen, is een cloud-TCO een hele uitdaging. De meeste cloud service providersgebruiken een dynamische manier om hun diensten te prijzen. Daarnaast zijn 6 er ook verschillende manieren om hun diensten af te nemen en die hebben telkens een impact op de prijs van de dienst. Wanneer bedrijven een cloud-TCO berekenen wordt meestal een vergelijking gedaan van onpremise apparatuur met cloud-apparatuur. Zo wordt de aankoopprijs van servers vergeleken met de maandelijkse huurkost van een vergelijkbare server via cloud. Dit is natuurlijk een goede manier om te starten, maar misschien geeft dit geen volledig beeld. Er zijn immers ook een boel verborgen kosten die mee in rekening dienen genomen te worden. Denk maar aan onderhoud, patching, beveiliging, backups … etc. Maar ook minder zichtbare kosten zoals bijvoorbeeld beschikbaarheid (of niet-beschikbaarheid) dient in rekening gebracht te worden. 4.3.1 Cloud pricing Niet elke CSP maakt gebruik van eenzelfde manier om de prijs te bepalen van de cloud service maar de meeste maken gebruik van dezelfde principes. Om een inzicht te krijgen in hoe de grote CSP’s hun prijzen bepalen, kan gebruik gemaakt worden van de manier waarop Amazon Web Services (AWS) zijn prijzen bepaalt. Wat vooral opvalt bij de prijzen van AWS is dat deze in de voorbije jaren sterk gedaald is maar hun filosofie voor de prijzen is niet gewijzigd. De manier waarop AWS zijn prijzen bepaalt bestaat uit volgende stappen: Pay as you go Er zijn geen minimumvereisten of langetermijncontracten waar bedrijven aan gebonden zijn. Er wordt gebruik gemaakt van een elastische prijsstrategie. § Voor rekencapaciteit wordt per uur betaald. § Voor datatransfer en -opslag wordt betaald per gigabyte. § Er wordt betaald voor de gebruikte infrastructuur en diensten. § Je kan bepaalde diensten stoppen (en dus niet meer betalen) wanneer je deze niet meer nodig hebt. Pay less when you reserve Voor bepaalde diensten kan je capaciteit reserveren. In dit geval betaal je een bepaalde lage prijs en krijg je reductie per gebruikte dienst. De kunst bestaat er dus uit om de capaciteit die nodig is te reserveren. Als je een overcapaciteit reserveert kan dit duurder uitvallen. Indien je dit echter op een goede manier doet, kan je aanzienlijke kosten besparen. Pay even less per unit when using more Je spaart uit naarmate je groter wordt. Voor opslag en datatransfer is de regel simpel: hoe meer je gebruikt hoe goedkoper het is per gigabyte. 7 Voor rekenkracht kan dit oplopen tot 20% korting. Pay even less as AWS grows AWS probeert constant zijn eigen kosten te drukken door hun datacentrum beter in te richten en beter te gebruiken. Deze efficiëntiewinst wordt doorgerekend aan de klanten. Dit is ook nodig omdat nieuwe CSP’s hun datacentra ook zo efficiënt mogelijk zullen maken en zodoende geen prijsdifferentiatie mogelijk te maken. Custom pricing Stel dat een project een ander pricing model nodig heeft. Voor grote projecten laat AWS toe om een eigen pricing uit te werken (alleen voor grote projecten met aanzienlijke volumes aan data of services). Op zich lijkt dit niet zo belangrijk, maar het geeft grote projecten de mogelijkheid om hun TCO te optimaliseren. De meeste CSP’s voorzien 3 prijs opties voor hun diensten. Je zou dit eigenlijk kunnen aanzien als de koppeling van de afgenomen diensten ten opzichte van de prijs die hiervoor betaald wordt. Er zijn dus 3 opties over de manier waarop de dienst aangeboden wordt en elke optie heeft zijn eigen prijskaartje. § The on-demand instance pricing option: Capaciteit wordt onmiddellijk aan- en afgezet. Er wordt alleen gekeken naar wat er verbruikt wordt op het moment zelf aan op voorhand afgesproken prijzen. Dit model is het duidelijkst in het berekenen van de kosten, maar eigenlijk niet vergelijkbaar met een IT-infrastructuur in eigen beheer. § The Reserved Instance (RI) pricing option: Dit model laat toe dat je capaciteit reserveert volgens wat je denkt nodig te hebben. Hoewel je hier eventueel een overcapaciteit voorziet, krijg je wel een betere prijs per gebruikte unit. Zoals hierboven aangeduid is deze optie goedkopen dan de on-demand instance pricing. Maar als je te veel reserveert kan het duurder uitkomen. Dit model is het best vergelijkbaar met het eigen beheer van een IT-infrastructuur. Want als je on premis IT-infrastructuur gebruikt, dien je ook te zorgen dat je geplande capaciteit voldoende is om de nodige applicaties te ondersteunen. § The Spot Instance pricing option: Dit model laat je toe om te bieden op ongebruikte capaciteit van de cloud provider. De prijzen zijn dus fluctuerend volgens de beschikbare capaciteit. Een dergelijk model is interessant voor bepaalde toepassingen, maar houdt ook enige risico’s in. Ook dit model is eigenlijk niet vergelijkbaar met een IT-infrastructuur in eigen beheer. Wanneer bedrijven migreren naar de cloud, dan gaan ze er bijna altijd van uit dat hun TCO goedkoper zal uitvallen. Maar door simpelweg te kijken naar de verschillende manieren om de 8 prijs te bepalen begrijpt men al snel dat een cloud TCO een veel complexer gegeven is, vooral als je rekening houdt met het lange termijn gebruik van cloud. Zoals in het vorige hoofdstuk aangeduid is één van de eigenschappen van cloud elasticiteit. Wanneer een bedrijf meer infrastructuur nodig heeft, kan deze simpelweg voorzien worden. De bijkomende capaciteit aan en af zetten verhoogd beschikbaarheid, maar kan een impact hebben op de uiteindelijke factuur. Omdat deze (pieken) zullen verrekend worden als on-demand instant pricing (of soms zelf nog hoger, afhankelijk van de SLA) 4.3.2 Schatting van de cloud TCO Bij het opstellen van een TCO voor cloud dien je eigenlijk rekening te houden met enkele belangrijke vuistregels. Er zijn een heleboel kosten die gepaard gaan met on-premesis infrastrutuur die wegvallen zoals onderhoud, vervangen van toestellen, up to date houden … etc. Veel van die kosten zal gedaan worden door de CSP. In de eerste fase (het overschakelen van on premises naar cloud) dient men vooral rekening te houden met 3 belangrijke kosten: de migratiekost om naar een cloudomgeving te migreren, de periodieke (veelal maandelijkse) kost voor de cloud services, en consultatie- en trainingskosten. 4.3.2.1 Migratiekosten Het verplaatsen van applicaties en data naar de cloud is een belangrijk onderdeel bij overgang van on-premise naar cloud. Het kan zijn dat bestaande applicaties dienen aangepast te worden zodat ze kunnen werken in een cloudomgeving. Het zou ook kunnen zijn dat door gebruik te maken van een CSP op zoek moet gegaan worden naar nieuwere versies of andere licenties voor bestaande applicaties. Gartner spreekt van 5 manieren om applicaties naar de cloud te verhuizen. 1. Het opnieuw hosten van applicaties zonder aanpassingen in de architectuur van de applicatie. 2. Het herstructureren van de architectuur van een applicatie zodat deze kan werken op een cloudplatform. 3. Herwerken van de applicatie (de broncode aanpassen). 4. Vernieuwen van zowel de code als de architectuur van de applicatie. 5. De applicatie vervangen door een commerciële applicatie die gebruikt wordt als SaaS. Elk van deze migratiemethoden heeft een eigen kostenplatje en een eigen nood aan vereiste (IT)-kennis. Wanneer die kennis niet aanwezig is, zal dit ook opnieuw voor kosten zorgen. Naast het migreren van de applicaties, dient ook nagedacht te worden over het migreren van de data. Ook dat zal een kost genereren. 4.3.2.2 Maandelijkse kost De maandelijkse kostprijs voor het gebruik van cloud zal afhangen van de workload en het soort cloud iensten die gebruikt worden. De kunst bestaat er dus uit om de potentiële maandelijks kost in te schatten gebaseerd op de workload van de on-premise-infrastructuur. 9 De meeste SCP’s voorzien online tools die het toelaten om de maandelijkse cloudkost te berekenen. De kost wordt beïnvloed door 2 belangrijke factoren: Het type van de gebruikte cloud services: Standaard services zoals opslag en compute zullen relatief minder duur zijn dan geavanceerde of gespecialiseerde services zoals bijvoorbeeld machine learning. Het cloud consumptiemodel: zoals hierboven aangeduid is bijvoorbeeld on-demand pricing duurder dan reserved instances. Soms kan het echter goedkoper uitvallen, afhankelijk van de frequentie waarop de resources gebruikt worden. De afweging dient op een doordachte manier te gebeuren. 4.3.2.3 Consultatie en trainingskosten. Wanneer bedrijven niet over de nodige kennis beschikken zal gebruik moeten gemaakt worden van consultants om de migratie in goede banen te leiden. Ook het gebruik van de nieuwe infrastrutuur kan aanleiding zijn om trainingskosten te voorzien. 4.3.3 De niet-tastbare voordelen van cloud Het kiezen voor cloudoplossingen kan leiden tot nieuwe opportuniteiten. En hoewel sommige van die opportuniteiten inderdaad zullen gepaard gaan met een kost, dient ook in rekening gebracht te worden wat de potentiële kosten zijn indien dergelijke opportuniteiten zich niet voordoen. Innovatie CSP’s voorzien honderden services die makkelijk gebruikt kunnen worden. Om te kijken of bepaalde services interessant kunnen zijn voor het bedrijf kunnen die zo goed als onmiddellijk aan en af gezet worden. Stel bijvoorbeeld dat een bedrijf zijn data wil analyseren, dan zullen de meeste CSP’s tools beschikbaar hebben om analyses te doen of data te herstructureren. Bij een on-premiseinfrastructuur zijn dergelijke projecten veel complexer en lenen die zich minder tot een experiment. De mogelijkheid tot innoveren is aanzienlijk veel makkelijker door gebruik te maken van de aangeboden services door de CSP. Elasticiteit Het plannen van de vereiste capaciteit voor IT-infrastructuur is een heel complex gegeven. Alleen bij een goede planning kan beschikbaarheid gegarandeerd worden bij een on-premise oplossing. Vooral het opvangen van een piek in gebruik kan een enorme kost teweeg brengen bij een on-premise oplossing. Er dient immers genoeg capaciteit voorzien te zijn om de piek op te vangen (veelal met dezelfde waarborgen rond beschikbaarheid). CSP’s kunnen die piek perfect opvangen met een aanvaardbare meerkost. Als de piek voorbij is kunnen de extra middelen gewoon weer vrijgegeven worden. 10 Soms kan zo’n piek voorspelbaar zijn (bijvoorbeeld alle studenten die in dezelfde periode hun punten consulteren in Oasis zorgt voor een piek), maar soms zijn dergelijke pieks niet voorspelbaar. Bijvoorbeeld een DDoS-aanval op een webserver. De meeste CSP zullen ervoor zorgen dat zo een DDoS-aanval niet gemakkelijk resulteert in het niet beschikbaar zijn van cloud infrastructuur. Een dergelijke vorm van elasticiteit is moeilijk te garanderen in een onpremise oplossing, of kan heel hoog oplopen in kost om dit wel te doen. 4.3.4 Vergelijken van een on-premise-TCO met een cloud-TCO Bij het vergelijken van de on-premise-TCO en cloud-TCO, zijn er enkele dingen die men in het achterhoofd moet houden. § § § § Cloud computing is niet gegarandeerd goedkoper dan een on-premise infrastructuur. Cloudadoptie is niet alleen een kwestie van kostenbesparing. De voordelen van cloud zijn zelden alleen te herleiden naar een lagere TCO (als die al lager is). Het juist inschatten van de nieuwe opportuniteiten die gepaard gaan met cloudoplossingen dienen goed afgewogen te worden Bij cloudoplossingen dient men ook na te denken hoe een kostefficiëntie voor cloud oplossingen kan bereikt worden. De oplossing kan gevonden worden in het juist monitoren van de cloudkosten om zodoende de initiële kostprijs te proberen drukken. 4.4 Clouddiensten monitoren Om de kost van de clouddientsen in de gaten te houden, hebben de meeste CSP’s allerhande monitoring tools beschikbaar. Het gaat hier veelal over dashboards die real-time het verbruik van de diensten weergeeft en gefundeerde prognoses kan doen voor toekomstig gebruik en toekomstige betalingen. Monitoring kan bedrijven ook in staat stellen om de kosten van cloud te optimaliseren. Stel dat een bedrijf 1TB reserved instance opslag heeft, maar slechts 20% daarvan gebruikt. Dan valt het te overwegen om na te denken of minder verbruik een aanzienlijk kleinere kost kan opleveren (wat hier vermoedelijk niet het geval zal zijn) Het monitoren van clouddiensten kan ook interessant zijn vanuit een ander standpunt. De manier waarop clouddiensten werken kan soms resulteren in een snel toenemende kost. Stel bijvoorbeeld dat gebruik gemaakt wordt van een service voor data-analyse en dat deze service gebruik maakt van een bepaald type API. Sommige API’s worden gefactureerd per keer dat ze gebruikt worden. Een simpele vorm van data-exploratie kan resulteren in 1000-den oproepen van die ene API. Wat op het eerste zicht een opportuniteit is om op een goedkope manier aan inovatie te doen kan snel oplopen tot een hogere kost dan voorzien of dan eigen ontwikkeling. Door het verbruik en de facturering te monitoren kunnen onaangename verassingen worden voorkomen. 11 Eigenlijk zou de cloudkost best een metriek zijn die gebruikt wordt bij projectplanning. Projectmanagers zouden mee moeten begrijpen dat bepaalde ontwikkelingen nefast kunnen zijn voor de TCO omdat het bedrijf gekozen heeft voor cloud. 12 4.5 Referenties Capital expenditure (capex), BusinessDictionary. Geraadpleegd op 22 augustus 2018 via http://www.businessdictionary.com/definition/capital-expenditure-CAPEX.html Christensen, D.K. (2016). Total Cost of Ownership. Facilities Manager, 32(4). Christensen, D. K., Rose, R., Ruprecht, T. W. (2006). Buildings…The Gifts That Keep on Taking. APPA. David, J., Schuff, D., & St Louis, R. (2002). Managing your IT total cost of ownership. Communications of the ACM, 45(1), 101-106 Dawson, K. (2013). The Total Cost of Ownership of Cloud and premise-based contact center systems. London: Ovum. Fujitsu & Intel. (2007). Reducing Total Cost of Ownership (TCO) Through Server Consolidation. Intel Corporation. Gartner (2018). IT Budget: Data Input Requirements, explain text and definitions. Stanford, CT: Gartner Inc. Gomolski, B., Grigg J., & Potter, K. (2001). 2001 IT Spending and staffinf survey results. Stanford, CT: Gartner Group Intacct. (2011). Moving to the cloud: Understanding the total cost of ownership. San Jose, CA: Intact Corporation Jies Varia (2012) The Total Cost of (non) Ownership of web applications in the cloud. Amazon web services (AWS) Mieritz, L., & Kirwin, B. (2005). Defining Dartner Total Cost of Ownership. Gartner. Piedad, F. (2001). Total Cost of Ownership: Priciples and Practical Applications. Pearson Education, Informit. Geraadpleegd op 22/8/2018 via http://www.informit.com/articles/printerfriendly/24404 Roda, I., & Garetti, M. (2016). Application of a performance-driven Total Cost of Ownership (TCO) Evaluation Model for Physical Asset Management. Lecture Notes inMechanical Egineering, 11-23 Wray, J. (2014). Where›s e Rub: Cloud Computing›s Hidden Costs. Geraadpleegd via https://www.forbes.com/sites/centurylink/2014/02/27/wheres-the-rub-cloud-computings-hiddencosts/#43a4b465f00e 13