Tradurre in pratica un progetto Cloud, pubblico, privato o ibrido, presuppone una valutazione attenta delle proprie necessità attuali e future e prendere in considerazione diversi fattori. Qualche consiglio. Anche di Cio che hanno affrontato questa esperienza
di Aldo Ceccarelli
Mentre l’economia globale si districa “languendo” attraverso i suoi prolungati malesseri, le organizzazioni IT affrontano ancora una volta la pressione a “fare di più con meno”.
Questa, come i Cio ben sanno, non è per nulla una novità ed è stato anzi argomento ricorrente a più riprese nell’ultimo decennio.
Le sfide dei mercati hanno implicato budget IT appiattiti o soltanto in modesta crescita a indurre situazioni dove nuove iniziative possono partire soltanto a seguito di storni o risparmi in altre aree di business. In compenso ai Cio si offrono diversi sistemi per supportare le organizzazioni a diventare più efficienti, liberando budget e risorse per progetti IT critici e a maggior valore aggiunto.
Fra questi, balzano per primi alla mente i seguenti:
– miglioramenti all’utilizzazione delle risorse attraverso il processo continuo di consolidamento e virtualizzazione;
– automazione e self-service in aree quali provisioning e identity management;
– iniziative che riducono costi energetici, di raffreddamento e di gestione delle physical facility.
Ci sono poi tre requisiti che, secondo i Cio, continuano a trainare le organizzazioni IT: le sempre crescenti richieste di capacità elaborativa, di application performance e di volumi dati. Le leggi di Moore, Kryder e Buttler che regolano le curve di crescita per capacity di utilizzo processori, storage e rete nel tempo si sono rivelate affidabili. Anche quest’anno i Cio vedono priorità nella sfera dello scalamento architetturale per gestire la grande mole dei Big Data, esplosione derivante dai flussi mobile, commerce, unstructured. Un approccio scale-out induce a sua volta richieste di sistema operativo e le aziende continuano a lavorare per aumentare la gestibilità, la security e la performance delle proprie piattaforme di sistemi operativi nello sforzo necessario a soddisfare le esigenze dei clienti.
Le “hype” suggeriscono un generale trend di implementazione per ambienti operativi che siano virtualizzati al massimo livello o implementati su infrastruttura Cloud. I report globali di Gartner, così come gli studi da aree geografiche come i più recenti di InformationWeek per il Nord America per arrivare agli ultimi survey e special study italiani pubblicati dall’Osservatorio Cloud & ICT as a Service della School of Management del Politecnico di Milano, da IDC, Enter The Cloud ed Easynet – per citare i principali – ci dicono che nella pratica la realtà è differente. Per il 2012 ancora le aziende continueranno tendenzialmente a introdurre sì nuovi pattern di infrastruttura, ma affiancandoli in modo graduale e incrementale in modo da salvaguardare e mantenere anche gli investimenti precedenti ove utile. Ne risulta un panorama diffuso di ambienti ibridi con workloads tradizionali su server fisici al fianco di resource pools virtualizzati e infrastrutture private Cloud.
Anche le aziende che pianificano di utilizzare servizi public Cloud lo fanno a estendere i pattern della loro infrastruttura esistente in modelli operativi ibridi.
Questi nuovi modelli costituiscono la base dei nuovi requisiti di implementazione per lo sviluppo, il deployment e la gestione degli ambienti hybrid.
In molti ambiti il 2012 pare anche essere l’anno di “rottura delle catene” del vendor lock-in, sentito dal consumer come fattore limitante del controllo del proprio destino. Adesso, mediante l’adozione di nuovi approcci basati su software open source, scale-out architecture, virtualizzazione, SOA e – come di nostro interesse – tecnologie Cloud, i Cio possono realmente trovare strategie di implementazione infrastrutturale davvero open e modulari se fatte con adeguata roadmap.
Nel frattempo anche lo stesso landscape applicativo sta evolvendo a sua volta, per cui i modelli applicativi si stanno muovendo verso architetture snelle e “a componente”, le quali hanno sempre più bisogno di linguaggi e framework di programmazione multi-piattaforma e Web-oriented. Questo comporta nuove esigenze di tool, servizi e componenti adatti allo sviluppo per mobile, Cloud ed enterprise alla luce dell’apertura verso nuovi paradigmi di delivery e utilizzo. Di qui la stimata crescita di migrazioni PaaS ad abilitare un aumento di agility delle realtà progettuali e operative inerenti.
In sostanza le opinioni raccolte dai Cio in merito alle esperienze progettuali Cloud computing delineano il momento attuale come “evolutivo più ancora che rivoluzionario”. Questo traspare da molteplici indicazioni che si colgono da una padronanza sempre migliore e più approfondita dei concetti di base che in cascata favorisce un cambio di marcia necessario per passare dalla teoria alla pratica.
Anche grazie al fiorire di eventi tematici e pubblicazioni di approfondimento, si coglie fra i Cio un aumento di consapevolezza e di training a vari livelli: una motivazione plausibile risiede nella ricerca per nulla banale e nella sentita necessità di riconoscere al meglio quali dei diversi approcci si adattino in modo migliore alle rispettive realtà e di come i diversi modelli Cloud (per esempio nell’accezione ormai standard della definizione Nist) si rapportino e si possano intersecare fra loro e combinare insieme.
DOVE STIAMO ANDANDO?
Gartner negli ultimi anni ha analizzato costantemente e con grande attenzione il Cloud computing e ne ha messo per prima cosa in luce la natura di “scalable style of computing“ fornito come servizio ai clienti utilizzatori di tecnologie Internet. L’enfasi maggiore è data all’idea di capacità scalabili ed elastiche. Ecco che abbiamo a disposizione il reostato che serve all’economia e al business: scalabile all’insù o all’ingiù in modo rapidissimo.
Secondo aspetto chiave è quello della “delivery as-a-Service”: questo crea un modello fra un consumatore e un provider di servizi Cloud. Molto importante: un consumatore di servizi Cloud guarda esclusivamente al servizio ricevuto, sia esso un compute service, un application service o di altro tipo; il consumatore usa il servizio. Tutti i dettagli dell’implementazione che sta dietro al servizio (l’hardware, l’automazione, i processi Idle che ci sono, dove siano i data center ecc.) sono nascosti al consumatore, che vede solo un’interfaccia del servizio. Così – ed è fondamentale – il provider può concentrarsi a guidare l’efficienza, mentre il consumatore si limita a consumare il servizio e a costruire on top of it le cose che gli servono. Molte realtà consumatrici esperiscono problemi con progetti Cloud a seguito del fatto che iniziano a preoccuparsi – in modo non sempre corretto – dei dettagli relativi all’implementazione, mentre ci si dovrebbe limitare a controllare le cose attraverso la Cloud service interface come solamente è possibile fare a un consumatore.
Dei tre modelli di servizi Cloud definiti (IaaS, PaaS e SaaS), se guardiamo l’Infrastructure-as-a-Service allora stiamo entrando appieno nel dominio Cloud environment. Quando ci spostiamo al Platform-as-a-Service allora con la gestione database e runtime tools stiamo astraendo anche più della stessa applicazione. Il provider fa sempre di più, aggiunge valore e il consumatore si occupa di un numero sempre minore di problematiche. Si può salire ancora di astrazione andando all’Information-as-a-Service dove a essere Delivered-as-a-Service è un feed di informazione (per esempio informazione borsistica, di cataloghi, di traffico website ecc.) e qui si raggiunge l’intersezione con la sfera dei business service. Migrare al Cloud significa ricevere con modelli di consegna as-a-Service, allora perché risulta davvero così importante identificare bene per ciascuna tipologia a quale livello di astrazione convenga porsi? Perché quando iniziamo a concentrarci su questi modelli di technology driven things as-a-Service iniziamo a capire come poter assemblare e miscelare tutte queste cose insieme. Ecco che abbiamo la strada aperta a creare i nostri composite business model del futuro – così si crea l’intero environment complessivo (a fronte del time frame a ciò necessario).
Un concetto importante su cui spesso Gartner ha posto l’accento è l’idea del Cloud Service Brokerage (Csb). L’idea del brokerage – o di un intermediario – nel mondo dell’IT non è nuova, ma nel mondo del Cloud computing, dove ci sono ogni sorta di servizi, cresce in modo significativo l’esigenza di un intermediario di una terza parte fra provider e consumer. Ecco che con il brokerage parliamo di un modello di business dove un’entità aggiunge valore a uno o più servizi per uno o più clienti. Il focus è sulle broker categories che stanno in mezzo. Una è l’aggregazione: vediamo l’evoluzione dei vendor che forniranno servizi di raggruppamento di singoli servizi al consumatore; altri vendor rivenderanno i servizi originali, ma secondo criteri differenti da quelli in origine e orientati alle esigenze di performance o di pricing del consumatore. Un altro è il contesto: vediamo i context broker ossia provider che forniscono contestualizzazione alla consegna dei servizi originali e veicolano la performance speciale su particolari utenti finali e business (talvolta anche con stazioni custom ed estensioni ad-hoc personalizzate oltre al servizio originale). Fornitori di terza parte in pratica specializzano con verticalizziazioni o estendono l’ambiente. Si pensi per esempio a security enhancements o governance mechanisms. Infine: integrazione, pooling di servizi insieme, ma anche assicurazione. Si vedono provider assumersi il rischio di business per l’accesso da provider multipli. Queste coperture operano a mezzo di contratti e meccanismi predisposti a garantire il flusso di dati in andata e in ritorno attraverso provider multipli in modo da raggiungere un livello di servizio migliore di quello ottenibile dai singoli provider separatamente. Il broker si assume rischi elevati per fornire higher business level assurance. Quello dei broker è un mercato relativamente nuovo dove nascono sistemi anche complessi per fornire per esempio meccanismi di governance. Tutti osservano come forniscono i servizi in un ambiente Cloud e analizzano i modi per incentivare l’aumento del consumo. È un mercato in crescita rapida perché con il crescere dei business che si affacciano o migrano sul Cloud aumenta in modo significativo anche il fabbisogno di value added service brokers.
Gartner ha identificato i cinque top trend che accelereranno o rallenteranno la crescita del Cloud nei prossimi tre anni, li ricordiamo:
1 – framework decisionali formalizzati ottimizzano gli investimenti (problematiche creano un ambiente complesso in cui valutare attentamente ogni beneficio);
2 – il Cloud computing ibrido è un imperativo (stabilire delle linee guida che indichino come elementi di Cloud pubblico debbano combinarsi con i sistemi interni per formare un ambiente ibrido);
3 – il ruolo del broker Cloud è centrale (i Cio dovranno capire come diventare soggetti che possono offrire il servizio brokerage all’interno dell’azienda);
4 – la progettazione “Cloud-centrica” diventa una necessità (specie dove i workload necessitano di molte risorse: applicazioni disegnate ad-hoc per il Cloud model guardando al di là della semplice migrazione per sfruttare appieno le opportunità);
5 – il Cloud computing influenza il futuro dei data center (nel private seguire modelli e best practice dei provider).
Gartner in una parola evidenzia che per le aziende è imperativo monitorare con attenzione l’evoluzione del Cloud sia nell’ottica di evitare di investire in servizi IT non adeguati, sia nell’ottica di non perdere opportunità di business.
In Italia dalla ricerca “Cloud computing: caratteristiche e opportunità”, realizzata mediante metodologia “a focus group” da Unioncamere Emilia-Romagna in collaborazione con Aster e Assi, emerge un quadro panoramico mirato in particolare alle diverse categorie di dimensioni aziendali.
Lo studio spiega approfonditamente che «vi sono aspetti economici, organizzativi e cognitivi di cui si deve tenere conto in fase di inserimento del Cloud in azienda e che possono avere implicazioni anche sugli schemi di revenue dei provider».
Allo scopo è bene ricordare subito che anche per il Cloud computing vale il consueto paradosso della piccola impresa in sede di adozione tecnologica. Anche se le piccole imprese sono quelle che potrebbero trarre maggiori benefici da una nuova tecnologia, qualunque essa sia, incluso il Cloud, queste organizzazioni sono anche quelle che hanno i budget più bassi. Inoltre, sono proprio queste le imprese che spesso faticano di più a comprendere la rilevanza della nuova tecnologia e che quindi, per potere capire se porterà in futuro a un risparmio sui costi o a una maggiore efficacia nell’azione manageriale, devono spesso cominciare con un investimento aggiuntivo in intelligence, già di per sé di incerta remunerazione futura.
Non si può quindi trascurare il problema della soglia minima di investimento per entrare nella nuova tecnologia, spesso una barriera invalicabile. Sotto questo profilo, il ruolo degli attori istituzionali e delle policy di sostegno alle piccole imprese appare assolutamente essenziale.
Le barriere di accesso al Cloud delle Pmi possono essere anche di natura semplicemente cognitiva. Prima di tutto, le percezioni circa l’effetto del Cloud sul rapporto costi/benefici possono significativamente variare da impresa a impresa. Quando, per esempio, vi è una elevata avversione al rischio da parte dell’imprenditore, la variabilizzazione del costo dell’IT, che normalmente si associa al Cloud, può addirittura costituire un ostacolo all’adozione più che un incentivo, in assenza di una chiara previsione su entità di utilizzo futuro e tipologie di applicativi. Con logiche apparentemente controintuitive, il piccolo imprenditore a volte preferisce sopportare un costo semi-fisso la cui entità è certa, piuttosto che puntare a un costo variabile probabilmente inferiore, ma non definibile a priori.
Per le grandi imprese i problemi sono generalmente diversi, di natura più tipicamente organizzativa. In questo caso, il problema non riguarda tanto le competenze tecnologiche necessarie per assorbire l’investimento, né le risorse finanziarie. Le resistenze possono provenire, invece, dall’atteggiamento verso il Cloud da parte dell’IT management. I timori reali o percepiti sono molteplici: vedere allentato il controllo sul processo; non potere garantire, rispetto al passato, un’analoga affidabilità e stabilità dei sistemi informativi; non avere un’analoga copertura in termini di tutele contrattuali; vedere ridotta l’allocazione di risorse ai budget di funzione. Non c’è dubbio che in molti casi, un piano di adozione del Cloud da parte di un’azienda medio-grande finisce per divenire anche un piano di ridisegno organizzativo dell’impresa e di riallocazione delle risorse.
Teoria e pratica: che differenza c’è?
Dalle analisi condotte in ogni parte del globo traspare così che il Cloud computing è arrivato per restare: il concetto fondamentale di utilizzare servizi running su ambienti flessibili gestiti dall’azienda o da un service provider è un assunto ormai fondamentale per le esigenze che si determinano nel contesto economico e sociale in cui il business opera. È questa una vera opportunità per il business al fine di rispondere con maggiore rapidità alle richieste variabili dai propri clienti. L’IT ha la scelta fra fornire al business la flessibilità e l’agilità che chiede oppure trasformarsi in un dinosauro che gestisce l’obsoleto e ben presto sarà bypassato nella gestione della maggioranza dei nuovi requisiti.
«Quando il futuro arriva ci sono tre tipi di persone: quelle che lo lasciano arrivare, quelle che fanno in modo che arrivi e quelle che si domandano cosa sia accaduto», (J.M. Richardson Jr).
Anche i Cio sono ora più che mai chiamati a confrontarsi con il proprio approccio nei confronti dell’innovazione e in particolare nel momento di valutare (o a volte anche “subire”) la migrazione al Cloud computing. Il Cloud computing è discusso ovunque e pare essere la risposta a tutto quanto serve: dalla riduzione dei costi alla increased agility.
Qual è davvero la reale situazione e perché i Cio dovrebbero focalizzarsi sul Cloud? Soprattutto su “quale” Cloud?
Nel mondo dell’IT, dove i bisogni sono ancora troppo pilotati dalla spinta dei produttori di tecnologia, quest’ultima innovazione non appare l’ultimo modo attraverso cui dobbiamo rifare le cose che abbiamo già fatto e che ancora funzionano bene. Si tratta piuttosto di un’evoluzione che tende a rendere più efficiente la distribuzione degli applicativi senza limiti di geografia, lingua e tempo. Molte aziende ne avvertono il bisogno.
Le preoccupazioni relative all’esternalizzazione delle attività si devono trasformare in attenzione nel gestire i rischi e nello stimolare tutte le azioni che rendono un mercato veramente competitivo: mercato che oggi ancora non c’è.
Non bisogna sottovalutare le opportunità di nuovo business che questa innovazione porta con sé, così come non bisogna sottovalutare le insidie dei falsi costi variabili, quando trasformiamo un investimento in un costo a vita.
È comunque emerso un dato certo e condiviso: sotto il profilo tecnologico si può stare tranquilli, c’è sia innovazione che solidità nel modello.
Il modo con cui questa innovazione potrà essere utilizzata dipenderà moltissimo dalla nostra capacità di interpretarla e qui si vede il vero passaggio per il Cloud dalla teoria alla pratica.
La tecnologia da sola non fornisce automaticamente innovazione: l’aspetto cruciale è come noi applichiamo la tecnologia nei diversi contesti del business. Ma anche qui, la tecnologia, nella maggioranza dei casi, fornisce dei meri blocchi costruttivi.
In marzo, durante il “Cloud computing Summit 2012”, organizzato da The Innovation Group, gli esperti hanno discusso principalmente dell’impatto economico, organizzativo e di business del Cloud computing sui principali settori industriali.
Fondamentali le riflessioni e i dibattiti per capire come generare valore dal Cloud e come superare le barriere alla diffusione e adozione legate alla tematica “sicurezza”.
Il Cloud è un fattore di cambiamento. Quattro parole chiave dal “Cloud Summit 2012”: innovazione, agilità, concretezza e trasformazione. Non c’è stato molto spazio per le discussioni tecnologiche, anzi, l’impressione è che argomenti di questo tipo siano ormai superati, assodati, quasi ovvi.
Si è parlato molto di velocità dei processi e di time-to-market: servono risorse che consentono di accelerare i processi di produzione e i tempi di sviluppo, che permettono di creare nuovi business il più velocemente possibile. Allo stesso modo occorrono soluzioni e nuovi servizi che nascono e si sviluppano nel Cloud.
È il Cloud computing della ricerca universitaria di IBM che ha consentito ai pescatori baresi di incrementare le entrate del 25% e di evitare la sovrapproduzione riducendo gli sprechi. Quante cose cambieranno quando strutture e concetti simili saranno applicati ad altri settori industriali?
Gianluigi Castelli, executive vice president ICT di Eni e presidente del Cio Aica Forum (associazione affiliata a EuroCio) ha sintetizzato già a partire dalla precedente edizione del Summit l’essenza del Cloud computing e l’esperienza miliare del progetto IT Trasformation come segue: «È un altro tassello nella costruzione della strategia ICT in azienda, non è la strategia ICT».
Questo comprova che l’innovazione non deve essere per forza dirompente, bensì può essere una “sustaining activity”, può creare modi nuovi di fare ciò che già oggi facciamo, di farlo meglio senza dover cambiare radicalmente il modo in cui facciamo le cose. Uno degli aspetti chiave dell’innovazione, specialmente in questa presente congiuntura e unitamente alla velocità con cui il cambiamento avviene nell’Information Technology oggi è il seguente “mantra”: innovare o restare tagliati fuori!
Il Cloud computing – in quest’ottica di innovazione tecnologia – è diventato un argomento prioritario così che figure operanti nei diversi livelli delle aziende hanno interesse a comprendere le diverse modalità con cui il Cloud può far raggiungere mete di innovazione al business. Tutti oggi hanno a vari livelli almeno sentito parlare del Cloud computing e se andiamo alla letteratura informatica “delle origini” troviamo che già se ne trovano tracce in termini di “utility computing” in auge già nell’ormai lontano 1964. Anche se fa effetto pensare che all’epoca già avessimo i computer, pare proprio che fosse così e che per esempio la GE e la IBM ne costruissero. Oggi viviamo in un’epoca interessante perché l’utility computing è divenuto possibile ed è oggi realtà. Negli anni 60 con buona probabilità non si ebbero i presupposti sociali e di business necessari per far sì che l’utility computing decollasse e si affermasse come standard tecnologico. Oggi la tecnologia cambia per abilitare l’economia. Oltre a questo fattore basilare si ha che nel nostro mondo business gli utenti valutano oggi la situazione in un modo diverso da quello dell’epoca. È molto probabile che oggi non esista più al mondo un solo Ceo disposto ad accettare un enorme investimento Capex in IT fine a se stessa. Il Ceo richiede che l’intero capital investment sia applicato ad asset che creino differentiating advantage, con inerente competitive separation sul mercato, un tipo di valore aggiunto più elevato rispetto al fare le cose che fanno gli altri. Altra cosa importante: in questa congiuntura recessiva, dove esiste un vero e proprio driver per questo, il Ceo vuole che l’IT sia “attaccata a un reostato” così che quando l’economia peggiora si vuole girare il reostato verso il basso e quando si riprende si rigira in su. La direzione aziendale vuole “metered IT”: non in termini di quanta Cpu o banda usiamo, bensì vogliono qualcosa che sia linearmente correlato al business.
Lo “stato del Cloud computing” varia continuamente, ma la questione fondamentale è che l’economia presente richiede con forza l’avvento del Cloud computing, per cui la tecnologia e chi in essa è chiamato a essere innovativo dovrà muoversi in questa direzione. Qualcuno certamente ricorda un articolo a firma di Paul Strassman (“A Retrospective Forecast of the Future” – From the Letters section, Harvard Business Review, June 2003) e – in senso figurato – immagina il Ceo irrompere nell’ufficio del Cio appena pubblicati i risultati del suo survey sull’IT da cui risultava che non esisteva alcun business value creato dall’IT! Strassman è di attualità se pensiamo a come potremmo mai oggi richiedere un investimento IT di qualche milione al nostro Ceo rispondendo (a sua certa domanda) che il suo Roi sarebbe… zero! Per nulla piacevole! Ora pensiamo a un altro articolo – scritto da Nicholas Kerr – che nel 2005 fece molto scalpore col titolo “End Of Corporate computing” in cui asseriva che oltre il 90% di quanto l’IT department svolge è ripetitivo, “ubiquitous” e privo del necessario valore strategico. Rieccoci di fronte al Ceo: gli abbiamo detto che spenderemo qualche milione, senza alcun Roi e alla richiesta se ci sarà almeno qualche valore strategico rispondiamo che «no, non ce ne sarà alcuno». Siamo nella “Ipotesi della Regina Rossa” spesso evocata nel mondo delle scienze ecologiche e della teoria dei giochi quando – ricordando la storia di Alice nel Paese delle Meraviglie – Alice doveva correre sempre più velocemente per poter rimanere nello stesso punto. Utile paradosso in tali ambiti scientifici, ma da noi nell’IT l’Ipotesi della Regina Rossa ha un altro nome e si chiama Technology Refresh Cycle. Ai vecchi tempi dei mainframe il refresh (o come lo chiamavano i nostri contabili: l’ammortamento) era settennale, oggi abbiamo cicli che spesso non superano l’orizzonte dei 18 mesi. Eccoci a concludere il discorso di prima insieme al nostro Ceo e a dirgli che dopo 18 mesi dovrà rispendere ex novo per il bellissimo investimento di cui sopra… Quanto sarebbe “popular” un Cio così? Forse per qualche head hunter, ma nel suo business no di certo!
Come dicono gli americani: ci sono più miti associati al Cloud computing che all’ultimo avvistamento di Elvis, ma per adesso “il Cloud” è il nostro end state.
Sul lungo termine, l’innovazione concerne la comprensione di quali diventeranno gli end state e applicare le risorse in nostro possesso per raggiungere proprio gli end state corretti.
Questo crediamo sia il percorso che seguiranno i modelli “a utility”.
Il primo sforzo di approccio che è richiesto ai Cio per intraprendere il necessario percorso di innovazione ai fini di un progetto Cloud computing efficace è proprio quello di portarsi ad astrarsi da quanto svolto di solito e virtualizzare tutto quanto è e fa l’infrastruttura (non solo in termini di server, bandwith, connettività di rete e storage, bensì – per esempio – il modo in cui Cio e IT “fanno” lo storage). Questo è già un grande step iniziale perché in ogni realtà “storica” di contesto progettuale e tecnologico il limite di partenza – e mi aggiungo nel novero – è che raramente abbiamo investito su noi stessi con la dovuta attenzione al system management e allo storage management: di regola invece – anziché automatizzare – gettiamo gente al lavoro sui problemi. La chiave per fare il salto di qualità – ed è impossibile il salto prima di aver compiuto il suddetto processo di astrazione – è di iniziare a introdurre automazione. Parliamo di avere un sistema virtuale per ciascun utente, gestendo un data center per ogni singolo utente individuale. La virtualizzazione è fondamentale a meno che non siamo già molto bravi nel system management e nella virtualizzazione si comprime geometricamente il problema della gestione del data center. Per cui il grande passaggio successivo è quello dell’automazione del data center seguito infine dalle Cloud. Ecco perché (soprattutto qui da noi in Italia, come dimostrato dalle più recenti statistiche e rilevazioni da IDC a “Enter the Cloud”) non possiamo dire di essere già ovunque pronti al Cloud. Prima di essere efficaci nell’uso delle Cloud bisogna – a detta di chi vi opera da provider o meglio ha esperienza diretta di consumer – aver coperto le tappe propedeutiche a ciò necessarie.
In pratica il panorama Cloud visto dai Cio e ritrovato negli scambi compiuti si può sintetizzare in tendenza come segue.
Le aziende oggi vogliono essere in grado di “tagliare dentro” l’hype per valutare soluzioni Cloud-based in termini di tempo, energia e spesa richieste per implementarle.
I Cio sono le figure più qualificate per condurre la Cloud strategy, grazie alla conoscenza di massimo livello e dettaglio che hanno dell’IT aziendale. Se la conoscenza approfondita della tecnologia è già di per sé critica, non meno importante è la capacità di articolare impatti sul business e opportunità del Cloud computing alla C-suite.
Un buon Cio dimostrerà un sistema di adottare il Cloud per esplorare business options con maggiore rapidità di prima.
Per poterlo fare il Cio dovrà essere almeno preparato a:
– sviluppare una holystic strategy per implementare Cloud interne, esterne, ibride e decidere un approccio di trasformazione e migrazione a step;
– esaminare i fabbisogni aziendali per identificare nuove opportunità di business che diano i maggiori benefici e rendano un ottimo Roi: in questo è essenziale che il Cio sia ottimistico, ma prudente nel migrare funzioni sul Cloud;
– considerare ogni applicazione nel portfolio IT come candidata al Cloud anticipandone e affrontandone tutti i potenziali rischi di security; una volta che il Cio è convinto che una particolare funzione è adatta per una Cloud initiative deve – come analizzeremo fra poco in dettaglio – poter trasmettere in modo chiaro alla C-suite quali business benefit ne conseguiranno;
– confermare che servizi esterni possono riallocare lo staff per gestire relazioni integrate fra risorse interne, service provider e business unit.
Il Cio deve essere il condottiero che prepara l’azienda a diventare “smart”: il modello Cloud computing trasforma il consumer di Cloud computing, in particolare a cambiare sono sia il modo in cui l’IT consegna e gestisce servizi sia anche il come i gruppi IT interagiscono fra di loro e con i propri clienti. Il Cio deve anticipare questi cambiamenti e ridisegnare modelli operativi e processi al fine di supportare le nuove procedure di lavoro.
Come si “governa” l’evoluzione al Cloud?
Oggi i responsabili di business unit spesso acquistano e implementano Cloud service senza coinvolgere l’IT e questo può introdurre seri rischi e problemi di security. Per evitare questi rischi il Cio dovrebbe prendere in carico l’implementazione e l’uso del Cloud computing e in particolare stabilire linee guida allineate all’approccio di risk-management e aggiornate man mano che le Cloud initiative maturano. È anche critico l’impegno a monitorare i Cloud service dopo l’acquisto per assicurare che i costi pay-as-you-go restino vantaggiosi per l’azienda.
Il Cloud cambia anche in modo importante il modo di rapportarsi del Cio al Cfo: la migrazione porta con sé nuove modalità di budgeting per le quali il Cio assurge a business partner. Questa trasformazione è ancora al suo stadio iniziale, ma i Cio “lungimiranti” iniziano a vedersi come provider di servizi anziché di infrastruttura. Poiché presiedono a operating expenditures anziché a capital expenditures, i Cio approcciano ora i Cfo come partner e non più come meri “supplicant” nelle decisioni di business-investment. Questo particolare aspetto costituisce un passo avanti significativo nella evoluzione del Cio verso un nuovo ruolo di business strategist. La partnership Cio-Cfo si sta anche approfondendo sulle problematiche core business quali il risk management, la security e la compliance.
Aspetto non trascurabile per i Cio è poi la gestione della problematica relativa al talent-management: il Cloud computing può ridurre il fabbisogno di risorse IT interne con elevata conoscenza di tecnologia e questo può arrecare problemi nella gestione delle risorse umane del dipartimento al Cio. Lo staff IT può percepire il Cloud computing come una potenziale minaccia al posto di lavoro e il Cio deve poter dimostrare quali percorsi di carriera l’azienda ha pensato per ciascuno. Per esempio parte dello staff può essere riallocato alla gestione di relazioni fra service provider e business unit.
Come si percepisce e misura l’efficacia
Allora adesso i Cio “sanno” che il futuro dell’Information Technology è nel Cloud computing: ma come possono spiegarlo chiaramente e con la necessaria efficacia ai “C” level executives in termini scevri da scarni tecnicismi e davvero significativi per il business?
Un modello che si sta affermando allo scopo introduce l’uso di due speciali metriche business e cinque metodi con cui riportare il Roi del Cloud computing al board e ai vertici aziendali.
• IT capacity – storage (GB or TB), Cpu cycles (GHz or THz), network bandwidth (Mbs or Gbs), e/o memory capacity (Ram) come misura della “performance”.
• IT utilization – uptime availability (% available per year) e volume of usage (# of requests) come indicatori di “activity and usability”.
Rapporti costo effettivo/performance e livelli di usage activity non implicano da soli benefici proporzionali al business. I suddetti sono semplici indicatori della business activity, ma non costituiscono segnali di per sé più utili di un eventuale abbassamento dei costi operativi. Cosa serve introdurre è invece un set di business metric che si basino sul Cloud computing model.
Le seguenti sono alcune business metric che possono tradurre utilmente gli indicatori dalla curva capacity-utilization in benefit diretti e indiretti per il business e costituire esempi concreti di come un Capex sia diverso dall’Opex nel Cloud computing.
- La velocità e il tasso di cambiamento – la riduzione dei costi e il costo di adozione/de-adozione è più rapido nel Cloud. Il Cloud computing crea benefici addizionali ai costi di trasformazione mediante la riduzione dei costi dovuti ai ritardi nelle decisioni e questo grazie all’adozione di servizi pre-built accompagnati da una maggiore rapidità di transizione a nuove capability. Questo è un obiettivo comune ai business improvement program che sono scarsi di risorse e che sono particolarmente time sensitive.
- Ottimizzazione del total cost of ownership (Tco) – nel Cloud computing gli utenti – non solo l’IT – possono scegliere, progettare, configurare e lanciare infrastrutture e applicazioni che siano meglio adatte ai rispettivi fabbisogni di business. Tradizionalmente questo è sempre stato stretto appannaggio del dominio IT anche in ambiti di servizi produttivi, ma nel Cloud computing ambienti e utenze sono molto più direttamente collegati.
- Provisioning elastico e rapido per uso dinamico – le risorse si possono scalare su o giù a seguire la business activity man mano che si espande, si contrae o debba essere rediretta. La compressione del provisioning time può passare da settimane a ore. Il service management impatta utenti finali e business need al punto che causa una evoluzione allo stesso scopo di funzionalità e servizi per l’utente che così può evolversi anche nella ricerca di nuove soluzioni che prima del Cloud model gli erano precluse.
- Aumento di margine e controllo dei costi – la crescita degli utili e le opportunità di migliore controllo dei costi consentono alle aziende di acquisire nuovi clienti e mercati ai fini della crescita del business e del miglioramento dei propri servizi. Poiché si può scalare, l’IT riesce a prevenire i sovra- e sotto-dimensionamenti dei servizi IT necessari a garantire smarter business services. Questa è enhanced capacity utilization, la possibilità di aggiungere e utilizzare hardware on-demand senza extra costi per hardware e manodopera aggiuntivi.
- Business process improvement – le Cloud computing capabilities possono essere progettate e implementate attarverso shared services. Gli utenti possono avere accesso a business capabilities che consentono il miglioramento o lo sviluppo di nuovi skill e soluzioni mediante Cloud sourcing e soluzioni on demand.
Queste cinque misure definiscono proprio un nuovo insieme di metriche business che si possono introdurre e utilizzare per creare una matrice di controlli a cruscotto del nostro operational business presente e futuro e dei relativi fabbisogni IT collegati al Roi potenziale del nostro ambiente di Cloud computing.
Per i Cloud service complessi di oggi, definire il corretto portfolio di metriche, i perfomance targets, i metodi di misurazione e i remedies è davvero una sfida cruciale. I Cloud-based Sla che incoraggiano efficacemente il comportamento desiderato e atteso del provider dovrebbero mantenere una sufficiente flessibilità per poter soddisfare i mutevoli business needs e restare gestibili sia per il Cloud service provider che per il cliente (consumatore del service) sul lungo termine.
Gli step che le aziende e i Cio possono intraprendere per assicurare che gli Sla servano veramente allo scopo sono riconducibili a quattro, secondo una best practice che si segnala in modo interessante sul mercato:
ñ Assicurarsi che ogni Sla considerato misuri effettivamente service elements di importanza per noi anziché per il provider.
ñ Descrivere i dettagli di ogni service level, compreso dove il servizio sarà misurato, come saranno raccolti i dati e come saranno eseguiti i calcoli del livello di servizio.
ñ Settare soglie di performance realistiche, idealmente basate e supportate sui dati storici.
ñ Predisporre e avere chiari i remedies a disposizione in caso il provider dovesse a un certo punto venir meno al rispetto dei service level stabiliti e concordati. I service credits sono comuni, ma si potrebbero anche analizzare opzioni non finanziarie quali documentazione di root-cause analysis di problemi persistenti e modifiche eseguite per affrontare i suddetti problemi.
LA PAROLA AI CLOUD project LEADERS
In conclusione riportiamo qui a supporto una piccola antologia di argomentazioni espresse nel corso di alcuni spunti scambiati via Web da Cio, concentrati su alcuni argomenti che ricorrono nelle discussioni sulle esperienze progettuali Cloud, sulla vision, sulle prospettive concrete di chi lo ha adottato e di chi è ancora scettico.
Cio nel Cloud: ruolo di costruttore o di condottiero?
«Il Cio è un conduttore perché ha il dovere di assicurare che la migrazione da servizi IT interni detenuti dalla sua compagnia non la comprometta passando al Cloud. Ci sono sistemi e servizi che potrebbero dover essere mantenuti in-house e sta al Cio assicurare che il mix sia adeguato alla performance richiesta dal business. I Cio stanno smettendo i panni di costruttori. Il Cloud consente la realizzazione di economie di scala cui ben poche società potrebbero aspirare entro i propri limiti di budget».
Cloud: quali esperienze dirette potete citare nel vostro percorso progettuale dalla teoria alla pratica?
«Uno dei principali problemi affrontati è stato quello di creare una struttura multitenant. È anche importante pensare in termini corretti architetture che affrontino gli aspetti di affidabilità e scalabilità. Questi aspetti sono intrinsecamente legati alla piattaforma Cloud scelta. E qui si nota che non tutti i Cloud pubblici sono uguali. Altro punto fondamentale è il billing. Tutto ciò che si fa in Cloud è “billato” in modo più o meno fine. Quando si realizza un’applicazione occorre controllare il consumo di risorse e provvedere di conseguenza. Non è per niente secondario. Con i server in casa i programmatori non consideravano più che tanto questi aspetti visto che la macchina era più o meno a loro completa disposizione. Infine l’aspetto legale e contrattuale è altrettanto importante. Sla ottenibili e promessi devono essere armonizzati. I contratti devono essere chiari negli obblighi reciproci. Personalmente ritengo che il Cloud ci abbia permesso di fare cose prima impensabili sia per le grandi, ma soprattutto per le medie e piccole aziende. La nostra esperienza è sicuramente positiva».
«Penso che la mia esperienza sia delle più banali: server di posta, prima ospitato nel data center in house poi spostato su data center remoto. A parte il fatto che la nostra tariffazione non è a consumo, ma annuale forfettaria (comprende sia lo spazio disco sia il traffico dati, indipendentemente da numero di caselle di posta e domini attivati), l’applicativo gira effettivamente su server e vi si accede via Web (sia con apposito client sia direttamente dal browser). Quello che si apprezza subito è la sensazione di essersi liberati di un peso: mai in casa avremmo potuto garantire la scalabilità e la versatilità che ci offre il data center remoto, oltre alle politiche di backup, disaster recovery, high availability e manutenzione dell’applicativo in generale, ai costi che ora sopportiamo. In sostanza, abbiamo ridotto l’immobilizzo in termini sia di hardware sia di personale, quest’ultimo riconvertito su attività più critiche e/o remunerative, oltre ad aumentare sensibilmente la sicurezza in generale.
La mia opinione, e se vuoi si tratta anche di un consiglio, è di cercare un fornitore più affidabile e robusto possibile: il successo del tuo progetto dipenderà in gran parte da questo.
Inoltre, non sottovalutare la disponibilità e affidabilità anche della tua rete (per intenderci, il collegamento a Internet locale): se sposti i servizi su un data center certificato e ridondato e poi il tuo carrier ti lascia a piedi, sei fermo, non puoi pensare di lavorare “offline”. Nel caso della posta elettronica, questo problema è marginale (l’importante è che riceva il server), ma se sposti per esempio il tuo Erp, blocchi l’azienda per tutto il periodo di disservizio».
«Parlando in prospettiva SaaS: quando si esegue un progetto Cloud per realizzare un software che debba essere utilizzato in un SaaS model, allora uno dei maggiori vincoli o assunzioni progettuali di cui preoccuparsi è il multi-tenancy. Gli aspetti di progetto database multi-tenancy si concentrano nella necessità di dover gestire business requirements differenti o configurazioni di processo in un modo flessibile. Ogni gruppo di utenti tipicamente ha il proprio set di specifiche e in un mondo tradizionale on-premise si sarebbero dovute mantenere diverse versioni di codice o avere delle verticalizzazioni a gestire set differenti di specifiche. Ma con un progetto Cloud SaaS si hanno modularità di progetto e configurabilità tali da poter gestire queste differenti specifiche mediante insiemi di parametri e videate di selezione».
«Alcuni consigli pratici, validi specialmente per lo IaaS: 1. Mantenete le medesime regole di change management che avreste in caso di soluzioni locali e fisiche: cambiare Cloud sembra così semplice da fare che la tentazione di farlo senza opportuna pianificazione e disegno va evitata. 2. In particolare si mantengano sempre test-bed environments per lo sviluppo, gli upgrade ecc. 3. Riceverete grandi pressioni per customizzare le soluzioni: resistete su tutto, dove potete. Off-the-shelf è più sicuro per il consumer e più sicuro ed economico per il provider: il Cloud non è altro che un modello in cui gli XaaS diventano commodity. 4. Pensate con grande cura ai tool e alle metodologie di misura delle network/application performance. Tali strumenti possono essere anche molto diversi da quelli tradizionali e nuovi per voi: in alcuni casi potrebbero essere essi stessi forniti mediante Cloud. 5. Quando fate stime e misure successive tenete conto che l’efficacia del Cloud passa attraverso l’inclusione di tecnologie per il single sign-on cross tool, billing consolidato per le infrastrutture e ausilii similari».
«La data security può essere un problema per cui consigliamo vivamente di valutare l’adozione di una opzione data escrow attiva: mediante una clausola di data escrow è possibile recuperare i propri dati anche nel caso estremo in cui il Cloud provider fallisca».
Cloud computing, cosa vi trattiene dall’adottarlo?
«Per prima cosa mai per nessun motivo sviluppare un progetto Cloud da cui non possiate poi uscire facilmente. Usare una piattaforma proprietaria che è vincolata in modo forzato a una Cloud è da pazzi e molti Cio lo fanno giornalmente… per poi ripartire da zero in caso di cambio necessario. In questi casi il Cloud si rivela uno dei fenomeni più fraintesi della storia: non risolve nessun problema reale e al contrario ne introduce parecchi nuovi».
«Cloud: di per sé non significa nulla! Facciamo un esempio: pensiamo di avere un’applicazione Crm in casa. Ce l’avevamo da anni a supportare 100 venditori con un costo annuo di manutenzione di 75mila dollari. Essendo on-site non c’è problema a disdire il canone di manutenzione e continuare ad usarla com’è. Ora migriamo a un Crm su Cloud a 60 dollari/mese per ciascun utente (aumenterà ogni anno). Quindi il primo anno abbiamo un costo di 72mila dollari. Poniamo che il secondo anno il canone mensile passi a 75 dollari per utente: non abbiamo scelta ad accettare perché non abbiamo più sistema e staff in casa a gestirlo. Adesso siamo passati a un costo annuo di 90mila dollari per il secondo anno. Il terzo anno il canone aumenterà ancora e il provider ha i nostri dati in formato proprietario per cui siamo fregati. Ma adesso il discorso si fa ancora più interessante: ecco perche i software vendor amano il Cloud e ci vorrebbero tutti sopra. Diciamo infatti che a causa della recessione le nostre vendite si appiattiscano. Con la soluzione in-house tradizionale di prima potevamo cessare di pagare il canone di manutenzione avendo sempre il sistema in uso autonomo e dirottare 75mila dollari alla nostra bottom line. Alla ripartenza delle vendite potevamo con calma rinegoziare il relicensing. Con la soluzione Cloud-based invece dobbiamo continuare a pagare i canoni di uso mensile (sempre crescenti), pena la perdita immediata delle funzioni software a noi ora necessarie. E allora dove il Cloud ha migliorato la nostra situazione?».
«Definizione di Cloud computing? Il termine ha perso ogni significato originale, dal momento che diversi vendor hanno dirottato il termine per riferirsi a servizi di hosting/SaaS ecc, che in realtà non garantiscono alcun risparmio a un’organizzazione. La spesa si sposta semplicemente da Capex a Opex e ancora la Opex ricorre spesso crescente e così per molte organizzazioni il “Cloud” si rivela troppo costoso da mantenere dopo solo un anno o due (in alcuni casi anche meno). Quasi ogni azienda che adotta il Cloud in realtà necessita ancora di infrastruttura interna per far funzionare il tutto correttamente ed è per questo che per la maggior parte dei business su Cloud si decide di costruire delle “private” Cloud (altro termine dirottato che realmente indica ambienti virtuali) e quando viene fatto correttamente si ottiene un certo grado di self/service per utenti/dipartimenti per la richiesta di risorse. Le aziende che implementano invece il vero “Cloud computing” – a significare: raw compute resources (Cpu, memory, disk) – ci arrivano dopo anni e riescono a gestire in modo trasparente richieste spike o per progetti senza aver dovuto sovra investire in computing resource. Attenzione: spostare le proprie risorse di elaborazione nel Cloud non significa smettere di aver bisogno di personale a gestire tali risorse e significa nuovi vendor. Tutte le società che hanno lasciato andare le loro valide risorse tecniche pensando di creare i risparmi sui costi IT presto vorrebbero non averlo fatto».
Cloud computing… in aula dibattimentale!
Per gli amanti dei dibattiti all’americana segnaliamo invece qui un classico veramente… http://www.economist.com/debate/overview/157 “all’ultima roadmap”!
