Cloud Enablement Kit —Il nostro piccolo contributo

Nel mese di marzo e di aprile abbiamo avuto la fortuna di partecipare alla raccolta degli elementi necessari alla realizzazione del Cloud Enablement Kit (CEK), realizzata dal Teamdigitale (TD) in collaborazione con Thoughtworks (TW).

TW (costituito da un team giovane di persone con elevate skill ed esperienze associate al cambiamento e alla trasformazione digitale oltre che con esperienza internazionale) aveva come deliverable (scopo) datogli da Agid di collaborare con alcune pubbliche amministrazioni (come ad esempio la nostra, il comune di Torino, regione Emilia-Romagna/Lepida, comune di Crema, Comune di Cremona, Corte dei Conti, Ministero dei Beni Culturali) per arrivare alla stesura del CEP (Cloud Enablement Program) e del CEK.

Questo per seguire l’approccio feedback-driven, basato sul coinvolgimento diretto degli utenti finali (user-centered) per la validazione in itinere di quanto si stava definendo, è stato proposto da TW in sede di inception, come loro approccio abituale alla gestione di questo tipo di problematiche. Team Digitale ha pienamente supportato il loro approccio e li ha aiutati a trovare gli interlocutori più adatti

Il percorso per raggiungere l’obiettivo è stato costituito da un assessment, è stato pragmaticamente realizzato mediante 3 workshop di circa un’ora l’uno, alcuni in presenza, altri in webinar.

Il tutto si è sviluppato seguendo alcuni principi.

Il primo principio utilizzato è stato quello della collaborazione e dell’uso di metodologie che la supportino, quindi non è stata una mera raccolta di informazioni bensì in ogni workshop c’era un confronto sulle possibili strade da attuare, valutando approcci di causa effetto sulle soluzioni e sulle proposte che venivano avanzate e condivise.

Il secondo principio utilizzato è stato quello della trasparenza sul processo in modo da fare un lavoro che fosse congiunto e non una semplice raccolta di informazioni elaborate poi in “una scatola nera” esterna alla PA, mostrando alla PA sono input e output. Il confronto è stato continuo e proseguiva anche tra un workshop e l’altro con strumenti (email, slack, chat, gdrive) continuativamente (continuous improvement e continuous delivery).

Tra gli obiettivi più importanti ne segnaliamo due: l’outcome (risultato effettivo, efficace, efficiente) degli workshop doveva essere un percorso concreto di migrazione di un servizio che fosse immediatamente attuabile dalla pubblica amministrazione, quindi realizzato su un caso concreto.

Il secondo obiettivo è stato quello di realizzare un canale di comunicazione tra gruppo di lavoro e PA che permettesse feedback continui e quindi di lavorare a piccoli passi (think big start small) che mediante retroazione potevano essere rivisti oppure consolidati per aggiungere step ad un percorso virtuoso di realizzazione del deliverable finale.

Gli workshop sono stati così suddivisi: nel primo veniva effettuata una mappatura non necessariamente completa (anche qui il concetto di completezza non necessaria al primo passo, perchè questo spesso frena la partenza, per evitare il concetto di “analysis paralysis”) di tutti i servizi erogati dall’ente, individuando principalmente quelli che potevano costituire un’opportunità di migrazione in Cloud.

Inizialmente i criteri di prioritizzazione per individuare il primo servizio da migrare in Cloud erano: l’alta complessità tecnologica, l’impatto del servizio, le dipendenze, l’alto beneficio nel cloud. Una volta classificati secondo questi criteri i servizi, si capiva quale scegliere.

Grazie ai feedback si è capito che questo approccio portava ad un’analisi completa di tutti i servizi individuati. Si è quindi cambiato il percorso trasformandolo:

si parte da un servizio ad alta opportunità ovvero per cui ci possono essere elementi molto migliorativi nel migrare nel cloud

successivamente si passa ai servizi che sono semplici da migrare nel cloud,

quindi ai servizi per cui c’è il minimo rischio nella migrazione,

e infine agli altri.

In tale modo non è necessaria una valutazione dei servizi al primo step (opportunità) se non di alto livello, senza doversi addentrare in ragionamenti relativi ai cittadini che ne fruiscono, all’architettura tecnica, alle dipendenze tecnologiche e non.

In tale modo, inoltre, si costituisce un percorso in cui progressivamente si vanno ad acquisire dei successi migrando piano piano servizi, si acquisisce know-how associato al cloud, si creano casi di rilievo e funzionanti che aiutano ad allargare la confidenza con cui si affronta il tema della migrazione e aiutano ad ampliare la zona di comfort di queste attività (fail-safe zone).

Individuati quindi nel primo workshop due o tre servizi da analizzare, si è nel secondo workshop entrati più in verticale per coglierne gli aspetti caratteristici e le complessità, in buona parte tecniche, ma anche relative agli stakeholder (figure coinvolte) e gli aspetti misurabili..

Si è partiti con una scheda molto schematica divisa in tre parti: informazioni generali, scheda tecnica, impatto applicativo.

Ognuna di queste sezioni era caratterizzata da sottopunti a cui si poteva rispondere in maniera abbastanza semplice, tipicamente quasi binaria oppure al massimo con una multi choices (scelta multipla). L’approccio è stato efficace e nell’attuarlo in pratica si è capito che era ulteriormente migliorabile. E’ stato molto importante tenere come obiettivo il CEK (deliverable) e capire che cambiare questa parte migliorandola era un successo a livello sistemico (CEK, ovvero ottimo globale) anche se poteva sembrare un passo indietro dal punto di vista delle condizioni maturare per questa parte (ottimo locale).

Grazie alla condivisione, al feedback continuo, e alla capacità di mettersi in discussione, si è deciso di sostituire questo tipo di scheda con una scheda più articolata che permettesse di individuare non solo in maniera binaria, ma anche in maniera descrittiva, gli aspetti positivi o le criticità associate alla migrazione della singola applicazione, permettendo una descrizione più articolata.

Sono stati aggiunti anche degli aspetti associati al monitoraggio del funzionamento effettivo della singola applicazione e non solo alla percezione di una figura tecnica del suo funzionamento, in modo da avere elementi concreti che permettano di capire quanto l’applicazione usia tilizzata, se ha dei picchi durante l’anno, se ha delle criticità specifiche derivanti dall’integrazione con altre applicazioni o derivante dai dati in essa contenuti ad esempio per privacy and Security.

Si sono anche analizzati gli stakeholder (le figure coinvolte) che spaziano dai cittadini, ai funzionari comunali, alle figure tecniche. Interessante è stato notare come lo stakeholder dovrebbe cercare di avere un nome e cognome, perchè è la singola persona con le sue peculiarità che può dare un feedback preciso del funzionamento del cambiamento effettuato. E’ chiaro che questo approccio non vale per l’ecosistema cittadini ma può essere declinato in fasce (es.nel caso dei cittadini può essere utile individuare un campione rappresentativo corrispondere al servizio che si vuole erogare).

In tutte queste analisi si sono tenuti in mente i principi: cloud first, cittadino first, interoperability first, security by design, privacy by design.

Nella seconda parte del workshop si è valutata la strategia migliore di migrazione della specifica applicazione, che poteva variare secondo sei metodologie.

La prima è retire ovvero si ritira l’applicazione e la si elimina perché non più utile e perché i suoi dati non sono necessari. Nel caso i dati siano ancora necessari in sola lettura e per una questione di consultazione sporadica in futuro, può essere prevista una migrazione in Cloud dei soli dati.

Retain invece è la strategia che viene utilizzata quando non si può eliminare l’applicazione eppure non la si ritiene adatta al cloud. Nel tempo dovrebbe portare a una strategia di repurchase o perlomeno di rehost.

C’è poi la strategia rehost che vuol dire prendere l’applicazione che esattamente com’è e spostarla nel cloud. (ad esempio prendendo la macchina virtuale su cui è ospitata e mettendola nel cloud).

La quarta è la strategia re-platform che permette di prendere l’applicazione, scomportla nei suoi componenti principali (es. database e server) e poi portarla nel cloud sfruttando le caratteristiche peculiari di cloud. (ad esempio scomporla nella parte applicazione e parte database e spostando l’applicazione con un rehost nel cloud, magari utilizzare un servizio di database nativo del cloud per la parte di re-platform del database).

Infine c’è la strategia re-architect che prevede un redesign completo dell’architettura dell’applicazione. Questo può essere fatto in grossi enti con gruppi di sviluppo. Nei piccoli enti, l’obiettivo massimo che si può raggiungere è un tentativo di influenzare su particolari caratteristiche il fornitore del singolo prodotto.

È chiaro che se il mercato della PA dovesse cominciare a chiedere in massa determinate caratteristiche associate alle applicazioni, può influenzare come vengono realizzati i prodotti in modo da corrispondere nelle gare a queste caratteristiche. È chiaramente un processo non breve ma che se innescato può portare nel medio termine a grossi risultati.

Il rehost tipicamente prevede di acquistare un servizio di tipo IAAS (infrastructure as a service). Il repurchase dovrebbe portare a un servizio di tipo SAAS (software as a service). il re-platform è tipicamente un PAAS (platform as a service) o ibrida IAAS-PAAS, mentre il re-architect dovrebbe portare alla conclusione dello sviluppo a un servizio di tipo SAAS.

Come da legislazione tutti gli acquisti della PA dovrebbero per IAAS, PAAS, SAAS vanno acquisti dal 1 Aprile 2019 mediante marketplace. Quindi tutte le strategie elencate, a meno di retain e il retire, vanno realizzate progressivamente e mediante il marketplace della pubblica amministrazione.

Individuata quindi nel primo workshop la metodologia per raccogliere le applicazioni da analizzare più in dettaglio, cosa che è stata fatta nel secondo workshop dove si è entrati più in verticale su caratteristiche tecniche ed effettivo utilizzo, per poi decidere che tipo di strategia utilizzare per la migrazione cloud, nel terzo workshop si è passati all’analisi delle competenze necessarie ad effettuare una migrazione al cloud, visto che il cloud costituisce un nuovo paradigma.

Mentre la maggior parte delle tecnologie precedenti poteva prevedere un approccio di acquisizione di competenze mediante un corso o una formazione e quindi utilizzo delle competenze, il Cloud comporta delle competenze molto più estese è molto più trasversali. Il fatto inoltre che sia in continua evoluzione porta alle necessità di acquisire continuamente e nuove competenze sui diversi servizi resi disponibili

È chiaro quindi che l’approccio del vecchio system administrator (conoscitore approfondito della tecnologia) non basta più, serve un team che collabori nella realizzazione del processo di definizione e realizzazione della migrazione al cloud, composto non solo dal system administrator, ma anche da tutte le figure (stakeholder) che possono partecipare e contribuire alla comprensione di come migrare l’applicazione al cloud. Queste possono contemporaneamente efficientare i processi che coinvolgono questa migrazione e anche analizzare i dati che sono coinvolti, oltre a dare feedback immediati sui piccolo step che vengono portati avanti, riuscendo a migliorare progressivamente il lavoro che si fa.

Ogni tipo di strategia scelta (es. rehost o purchase), richiederà anche diversi tipi di competenze tecnologiche, di ambito specifico dell’applicazione o di dominio che vanno mappate e considerate. Per farlo si può usare uno spider chart.La mappatura delle competenze disponibili confrontandole con quelle necessarie migliora la consapevolezza degli sforzi necessari al cambiamento secondo la strategia scelta.

Infine, sempre nel terzo workshop, si sono valutate le metriche e gli indicatori da cui si posso misurare i risultati del passaggio.

La misurazione dei risultati è un passaggio fondamentale, prima di tutto da un punto di vista culturale perché non è un aspetto che tipicamente viene valutato nelle pubbliche amministrazioni, secondo perché è fondamentale per avere un feedback (misurare è avere feedback, fare lesson learning o postmortem) di quanto si è fatto.

Il misurare quanto fatto aiuta a migliorare le successive migrazioni e a raccogliere gli effettivi impatti benefici (e non) sulla realtà della pubblica amministrazione sui servizi erogati.

Gli indicatori possono essere di due tipi:

possono essere di risultato, ovvero esprimere l’esito immediato del programma di abilitazione al cloud,

oppure di impatto, ovvero possono spiegare ad esempio quanto si risparmia sui costi oppure il miglioramento delle attività operative della PA

Concludendo, grazie a questi workshop e grazie al lavoro di TD e TW (che ha saputo coinvolgerci nell’attività e utilizzare un approccio molto discreto e umile di comprensione e di dialogo prima che di miglioramento, cosa che pochi fanno quando si approcciano alla PA), ci è stato permesso dare il nostro contributo alla stesura del Cloud Enablement Kit. Il CEK non si esaurisce a quanto in breve presentato, ma contiene molto molto altro per approfondire e mettere subito a terra il processo di migrazione al cloud, oltre che indicazioni e linee guida per come realizzarlo, anche mediante il supporto dei Centri di Competenza.

Nella speranza che il CEK venga pubblicato prima possibile, abbiamo voluto effettuare questo piccolo “spoiler” in modo da cominciare a diffondere quanto imparato durante il percorso fatto condividendo questa esperienza che ci ha permesso un cambio culturale e di approccio al tema che speriamo il CEK possa permette a molte altre pubbliche amministrazioni come lo siamo noi.