Tutti a parlare di cloud nella Pubblica Amministrazione. Agilità, scalabilità, innovazione, e ormai anche AI. Basta migrare, si dice, e il comune entra in una nuova era digitale.
Poi però succede una cosa curiosa. IDC, uno dei centri di ricerca più autorevoli al mondo su infrastrutture IT, osserva da tempo un fenomeno opposto: aziende che dopo aver migrato in cloud pubblico riportano workload indietro, verso l’on premise o verso ambienti gestiti. Lo chiamano cloud repatriation, ed è entrato stabilmente nell’agenda dei CIO.
Non è un rifiuto del cloud. È il sintomo di qualcos’altro.
Indice degli argomenti
Il sintomo che IDC osserva
Negli approfondimenti IDC sulle lezioni apprese dalle migrazioni cloud, il repatriation emerge quasi sempre per lo stesso motivo: una migrazione infrastrutturale non accompagnata da un lavoro reale sull’architettura applicativa.
Si sposta il software così com’è. Stessa logica, stesso accoppiamento rigido tra i moduli, stessa incapacità di scalare in modo indipendente le singole componenti. Cambia solo dove gira la macchina virtuale.
Il risultato, secondo IDC, è prevedibile: senza refactoring, prima o dopo la migrazione, il cloud smette di essere una leva di agilità e diventa semplicemente un fornitore diverso per lo stesso problema.
È una diagnosi che arriva dal mondo enterprise privato. Ma per chi lavora con i comuni italiani suona incredibilmente familiare.
Se a questo sommiamo la sovranità del dato e il rischio di sorprese anche dai vendor USA causa governo USA, capiamo come il fenomeno sia multidimensionale.
Migrare non è modernizzare
C’è una differenza tecnica netta tra spostare un applicativo in cloud e modernizzarlo, ed è una differenza che nei capitolati di gara della PA viene spesso persa per strada.
Il lift and shift, cioè prendere il software esistente e farlo girare su un’infrastruttura cloud senza toccarne il codice, è veloce, costa poco nell’immediato, e produce un powerpoint di progetto molto convincente. Il refactoring, cioè riscrivere l’architettura per renderla nativa cloud, modulare, interoperabile, è lento, costa di più subito, e richiede competenze che spesso il fornitore non ha interesse a mettere in campo.
Indovinate quale delle due strade viene scelta nella maggior parte dei casi, per motivi economici, tecnici o di mancanza di competenze.
Il problema è che senza bonifica strutturale il comune finisce per pagare costi operativi più alti per far girare lo stesso software rigido e ridondante di prima. Il canone cloud si somma ai limiti architetturali che il cloud avrebbe dovuto risolvere. Il risultato netto vanifica gran parte del ritorno atteso dalla migrazione.
Cosa ottengono davvero i comuni dal cloud
Per essere onesti fino in fondo, qualcosa i comuni lo ottengono davvero. Backup gestito, disaster recovery, aggiornamenti applicati dal fornitore senza dover coinvolgere l’ufficio IT interno, spesso composto da una o due persone che si occupano di tutto, dalla rete ai PC ai permessi di accesso, quando va bene. Quando va male, tirano un sospiro di sollievo l’ufficio tecnico o la ragioneria, che prima facevano anche l’IT.
Sono vantaggi reali, non vanno sminuiti. Un comune che prima teneva il gestionale su un server in uno sgabuzzino, senza backup verificato e senza piano di continuità, oggi sta oggettivamente meglio.
Ma qui si ferma quasi sempre l’elenco. E il punto non è quello che il cloud offre. È quello che il comune non riesce a prendere, perché l’applicativo che ci gira sopra non è suo.
Sono ancora i miei dati?
Ecco la domanda che quasi nessun capitolato si pone esplicitamente: se l’applicativo è del fornitore, i dati come vi si accede?
Non è una domanda retorica. Se un comune vuole cambiare software house, spesso deve chiedere l’esportazione dei propri dati al fornitore uscente, secondo tempi, formati e condizioni che il fornitore stesso decide. In alcuni casi l’esportazione è prevista in contratto in formati aperti e immediatamente riutilizzabili. In molti altri, è un file grezzo, incompleto, o disponibile solo dopo settimane di solleciti. In altri diventa una telefonata dal commerciale, con un prezzo migliorativo che blocca lo spostamento.
Se per accedere ai propri dati un ente deve passare da un intermediario che ha ogni interesse a rendere l’operazione lenta e costosa, quei dati sono ancora davvero suoi? Il possesso formale, quello scritto nei considerando del contratto, e la disponibilità effettiva, quella che permette di usarli quando servono, sono due cose diverse. E nella PA italiana la seconda viene trattata come un dettaglio tecnico, non come un requisito.
API e raggiungibilità del dato
Qui si arriva al punto che più di ogni altro rende evidente il paradosso del cloud senza refactoring: i vantaggi tecnologici che il cloud promette restano inaccessibili se il dato non è raggiungibile tramite API aperte e documentate.
Un comune vorrebbe collegare i propri dati a Claude, a ChatGPT, a uno strumento di analisi, per automatizzare una pratica, per rispondere più in fretta a una richiesta di accesso civico, per incrociare informazioni tra uffici diversi. Sulla carta è esattamente ciò che il cloud dovrebbe abilitare: interoperabilità, integrazione, nuovi strumenti che si agganciano ai dati esistenti senza dover riscrivere tutto da capo.
Nella pratica, quell’aggancio richiede un’API. E se l’applicativo non ne espone una, o ne espone una chiusa, proprietaria, accessibile solo a pagamento e solo per le integrazioni che il fornitore ha deciso di supportare, quella promessa resta lettera morta. Il dato esiste, gira su server performanti, è pure backuppato bene. Ma è irraggiungibile per chiunque non sia il fornitore stesso.
La raggiungibilità del dato, non la sua semplice esistenza, è la vera misura di quanto un comune abbia davvero modernizzato qualcosa. Un dato senza API è un dato prigioniero, anche se vive su un’infrastruttura all’avanguardia. È l’esatto contrario di quello che ci si aspetterebbe da una migrazione cloud fatta bene: il cloud dovrebbe moltiplicare i punti di accesso ai dati, non restringerli a uno solo, quello del fornitore. Il comune ha cambiato armadio, non ha aperto la porta.
E se domani le interfacce umane sparissero e parlassimo solo di interfacce AI, come farebbe un’AI ad accedere a dei dati che sono raggiungibili solo da interfacce umane?
Il paradosso dei vantaggi mancati
Quindi, quali vantaggi del cloud un comune non può davvero usare, se l’applicativo e i dati alla fine restano del fornitore e non suo?
Non può scegliere liberamente lo strumento di AI da collegare ai propri dati, perché l’accesso passa da un’API che il fornitore controlla, quando esiste. Non può portare i dati su un altro ambiente di analisi senza un’estrazione negoziata. Non può far parlare due applicativi di fornitori diversi tra loro, se nessuno dei due espone interfacce compatibili. In sostanza, non può fare quasi nessuna delle cose che rendono il cloud interessante oltre al semplice hosting.
Quello che resta è un affitto di infrastruttura più affidabile di un server in cantina. Utile, ma lontanissimo dalla promessa di trasformazione digitale che accompagna ogni bando.
Se lo facciamo per Google, perché non per gli applicativi PA
C’è un paragone che aiuta a mettere a fuoco quanto la questione sia sottovalutata. Molte organizzazioni, pubbliche e private, fanno oggi un backup indipendente della propria suite Google Workspace o Microsoft 365, anche se questi servizi girano su infrastrutture SaaS gestite da colossi con SLA solidissimi. Il ragionamento è semplice: non si sa mai cosa può succedere, un errore umano, una cancellazione accidentale, un problema di account, una nuova politica governativa: è meglio avere una copia dei propri dati fuori dal perimetro del fornitore.
Se applichiamo questa cautela a Google, che ha risorse e affidabilità difficilmente eguagliabili, perché non la applichiamo agli applicativi gestionali ospitati dai fornitori della PA, spesso realtà molto più piccole, con continuità aziendale meno garantita e minore trasparenza sui processi interni?
Un comune dovrebbe poter avere una copia autonoma, in formato aperto, dei propri dati anagrafici, contabili, edilizi, indipendentemente dal fornitore che oggi gestisce l’applicativo. Non per sfiducia verso quel fornitore specifico, ma per lo stesso principio prudenziale che si applica a chiunque altro.
Cosa si può fare
La buona notizia è che si tratta in gran parte di un problema contrattuale e organizzativo, non tecnologico. Le soluzioni esistono già, vanno solo pretese.
Primo, l’esportabilità dei dati in formati aperti e documentati va scritta nel contratto fin dall’inizio, con tempi certi e senza costi aggiuntivi legati al cambio di fornitore. È una clausola di libertà, non un dettaglio tecnico.
Secondo, la disponibilità di API documentate per l’accesso ai dati va inserita tra i requisiti minimi di gara, non lasciata alla buona volontà del fornitore. Un applicativo senza API aperte oggi è, di fatto, un applicativo che nega al comune l’uso di qualsiasi strumento di AI o di analisi esterno.
Terzo, il backup dei dati applicativi va reso indipendente dal fornitore che eroga il servizio, con lo stesso approccio già adottato per le suite di produttività. Un ente che possiede una copia autonoma dei propri dati negozia da una posizione diversa, sempre.
Quarto, e forse più importante, il refactoring applicativo va trattato come condizione della migrazione, non come sua eventuale conseguenza futura. Un ente che stipula un contratto cloud pluriennale senza chiedere conto dell’architettura sottostante sta comprando, quasi sempre, lo stesso problema di prima con una fattura diversa.
Una domanda prima di rinnovare
La prossima volta che un RTD si trova davanti al rinnovo di un contratto cloud, prima di firmare vale la pena farsi una domanda semplice: se domani dovessi cambiare fornitore, quanto tempo mi servirebbe per avere i miei dati, in un formato che posso davvero usare, tramite quali API?
Se la risposta non è immediata, o dipende dalla buona volontà di chi sta dall’altra parte del contratto, il comune non ha ancora fatto il salto che il cloud promette. Ha solo cambiato indirizzo al proprio problema.
Partecipa alla community