Definire un framework per l adozione del cloud

IBM Global Technology Services White Paper di Thought Leadership Computing Definire un framework per l adozione del cloud Una base comune per aiutare le imprese a sfruttare i vantaggi del cloud computing

2 Definire un framework per l adozione del cloud Sommario 2 Introduzione 3 Guardare al cloud computing attraverso due dimensioni 3 Modelli di delivery in ambiente cloud 7 Tipi di servizi del cloud 8 Ruoli nella delivery e nell utilizzo del cloud 10 Problemi da affrontare e riflessioni 11 Riepilogo Introduzione Dati i molti vantaggi, ormai ampiamente riconosciuti, del cloud computing, fra cui scalabilità modulare, rapida erogazione dei servizi, più efficienza per l IT e tariffazione in base all uso, le aziende sono sempre più interessate ad adottare un ambiente di elaborazione dati secondo un modello cloud. Nonostante ciò, il fatto che i media e gli analisti ne parlino molto, unito ad una proliferazione di provider e di messaggi di marketing, ha causato una certa confusione sul significato reale del termine cloud computing. Ad esempio, alcuni provider hanno identificato nel cloud computing un modo per fornire capacità elaborativa o di storage in modalità as a service, con erogazione on-demand da una piattaforma di elaborazione parallela, che sfrutta le economie di scala. Altri equiparano il cloud computing alla tecnologia SaaS (Software as a Service), un modello per la fruizione di software applicativo via Internet. Gli analisti IT percepiscono il cloud computing nella prospettiva di prezzi variabili, senza investimenti a lungo termine, con una notevole elasticità nell erogazione dei servizi. I responsabili IT considerano il cloud un architettura alternativa per l infrastruttura in grado di ridurre i costi. Gli utenti finali, i media e gli analisti finanziari, infine, vedono la questione da prospettive ancora diverse. Tutte le suddette categorie parlano del cloud computing, ma non tutte nello stesso modo. Questa molteplicità di interpretazioni è stata confermata da uno studio condotto da IBM nel 2009 su oltre 1.000 responsabili IT e di Line of Business (LOB) di tutto il mondo, intervistati sulla loro concezione di cloud computing. 1 I risultati hanno dimostrato che, nonostante il 73% fosse già a conoscenza dei differenti metodi di utilizzo del cloud computing prima di partecipare al sondaggio, non vi era grande coerenza sui termini che venivano associati ai metodi di erogazione via cloud interni o esterni. Ad esempio, il 30% degli intervistati aveva scelto SaaS, mentre solo il 24% selezionava cloud computing. Tra le altre definizioni scelte figuravano hosting (19%), virtualizzazione/ consolidamento (16%) e utility computing (4%). Senza un vocabolario comune e un modello di riferimento univoco è difficile, se non impossibile, per le organizzazioni parlare di cloud computing in maniera coerente, sia esternamente con i provider di servizi, sia internamente tra responsabili IT e responsabili aziendali, oppure fra figure professionali appartenenti all IT. Già questo è sufficiente a creare una barriera allo sviluppo di una strategia di adozione del cloud computing vincente in ambito aziendale. Per risolvere questo problema, IBM ha sviluppato un framework di adozione che stabilisce definizioni comuni per modelli e servizi, illustra i requisiti basilari da prendere in considerazione durante lo sviluppo di strategie per l implementazione del cloud computing e identifica i fattori essenziali per attuarle con successo.

IBM Global Technology Services 3 Il framework di adozione del cloud computing è basato sulle linee guida del National Institute of Standards and Technology e costituisce un ausilio per l analisi, utilizzabile dai consulenti IBM, unitamente a tutto il resto del capitale intellettuale di IBM, per aiutare le organizzazioni a stabilire una roadmap visiva per l adozione del cloud. In questo contesto, il framework è in grado di aiutare le organizzazioni a: Determinare i tipi di servizi disponibili tramite il cloud Identificare le funzionalità di gestione dei servizi necessarie per supportare il modello di delivery e il servizio desiderati, ad esempio sistemi di misurazione e fatturazione Identificare le sfide da affrontare, sia nell immediato che a lungo termine, prima dell implementazione del cloud, come ad esempio problemi di integrazione o di governance. La finalità del presente documento è presentare il framework di adozione del cloud computing di IBM e renderlo disponibile per l uso da parte delle organizzazioni che desiderano avvalersi di una struttura di riferimento standardizzata per parlare di cloud computing. Caratteristiche salienti del framework di adozione del cloud computing Identifica due dimensioni principali da prendere in considerazione per lo sviluppo di una strategia di cloud computing Identifica le principali funzionalità differenziate in queste due dimensioni Identifica le competenze chiave e le considerazioni da fare per fornire e utilizzare con successo servizi in cloud ai punti di intersezione definiti dagli elementi differenziati Allinea le capacità richieste ad ogni fase del processo di adozione. Guardare al cloud computing attraverso due dimensioni Il framework di adozione definisce le due dimensioni intersecanti da tenere in considerazione nello sviluppo di una strategia per il cloud computing: il modello di delivery e il tipo di servizio o servizi da fornire. Unendo questi due elementi fondamentali, emerge un framework di base che permette di esaminare i requisiti e le possibilità per l implementazione del cloud. La conoscenza di questi requisiti può essere utile alle organizzazioni per scegliere la combinazione ottimale fra modello di delivery e tipo di servizio per ogni carico di lavoro che desiderano implementare in ambiente cloud. I carichi di lavoro costituiscono la tipologia di lavoro che un azienda deve svolgere. Ciascun carico di lavoro ha caratteristiche peculiari che lo rendono più adatto ad un erogazione di tipo pubblico o privato, nonché al tipo di servizio specifico. Modelli di delivery in ambiente cloud La prima dimensione da considerare quando si sviluppa una strategia di cloud è il modello di delivery da utilizzare, che costituisce la dimensione orizzontale del framework, ovvero l asse x. Esistono due modelli di delivery principali per il cloud: pubblico e privato. Volendo, ne è disponibile anche un terzo, che consiste in una combinazione dei due precedenti. In un cloud privato sia l utilizzatore che il provider dei servizi fanno parte della stessa azienda. La proprietà delle risorse del cloud risiede all interno della stessa azienda che fornisce e che utilizza i servizi del cloud.

4 Definire un framework per l adozione del cloud In un cloud pubblico l utilizzatore e il provider dei servizi del cloud appartengono ad aziende distinte. La proprietà delle risorse utilizzate per fornire i servizi di cloud è del provider. Un cloud ibrido è caratterizzato dalla compresenza di elementi propri sia del cloud privato che di quello pubblico, ovvero consiste in una combinazione qualsiasi di provider e utilizzatori e può anche contenere vari livelli di servizio. Come illustrato nella Figura 1, il framework di adozione del cloud computing definisce inoltre varie tipologie di dettaglio all interno dei modelli di delivery del cloud pubblico e privato. Queste segmentazioni interne ai modelli di delivery pubblico e privato introducono una discussione più mirata sui ruoli e le responsabilità tanto del provider quanto dell utilizzatore dei servizi del cloud, in base ai requisiti specifici dello scenario in questione. Questi sottotipi implicano inoltre la necessità di considerare il livello di competenza e sofisticazione richiesto per fornire e utilizzare proficuamente i servizi del cloud. Carico di lavoro isolato, primo approccio al cloud computing esplorativo Pochi partecipanti, tutti interni e provider dei servizi del cloud fanno parte della stessa azienda Organizzazione IT e utenti del cloud fanno parte di un solo settore gestionale dipartimentale CLOUD PRIVATI Organizzazione IT e utenti del cloud attraversano i confini gestionali interni aziendale Entità organizzativa Modelli di delivery e provider dei servizi del cloud fanno parte di aziende diverse Rapporto da uno a uno fra provider dei servizi o organizzazione utilizzatrice esclusivo Rapporto da uno a molti fra provider di servizi e utilizzatori aperto CLOUD PUBBLICI Molti partecipanti, interni ed esterni Figura 1: Sottotipi di cloud. Il framework di adozione del cloud computing definisce i singoli sottotipi del modello di delivery e supporta le organizzazioni nella scelta del più adattato alle loro esigenze. Sottotipi di cloud privati esplorativo Questo modello di delivery rappresenta il primo approccio di un organizzazione al cloud computing, in cui l obiettivo principale è sviluppare competenze ed esperienza nella delivery del cloud. Le finalità dell implementazione di un cloud esplorativo, che ha caratteristiche simili a quelle di un progetto pilota, consistono nello sviluppare le competenze di utilizzatori e provider, nonché la conoscenza dei requisiti specifici di architettura di gestione di un cloud esclusivo. Il suo valore deriva dallo sviluppo di capacità atte a fornire servizi in cloud e all individuazione degli accorgimenti tecnici necessari in questo ambiente. È inoltre un punto di partenza per valutare il ritorno sull investimento (ROI) di servizi erogati via cloud. Per poter varare un cloud esplorativo, un organizzazione deve disporre di standard documentati, essere ben gestita e regolata, utilizzare strumenti basati su standard che possono essere sviluppati o già esistenti, purché estendibili. Questo tipo di cloud viene di norma utilizzato per l elaborazione di carichi di lavoro non critici ma con elevato utilizzo di CPU. dipartimentale L organizzazione IT che fornisce i servizi in cloud e il reparto funzionale che li utilizza risiedono all interno della stessa organizzazione ed è il reparto che ne determina i requisiti. In un cloud dipartimentale, lo scopo è espandere l uso del cloud computing agli utilizzatori che non ne conoscono le potenzialità e iniziare a sviluppare capacità operative di supporto alle componenti architetturali di business support system e di operational support system. Il suo valore nasce dall incremento di competenze nella condivisione di risorse e nella gestione della virtualizzazione, nonché da una maggiore conoscenza dei vantaggi offerti da modelli di delivery alternativi, acquisiti all interno del sistema di gestione del modello di business. Per implementare un cloud dipartimentale l organizzazione deve disporre di

IBM Global Technology Services 5 standard aperti che possano evolversi, così come la possibilità di adottare la virtualizzazione e un modello di sicurezza tipico dell ambiente cloud. I carichi di lavoro che vengono elaborati in questo tipo di cloud possono essere ambienti di test o applicazioni dipartimentali. aziendale L organizzazione IT che fornisce il cloud e l organizzazione o le organizzazioni che si avvalgono dei servizi del cloud fanno parte delle stessa azienda, ma rientrano in settori gestionali diversi. Lo scopo dell implementazione di un cloud aziendale è risolvere problematiche di business in cui i tempi sono di importanza cruciale, utilizzando risorse esistenti precedentemente inattive. Questo modello genera valore ottimizzando gli investimenti in risorse IT effettuati dall azienda. In un cloud aziendale la sicurezza deve essere sia definita che implementata correttamente e l organizzazione deve disporre di funzionalità aggiuntive, quali monitoraggio, provisioning automatizzato e autenticazione degli utenti. Sono altrettanto importanti le funzionalità di misurazione e fatturazione, che consentono all IT di imputare alle LOB i servizi del cloud utilizzati. Esempi di carichi di lavoro elaborabili in questo tipo di cloud sono l e-mail e gli strumenti per la collaborazione interna. Per ciascuno dei tre sottotipi di un cloud privato, i sistemi di supporto sia di tipo business cloud, che operativi, risiedono all interno dello stesso settore gestionale aziendale di cui fanno parte anche i servizi del cloud. Sottotipi di cloud pubblici esclusivo Il cloud esclusivo viene di solito impiegato per fornire servizi condivisi ai membri di un singolo gruppo o organizzazione, ad esempio un consorzio di università o istituti di ricerca, una società con le sue sedi remote e i suoi business partner affiliati, un settore di attività industriale o associazione commerciale. La finalità di un cloud esclusivo è fornire l accesso ai soli partecipanti che ne hanno diritto, in modo che possano utilizzare applicazioni di importanza cruciale per lo svolgimento delle loro attività. I membri utilizzano i servizi grazie ai loro rapporti con l organizzazione padre, ed è quest ultima ad intrattenere le relazioni di business con il provider del cloud. Il cloud pubblico esclusivo è caratterizzato da due elementi distintivi. Primo, il provider del cloud e l organizzazione che ne utilizza i servizi sono noti l uno all altra e sono in grado di negoziare i parametri relativi al livello di servizio. Questa relazione di business può andare oltre quella di norma esistente fra utilizzatore e fornitore; ad esempio l utilizzatore può stipulare un contratto di outsourcing più ampio con il provider, ma non è un requisito indispensabile. Secondo, tutte le risorse di delivery utilizzate per fornire i servizi all organizzazione sono dedicate a questo cloud esclusivo e non sono condivise con altri ambienti gestiti dallo stesso provider o utilizzati da altri consumatori esterni all organizzazione. È importante sottolineare che cloud esclusivo e cloud privato virtuale non sono la stessa cosa. Si parla di cloud privato virtuale quando una sola organizzazione utilizzatrice, ad esempio una società o un reparto di una società, utilizza in modo esclusivo le risorse che il provider le fornisce come servizio. Queste risorse tuttavia sono residenti in un centro elaborazione dati o su un server che fornisce servizi anche ad altre organizzazioni. Un organizzazione che implementa un cloud esclusivo può avere l intento di ridurre tanto le spese in conto capitale quanto i costi di gestione per l utilizzatore, nonché sviluppare nuove competenze in materia di collaborazione in cloud, quali ad esempio garantire l approvazione dei cambiamenti del business o le variazioni dei sistemi di supporto operativi, identificando i problemi di sicurezza e stabilendo contratti per il livello di servizio (SLA). Per questo tipo di cloud sono necessari differenti profili di associazione, una regolamentazione per l ubicazione fisica dei dati e una

6 Definire un framework per l adozione del cloud Livelli di servizio Basso Livello di struttura e standard Alto per i processi di business applicativi di piattaforma infrastrutturali Chiamati anche: Business Process as a Service (BPaaS) Caratteristiche: applicazioni utilizzate dal personale del provider di servizi, che esegue processi di business per conto del cliente Esempi di servizi: HR, procurement, amministrazione, processi di back-office Chiamati anche: Software as a Service (SaaS) Caratteristiche: PaaS più istanze di applicazioni condivise Esempi di servizi: email, Web conferencing, collaborazione, Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), applicazioni settoriali Chiamati anche: Platform as a Service (PaaS) Caratteristiche: laas più istanze middleware condivise o private Esempi di servizi: software per database, tool di sviluppo, runtime Java, runtime applicazioni Web 2.0 Chiamati anche: Infrastructure as a Service (IaaS) Caratteristiche: infrastruttura virtualizzata condivisa; provisioning, misurazione e fatturazione dinamici Esempi di servizi: risorse di elaborazione, server, reti, data centre fabric, storage Figura 2: Tipi di servizi del cloud. Ogni tipo di servizio rappresenta un aumento di livello della struttura e degli standard, in cui i servizi del cloud legati ai processi di business sono quelli con i requisiti più elevati. ripartizione equa dei costi. Un buon esempio di utilizzo efficiente di un cloud esclusivo può essere un gruppo di università che richiede capacità on-demand per carichi di lavoro intermittenti che necessitano di molte risorse di elaborazione, ad esempio una modellazione sofisticata. Altri carichi di lavoro per questo tipo di cloud sono applicazioni settoriali specifiche, condivise fra i membri di un associazione commerciale, o applicazioni analitiche, utilizzate congiuntamente da istituti di ricerca. aperto Le organizzazioni che utilizzano il servizio e quella che lo fornisce non si conoscono prima della presentazione di una richiesta di servizio. Il principale fattore distintivo di un cloud aperto è che la negoziazione dei servizi avviene mediante un evento automatizzato, basato su standard, i cui termini di governance sono definiti e controllati dal provider. Il modello di delivery del cloud aperto richiede inoltre la negoziazione e la riconciliazione automatiche di livelli di servizio, dei prezzi e dei criteri, oltre che l applicazione automatizzata di questi criteri.

IBM Global Technology Services 7 Di norma i servizi vengono ordinati, prestati e pagati via Internet, in molti casi senza l intervento umano, a meno che l utilizzatore non avvii un interrogazione o una transazione del servizio clienti. Questo tipo di cloud genera valore eliminando gli investimenti di capitale preliminari che l utilizzatore dovrebbe effettuare per dotarsi internamente delle risorse informatiche necessarie e velocizzando i tempi di implementazione e il relativo conseguimento di benefici per il business. Sebbene in teoria in un cloud aperto possano essere elaborati pressoché tutti i tipi di carichi di lavoro, dall analisi effettuata da IBM 2 delle barriere e degli elementi facilitatori o preferenze dei clienti è emerso che i carichi più adatti ad iniziare l erogazione su cloud pubblico sono quelli di tipo applicativo, infrastrutturale e di piattaforma. In particolare, i carichi di lavoro che meglio si prestano al cloud aperto sono applicazioni tipo il Web conferencing, i servizi di help desk, le applicazioni di tipo CRM (Customer Relationship Management) su desktop virtuale, nonché gli ambienti per attività di test e servizi di storage. 3 Tipi di servizi del cloud La seconda dimensione definita dal framework di adozione del cloud computing è il tipo di servizio. Questa è la dimensione verticale del framework, ovvero l asse y. Come illustrato nella Figura 2, i quattro tipi di servizi definiti nel framework sono stratificati in modo da rappresentare l incremento del livello di infrastruttura e degli standard. Ogni tipo di servizio costituisce la base per il successivo e richiede l infrastruttura e gli standard di quello sottostante. Come verrà descritto nel prosieguo di questo documento, questa progressione ha implicazioni significative tanto per il provider quanto per l utilizzatore dei servizi del cloud. In molti casi le organizzazioni scelgono uno o più tipi di servizi e questa scelta aggiunge complessità nella selezione dei metodi di delivery del cloud, evidenziando l esigenza di una mappa visiva per esaminare tutti gli aspetti del delivery. I tipi di servizi del cloud definiti nel framework sono: cloud di infrastruttura (noti anche come Infrastructure as a Service, o IaaS) Forniscono l accesso on-demand, pagando solo ciò che si usa, alle risorse dell infrastruttura, fra cui i server e i dispositivi di storage e di rete, che l utilizzatore configura e controlla utilizzando applicazioni a sua scelta. Questo servizio può essere fornito con un modello di business a consumo, ad esempio istanza virtuale per ora o in base al numero di gigabyte trasferiti, oppure a tariffa fissa per un dispositivo virtuale con capacità e configurazione predefinite. In entrambi i casi, l accesso alle risorse avviene tramite rete, di solito Internet. I servizi infrastrutturali possono comprendere anche un sistema operativo, con o senza l ausilio di basilari strumenti di gestione del sistema. cloud di piattaforma (noti anche come Platform as a Service, or PaaS) Questi servizi forniscono funzionalità elaborative (infrastruttura) oltre ad uno stack middleware predefinito, di norma strutturato per gli sviluppatori o per gli utenti IT avanzati. I provider possono decidere di offrire una varietà di servizi (stack), configurabili dall utilizzatore a vari livelli. Ne sono esempi il software per database, l accesso al Web e i server delle applicazioni. La configurazione e la gestione di queste risorse middleware competono all utilizzatore, ma il provider può offrirsi di gestire immagini standard, una volta definite. cloud di tipo applicativo (noti anche come SaaS) Sono servizi consistenti in un applicazione predefinita, ad esempio CRM ed ERP (Enterprise Resource Planning), che viene di solito fornita tramite un cloud pubblico. Gli utilizzatori, appartenenti a più organizzazioni, condividono un unica istanza dell applicazione e vengono impiegate

8 Definire un framework per l adozione del cloud tecnologie di virtualizzazione per separare i dati dei singoli clienti e salvaguardare la privacy. La configurazione e la gestione delle applicazioni competono al provider dei servizi. Un organizzazione può tuttavia decidere di implementare un tipo di servizio applicativo all interno di un cloud privato per ridurre i costi legati alle licenze o di altra natura. per i processi di business (noti anche come Business Process as a Service, o BPaaS) In sé riuniscono servizi applicativi e il modello di servizi condivisi in cui è una singola organizzazione a fornire a vari utilizzatori, sia interni che esterni, servizi di business quali la gestione degli incentivi per i dipendenti e le funzionalità per l help desk o il procurement. Sebbene gli utilizzatori comprino servizi di business e non applicazioni, questi possono beneficiare di una riduzione dei costi e maggiore flessibilità, nel caso il provider si affidi ad una struttura di delivery basata sul cloud. Una volta che il modello di delivery e il tipo di servizio siano stati identificati, le organizzazioni possono dedicarsi ad individuare le funzionalità di gestione dei servizi necessarie per attuare il modello di delivery e di servizio prescelti. Ne sono un esempio la misurazione e la fatturazione, in cui il provider è in grado di addebitare all utilizzatore solo i servizi effettivamente utilizzati e l utilizzatore può fruirne pagando solo ciò che utilizza. In un ambiente cloud privato, la misurazione e la fatturazione consentono al reparto IT di mappare i costi IT alle business unit e, se lo desiderano, recuperarli tramite riaddebiti contabili interni. Come minimo è importante implementare almeno la misurazione, in modo che l organizzazione IT abbia il pieno controllo sui costi di produzione di un determinato servizio. Ruoli nella delivery e nell utilizzo del cloud Le due dimensioni principali, modello di delivery e tipo di servizio, insieme creano un framework di adozione basilare che consente di esaminare i requisiti di implementazione del cloud. Il framework di adozione del cloud computing permette inoltre di identificare i principali ruoli di chi utilizza e di chi fornisce i servizi di cloud, unitamente alle competenze richieste per ciascuno di questi ruoli. I ruoli sono i seguenti. Nei cloud privati, gli utilizzatori sono all interno dello stesso settore di gestione di impresa del provider. Nei cloud pubblici, gli utilizzatori e i provider appartengono ad aziende diverse. Il ruolo dell utilizzatore può essere suddiviso in due ruoli secondari, utente e abbonato. Di seguito sono elencate le competenze richieste per ciascun ruolo: Abbonati Devono accollarsi impegni finanziari e contrattuali per poter utilizzare i servizi del cloud e sono responsabili di informare i loro utenti su tali servizi e sulle attività che essi possono svolgere. Gli abbonati hanno inoltre il compito di disdire l abbonamento. Utenti Utilizzano i servizi del cloud in maniera produttiva e smettono di servirsene una volta terminato il loro compito. Il provider fornisce i servizi del cloud ed è proprietario delle risorse necessarie per produrli ed erogarli all utilizzatore. Nel modello del cloud privato, provider interni forniscono servizi a utilizzatori interni. Nel modello del cloud pubblico, il provider è costituito da una terza parte esterna e può fornire i servizi a più utilizzatori oppure a una singola organizzazione. I provider possono inoltre far parte di un modello di delivery di tipo ibrido, in cui forniscono servizi sia mediante cloud pubblico che privato. Integratori Gli integratori apportano la competenza tecnica necessaria per riferire con precisione al provider quali sono i requisiti IT dell utilizzatore. In un modello di delivery di cloud pubblico, il ruolo dell integratore è svolto per conto del cliente finale e si fa inoltre carico della parte commerciale dei servizi di cloud erogati da terzi.

IBM Global Technology Services 9 Livelli di servizio Basso Livello di struttura e standard Alto per i processi di business applicativi di piattaforma infrastrutturali L'utilizzatore o integratore è responsabile di tutti gli aspetti (IT e utilizzatore) al livello del servizio utilizzato e livelli SUPERIORI Il provider è responsabile e interessato da tutti gli aspetti (IT e utilizzatore) al livello del servizio fornito e livelli SOTTOSTANTI esplorativo Pochi partecipanti, tutti interni dipartimentale CLOUD PRIVATI aziendale Entità organizzativa Modelli di delivery esclusivo aperto CLOUD PUBBLICI Molti partecipanti, interni ed esterni Figura 3: Ruoli e responsabilità. Il framework di adozione del cloud computing definisce i livelli di responsabilità dei ruoli di provider, utilizzatore e integratore nei modelli di cloud pubblico e privato. Il framework di adozione del cloud computing delinea chiaramente le responsabilità che competono ad ogni ruolo, a seconda del tipo di servizio e del modello di delivery scelti. Come illustrato nella Figura 3, l utilizzatore e il provider sono collettivamente responsabili di tutti gli aspetti. Le responsabilità specifiche di ciascuno variano a seconda del tipo di servizio. Una volta identificato il livello di servizio specifico desiderato, gli utilizzatori devono comunicare al provider le loro esigenze in merito, continuando però ad essere responsabili per le richieste IT correlate a tale livello. Ad esempio, un utilizzatore di servizi cloud di piattaforma è responsabile di tutte le applicazioni e i processi di business di cui necessita l organizzazione. Analogamente, il provider ha la responsabilità di concordare con l utilizzatore i requisiti inerenti a un tipo di servizio specifico. In questo caso, tuttavia, il provider è responsabile esclusivamente delle le decisioni IT pertinenti al livello di servizio scelto e a quelli sottostanti. Proseguendo nell esempio, il provider di servizi di piattaforma è responsabile sia del livello middleware sia del livello dell infrastruttura sottostante, mentre un provider di servizi applicativi è responsabile del livello applicativo, del livello del middleware e del livello dell infrastruttura.

10 Definire un framework per l adozione del cloud Livelli di servizio Basso Livello di struttura e standard Alto per i processi di business applicativi di piattaforma infrastrutturali Grande azienda, esigenze aziendali Grande azienda, riduzione dei costi IT Azienda di medie dimensioni esplorativo Pochi partecipanti, tutti interni dipartimentale CLOUD PRIVATI aziendale Entità organizzativa Modelli di delivery esclusivo aperto CLOUD PUBBLICI Molti partecipanti, interni ed esterni Figura 4: Mappa visiva di possibili percorsi di adozione del cloud. I percorsi variano in base al modello di delivery e al livello di servizio scelti, oltre che in base a chi sia l incaricato di gestire la migrazione al cloud, se l azienda o l IT. Problemi da affrontare e riflessioni Una volta identificato il tipo di ambiente cloud per un determinato carico di lavoro o insieme di requisiti dell utilizzatore, il framework di adozione del cloud computing aiuta le organizzazioni a identificare le problematiche da affrontare prima dell implementazione del cloud, sia nell immediato che a lungo termine, come ad esempio problemi di integrazione e di governance. In un cloud dipartimentale, ad esempio, le organizzazioni devono essere in grado di creare team interfunzionali e di condividere sia gli investimenti che l utilizzo. Un altro requisito importante per l integrazione è la capacità di garantire la virtualizzazione e la disponibilità dei dati. In un cloud aperto, i provider devono essere in grado di soddisfare quanto garantito dai contratti sia per il livello di servizio che per le risorse pattuite. Inoltre, dal punto di vista dell integrazione, devono essere in grado di automatizzare la negoziazione e la riconciliazione di livelli di servizio, prezzi e criteri.

IBM Global Technology Services 11 Creazione di un percorso visivo che porta all adozione del cloud A seconda dei tipi di servizi e dei sottotipi del modello di delivery scelti da un organizzazione, il framework di adozione del cloud computing fornisce uno strumento utilizzabile per creare una roadmap visiva per il cloud. Come illustrato nella Figura 4, i percorsi variano a seconda della strategia IT dell organizzazione, del modello di delivery scelto e del tipo di servizio/i forniti, oltre che di chi presiede la migrazione al modello cloud, se l azienda o l IT. Nelle grandi aziende, quando il cloud è voluto da uno sponsor a livello aziendale, il percorso che porta al cloud inizia con una nuova opportunità di business o da un area critica che, per poter essere affrontata, deve fare affidamento su nuove tecnologie abilitanti. La giustificazione aziendale può essere incentrata sulla riduzione dei costi legati all acquisizione della risorsa, ma è più spesso avallata da un veloce time-to-value e dal conseguimento di un vantaggio competitivo ottenibile nell arco di giorni o settimane, anziché mesi. I tipi di servizi richiesti in genere sono a più alto livello, di norma si tratta di servizi applicativi o di processi di business. Al contrario, nelle grandi imprese in cui il fattore di spinta viene dall IT, il percorso che porta al cloud parte più frequentemente dall esigenza di ottimizzare l infrastruttura per fornire i servizi in maniera più dinamica, oltre che dalla necessità di ridurre le spese in conto capitale sfruttando meglio l infrastruttura esistente. In questo scenario, le implementazioni iniziano con progetti che prevedono un cloud privato, inizialmente a livello di infrastruttura, per poi passare ad un livello più elevato una volta acquisite le competenze basilari. Inoltre, partire con un cloud privato permette all IT di avere l opportunità di conoscere meglio le funzionalità del cloud prima di passare a un cloud pubblico per determinati carichi di lavoro quali ad esempio il Web conferencing o gli ambienti di test. Nelle aziende di medie dimensioni, il percorso che porta al cloud può partire dall esigenza di decongestionare le operazioni IT di base, in modo da ridurre sia le spese in conto capitale sia i costi operativi, nonché il livello e la complessità delle competenze IT necessarie all interno. Questo permetterebbe all organizzazione IT rimasta di concentrarsi sulle soluzioni aziendali, disponendo nel contempo dell elasticità necessaria a fronte di una domanda variabile. Le piccole aziende possono inoltre utilizzare i servizi di business offerti da un provider pubblico per ridurre i requisiti necessari sia in ambito di competenze IT che di competenze di delivery. Riepilogo Nonostante l interesse per il cloud computing sia in forte crescita, potrebbe esserci poca chiarezza su quello che questo rappresenti realmente. Senza un vocabolario comune e un modello di riferimento univoco, le organizzazioni non sono in grado di intavolare una discussione convincente sul cloud computing. Il framework di adozione del cloud computing risolve questo problema fornendo il contesto per una discussione produttiva, oltre che una struttura per la pianificazione, sia a breve che a lungo termine, di un implementazione di successo.

Per saperne di più Per ulteriori informazioni sul cloud computing e sul framework di adozione del cloud computing, contattate il rappresentante IBM o visitate il seguente sito Internet: ibm.com/cloud IBM Italia S.p.A. Circonvallazione Idroscalo 20090 Segrate (MI) Italia La home page di IBM è disponibile all indirizzo ibm.com IBM, il logo IBM e ibm.com sono marchi o marchi registrati della International Business Machines Corporation negli Stati Uniti e/o in altri Paesi. Se, la prima volta che compaiono nella presente pubblicazione, questi e altri termini commerciali IBM sono contrassegnati con un simbolo commerciale ( o ), indicano un marchio registrato negli Stati Uniti o un marchio di fatto di proprietà di IBM all atto della pubblicazione del presente documento. Tali marchi possono anche essere marchi registrati o marchi di fatto in altri Paesi. L elenco aggiornato dei marchi di fabbrica IBM è disponibile nella sezione Copyright and trademark information all indirizzo Web ibm.com/legal/copytrade.shtml Java e tutti i marchi e i logo basati su Java sono marchi di Sun Microsystems, Inc. negli Stati Uniti e/o in altri Paesi. Altri nomi di società, prodotti e servizi potrebbero essere marchi di fabbrica o marchi di servizio di altri. 1 IBM Market Insights, Computing Strategy Research, luglio 2009. 2 Ibidem 3 Diradare le nebbie attorno al cloud computing: fattori di spinta, barriere e riflessioni circa l adozione dei modelli di cloud computing pubblici e privati. IBM, gennaio 2010. ibm.com/ibm/cloud/resources.html#5 Ogni riferimento a prodotti, programmi o servizi di IBM non implica la volontà, da parte di IBM, di rendere tali prodotti, programmi o servizi disponibili in tutti i Paesi in cui IBM opera. Qualunque riferimento a prodotti, programmi o servizi IBM non implica l utilizzo esclusivo di prodotti, programmi o servizi IBM. Prodotti, programmi o servizi funzionalmente equivalenti possono essere utilizzati. Questa pubblicazione è fornita a puro titolo informativo. Le informazioni sono soggette a modifica senza preavviso. Per informazioni aggiornate sui prodotti e i servizi IBM, contattare l ufficio vendite o il rivenditore IBM di zona. IBM non fornisce consulenza in materia legale, contabile o di auditing, né dichiara o garantisce che i propri prodotti e servizi siano conformi alle prescrizioni di legge. È responsabilità del cliente osservare le disposizioni di legge e i regolamenti in materia di mercati finanziari, incluse le normative nazionali. Le immagini potrebbero fare riferimento a modelli di progettazione. Copyright IBM Corporation 2010 Tutti i diritti riservati. Si prega di riciclare CIW03067-ITIT-00