Interconnessione applicativi in uso alla PA

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.

1 Mi Piace

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:

2 Mi Piace

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

3 Mi Piace

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?

2 Mi Piace

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? :slight_smile:

Sto cercando di fare il punto sullo stato dell’arte e approfitto di @Roberto_Polli per chiarire qualche dubbio.

Per adesso abbiamo:

  1. Obblighi e indicazioni generiche del CAD
  2. 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?)
  3. 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.

2 Mi Piace