Progetto SEMPLIFICA. (Strumenti E Metodi Per L Interazione tra FIumicino Comune e Aziende). PROMOSSO DA: COFINANZIATO DA: IN COLLABORAZIONE CON

Transcript

1 Progetto SEMPLIFICA (Strumenti E Metodi Per L Interazione tra FIumicino Comune e Aziende). PROMOSSO DA: COFINANZIATO DA: COMUNE DI FIUMICINO IN COLLABORAZIONE CON Workpackage 05 Studio delle nuove infrastrutture cloud computing Redatto da: Masimo D Aniello IBM Verificato da: Massimiliano Bondanini Unindustria Approvato da: Comitato Direttivo Riunione del gg/mm/aaaa 1

2 Progetto SEMPLIFICA (Strumenti E Metodi Per L Interazione tra FIumicino Comune e Aziende). Il Comitato Scientifico: Dott. ssa Daniela Quaranta Leoni Dott. Andrea Gumina Ing. Augusto Coriglioni Dott.ssa Loretta Angelini Dott. Marco Conte Dott. Bruno Francesconi Dott. Sergio Gigli Dott.ssa Francesca Romana Nicastro Dott. Corrado Felici Unindustria (Presidente) Nexttlab Presidente Sezione IT di Unindustria INPS Unioncamere Poste Italiane ARALL SUAP Roma Capitale Unindustria Il Comitato Direttivo: Avv. Massimiliano Bondanini Ing. Vincenzo Bianchini Ing. Massimo D Aniello Dott. Guido Emiliano Doveri Dott. Giuseppe Galli Dott. Andrea Gumina Dott. Antonio Sfameli Unindustria (Presidente) Tecnologie e Comunicazioni IBM Italia Poste Italiane Comune di Fiumicino Nexttlab Ericsson ll Team di Progetto ( per brevità GdP): Ing. Vincenzo Bianchini Avv. Massimiliano Bondanini Da nominare Ing. Massimo D Aniello Ing. Carlo Spinelli Barrile Dott. Claudio Ballanti Dott. Maurizio Falcioni Tecnologie & Comunicazioni; Team leader Unindustria Comune di Fiumicino IBM Italia IBM Italia IBM Italia Poste Italiane 2

3 Dott. Alessandro Saralli Dott.ssa Romina Ciocca Dott. Andrea Gumina Dott. Fuhang Wang Dott. Andrea Eliseo Ing. Carlo Dotti Dott.ssa Alessandra Peduto Dott. Corrado Felici Dott. Marco Galluzzo Dott.ssa Pamela Morasca Dott. Davide Lucchetti Poste Italiane Poste Italiane Nexttlab Nexttlab Nexttlab Tecnologie & Comunicazioni Tecnologie & Comunicazioni Unindustria Unindustria Unindustria Unindustria 3

4 Sommario 1 EXECUTIVE SUMMARY INTRODUZIONE SCOPO DEL DOCUMENTO AUTORI DEL DOCUMENTO LA METODOLOGIA UTILIZZATA I FONDAMENTI DEL CLOUD COMPUTING LE PRINCIPALI CARATTERISTICHE DEL CLOUD I BENEFICI DELL ADOZIONE DEL CLOUD MODELLI DI DELIVERY IN AMBIENTE CLOUD TIPI DI SERVIZI DEL CLOUD ADOZIONE DEL CLOUD COMPUTING E FATTORI DA CONSIDERARE L ADOZIONE DEL CLOUD PER IL SUSI LE ATTUALI ARCHITETTURE DEL SUAP L ARCHITUTTURA PROPOSTA PER IL SUSI INTEGRAZIONE CON SISTEMI ESTERNI UNA ROADMAP PER L ADOZIONE DEL CLOUD NEL SUSI IL VALORE DELL ARCHITETTURA PROPOSTA CONCLUSIONI

5 Indice delle figure Figura 1 La metodologia di analisi... 8 Figura 2 I fattori di adozione del cloud Figura 3 - Il modello cloud provato Figura 4 - SUSI in architettura cloud Figura 5 - Framework dei servizi Figura 6 - Architettura del back-end Figura 7 - Architettura del front-end Figura 8 - Layer architetturali del cloud IBM Cloud Computing Reference Architecture Figura 9 - Dettaglio dei layer architetturali del cloud - IBM Cloud Computing Reference Architecture Figura 10 - La virtualizzazione alla base dei modelli di cloud computing Figura 11 - Le principali caratteristiche del SUAP in architettura cloud

6 1 Executive summary Lo Sportello Unico Servizi alle Imprese (SUSI), proposto dal progetto SEMPLIFICA, ha una valenza di supporto a molteplici servizi, di natura e con processi differenti, e con un elevato livello di integrazione con enti terzi. Questo comporta che le esigenze di business debbano prendere il sopravvento rispetto a quelle più tipicamente legate alla gestione dell IT (tecnologie, infrastrutture e applicazioni) che ne permettono l erogazione. E per queste ragioni che, paradossalmente, è necessario fare un analisi molto più accurata, rispetto ad un qualsiasi progetto IT, per definire quella che possa essere l architettura di riferimento che supporti le esigenze di business, la complessità del sistema, e le dimensioni geografiche su cui opera. Un architettura cloud è, tipicamente, la scelta che viene fatta per questa tipologia di progetti. Nel presente workpackage, il team di lavoro ha quindi analizzato le caratteristiche del SUSI proposto dal progetto SEMPLIFICA, verificato che l architettura cloud avesse tutte le caratteristiche per supportarle, ed infine, proposto un architettura cloud specifica per il SUSI. L estrema eterogeneità di casistiche da integrare, modelli organizzativi da gestire e la dimensione geografica di possibile competenza, hanno consigliato di definire una roadmap di applicazione del cloud per il SUSI, così da rendere il documento flessibile per un suo futuro utilizzo quale riferimento architetturale in uno specifico progetto. 6

7 2 Introduzione 2.1 Scopo del documento Il presente documento fornisce un analisi di fattibilità dell utilizzo dell architettura cloud per l erogazione dei servizi del SUSI. 2.2 Autori del documento Massimo D Aniello (IBM) Chiara Maresia (IBM) Claudio Ballanti (IBM) Il documento è stato inoltre rivisto da: Ing. Vincenzo Bianchini (Tecnologie e Comunicazioni) 2.3 La metodologia utilizzata Il presente documento rappresenta la sintesi del lavoro di analisi fatto dai consulenti IBM, secondo una specifica metodologia, nella figura di seguito illustrata. 7

8 Figura 1 La metodologia di analisi A partire dalle esigenze di business, identificate e definite nei workpackage precedenti (1, 2, 3), e dopo un analisi dello status ad oggi delle applicazioni esistenti, sia da integrare che da realizzare, il team di lavoro ha identificato quelle che sono le Enterprise Capabilities, ovvero le capabilities che il SUSI dovrà essere in grado di mettere in produzione; l analisi delle possibili architetture di business (ad esempio l adozione del portale, descritto nel workpackage 4, e delle architetture IT, hanno permesso poi di definire l architettura, cloud nel progetto SEMPLIFICA, di riferimento; infine, la gap analysis ha permesso di delineare una roadmap di adozione del cloud, atta a definire un percorso di realizzazione di un architettura complessa come quella in esame. 8

9 3 I fondamenti del cloud computing Il cloud computing catalizza l attenzione di molti, ma regna ancora confusione sul reale significato del termine. E doveroso quindi introdurre il lavoro svolto nella identificazione di una architettura ottimale per il SUSI così come descritto nei WorkPackage precedenti- con una definizione di cloud, definizione del National Institute of Standards and Technology:... un modello di service provisioning per consentire l accesso in modalità on-demand ad un insieme di risorse computazionali opportunamente configurabile dall utente, che può essere messo in linea con estrema facilità e altrettanto facilmente riallocato per altre esigenze, con minime esigenze gestionali e di supporto.... Formulare una strategia per l adozione del cloud computing e seguire il giusto percorso di implementazione è di importanza fondamentale. Questo è forse il momento più impegnativo e complesso del processo di adozione di modelli architetturali di tipo cloud. Con una strategia che consenta di assegnare una priorità alle tipologie di workload e di mapparle secondo il modello di delivery ottimale, il cloud computing offre alle Aziende che lo adottano un opportunità straordinaria per aumentare il valore dei servizi offerti ed il ROI. In un mondo sempre più tecnologico, interconnesso e intelligente, il cloud computing rappresenta un modo più efficiente di erogare i servizi, utilizzare le risorse e controllare i costi. Grazie a una strategia che abbracci anche il cloud computing, le Aziende possono migliorare la soddisfazione dei clienti, le Imprese nel nostro caso, attraverso una maggiore capacità di risposta, processi semplificati e una erogazione dei servizi economicamente vantaggiosa. Il cloud computing consente anche di ampliare la gamma dei servizi, delle applicazioni e delle funzionalità che il SUSI è in grado di mettere a disposizione. Un implementazione di successo dell architettura cloud richiede una visione strategica complessiva, unita a un approccio pragmatico ed evolutivo. Di seguito vengono descritti i razionali che hanno portato il team di lavoro a giudicare l architettura cloud proposta per il SUSI come quella che, potenzialmente, garantisce un maggior valore alla soluzione progettuale complessiva, sia in termini di scelte tecnologiche innovative, sia nel ritorno degli investimenti sostenuti. 3.1 Le principali caratteristiche del cloud Il cloud computing rappresenta un fattore innovativo che permette di fare evolvere il SUSI verso una nuova, più semplice e articolata offerta di servizi. Questo rende possibile un diverso rapporto con le Imprese, rendendo questo rapporto più semplice nella sua gestione ed efficace nel suo compimento. Una sintesi di quanto l architettura cloud permette di gestire, in ottica SUSI, viene riportata di seguito: 1. On-demand self-service: uno specifico centro servizi può richiedere, allocare e configurare unilateralmente risorse e/o servizi IT, senza alcuna interazione con i vari service provider. 9

10 2. Broad network access: le risorse e/o i servizi IT sono disponibili ed acceduti tramite rete e meccanismi standard che promuovano l uso di client leggeri (es. cellulari, laptop e PDA). 3. Resource pooling: le risorse IT sono aggregate per pool e virtualizzate per essere rese disponibili ai richiedenti secondo la domanda. 4. Rapid elasticity: le risorse IT a disposizione di un utente possono essere dinamicamente aumentate o diminuite, in modo da apparire illimitate e poter essere richieste in qualsiasi quantità ed in ogni momento. 5. Measured service: i sistemi cloud controllano ed ottimizzano l uso delle risorse IT utilizzando metodi di misurazione a vari livelli di astrazione (es. storage, processing, bandwidth, and active user accounts). L utilizzo delle risorse IT può essere monitorato, controllato e documentato con trasparenza sia per il provider sia per l utente dei servizi IT. I principali fattori di spinta che indirizzano verso l adozione di un modello cloud per il SUSI sono rappresentati nella figura seguente: Riduzione della complessità tecnologica Rapidità nella erogazione dei servizi 1 No No ad ad un un approccio approccio per per singole singole componenti componenti Servizi preconfigurati e modulabili Contenimento dei costi 2 3 E E importante importante una una visione visione completa completa Occorre Occorre avere avere un un approccio approccio sistemico sistemico Semplicità di fruzione Opportunità di crescita e innovazione Figura 2 I fattori di adozione del cloud 3.2 I benefici dell adozione del cloud L adozione di un architettura cloud per il SUSI porta molteplici benefici, sia per il SUSI che per le Imprese che usufruiscono dei servizi così erogati. Efficienza migliore utilizzo delle tecnologie e dei sistemi; accelerazione del processo di aggregazione della domanda; consolidamento dei sistemi applicativi e dell infrastruttura tecnologica; 10

11 miglioramento della produttività nella gestione dei servizi offerti. Agilità vendita/acquisto as-a-service dei servizi offerti; risposta immediata ai fabbisogni degli enti. Innovazione possibilità di beneficiare immediatamente delle innovazioni introdotte e dei benefici tecnologici/economici ad essi relativi. Abbiamo inoltre identificato un percorso di adozione del cloud computing, basato sulle linee guida della IBM Cloud Computing Reference Architecture (publicata dal Cloud Architecture Project of the Open Group), rappresentata di seguito in Figura 8 e Figura 9, e stabilire una roadmap per la sua adozione. Occorre in definitiva: 1. identificare le modalità di gestione dei servizi necessarie per supportare il modello di delivery e il servizio desiderati; 2. determinare i tipi di servizi da rendere disponibili tramite il cloud. Unendo questi due elementi, emerge un disegno di base che permette di esaminare i requisiti e le possibilità per l implementazione del SUSI in architettura cloud. 3.3 Modelli di delivery in ambiente cloud La prima dimensione da considerare per sviluppare una strategia di cloud è il modello di delivery da utilizzare. 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 comunità, che condivide le stesse necessità in termini di servizi. La proprietà delle risorse del cloud risiede all interno della stessa azienda che fornisce e che utilizza i servizi 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. 11

12 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. Per come è proposta la struttura del SUSI proposto dal progetto SEMPLIFICA, il modello di cloud privato è quello che maggiormente risponde alle caratteristiche di community che si intendono realizzare. La dimensione della community può variare, senza però modificare il modello di riferimento, da scala regionale -un unico provider per tutta la regione-, a provinciale -un provider per tutti i comuni di una provincia-, piuttosto che per area geografica, etc. Si può quindi ipotizzare un unico provider per tutti i servizi erogati dal SUSI, che gestisce le risorse IT e il catalogo dei servizi erogati dal SUSI, si interfaccia con gli enti terzi coinvolti nel processo e distribuisce i servizi ai SUSI della community. E a carico del provider il monitoraggio, e la gestione delle risore utilizzate ed i servizi erogati. Enti terzi coinvolti nel processo SUSI Monitor & Manage Services & Resources Datacenter Infrastructure Accesso ai servizi Cloud Administrator Service Catalog, Component Library Publish & Update Components, Service Templates SUSI Figura 3 - Il modello cloud provato 3.4 Tipi di servizi del cloud La seconda dimensione è il tipo di servizio. I tipi di servizi del cloud sono quattro e vengono di seguito definiti: 1. Servizi 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, 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. 12

13 2. Servizi cloud di piattaforma (noti anche come platform as a service, o paas) questi servizi forniscono funzionalità elaborative (infrastruttura) oltre ad uno stack middleware predefinito. I provider possono decidere di offrire una varietà di servizi, configurabili dall utilizzatore a vari livelli. Ne sono esempi il software per database, l accesso al web e i server delle applicazioni. 3. Servizi cloud di tipo applicativo (noti anche come software as a services, o saas) sono servizi consistenti in un applicazione predefinita, ad esempio CRM ed ERP. Gli utilizzatori condividono un unica istanza dell applicazione e vengono impiegate 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. 4. Servizi 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. Lo status attuale dei SUAP, SUE, etc. nel Lazio non permettono di dare oggi a questa dimensione una risposta complessiva ed univoca. L eterogeneità di situazioni con cui il SUSI dovrà interagire necessita di una riflessione molto più analitica delle numerose integrazioni da prevedere. E per questo che la risposta a questa dimensione deve essere data mediante la definizione di una roadmap di adozione del cloud. Una volta che il modello di delivery e il tipo di servizio sono stati identificati, possiamo dedicarci 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. La conoscenza di questi requisiti è utile 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 deve essere svolta. Ciascun carico di lavoro ha caratteristiche peculiari che lo rendono più adatto ad un erogazione di tipo pubblico o privato del cloud, nonché al tipo di servizio specifico. 13

14 3.5 Adozione del cloud computing e fattori da considerare Il cloud computing suscita interesse per la sua capacità di velocizzare l erogazione dei servizi, migliorare la disponibilità dell infrastruttura e al tempo stesso offrire un elasticità che consente di ampliare o contrarre i servizi di pari passo con le variazioni della domanda. E grazie allo sfruttamento delle economie di scala rese possibili da un ambiente cloud, è possibile ottimizzare e rendere più efficienti i servizi erogati; inoltre, possiamo pensare alla definizione di nuove tipologie di servizi. Il cloud computing necessita di un architettura SOA (Service Oriented Architecture), orientata quindi ai servizi ed alla loro integrazione. Passaggio questo importante nella riorganizzazione dei servizi in un ottica di rivisitazione dei processi di business. Facendo riferimento alla Figura 2, possiamo evidenziare come l adozione del cloud porta con sè un valore aggiunto derivante dalla necessaria riorganizzazione dei servizi, quale attività di change management preliminare alla definizione delle architetture dei servizi SUSI da erogare in modalità cloud. Fase che comporta, inevitabilmente, la necessità e lo sforzo- di dover definire una visione unica e completa dei servizi che il SUSI è in grado di erogare. Inoltre, questa attività consente all ecosistema gestito attraverso il SUSI di condividere quel livello di standardizzazione e di ontologia, di cui il progetto SEMPLIFICA si fa promotore. 14

15 4 L adozione del cloud per il SUSI Sulla base delle indicazioni riportate nei precedenti capitoli, la definizione di una architettura di business definita dagli specifici workpackage e dalle esperienze disponibili ad oggi di progetti realizzati in cloud, il team di lavoro ha prodotto un analisi di come il SUSI può trarre vantaggio da questo approccio architetturale, e quali possano essere i benefici ottenibili. Dall analisi fatta emerge la necesità di un intervento per coordinare le attività che intervengono nell espletamento dei procedimenti, al fine di migliorare l efficienza dei servizi e realizzare un livello omogeneo dei servizi su tutto il territorio, di elevata qualità, e in grado di garantire alle imprese: disponibilità in tempo reale di informazioni certe, trasparenti ed uniformi sul territorio regionale relative all attivazione dei procedimenti; possibilità di avviare i procedimenti necessari in tempi ridotti; capacità di monitorare tempi e fasi del procedimento. Da un punto di vista architetturale, emerge la necessità di definire: una struttura tecnologica dedicata alla integrazione applicativa e relativi standard; una struttura operativa per la cooperazione amministrativa; un censimento dei procedimenti e la costruzione di un catalogo con classificazione uniforme; la definizione degli standard relativi ai contenuti; i servizi di assistenza e supporto delle imprese mediante operatori esperti. Alla luce delle considerazioni preliminari emerse, lo studio ha identificato le peculiarità di una architettura cloud che abiliti la necessaria gestione di un SUSI, avente le caratteritiche descritte nei precedenti workpackage. Nel seguito vengono descritte le principali considerazioni emerse, alcune indicazioni per completare un percorso realizzativo di successo, ed il valore che l ecosistema SUSI può trarre dall adozione di questa architettura. 15

16 Risulta evidente come l architettura proposta per il SUSI sia, in parte, anche condizionata dalle architetture con le quali deve interagire; è per questo che il team di lavoro ha svolto un analisi di massima delle architetture dei SUAP ad oggi esistenti nel Lazio, quale riferimento generale per le valutazioni architetturali e di integrazione proposte per il SUSI. Workflow Processi SCIA No SCIA Dominio SUSI Knowledge base Catalogo dei servizi Portale WEB Back Office Dominio Attore 1 Browser web estrazione o inserimento dati Dominio Attore n Attori base Applicazioni interne esistenti Processo 1 Processo 2 Intrane t PEC PEC Altri Attori Front office Impresa Documentazione cartacea Digitalizzazione Figura 4 - SUSI in architettura cloud 4.1 Le attuali architetture del SUAP Dal punto di vista organizzativo, la situazione attuale a livello regionale è eterogenea. Esistono infatti Comuni che si sono attivati autonomamente, altri che fanno da capofila ed erogano il servizio per sé e per altri comuni del proprio comprensorio, in una o più sedi accentrate, e altre situazioni in cui i Comuni si sono consorziati per attivare un SUAP unitario cui delegare alcuni compiti (ad es. la formazione degli operatori, le convenzioni con enti terzi, etc.), pur rimanendo a livello comunale la funzione di front-end verso l utenza. In ottica analitica possiamo individuare tre macro-modelli organizzativi: gestione singola. Il Comune svolge autonomamente le funzioni ammininistrative, informative e promozionali del SUAP; gestione associata accentrata. Le funzioni amministrative e gestionali del procedimento unico vengono accentrate a livello di comprensorio, e presso ciascun Comune opera un ufficio che svolge da terminale periferico, con compiti limitati; 16

17 gestione associata decentrata. Il sistema è caratterizzato da un elevato grado di autonomia da parte di ciascun Comune associato. La gestione del procedimento viene esercitata da ciascuno sportello comunale, mentre il servizio comprensoriale cura interessi di carattere più generale, in particolare la promozione, l informazione e la definizione di intese con le amministrazioni esterne. Altrettanto eterogenea è la situazione per ciò che concerne il software utilizzato, come si è dedotto dalla documentazione riportata negli altri workpackage. Da chi ha già messo a punto soluzioni complesse per la gestione del SUAP e dei rapporti con l utenza su scala comprensoriale, a chi si è dotato di software per la gestione interna su scala comunale o comprensoriale, fino a chi non ha ancora attivato procedure informatiche o telematiche. Da questo quadro si evince la necesità di avere un modello architetturale unitario nella sua visione e condiviso. 4.2 L archituttura proposta per il SUSI Il modello di SUSI, così come proposto dal progetto SEMPLIFICA, permette di offrire servizi di tipo: amministrativo, relativi cioè al complesso delle autorizzazioni; informativo, promozionale, consulenziale, poiché raccoglie e diffonde le informazioni sulle normative in vigore riguardanti lo svolgimento di attività economiche, le modalità di accesso alle agevolazioni a disposizione, la struttura produttiva del territorio comunale e della Regione di appartenenza; che devono necessariamente essere riflessi nell architettura proposta. In base a tale schema, l architettura di riferimento che viene proposta si compone di due elementi principali: un front office, che si occupa della gestione dell attività informativa relativa alla funzione autorizzatoria e alla funzione promozionale, a contatto, diretto o mediato, con l impresa; un back office, che si occupa di tutte le attività legate alla gestione del procedimento unico autorizzatorio e alla pianificazione e promozione del territorio, senza diretto contatto con l impresa. La suddivisione del modello in front office e back office, è finalizzata alla migliore ripartizione dei compiti, poiché i due elementi del modello operano in modo complementare. 17

18 Tutti questi elementi portano ad identificare in un modello di delivery di tipo cloud privato il più idoneo alla gestione del SUSI. Con questo modello di delivery, possiamo prevedere una roadmap di adozione che prevede una scalabilità che parte dal livello comunale, passando per quello provinciale/di area e finire con un livello di scalabilità a livello Regionale. Dal punto di vista architetturale di alto livello, i servizi di una infrastruttura dinamica così definita possono essere logicamente suddivisi in strati, come indicato nella figura che segue. Figura 5 - Framework dei servizi Lo strato fisico, contenente i sistemi hardware, viene virtualizzato allo scopo di fornire una piattaforma flessibile, adattabile e in grado di migliorare l utilizzo complessivo delle risorse. I punti di forza di una infrastruttura dinamica sono i due strati sovrastanti: lo strato di virtualizzazione e lo strato di gestione. La combinazione di questi due strati assicura che le risorse, in un data center, siano gestite in modo efficiente e possano essere sottratte, riconfigurate e rilasciate velocemente per far fronte a nuove esigenze. Inoltre, una infrastruttura di tipo dinamico deve essere disegnata e progettata per essere in grado di gestire carichi di lavoro composti da un misto di possibili casi d uso. Questo comporta la necessità di adozione di un Enterprise Service Bus e un modello SOA (Service Oriented Architecture) per permetta di scomporre in servizi atomici il modello di business erogato e dare la possibilità a chi eroga il servizio di creare un workflow completo sulla base dei servizi atomici disponibili. La figura seguente descrive le caratteristiche tecnologiche dell Enterprise Service Bus. 18

19 Figura 6 - Architettura del back-end Per il front-end una possibile soluzione è rappresenta dalla figura seguente: Figura 7 - Architettura del front-end Da un punto di vista logico, la realizzazione del SUSI in architettura cloud porta a definire dei layer specifici per ciascun servizio di cui il SUSI cloud deve adottare. Nella figura seguente viene data una rappresentazione grafica della Reference Architecture di IBM: 19

20 API User Interface Progetto Semplifica Cloud Service Consumer Cloud Service Provider Cloud Service Developer Business-Process-as-a-Service Cloud Service Integration Tools Cloud Services Software-as-a-Service Platform-as-a-Service Infrastructure-as-a-Service (Virtualized) Infrastructure Server, Storage, Network, Facilities Infrastructure for hosting Cloud Services and Common Cloud Platform Service Development Tools Consumer In-house IT Common Cloud Platform BSS Business Support Services Business-level functionality for management of Cloud Services OSS Operational Support Services Operational-level functionality for management of Cloud Services Security & Resiliency Figura 8 - Layer architetturali del cloud IBM Cloud Computing Reference Architecture Questa rappresentazione, tratta dalla IBM Cloud Computing Reference Architecture, mette bene in evidenza, nel box centrale, tutte le caratteristiche infrastrutturali e applicative, di cui il SUSI cloud dovrà disporre. Una rappresentazione di maggior dettaglio è riportata nella figura seguente, dove viene anche messa in evidenza l importanza del layer di governance: 20

21 Infrastructure Mgmt Interfaces Platform Mgmt Interfaces Software Mgmt Interfaces BP Mgmt Interfaces Progetto Semplifica Cloud Service Consumer Cloud Service Provider Cloud Service Creator Consumer End user Cloud Service Integration Tools Cloud Services Existing & 3 rd party services, Partner Ecosystems API BPaaS Common Cloud Platform OSS Operational Support Services Service Delivery Catalog Service Manager BSS Business Support Services Customer Account Service Offering Catalog Business Manager Service Offering Service Component Developer Service Composer Service Integrator Consumer Business Manager Consumer Inhouse IT Business Processes Applications Middleware Infrastructure Service Consumer Administrator API API API SaaS PaaS IaaS Service Consumer Portal & API Deployment Architect Service Automation Service Request Provisioning Monitoring & Event Change & Configuration Incident & Problem IT Asset & License Transition Manager Infrastructure Image Lifecycle IT Service Level Capacity & Performance Platform & Virtualization Operations Manager Contracts & Agreement Subscription Pricing Entitlement Metering Rating Billing Clearing & Settlement Service Provider Portal & API Service Request Accounts Payable Security & Risk Manager Order Accounts Receivable Service Development Portal & API Customer Care Offering Manager Service Creation Tools Service Development Tools Service Runtime Development Tools Software Development Tools Image Creation Tools Security, Resiliency, Performance & Consumability Governance 2011 IBM Corporation Figura 9 - Dettaglio dei layer architetturali del cloud - IBM Cloud Computing Reference Architecture Alla base di questo modello per l adozione del cloud vi è la governance, che riveste un ruolo chiave sia nelle scelte preliminari all adozione di questo specifico modello che, in fase di erogazione dei servizi, nella gestione quotidiana dei servizi erogati e nella strategia di sviluppo/innovazione dei servizi Integrazione con sistemi esterni L architettura cloud proposta permette anche una gestione delle necessarie integrazioni con i sistemi di enti esterni, presenti nel processo (quali pagamenti on-line, Posta Elettronica Certificata, etc.) che permettono una gestione più efficiente del processo. 4.3 Una roadmap per l adozione del cloud nel SUSI L adozione dell architettura cloud in un sistema complesso quale quello del SUSI deve seguire un percorso di analisi, e di scelte strategiche, molto rigoroso e basato su metodologie che permettano di governarne il percorso di adozione, monitorarne i progressi e, soprattutto, gestire le attività più critiche che, inevitabilmente, emergono in progetti di tali dimensioni e complessità. 21

22 E per questi motivi che il team di lavoro ha pensato ad una roadmap di adozione del cloud che si compone di 4 passi fondamentali: 1. una fase di consolidamento degli ambienti e dei servizi; 2. la creazione di un pool virtuale di risorse (siano esse tecnologiche che di servizi); 3. una fase di virtualizzazione; 4. l adozione completa dell architettura cloud per il SUSI. Di seguito vengono riportati i principali elementi di valore di ciascuna fase della roadmap proposta. Figura 10 - La virtualizzazione alla base dei modelli di cloud computing L adozione della roadmap proposta permette, inoltre, di ottenere il maggior valore dalle principali caratteristiche del SUSI in architettura cloud: 22

23 Figura 11 - Le principali caratteristiche del SUAP in architettura cloud. La roadmap proposta è l elemento di base per l applicazione del SUSI in architettura cloud e potrà essere utilizzata come canovaccio nella definizione del singolo progetto realizzativo. 4.4 Il valore dell architettura proposta L architettura proposta permette di progettare un modello del SUSI in grado di garantire il soddisfacimento degli obiettivi di: Efficienza migliore utilizzo delle tecnologie e dei sistemi: completa integrabilità ed interoperabilità con i sistemi informativi dei vari SUAP/SUE; accelerazione del processo di aggregazione della domanda e del consolidamento dei sistemi: grazie alla standardizzazione dei processi, delle ontologie e delle informazioni richieste nella modulistica, è possibile garantire un servizio nel ripetto della riduzione del tempo e dell impegno richiesto da parte dell utente; miglioramento della produttività nella gestione dei servizi offerti: il servizio offerto, standardizzato ed ottimizzato può seguire un iter più veloce e minimizza i passaggi da gestire. Agilità 23