Interconnessione applicativi in uso alla PA

@RaffaeleF

individuare standard minimi di interoperabilità tra applicativi interni alla PA.

L’interoperabilità ex CAD ar.73 riguarda “l’interoperabilita’ tra i sistemi informativi delle pubbliche amministrazioni” quindi a meno di elementi critici come la sicurezza non potevamo non focalizzarci sulla norma.

Si possono fare dei ragionamenti nelle prossime evoluzioni, ma parliamone su slack, che è più veloce.

No, ma ci sono varie soluzioni:

  • i piccoli si possono consorziare e/o coordinare per il procurement, eventualmente aggregandosi a comuni più grandi: questo sta già accadendo da tempo;
  • si può far leva sul catalogo del riuso o sui servizi cloud certificati;
  • si possono usare le piattaforme come forum e slack per creare delle relazioni tra gli enti e discutere sui vari temi.

Anpr è un caso di successo che ha visto la collaborazione dei colleghi del Team Digitale, del Ministero dell’Interno e Sogei, dei Comuni e dei loro partner tecnologici. La norma c’era da tempo, ma non è stata sufficiente. Anche nel caso dell’Interoperabilità è necessario un lavoro di community building.

Vi aspetto su slack per continuare la discussione, R.

1 Mi Piace

Non so cosa sia slack, lo ammetto. Sull’inefficacia delle tre soluzioni proposte abbiamo discusso ampiamente - e con interventi ben qualificati - in queste pagine.
Peccato la frammentazione di luoghi di discussione.

Quanto ad ANPR… e’ partito, vero, i comuni comunicano i dati ma… anche qui si potrebbero evidenziare delle crticità e il mancato riverbero sui sistemi locali…

  • ANPR ha definito un linguaggio che si discosta in parte da dalle indicazioni di chi (ISTAT) per attribuzione di legge ha definito da tempo un linguaggio: ok, poco male;
  • i software locali continuano a usare propri nomi per i campi dell’anagrafe che sono anche in numero diverso rispetto a quelli di ANPR: i dati sono quindi riversati in modo impreciso e poco accurato;
  • i software di anagrafe locali hanno elaborato API per rispondere all’obbligo di legge di comunicare con ANPR, ma non hanno aperto le stesse API al sistema informativo locale oppure hanno continuato a esporre prorie API con tracciati proprietari ecc: cosi’, anche se esistono un linguaggio e una sintassi nazionale per chiedere a una banca dati l’indirizzo di una persona a partire dal suo codice fiscale, se l’applicativo dei tributi comunali deve avere un indirizzo dall’anagrafe comunale si tratta di sviluppare da zero l’apposito connettore se i due software non sono parte della stessa suite. Eppure uno schema efficace c’e’…

Buon lavoro :slight_smile:

2 Mi Piace

@frantheman quanto dici su Anpr è verissimo. Per slack ecco il link.

Sulla frammentazione faccio qui uno schema:

  • forum: per post organizzati e discussioni a basso traffico
  • slack: per interazioni rapide/chat dove scambiarsi idee che, riorganizzate, possono essere riportate su forum una volta valorizzate o meno.
1 Mi Piace

Ok, mi sono unito al canale #api e condiviso qualche idea, in linea con quelle di @RaffaeleF , nelal direzione di definire specifiche API uniche per ogni dominio funzionale.

… mi sembra la discussione principe. Anni fa mi sono ritrovato a fare una denuncia nel comune di Buccinasco, ed a non poterla modificare in un’altra stazione dei carabinieri, perchè tanto i due sistemi non si parlano. O prendi una multa e la puoi pagare online se l’hai presa a Milano ma non altrove.
Io APP è un bel passo in avanti, un punto unico di comunicazione col cittadino. Ma se i comuni vogliono dare la possibilità di pagare la mensa dei figli, la TARI, le multe … possibile che si debba capire come farlo 8mila volte e non si possa sviluppare un tool unico ? capisco che farlo 8mila volte muoverebbe l’economia di più, ma tra 10 anni non siamo ancora arrivati a risolvere, temo. L’aggregazione dei piccoli comuni in consorzi con persone che ne gestiscono le esigenze informatiche si è fatto nel Cremasco con 50 comuni, con successo a quanto pare (Ripalta Cremasco è un piccolo comune che fornisce già 4 servizi su “io App”).

Sposo molti dei pro e contro e delle considerazioni fatte, peraltro io non lavoro in una amministrazione pubblica, nè ci ho a che fare come cliente (non lavoro in una software house).

Però concordo che ci sono problemi anche grossi, con soluzioni che hanno pro e contro e non sono mai perfette. Per esempio penso che i dati dei cittadini mantenuti in database delocalizzati in ogni singolo comune, sia un problema di sicurezza e privacy. E’ un po’ il principio per cui ha avuto tanto successo ‘Paypal’: è un ente terzo che consentiva il salvataggio dei numeri di carte di credito in un ‘unico’ punto (che deve essere super sicuro), e faceva da intermediario nei confronti delle migliaia di rivenditori, che non avevano più bisogno di salvare nulla in locale, se non un ID univoco della transazione, con cui interfacciarsi a Paypal in caso di controversie. E’ ben più sicuro del negozietto con un solo PC, che salva in locale carte di credito, siamo d’accordo credo no ? PagoPA mi risulta funzioni in modo simile, è un intermediario ma materialmente non fa nulla. Cosi come ‘Io APP’ mi risulta non salvi in locale nel telefono i numeri di carte di credito.
Le software house per le quali è ‘comodo’ avere il db locale, cambiano approccio o non entrano. O escono e perdono i clienti. E’ vero il tema dei comuni montani, ma che alternative ci sono ? se vuoi comunicare con i cittadini tramite “Io APP”, i cittadini devono comunque avere cellulare e/o connettività, cosi come il comune. Il segnale 4G ormai arriva praticamente ovunque, l’alternativa sarà recarsi nel comune più vicino, e accorpare comuni privi di connessione internet, che non hanno senso di esistere perchè hanno 7 abitanti. Hanno sicuramente gli stessi disagi quando devono andare a fare la spesa, o gli serve andare dal medico o in ospedale.
Anche i comuni ormai dovrebbero avere oltre ad una linea fissa, anche un backup eventuale radio, i casi di assenza totale di connettività prolungati non credo siano la norma, ove capitasse si bloccheranno i servizi ai cittadini perchè non si riescono a scaricare i dati dal DB centrale dello stato. Non mi pare una tragedia rispetto al problema di avere 8mila database distribuiti in mano a persone che non possono avere nè delegare (troppo costoso e di nuovo poco sicuro) le competenze per gestirli.
L’alternativa è una struttura gerarchica in cui si creano eventuali DB regionali, che poi se serve si parlano tra loro, ma il formato delle info deve essere standard, cosi come già detto il protocollo di comunicazione. Mi sembra comunque una soluzione peggiore della precedente, che andrebbe gestita in un cloud ridondato in Italia autogestito dallo stato (e non con i dati tenuti a Dublino dai soliti noti americani, che per giunta in Italia non pagano 1 euro di tasse)

1 Mi Piace

Tutto bellissimo, a patto che con db centrale si riesca a comunicare. E visto che ho a che fare con banche dati e sistemi centralizzati, che sistematicamente quando ci sono più connesisoni vanno in crash, non sono molto ottimista.

1 Mi Piace

se tecnicamente non si potesse fare, non esisterebbe il mercato del Cloud che sta facendo sparire tutti i DC locali. Che poi ci siano sistemi in giro fatti male, è probabile pure questo. Al netto del fatto che i problemi ce li hanno tutti una volta ogni tanto, compresi Google, Microsoft, Amazon.

Io parlo di problemi sistematici come quello per accedere ai sistemi ANAC per ottenere CIG o altri codici in ora di punta (non quotidiano, ma frequente). O di accedere a Sicoge a fine anno. O al sw di protocollo di un ministero di cui non farò il nome per pudore, sistema che ti butta fuori con messaggi di errore ogni tre per due. Il down occasionale nessuno lo discute.
Certo che tutto si può fare, ma finchè nell’informatica pubblica si vogliono fare le megariforme a costo zero o peggio si sprecano miliardi per chissà cosa (che si sa bene per cosa, alla fine), l’infrastruttura è inadeguata, e di conseguenza il servizio risulta peggiore di com’era in partenza. Tutto qui. Se poi si investono i soldi necessari per infrastrutture adeguate, evviva. Ma sarebbe la prima volta.

2 Mi Piace

Concordo con @Elena_S … non è che il “cloud” sia la panacea di tutti i mali, sebbene sia la moda del momento: se la connessione internet vacilla o è claudicante non si lavora più…
Le banche-dati centralizzate se non hanno una larghezza di banda e capacità di carico sufficienti (e non sono ridondate) costituiscono un collo di bottiglia (o peggio un single point of failure) quanto più sono critiche e possono comportare disservizi anche gravi; ritengo sarebbe meglio avere più server sincronizzati che alleggeriscano il carico.

2 Mi Piace

https://www.freecodecamp.org/news/understanding-database-scaling-patterns/
Il Cloud non è la moda del momento, o se lo è, lo è da almeno 10 anni. Se la connessione internet non funziona, aspetti che si ripristini, nel frattempo farai altro. Non mi pare stiamo a piedi tutti i giorni, tra connessione fissa, radio e con più fornitori. E’ come salvarsi tutti i siti internet in locale perchè se non va internet non li vedi più.
La banda si dimensiona sulla base di ciò che serve, come accade per internet, e come fanno tutti i provider. Se lavori male avrai sempre problemi. Più server sicronizzati possono essere un modo per scalare, come descritto nel link allegato, la cosa non è in contrasto con il fatto di usare il Cloud, che deve scalare su migliaia di clienti di medie o grosse dimensioni. Netflix per dire, usa il cloud di Amazon. Basterebbe pagare un po’ di meno tanti politici del tutto inutili, e un po’ di più gente che sappia lavorare e abbia fatto esperienze ad un certo livello.

Suppongo che ti sfuggano molte cose sulla situazione degli Enti pubblici nel mondo reale:sweat_smile: e dato che del settore pubblico si sta parlando in questo contesto (e non in generale) sarebbe utile averne una conoscenza diretta quando si prendono delle posizioni :roll_eyes:

Certo. Glielo dici tu agli utenti in fila all’anagrafe, o ai tecnici in fila all’ufficio edilizia, di ripassare? Dovresti parlare con chi predispone gli stipendi dei dipendenti pubblici per avere un riscontro sul ‘fare altro’ quando il server è raggiungibile 7 giorni al mese…

1 Mi Piace

perfetto, mi avete convinto. Io in 10 anni di Tiscali ricordo un disservizio, ma si vede che il mondo intero ce l’ha con il pubblico, che invece rende raggiungibili i server 7 giorni al mese. I vostri telefonini funzionano 7 giorni al mese ? il problema è la connettività o i server, fisici e con 20 anni di vita che dovrebbero sparire per fornire gli stessi servizi nel cloud ? I soldi ci sono, basterebbe centralizzare le progettazione e smetterla con il divide et impera, per cui ci si reinventa costantemente la ruota, per rifare ognuno le stesse cose, sempre male.
Per cui secondo voi serve tenere 8000 copie locali, sui PC dell’impiegato del comune che sicuramente è attentissimo ai temi privacy. “Abbiamo sempre fatto cosi” è una risposta egualmente valida.

Buongiorno, avrei bisogno di alcuni dettagli sul discorso interoperabilità e in particolare quanto contenuto nell’allegato 6: Comunicazione tra AOO di Documenti Amministrativi Protocollati. Ho visto i wsdl/ xsd contenuti qui https://github.com/AgID/protocollo-comunicazione-aoo/blob/master/interfaces_SOAP/protocollo-destinatario.wsdl e leggendo la documentazione ho immaginato un percorso di questo tipo --> prendo il domicilio da IPA e mando il messaggio a quel domicilio se diverso da PEC (sarà un servizio esposto su Internet in https di un’altra PA).
Oppure manderò il messaggio ad un endpoint di AgiD che a sua volta lo smisterà verso un endpoint che è la AOO di un altro Ente?

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