Un lustro è un arco temporale sufficiente per valutare l’impatto di misure prese per stimolare un’organizzazione, in particolare il 2022 rappresenta la fine del primo lustro della prima edizione del piano triennale per l’informatica nella pubblica amministrazione (2017-2019), documento centrale che ha condizionato in maniera determinante le scelte strategiche dando una linea di indirizzo per la transizione digitale della PA che è rimasta abbastanza stabile nelle edizioni successive. Sono stati fatti aggiustamenti sia nel formato di redazione che in alcune aree strategiche, in particolare cambiando in modo significativo il concetto di Polo Strategico Nazionale (PSN) e rivedendo, alla luce dei risultati, le azioni collegate alla classificazione “A” o “B” dei datacenter della PA.
Sappiamo tutti però che i documenti di indirizzo, anche se supportati da dispositivi legislativi, non sono garanzia di attuazione, come testimoniano i continui rinvii su fattura elettronica e pagamenti elettronici che alla fine hanno però portato al risultato atteso (la legislazione ottimistica è una caratteristica del nostro paese). È lecito quindi chiedersi lo stato di avanzamento dopo 5 anni sulla struttura dei software della PA, in particolare relativamente ai modelli di sviluppo incoraggiati sia dal quadro normativo nazionale che da quello Europeo.
Piano triennale per l’informatica, tutte le novità dell’aggiornamento: regole e sanzioni
Disaggregare i sistemi
L’intento del legislatore nella redazione del piano è stato quello di incoraggiare metodi moderni di sviluppo software secondo le best practice dello sviluppo agile al fine di evitare lo sviluppo di sistemi monolitici che inevitabilmente portano una PA ad un lock-in con il fornitore di turno a cui si devono chiedere modifiche e, spesso, anche proiezioni dei dati interni al sistema. Per contro il modello monolitico è attraente per una PA poiché riduce il numero di oggetti da manutenere e gli affidamenti da effettuare.
Il piano triennale del 2017 nella sezione 13 indica i principi da seguire nello sviluppo di progetti digitali, e in particolare nella sezione 13.2 indica lo sviluppo agile secondo lo schema illustrato in figura.
Nella stessa sezione vengono poi indicati altri requisiti per il software:
1. Essere strutturato in microservizi
2. Esporre le API
…
4. Mantenere l’interoperabilità
…
6. Usare le best practices di sicurezza
…
8. Appartenere alla PA
9. Essere messo a disposizione di altre PA
Chiunque sviluppi software sa che si tratta di requisiti apprezzabili ma non semplici da raggiungere, anche perché la disaggregazione di un sistema in molti programmi che espongono API utilizzate per integrare i vari pezzi per la realizzazione della funzione complessiva richiede un significativo livello di maturazione non solo della PA che detta i requisiti, ma anche dei fornitori che devono abbracciare questo modello di sviluppo.
Il punto cinque anni dopo
La teoria ci dice che una PA dovrebbe strutturare il proprio software secondo vari microservizi che espongono poi le proprie funzionalità attraverso delle API. In un mondo così un sito Web potrebbe seguire l’approccio Single Page Application (SPA) e interrogare direttamente i microservizi per ottenere i dati che poi lato client vengono utilizzati per la visualizzazione delle informazioni nella pagina. In fondo questo è il modo di funzionare dei grandi social network a partire da Facebook.
Come è possibile scoprire se le PA sono state influenzate da queste importanti linee di indirizzo? Non è facile avere un quadro completo: le PA raramente danno informazione sulla struttura dei propri sistemi informativi, è quindi necessarie seguire un approccio sperimentale cercando indizi nei sorgenti delle pagine Web per capire come vengono ottenuti i dati usati per popolarle. Dopo un’analisi dei siti Web dei principali ministeri si evince che i sistemi generino ancora il testo della pagina Web con script lato server che possono usare o meno dei microservizi (in molti casi sembra difficile poiché si evidenziano schemi nei sorgenti che lasciano intendere che la struttura del sistema sia più tradizionale). È da sottolineare come non tutti i siti visitati hanno adottato il template di sito Web promosso da AgID e che quantomeno assicura pagine che seguono le odierne convenzioni e framework di sviluppo Web.
È possibile però farsi un’idea della struttura dei software leggendo i sorgenti condivisi attraverso l’iniziativa Developers Italia che consente la navigazione anche dei codici sorgenti dei software messi a riuso da varie pubbliche amministrazioni. Nella maggior parte dei casi si tratta di codici monolitici che non mettono a disposizione API (con dovute e importanti eccezioni), e soprattutto non strutturati secondo architettura a microservizi.
Ovviamente servizi centrali come la App IO o Immuni seguono architetture moderne, ma si tratta di servizi con visibilità nazionale e di rilievo strategico. Nella maggior parte dei casi troviamo invece applicazioni con strutture difformi e largamente monolitiche che non sono strutturate per funzionare secondo una logica a microservizi.
In alcuni casi si trovano applicazioni che fanno uso della tecnologia dei containers come, ad esempio, Docker, ma solo al fine di semplificare l’esecuzione, non certo per eseguire più container che erogano microservizi usando un software di orchestrazione come, ad esempio, Kubernetes.
In alcuni casi si trovano nei sorgenti anche username e password dei servizi in barba al requisito #6 enunciato nella sezione precedente.
Un quadro immaturo ma il sistema procede
Dalle ricerche fatte emerge un quadro, per quello che si può “indovinare” ancora immaturo, in cui parole come “orchestrazione di container con Kubernetes” sono ancora dette più per mostrare di esserne a conoscenza che per un reale impiego all’interno dei sistemi della PA. Per quello che conosco le installazioni di Kubernetes sono ancora allo stadio prototipale, e quando vengono usati è per supportare l’installazione di sistemi che già sono in grado di beneficiare di queste tecnologie, come ad esempio sistemi noSQL (es. MongoDB) o Object Storage (es. MinIO).
Eppure, non bisogna essere pessimisti, il quadro è molto migliorato rispetto a pochi anni fa, e anche i sorgenti disponibili per il riuso del software sono cresciuti. Non si vedono mostruosità, magari sistemi difficilmente adottabili da altre pubbliche amministrazioni, ma che comunque fanno uso di standard di sviluppo recenti (o abbastanza recenti), e l’organizzazione di molti di questi software sembra andare nella direzione indicata cinque anni fa dal Piano Triennale.
Conclusioni
Possiamo quindi dire che anche in un settore complesso come quello dello sviluppo software il piano triennale ha prodotto un impulso al miglioramento, certo forse le previsioni erano eccessivamente ottimistiche, ma comunque ora si cominciano a vedere i primi effetti ed è solo questione di tempo perché i software sviluppati siano effettivamente realizzata secondo una logica a microservizi composti mediante l’invocazione di API: è facile a dirsi ma il cambiamento culturale è enorme e le PA non sempre hanno la possibilità di imporre ai propri fornitori in modo che questi contribuiscano nell’implementazione di queste indicazioni.
C’è quindi da essere ottimisti per il futuro e fare pressione non solo sulle pubbliche amministrazioni, ma anche sull’indotto produttivo che dovrebbe essere più attivo nel proporre soluzioni rispettose del quadro normativo. Vedremo se ora, in assenza di un ministro per la Transizione Digitale, questo impulso al cambiamento proseguirà o si arenerà nuovamente in attesa di tempi migliori.
