Ricky, ti garantisco che la maggior parte dei problemi ci sono sui siti e sui server centralizzati. Mi rendo conto che nel mondo privato è inconcepibile, ma nel mondo PA è così. Proprio quello che dovrebbe funzionare meglio è quello che funziona peggio.
I soldi ci sono ma la PA centrale li butta via in modo indegno (e nessuno che manco si sogni di andare a guardare come e A CHI), col risultato che le reti sono lentissime, i server sovraccarichi, i sw obsoleti e sempre carenti di qualche funzione indispensabile.
Lo so bene che il decentramento non è la soluzione anzi, ma così almeno la continuità operativa la assicuri. Poi se finalmente le grandi sw house statali cominciassero a lavorare come si deve il discorso cambierebbe, ma fino ad allora non puoi rischiare di bloccare l’attività di SUAP, uffici tributi, ASL ecc.
Le LLGG si dimenticano proprio delle cose essenziali che rendono l’interoperabilità utile: la definizione delle interfacce. Che è poi è quello che evidenzia @Riccardo nel post iniziale e anche @Elena_S e @frantheman .
Cosa che da dirigente dei sistemi informativi, responsabile di integrare fra loro i diversi gestionali, è sempre stato il problema nr 1. E’ proprio la declinazione di interoperabilità data nel piano triennale che è limitata e non aiuta, nel concreto, chi deve realmente integrare i diversi sistemi.
Ne ho scritto tempo fa su AgendaDigitale.eu, se avete un po’ di pazienza, leggete qui:
Buongiorno Elena, certi processi sono costosi perchè al momento sono lasciati alle foglie, ossia ai responsabili dei sistemi informativi. Se questa logica viene fatta galleggiare ed a livello centrale (regionale o nazionale) si individuano degli standard minimi di dialogo tra applicativi e questi divengono condizioni necessarie, ecco che i fornitori pur di continuare a mantenere la propria posizione di mercato si attrezzano, allo stesso modo come è avvenuto per erogare SaaS, si è deciso che i SaaS dovessero essere certificati e così è stato. A mio avviso manca solo organizzazione da parte nostra. Dobbiamo lavorare assieme per fare in modo che i problemi che dobbiamo affrontare arrivino sui tavoli giusti e con il giusto peso. Allego due link a documenti che ho predisposto relativamente a questo ambito Presentazione Bozza proposta
Ben fatto, complimenti!
Direi che il breve passaggio su Slack sia stato un vero buco nell’acqua. Io stesso credo di non poter nemmeno piu’ recuperare i pochi e disordianti spunti che avevo affidato a un documento nell’etereo cloud.
Suggerisco un ulteriore sviluppo in ambito PagoPA: il PT espone un servizio per avviare un pagamento (modello 1) da parte di un altro applicativo con regole precise per la restituzione dell’esito del pagamento (es.: URL di ritorno OK e URL di ritorno KO). Esempio pratico, iscrizione a un concorso o altra istanza subordinata a un pagamento (la parte di creazione del dovuto la hai già trattata tu).
E un altro ancora: modulistica online. Iniziare almeno a definire un formato standard per il passaggio dei dati e un vocabolario preciso almeno per i dati anagrafici sia delle persone fisiche sia di quelle morali.
Domanda: la tua amministrazione ti appoggia in questo?
Il lavoro di standardizzazione dei dati e degli applicativi è fondamentale, come anche quello di uniformizzazione delle interfacce.
Questi temi sono affrontati anche nei progetti del PNRR attraverso il Catalogo API e la Piattaforma di Interoperabilità istituita dal CAD art. 50-ter e da un Catalogo per l’interoperabilità semantica che valorizzerà il lavoro iniziato con Ontopia - che comunque è lì ed è usabile.
Rendere uniformi le API delle PA non è semplice perché in molti casi le procedure amministrative e l’organizzazione degli enti non lo permettono: per raggiungere questi obiettivi, descrivere, catalogare e pubblicizzare i vari servizi e schemi dati usando formati standard è fondamentale. Ma serve un lavoro di co-design tra gli enti interessati che porta insieme ad allineare normativamente, organizzativamente e semanticamente il contesto in cui le API devono essere erogate.
Bene, quando si inizia? 
Sto cercando di fare il punto sullo stato dell’arte e approfitto di @Roberto_Polli per chiarire qualche dubbio.
Per adesso abbiamo:
- Obblighi e indicazioni generiche del CAD
- linee guida su tecnologie e standard di sicurezza per l’interoperabilità tramite API (approvate. ma sono quelle che erano in consultazione qui su forum.italia.it nel 2018?)
- linee guida per l’interoperabilità tecnica tramite API (approvate)
→ Dubbio grande: il campo di applicazione di queste linee guida. SI parla di sistemi di enti diversi e di accordi di fruizione. Sono senz’altro esclusi i dialoghi fra componenti del sistema informativo di un ente. Però:
- ci rientra l’interoperabilità di protocollo tramite WS come descritta dalle linee guida sul documento informatico di prossima applicabilità? Lì non c’e’ accordo di interoperabilità punto-punto (sarebbero dell’ordine di 10^8 accordi) ma un’adesione a uno schema obligatrio per gli aderenti a una comunità (qui il dominio sarebbero proprio tutte le p.a. italiane);
- ci rientra la comunicazione con app IO? al momento l’interazione con app IO è piuttosto immediata e sostenibile (accordo di interoperabilità/adesione, API key, interazione REST liscia). Aderire alle regole individuate dalle linee guida, oltre al ridisegno delel interface attuali, nuocerebbe gravemente alla sostenibilità dell’adesione a IO.
Sono in consultazione:
4. Linee guida sull’interoperabilità dei dati tramite PDND.
Queste sembrebbero una applicazione delle linee guide dei punti 2-3 ai domini delle banche dati dichiarate di interesse nazionale dal CAD. Corretto?
Ci sono poi:
5. le ontologie di Ontopia
Dubbio: queste chi le usa? ci sono casi di implementazione in contesti applicativi reali? chi le conosce ed è ingrado di interpretarle? Senz’altro è un ambito che andrebbe frequentato di più, temo che sia poco noto ai più.
I fantomatici progetti PNRR riguarderanno quindi cose già preconizzate fra CAD e linee guida attive:
6. catalogo delle API (nominato nelle linee guida del punto 3.)
7. piattaforma di interoperabilità (è il PDND?)
8. catalogo per l’interoperabilità semantica (messa a sistema di Ontopia).
Tornando all’interoperabilità degli applicativi, senz’altro il tema è legato a quella dell’interoperabilità come intesa dalle linee guida, anche se probabilmente coinvolge in maniera minore gli aspetti di convenzioni fra enti e di firma di token e pacchetti di dati scambiati. Trae sicuramente giovamento dalla definizione di linguaggi condivisi. Penso che però il punto di vista non debba essere quello “del co-design degli enti interessati” ma proprio quello del dominio, perché il punto è che la partita si gioca in massima parte in seno a un medesimo ente che acquista software da soggetti esterni e deve farli parlare fra loro. Tutto lo stato dell’arte descritto sopra torna comodo per capire come un software recupererà l’ISEE del fuitore di un servizio alla persona, ma continuerà a non dirci in che modo il gestionale di quel servizio alla persona comunicherà al gestionale della contabilità spese e ricavi.
A proposito di interoperabilità interna fra applicativi di una PA:
Giusto una proposta, migliorabile ma del tutto sostenibile.