Oggi le organizzazioni che vogliono intraprendere un percorso di trasformazione digitale devono essere consapevoli delle sfide da superare: se da un lato i vantaggi sono ben noti, dall’altro gli ostacoli per raggiungere il successo sono spesso complessi e di ampia portata. Se si guarda inoltre al settore pubblico, va tenuta in considerazione la presenza di applicazioni legacy che aggiungono ulteriori livelli di complessità al processo.
PA digitale: buone pratiche delle Regioni Ue che l’Italia dovrebbe imitare
Il divario tecnico della PA
Non solo: la PA deve confrontarsi con un divario tecnico che la posiziona in molti casi in ritardo rispetto al Settore Privato. Negli anni, tale divario è aumentato in modo sensibile per diverse ragioni: per esempio, i vincoli in termini di budget, la mancanza di risorse e i tempi lunghi di approvvigionamento hanno rallentato il processo di Digital Transformation, portando le Amministrazioni a rimandare progetti di modernizzazione complessi e a lungo termine in favore di altri più semplici, ma che potessero essere implementati rapidamente dando riscontri immediati.
Inoltre, le piattaforme legacy su cui si basano e operano molti sistemi della PA sono state oggetto di importanti personalizzazioni e sviluppi ad hoc nel corso degli anni: spesso, però, tali piattaforme supportano processi mission-critical ed è quindi difficile che le Amministrazioni approvino i tempi di inattività necessari a implementare i miglioramenti tecnologici. A questo si deve poi aggiungere il fatto che la migrazione verso piattaforme nuove e più moderne può essere difficile e richiedere quindi molto tempo per essere completata.
Spesso non è semplice individuare ciò che serve per affrontare il divario tecnico e c’è la tendenza a concentrarsi su aspetti e processi non fondamentali. Di conseguenza, il divario rischia di aumentare, riducendo la produttività, inibendo l’innovazione e impedendo l’evoluzione dei servizi pubblici stessi a causa della mancanza di agilità e flessibilità.
I servizi necessari per raggiungere gli obiettivi prefissati
Per affrontare il problema, il primo passo da compiere è valutare e comprendere quali sono i servizi necessari per raggiungere gli obiettivi prefissati: a questo punto, le organizzazioni possono quindi partire con la progettazione di un Target Operate Model (TOM), che permetterà di adottare progetti e tecnologie sufficientemente agili anche per il futuro. Sfruttare adeguatamente i TOM consentirà quindi ai Chief Experience Officer (CXO) e ai loro team di prendere decisioni informate su quali approcci adottare, quali tecnologie mantenere e quali sostituire, nonché quali servizi di public e private cloud adottare in un ambiente ibrido e complesso.
Integrare un Target Operate Model nella propria strategia permette di definire le priorità, comprendere al meglio quali investimenti è necessario effettuare e organizzare i team e le strutture interne nell’ottica di un programma che contribuisca a risolvere il divario tecnico. In particolare, le decisioni informate per ogni servizio o applicazione, possono includere opzioni come:
Modernizzare le tecnologie in uso o ricominciare daccapo?
È necessario valutare se vale la pena modernizzare le tecnologie in uso o se, invece, potrebbe essere più semplice o più vantaggioso migrare i processi e i dati verso altri sistemi. Per esempio, si potrebbe usufruire di una moderna piattaforma SaaS o di un’applicazione sostitutiva più “leggera” e basata su microservizi. Se si hanno già a disposizione prodotti SaaS idonei, la migrazione dei servizi legacy trasferirebbe i rischi e i costi dello sviluppo e della manutenzione del software applicativo e delle infrastrutture sottostanti al provider SaaS.
Dal SaaS al PaaS
Laddove il Software-as-a-Service non fosse percorribile, l’opzione Platform-as-a-Service può ridurre il rischio di divario tecnico: in questo modo si spostano infatti al cloud provider le responsabilità di manutenzione, applicazione di patch e aggiornamento dell’infrastruttura, dei sistemi operativi e del middleware sottostanti. Le migrazioni PaaS comportano il refactoring delle applicazioni legacy per adattarle alla piattaforma offerta dal fornitore di servizi, pertanto possono richiedere molto tempo: tuttavia, una volta completate, liberano i programmatori dalla necessità di occuparsi della manutenzione, dando loro la possibilità di concentrarsi sullo sviluppo di nuove applicazioni.
“Lift and Shift”
La migrazione IaaS, chiamata anche “lift and shift”, è uno dei modi più semplici ed economici di migrare un carico di lavoro già esistente sul cloud, con minime modifiche e su risorse cloud native. Tale approccio è particolarmente utile nel caso in cui il divario tecnico coinvolga posizioni di hosting e hardware fisici, ma può non essere la risposta più adatta quando il divario si riferisce ad applicazioni o software: in questi casi, un “lift and shift” può essere parte di un programma più a lungo termine, dove si ha a disposizione più tempo per modernizzare le applicazioni una volta migrate sul cloud pubblico, eliminando così i rischi immediati associati all’invecchiamento dell’hardware o alla chiusura degli edifici.
Modernizzazione in situ
È poi possibile scegliere di migrare lentamente il sistema legacy sostituendo componenti specifici in un determinato periodo di tempo. Le varianti di questo approccio sono molteplici, ma una delle più comuni è il modello “Strangler Fig”, che prevede la creazione di una nuova zona di destinazione parallela e il reindirizzamento lento dai componenti dell’applicazione già esistenti a quelli nuovi, mano a mano che vengono implementate funzionalità e servizi sostitutivi. Alla fine del processo, i sistemi legacy vengono ritirati completamente.
Qualunque sia il metodo adottato, una volta eliminato il divario tecnico il percorso non è giunto al termine, anzi: il mantenimento del TOM implica un monitoraggio costante per garantire che il divario stesso non continui ad accumularsi.
Il Polo Strategico Nazionale accelera: ecco come prende forma
Suggerimenti per mantenere i risultati acquisiti
Di seguito, sei suggerimenti per evitare che si ripeta:
- Invece di organizzare grandi progetti una tantum, creare team dedicati che si occupino di aggiornare i prodotti costantemente. Il livello di investimento può sembrare elevato, ma il Total Cost of Ownership sarà inferiore se il prodotto rimarrà sempre attivo, supportando l’innovazione ed evitando l’accumulo di divario tecnico.
- Mantenere le roadmap tecnologiche e rivederle regolarmente, con un aggiornamento tecnologico integrato nei casi di investimento anticipato.
- Implementare moderne metodologie DevSecOps e Infrastructure as Code per garantire che i servizi vengano aggiornati facilmente.
- Prendere in considerazione opzioni come Low-code/No-code e RPA per la creazione di applicazioni e flussi di lavoro nei luoghi più adatti, evitando la necessità di scrivere e mantenere il codice.
- Progettare microservizi su monoliti, che consentiranno di aggiornare e modernizzare parti delle applicazioni in modo isolato dal resto dei servizi. In questo caso i principi di astrazione sono un valido supporto, così come la progettazione di componenti/servizi da integrare utilizzando API e loose-coupling.
- Fare affidamento su dei partner affidabili che possano consigliare, progettare e, se necessario, mettere in atto la trasformazione tecnologica.
Conclusioni
Per chiudere, in questo momento storico, guardando in positivo, la Pubblica Amministrazione ha una occasione unica e irripetibile di ridurre sensibilmente, se non addirittura eliminare, il divario tecnico esistente, potendo usufruire della spinta poderosa che potrebbe arrivare dal PNRR e di conseguenza con il concretizzarsi dell’iniziativa del Polo Strategico Nazionale (PSN) che offre la possibilità alle Amministrazioni di intraprendere una strada di innovazione e trasformazione digitale forse impensabile fino a qualche tempo fa.
