Elogio all’interoperabilità nella PA: dieci consigli per migliorarla

Il PNRR permetterà di attivare le piattaforme abilitanti a livello nazionale, portando uniformità e standardizzazione tecnologica e una riduzione delle macchie di leopardo digitali all’interno del nostro territorio.

L’adesione alle piattaforme abilitanti è sicuramente un valore aggiunto. Tuttavia, come si realizza l’adesione è fondamentale. E il “come” passa per l’interoperabilità.

L’interoperabilità nella PA: cos’è e perché è importante

Quindi non stiamo parlando di tracciati esportati a mano in Excel, non stiamo parlando di export fatti la notte di ogni giorno, non stiamo parlando di aggiornamenti di dati fatti la domenica notte tra l’una e le due fermando tutti i sistemi.

Stiamo parlando di sistemi che in tempo reale leggono dati da diverse basi dati, inizialmente partendo da quelle di interesse nazionale individuate dall’articolo 60 del CAD. Ci riferiamo a sistemi che permettono di avere servizi con dati aggiornati e di qualità, quando si vuole, da dove si vuole e in tempo reale, con fruizione automatizzata e con un pizzico di intelligenza artificiale per la personalizzazione del servizio e la previsione delle necessità.

Il ruolo cruciale delle software house

È vero che le pubbliche amministrazioni devono interiorizzare questi concetti, ma prima ancora devono farlo le software house per realizzare applicativi che siano in grado di gestire la vera interoperabilità sia a livello tecnologico che a livello commerciale.

Questa non è una scelta che ogni software house può fare se si sente.

È invece una necessità che ogni software house deve avere perché altrimenti non può entrare nel catalogo ACN. Se prima, infatti, con il catalogo AGID era possibile autodichiarare anche funzionalità presenti solo sulla carta, dopo il passaggio della gestione del catalogo dei software ad ACN si sta iniziando a verificare le autodichiarazioni, i software e le procedure associate.

Non solo: i requisiti che riguardano l’esposizione di API per interoperabilità sono divenuti nel tempo più puntuali, specifici per ogni software house e stringenti.

I requisiti per la qualificazione dei servizi cloud SaaS e dove trovarli

I requisiti per la qualificazione dei servizi cloud SaaS si trovano, secondo la nostra ricerca, in tre documenti di riferimento principali:

• Circolare AgID n. 3 del 9 aprile 2018 “Criteri per la qualificazione di servizi SaaS per il Cloud della PA”, Allegato A “Requisiti per la qualificazione di servizi SaaS per il Cloud della PA” (con requisiti di interoperabilità);
• ll Regolamento sui livelli minimi per i servizi cloud della p.a. e la qualificazione, pubblicato dall’AgID il 15 dicembre 2021 con Determinazione AgID 628/2021;
• Il Regolamento ACN, che aggiorna le caratteristiche minime fissate dal Regolamento AgID, approvato e pubblicato con Determinazione n. 307 del 18 gennaio 2022.

Interoperabilità e portabilità: la circolare Agid

Dei tre documenti il più “human-readable”, dal nostro punto di vista, è quello di AGID che riportiamo e commentiamo di seguito per la parte che riguarda interoperabilità e portabilità (che nei successivi documenti, ordine dei fattori a parte, è confermata). Aggiungiamo poi 10 considerazioni, ipoteticamente rivolte a una software house, per fare al meglio l’interoperabilità.

“I servizi SaaS devono consentire l’interoperabilità dei sistemi informativi fra le Amministrazioni pubbliche e fra gli altri applicativi in uso presso il medesimo Acquirente. A tal fine devono esporre opportune Application Programming Interface (API).

Tali API dovranno rifarsi alle migliori pratiche di gestione (API management), prevedendo in particolare la tracciabilità delle versioni disponibili, la tracciabilità delle richieste ricevute ed evase, la documentazione degli endpoint SOAP e/o REST disponibili e delle rispettive modalità di invocazione.

Deve essere sempre possibile la migrazione dell’Acquirente verso un altro Fornitore SaaS con conseguente eliminazione permanentemente dei propri dati al termine della procedura di migrazione. In aggiunta, il Fornitore SaaS dovrà documentare le procedure e modalità di reversibilità del servizio.

Dettaglio dei requisiti di interoperabilità e portabilità:

RIP1 – Il Fornitore SaaS dichiara che il servizio SaaS espone opportune Application Programming Interface (API) di tipo SOAP e/o REST associate alle funzionalità applicative, di gestione e configurazione del servizio.

RIP2 – Il Fornitore SaaS dichiara se il servizio SaaS è interoperabile con i servizi pubblici SPID e PagoPA.

RIP3 – Il Fornitore SaaS garantisce all’acquirente la possibilità di estrarre in qualsiasi momento una copia completa di dati, metadati e documenti memorizzati dal servizio SaaS in formati pubblici e aperti.

RIP4 – Allo scopo di consentire la migrazione da un altro Fornitore SaaS o servizio SaaS, il Fornitore SaaS garantisce all’acquirente la possibilità di importare i dati all’interno del servizio SaaS tramite formati pubblici e aperti.

RIP5 – Il Fornitore SaaS dettaglia le procedure per garantire la reversibilità del servizio SaaS.”

Le disposizioni della Circolare AgID e il requisito RIP1 sono ribadite e ulteriormente specificate, con particolare riferimento alle funzioni applicative, nel successivo Regolamento AgID all’Allegato B, requisito SC-IP-03 e in quello ACN all’Allegato B2, par. 2.4.2, requisito IP.IN-1.

I punti salienti della circolare

Limitandoci alla più leggibile e discorsiva formulazione della Circolare AgID n.3 del 2019, in particolare, ci preme sottolineare ed evidenziare alcune parti:

• e fra gli altri applicativi in uso presso il medesimo Acquirente: incredibile ma vero ad oggi è molto probabile che applicativi di software house diverse dello stesso comune non si scambino dti (i famosi silos informativi). A volte nemmeno quelli della stessa software house. Quindi è molto probabile che lo scenario futuro sia che i software di uno stesso ente comunichino con le basi di dati di interesse nazionale (come fruitori) ma non abbiano API di erogazione. Si tratta di uno scenario assolutamente da combattere con una cultura delle API e del dato da mettere al centro dello sviluppo nelle software house. In questo caso si può dire che manca l’interoperabilità interna all’ente.
• la migrazione dell’Acquirente verso un altro Fornitore SaaS: facile a scriversi ma non a farsi. Senza un “formato standard” dei dati per la portabilità questo non sarà possibile ma si tradurrà semplicemente in un export del database – più o meno descritto – utilizzato dal fornitore che si sta lasciando. Potrebbe essere interessante per ogni dominio operativo arrivare a definire un nucleo minimo di informazioni essenziali con uno schema di strutturazione dei dati standard. Poi se un SaaS ha peculiarità avanzate, accessorie, nella migrazione se ne farà eventualmente a meno, come capita passando da un cloud all’altro delle big tech anche oggi;
• espone opportune Application Programming Interface (API) […] associate alle funzionalità applicative: anche qui manca la parola magica: standard. Senza uno standard di API (REST o SOAP che siano) per i vari ambiti, aumentando le esigenze di scambio di dati e documenti fra componenti informatiche interne alla stessa amministrazione, diventano insostenibili i costi – ma anche gli sforzi tecnici di implementazione e manutenzione – per integrazioni ad hoc. Risultato: si vira verso soluzioni monofornitore, con conseguente hyper lock-in;
• formati pubblici e aperti: pubblico e aperto non vuol dire standard. Anche qui assente la parola magica (forse a questo punto era innominabile?);
• i requisiti da RIP1 a RIP5: dovrebbero essere le condizioni minime non solo per la certificazione ACN ma per l’uso efficace ed efficiente degli strumenti di cui si dota la pubblica amministrazione. È assolutamente utile che anche i contratti e qualsiasi accordo con i fornitori, in termini operativamente comprensibili e adattati al contesto, preveda le RIP;
• Documentazione degli endpoint SOAP e/o REST: sarebbe auspicabile che tale documentazione fosse disponibile già nel rinnovato “Catalogo dei servizi cloud” di ACN. Ciò consentirebbe anche di avere una visione oggettiva non solo sulla propensione di una soluzione all’aperta al mondo esterno ma anche, con minore immediatezza, sulle sue funzioni applicative per le quali, altrimenti, ci si deve affidare esclusivamente alla descrizione testuale prodotta dal fornitore, unica concessione del rinnovato Catalogo ACN alla dimensione applicativa. Ci può anche essere un rimando a degli e-service PDND in qualche modo, anche se dovrebbe essere generico e non riferito all’istanza del singolo comune.

Dieci consigli per migliorare l’interoperabilità nella PA

Ecco 10 consigli o primi passi per migliorare l’interoperabilità nella PA nelle software house, perlomeno per l’esperienza che abbiamo raccolto nel tempo:

• Iniziare con le integrazioni facili, come fruitori di API. Per esempio integrare i Saas con app IO per l’invio di messaggi. Le API di appIO sono un esempio di interfacciamento semplice, standard, open e ben documentato: openapi.
• Proseguire con la fruizione di API accessibili tramite PDND, la Piattaforma DIgitale Nazionale Dati. Qui occorre comprendere  sia la parte tecnologica, sia la parte amministrativa, sia quella di protezione dei dati personali (privacy). La documentazione sul funzionamento della PDND è disponibile nel sito ufficiale della documentazione di PagoPA. Non tutte le API (o e-service) pubblicati su PDND hanno documentazione altrettanto chiara ed esaustiva, potrebbe invece essere interessante avere un solo documento o zip per la parte tecnica e un solo documento o zip per la parte amministrativa (proponiamo nuovamente l’invito, già avanzato qui). La parte di protezione dei dati poi verrà da sé al momento della progettazione dell’utilizzo dell’API (privacy-by-design) nel corretto contesto (anche se la questione non è assolutamente da sottovalutare). Una volta capito il funzionamento di PDND è possibile accedere, sempre come fruitori, alle API di INAD, ANPR o altre basi dati di interesse nazionale mano a mano che vengono rese disponibili su PDND.
• Anche le piattaforme abilitanti, fondamentali per la digitalizzazione sostenibile e l’interoperabilità della pubblica amministrazione (da cui il termine “abilitanti” nel loro nome) espongono API standard, che meritano di essere analizzate e comprese (e implementate nei prodotti!), per entrare ulteriormente nei meccanismi dell’interoperabilità in contesti procedurali sempre più articolati. Per esempio, sono interessanti e ben documentate le API di:
  1. SEND: https://developer.pagopa.it/send/api#/ oppure swagger
  2. pagoPA: https://docs.pagopa.it/sanp

Fin qui si è parlato di interoperabilità “esterna”, in cui la pubblica amministrazione (ovvero il suo software) è fruitore di API esterne e tipicamente fornite dalla PAL. Probabilmente, tutte le software house ce la possono fare fino al punto 3: non serve interoperabilità extrasilos o umana per trovare un punto comune di incontro o accesso ad API delle PAC. Ora, però, viene il bello: fatta quella “esterna” occorre realizzare anche l’interoperabilità interna, cioè quella che coinvolge software e sistemi in uso a una medesima amministrazione (che, ricordiamolo, è requisito per un SaaS già dal 2019). Volendo si può passare da PDND, ma rimane il concetto di dare valore al patrimonio informativo interno all’ente, da qui interoperabilità “interna”.

• API per la protocollazione e la fascicolazione: l’integrazione con il sistema di gestione documentale per registrazione e fascicolazione dei documenti è funzionalmente strategico oltre che essenziale per la regolarità giuridico-amministrativa dei procedimenti. Anche qui serve – e, purtroppo, manca – la parola magica: standard. La maggior parte delle software house che offre sistemi di gestione informatica dei documenti ha almeno capito che il loro prodotto deve permettere di staccare un protocollo mediante API e sarebbe bello che permettesse la creazione di un fascicolo e la sua alimentazione, ancora tramite API secondo le corrette logiche di gestione documentale. Le regole di interazione standard mancano e, come conseguenza, ogni software espone API differenti, che danno accesso a funzionalità applicative differenti con sottostanti logiche gestionali differenti. Ulteriore conseguenza: si disincentiva, perché insostenibile nei fatti, la corretta archiviazione dei documenti che, per forza di cose, ogni software in uso presso la pubblica amministrazione produce e che è a fondamento dell’azione amministrativa. A meno che, di nuovo, non si ceda alla tentazione del monofornitore (sperando che sia “documentalmente sensibile”), si finisce nuovamente per mancanza di standard a fare tutto con la software house A o B, con lock-in progressivo.

• Un altro punto dolente sono le integrazioni con pagoPA. Se la piattaforma ha avuto il merito di permettere l’introduzione del tema integrazione nel mondo della PA (prima praticamente non se ne parlava), il fatto che ogni Partner Tecnologico abbia le sue API verso gli applicativi di back-office, sia per la creazione e l’aggiornamento dei dovuti, sia per la riconciliazione sia per la rendicontazione dei pagamenti ricevuti, rende il lock-in una sorta di jail-lock-in. Una standardizzazione delle interfacce tra PT e back-office anche solo proposta o promossa a livello centrale su GitHub o come linea guida, o anche come convenzione costruita da un gruppo di fornitori più grandi che poi diventa uno standard nazionale, sarebbe auspicabile. O forse in qualche modo potrà aiutare l’ACA (Archivio Centralizzato degli Avvisi) come proposto nelle SANP 3.6.0?.

• Altro punto di attenzione sulle API è dato dal rapporto tra partner tecnologici SEND e partner tecnologici pagoPA. Sull’esperienza della NON standardizzazione delle API dei PT pagoPA verso i  backoffice, i fornitori che si sono avventurati nel diventare partner per le notifiche digitali SEND, hanno deciso di smetterla di fare N>50 integrazioni. Hanno proposto una strategia semplice: se vuoi il mio applicativo fai PT SEND e PT pagoPA con me. Quindi tutta la filiera diventa un silos e si torna al modello di silos interni all’ente che parlano solo come fruitori con le basi dati di interesse nazionale. Con buona pace della già citata gestione documentale, sempre più negletta, e della capacità di un ente di tenere la situazione sotto controllo con strumenti unici e organici. Delle api standard proposte da un gruppo di fornitori importante come numeri di clienti o da PagoPA con loro supporto, potrebbe diventare uno standard de facto. In fondo i programmatori bravi si dice che siano pigri: perché inventarsi una cosa nuova quando puoi copiare uno standard o una linea guida?

• Anche nei casi in cui le API sono messe a disposizione, spesso la documentazione non viene presentata in openapi o con uno swagger bensì con dei documenti di testo. No Comment.

• Il modello economico delle API ha qualcosa di antico per non dire di non più accettabile dopo la migrazione al Cloud. Si propone di migrare al cloud gestendo poi le API come fossero dei moduli aggiuntivi (anagrafe, tributi, …) e facendo pagare un costo di attivazione e un canone che non sono minimamente rapportati allo sforzo di gestione. Si aprono quindi due strade di miglioramento: alcuni fornitori stanno includendo API e integrazioni nel canone di prodotto; altri continuano con il modello investimento e canone per gruppi di API (es. quelle del protocollo) ma riducendo sia investimento che canone capendo che è in gioco la sostenibilità di lungo termine della capacità di investimento dei comuni e anche la loro stessa redditività. La maggior parte invece procede come fossimo ancora on-premise, con assenza di evoluzione.

• Per le integrazioni l’unica strada sono solo le API? C’è chi si è fatto questa domanda e inizia ad usare l’AI per estrarre dai tracciati degli altri fornitori le informazioni che servono e poi lavorarle nei propri applicativi. Non molto realtime, del resto è una strada alternativa che volevamo indicare come possibile. Ad esempio il software A mi permette l’export di un tracciato T, analizzo con l’AI il tracciato T, ne estraggo le informazioni  I che mi servono e le utilizzo nel mio software. La stessa cosa che in un mondo evoluto l’avrei richiesto con un API ma tant’è. Certo, anche in questo caso serve che i software consentano esportazione ed importazione di dati, almeno con tracciati loro proprietari e che ci si tappi il naso nell’accettare questa modalità.

• Tutto questo non è uno sfizio ma una necessità. Infatti, se non avremo collegato il portale dei servizi online, rinnovato con il contributo PNRR Cittadino Attivo della misura 1.4.1, con il back-office portato in cloud con la misura 1.2, passando ovviamente da registrazione a protocollo e fascicolazione, avremo creato dei mostri tecnologici isolati, spendendo i soldi del PNRR per un bel sito e a volte una migrazione al cloud di facciata.

Se front-office e back-office non comunicheranno (o comunicheranno solo se si ha lo stesso fornitore anche se il come è tutto da verificare), avremo attivato le piattaforme abilitanti senza sfruttare il vero potenziale esplosivo e esponenziale di dati forniti in realtime, accurati e sempre freschi, che fluiscono liberamente tra gli applicativi dell’ente e si fondono per creare conoscenza e saggezza con i dati della basi dati di interesse nazionale.

Il futuro dell’interoperabilità nella PA

L’interoperabilità può portare enormi benefici:

• a cittadini e imprese che smettono di lavorare da citizen bus service portando dati da una PA all’altra;
• alla PA perché può avere dati freschi e corretti senza perdere tempo in inserimenti, correzioni, analisi;
• all’automazione dei processi, che spesso si blocca sull’inserimento manuale di dati;
• alle software house perché possono aprirsi a nuovi ecosistemi di opportunità, soprattutto dopo il PNRR, momento in cui avranno esaurito le proposte commerciali che fanno da anni e dovranno pensare a nuovi scenari;
• ancora alla PA che, se dotata di sistemi versatili e votati all’apertura e all’interoperabilità, può fare fronte con tempestività a esigenze impreviste, senza necessità di programmazioni o personalizzazione avanzate (ci ricordiamo bene le lodevoli ma spesso disordinate iniziative durante il lock-down), o risolvere problemi annosi (tipo il recupero crediti) la cui soluzione si arena miseramente perché dovrebbe attraversare sistemi diversi, restii a parlarsi e a condividere logiche applicative.

Ma senza standardizzazione non potremo fare l’interoperabilità che serve, oltre al fatto che dovremo convergere su cosa vuol dire standard.

Spesso si dice API per comprendere tutto, ma oltre all’interfaccia tecnologica fra due macchine, c’è di più (e non solo del dominio tecnologico).

Ci offre un esempio l’impostazione del lavoro in corso per la (nuova) digitalizzazione dei procedimenti SUAP. Il progetto si è fatto o si sta facendo carico di descrivere:

• lo schema logico e l’architettura di un sistema informativo distribuito;
• attori e ruoli (chi fa che cosa);
• modulistica unificata standard con alla base vocabolari controllati; flussi di lavoro (workflow);
• tracciati (XML) per lo scambio di informazioni e, infine, API di comunicazione per ogni fase del processo.

Conclusioni

Del resto i fondi del PNRR sono disponibili adesso. Questa sfida va vinta adesso o ci troveremo ancora a parlare di integrazioni per i prossimi 20 anni. E alla fine non è qualcosa di inarrivabile, anzi è già iniziato, occorre solo dare una direzione migliorativa partendo con qualche standardizzazione e un po’ di cultura dell’interoperabilità nelle software house, sia ai tecnici che hai commerciali, oltre che al management.