Riuso (di buone pratiche e di software): come e perché usarlo per rinnovare la PA

Di riuso si parla da anni, spesso peraltro confondendo riuso con open source. Cerchiamo di capire come il riuso va declinato per renderlo utile per il cambiamento che la PA dovrà affrontare grazie anche alle risorse del PNRR e della programmazione 2021-2027.

Partiamo dallo stato dell’arte:

• AgID promuove il riuso di soluzioni nella PA, in particolare grazie alle Linee guida di acquisizione e riuso software della PA
• AgID ha realizzato un centro di competenza adatto allo scopo, esiste un catalogo delle soluzioni a riuso per la PA, in cui sia PA che aziende private sono invitate a pubblicare il proprio software.

E proseguiamo con i concetti di base:

• Con il termine “riuso” di un software si intende l’insieme delle attività che consentono il suo utilizzo in un contesto diverso da quello per cui è stato originariamente sviluppato. Secondo il Codice dell’Amministrazione digitale, il software in riuso è esclusivamente quello:
  • rilasciato con licenza aperta da una pubblica amministrazione
  • pubblicato sul portale nazionale del riuso (Developers Italia)
• Le “Linee guida per acquisizione e riuso software PA” sono adottate in attuazione dagli articoli 68 “Analisi comparativa delle soluzioni” e 69 “Riuso delle soluzioni e standard aperti” del Codice dell’amministrazione digitale.

In pratica, alla PA è richiesto di:

• investire su soluzioni con licenza aperta, anche se i costi dovessero risultare maggiori rispetto ad acquisire una soluzione proprietaria (i risparmi si avranno comunque dalla condivisione della soluzione con altre amministrazioni e dal “fare sistema);
• rilasciare gli eventuali miglioramenti ed evoluzioni sul portale nazionale del riuso;
• giustificare con un atto pubblico l’eventuale acquisto di software proprietario, qualora la soluzione con licenza aperta sia impossibile da utilizzare, anche attraverso adattamenti ed evoluzioni.

In particolare per il PNRR e pianificazione europea 2021-2027, il riuso può assumere due declinazioni:

1. riuso di software
2. riuso di buone pratiche

Vediamo prima il secondo punto e poi il primo in dettaglio, in modo da capire come possono funzionare.

Riuso di buone pratiche

Una soluzione innovativa che funziona realmente è l’esito finale di un percorso complesso e faticoso, che richiede investimenti importanti e competenze adeguate; molto spesso, una strada vincente si trova solo dopo numerosi fallimenti ed errori.

Visto il poco tempo a disposizione per trasformare l’”elefante PA” in una specie di “gazzella PA”, è fondamentale non “reinventare la ruota”, ma sfruttare l’investimento ed il lavoro messo a disposizione in riuso da parte di chi ha già messo a punto soluzioni tecnologiche e modelli organizzativi che hanno già dato prova di funzionare sul campo, riducendo gli errori, i tempi necessari per avviare un cambiamento e i costi di start-up; questo consente anche di semplificare i processi di trasformazione e di ridurre i rischi che si prende in carico ogni amministrazione.

Esempi:

Problema 1: vogliamo abbracciare il tema dello smartworking all’interno del cambiamento organizzativo

Soluzione 1: esiste il kit www.smartworkingvela.it, costruito da amministrazioni che hanno lavorato su questo tema e attuato la trasformazione prima della pandemia. Non sarà calzante al 100% alla nostra realtà perché “siamo speciali”, “noi siamo diversi” etc etc, ok può essere, lo sarà al 90%. Ma intanto ci dà una grossa mano a capire il tema smart working, come va inquadrato, che dimensioni ha, che problemi comporta e ci dà la possibilità di accelerare velocemente nella trasformazione in questa direzione.

Problema 2: devo migrare al cloud ma non so come fare

Soluzione 2: esiste il cloud enablement kit che permette di capire il percorso da fare per la migrazione al cloud, valutare gli stakeholder, capirne i contenuti e i problemi, trovare soluzioni.

Problema 3: devo rifare il sito comunale

Soluzione 3: si parte dai siti developers.italia.it e designers.italia.it e si guarda che kit e soluzioni hanno già permesso di effettuare il percorso indicato.

Questo solo per fare alcuni esempi. A disposizione della PA ci sono ormai numerosi KIT e casi d’uso di PAC e PAL che hanno già intrapreso dei percorsi su varie tematiche e dimensioni: metterli a fattor comune sarà fondamentale per migliorare la velocità di cambiamento per tutti. (PS: proprio mentre scriviamo questo articolo abbiamo proposto sul canale slack.developers.italia.it di aggiungere un catalogo di buone pratiche ad uso e consumo di tutti).

Riuso di software

Il riuso di software funziona, come in tutte le iniziative open source, nel caso in cui ci siano:

• un software open source reso disponibile da un privato o commissionato da una PA e reso disponibile a riuso;
• una community di utenti, anche piccola, che si confronta pubblicamente su problemi, possibilità e nuove feature;
• uno o più team, anche di organizzazioni distinte, che contribuiscono con una governance molto chiara allo sviluppo e curano la manutenzione del software;
• essenziale: un supporto efficiente nella risoluzione effettiva dei problemi.

Dal punto di vista della community, è positivo il fatto che l’ecosistema attorno ai software a riuso della PA si stia formando ed evolvendo, con relative issue e segnalazioni di vario tipo, aperte su più prodotti: provate a guardare quante sono ormai le discussioni pubbliche che si sono avviate sui repository del codice rilasciato (Github, Gitlab) collegati al portale del riuso.

Questi contributi a volte arrivano anche da persone non conosciute dal team originale di sviluppo del prodotto o dalla PA committente (che è la forza del modello open source); spesso si tratta di suggerimenti migliorativi o di segnalazioni di problemi, persino di risoluzione degli stessi, molto preziosi ed utili per far funzionare i progetti, che aiutano a rendere più flessibili le applicazioni software e a renderle maggiormente adattabili a contesti diversi, aumentando il numero potenziale di soggetti riusanti.

Con queste linee di riferimento, i software a riuso saranno progressivamente migliorati ed i benefici economici ricadranno su tutti i successivi enti “riusanti”. Si innesca quindi un circolo virtuoso, che rende sostenibile nel medio-lungo periodo l’innovazione digitale per l’intero sistema pubblico.

Un esempio: l’esperienza di un sistema a licenza aperta per la gestione delle segnalazioni:

• Comune di Trento: primo investimento
• Consorzio dei Comuni Trentini: miglioramento e diffusione
• Riva del Garda tra i primi riusanti
• Comune di Bolzano: miglioramenti di varia natura
• Comune di Genova: reingegnerizzazione interfacce utente e nuova versione dei report automatici
• risultato:
  • l’ultima versione del software è ora a disposizione di tutti
  • il tutto è open source
  • anche i primi enti enti che ci hanno investito ne beneficiano
  • un singolo ente (a meno che di dimensioni medio – grandi) difficilmente avrebbe potuto sostenere il costo dell’investimento associato alla realizzazione di un progetto così presentato. Enti piccoli, quindi, sono riusciti ad avere una soluzione da grande ente con un costo condiviso.

Nel caso di alcune soluzioni più evolute, si può addirittura contribuire, grazie a dei motori di creazione di servizi associati all’applicazione, a definire nuovi modelli di servizi digitali e anche questi disponibili in riuso. Questo non richiede sviluppo di codice e il deploy viene fatto in maniera guidata attraverso il browser; si tratta di una modalità molto pratica e concreta per codificare il sapere dei funzionari più esperti sui processi della PA, in formati che possono essere automaticamente interpretati dalle “macchine” e quindi più velocemente riutilizzabili.

Il codice sorgente, come la definizione del servizio, in chiara ottica di riuso, sono:

• in un file json;
• versionato su git;
• reso disponibile su Developers Italia;
• esposti pubblicamente e resi disponibili alla verifica e uso della community.

Nel caso ideale, il software a riuso è utilizzato per offrire anche un servizio qualificato nel marketplace AgID, semplificando al massimo il lavoro per la PA che vuole adottarlo rispettando contemporaneamente quanto previsto dalle linee guida su acquisizione del software e quanto previsto da quelle relative al Cloud della PA.

In questo modo, il software a riuso è disponibile a tutte le PA, e chi l’ha prodotto può fornire:

• per gli enti più grandi e le società in house: consulenza a chi avesse bisogno di supporto per progetti critici e ha scelto la modalità on-premise (IaaS); questa sarebbe la modalità ideale per collaborare con i grandi comuni e con le società in-house, che hanno competenza tecnica interna;
• per gli enti piccoli: servizio chiavi in mano (hosting, assistenza, manutenzione con SLA) per chi demanda completamente la gestione (SaaS).

Questo è forse uno dei miglior modi di interpretare quanto previsto dai cap 2.5 e 2.8 delle linee guida su acquisizione e riuso, che schematizziamo come segue:

Le stesse in-house regionali svolgono un ruolo fondamentale in questo processo, fungendo da catalizzatore di iniziative locali, evitando il rischio di iper-personalizzazioni, ma garantendo efficienza ed economie di scale per tutto l’ecosistema.

Questo è fattibile se si supera il concetto, tutto italiano, secondo cui ogni ente “è speciale” e “ha le proprie peculiarità” che lo rendono unico e differente, impossibilitato ad utilizzare un modello condiviso. McDonalds ragiona all’opposto: che piaccia o no, il panino di McDonalds trova la sua forza nell’esperienza utente, che deve essere uguale in tutta Italia e spesso nel mondo.

Nella PAL siamo ancora fermi a procedimenti diversi per ente, per provincia, per regione, per funzionario, per sensibilità, per competenze, per comune, per pratica, per organizzazione; di conseguenza, ogni cittadino deve capire come muoversi perché l’esperienza non è standard, ma cambia in base all’ente o alla struttura di riferimento.

Il riuso può dare un supporto significativo per mettere a fattor comune esperienze, modelli, procedure. Perché inventarsi soluzioni personalizzate e costruite su misura, che pongono tipicamente seri problemi di sostenibilità nel medio e lungo termine, se qualcuno ha già messo in riuso una soluzione già pronto e funzionante?

Magari non sarà perfettamente coincidente con l’esperienza finora maturata dal singolo ente e non permetterà di conservare le abitudini interne attuali, ma anche questi aspetti dovrebbero aiutare a sollevare dei dubbi: l’impostazione attuale è corretta ed ottimale in ottica di qualità del servizio erogato?

Una soluzione diversa, che risente delle riflessioni, dei contributi e delle esperienze di molti altri enti, potrebbe costituire una fonte di ispirazione e di potenziale miglioramento rispetto agli strumenti e alle procedure attualmente utilizzati.

Considerazioni finali

Infine, ecco alcune considerazioni per i più esperti di riuso e soluzioni opensource, che ci sentiamo di evidenziare e che emergono dalla nostra valutazione del modello in atto:

• al momento manca un riferimento normativo chiaro ed esplicito tra il modello Cloud della PA (SaaS in particolare) e le linee guida di acquisizione e riuso del software; i modelli sopra descritti si evincono dall’analisi delle esperienze maturate sul campo;
• quando si inizia a sviluppare una nuova applicazione, dovrebbe essere sempre definito il modello di business sotteso, che garantirà la sostenibilità dell’iniziativa nel medio-lungo periodo; in mancanza di questa condizione, il progetto sarà con ogni probabilità destinato a morire. Questo è un compito che generalmente riesce meglio alle aziende private, più che alle PA: per questo è necessario individuare degli strumenti che favoriscano maggiormente la collaborazione tra pubblico e privato;
• nelle linee guida rappresentano già un ottimo strumento, che entra nel dettaglio nell’iter che una PA deve seguire quando adotta un software e come può richiedere modifiche. Sappiamo che le difficoltà maggiori del software open source sono rappresentate dal suo costante aggiornamento, dalla vitalità della community e dalla sua sostenibilità a lungo termine. Per ogni progetto è quindi necessario definire una unica roadmap (anche in maniera collaborativa) all’interno della quale far rientrare le modifiche richieste dagli enti: è l’unico modo per evitare i fork ed evitare le dispersioni di investimenti pubblici volti a soddisfare esigenze di singoli enti. Ad oggi, manca qualche indicazione pratica ed operativa su questi aspetti.