Interconnessione applicativi in uso alla PA

Ottima iniziativa. Io ho espresso il mio punto di vista in vari post sparsi sul forum, che adesso non so piu’ ritrovare.

Concordo anche sul fatto che occorre distinguere fra l’interoperabilità verso una banca dati o un nodo centrale e l’interoperabilità fra software gestionali. Quest’ultima è senz’altro più dura da raggiungere, deve poggiare su una preventiva condivisione lessicale, semantica, di organizzazione dell’informazione ecc.

Esistono settori in cui, se non si è raggiunta, si è almeno a un livello di integrazione e interoperabilità molto avanzato (vedi sanità, HL7 CDA2).

@RaffaeleF premesso che le Linee d’indirizzo includono molte delle Best Practice adottate a livello globale sia dal pubblico che dal privato, è pure vero che all’interno delle PA ci è sembrato corretto permettere una sana e ragionevole flessibilità, soprattutto per quegli enti che hanno una consolidata esperienza tecnologica.

Coi fornitori suggerisco sempre di creare un rapporto costruttivo ed eventualmente allegare le Linee d’indirizzo ai contratti di acquisto. Credo però che non si possa delegare tout-court ai fornitori le decisioni tecnologiche e che gli enti devono migliorare continuamente le competenze sulle architetture digitali e guidare i loro fornitori.

Il canale #api sulla piattaforma https://slack.developers.italia.it è uno spazio di discussione dove IT manager e tecnici della PA possono confrontarsi anche su questi temi relativi alla gestione dell’interoperabilità dei servizi creati dai loro fornitori.

@frantheman una interoperabilità “orizzontale” è molto più complessa. Per questo è importantissimo il ruolo delle piattaforme come Ontopia di Agid. Questo è un cammino tutto da compiere.

@Roberto_Polli, lo so bene, ma è una questione ormai ineludibile, va affrontata nella sua complessità. altrimenti, spinti dal solo amore di risultato, si concretizzano solo le azioni semplici e si lasciano le 20.000 e piu’ amministrazioni italiani prive di strumenti.
Per esemplificare, e’ inutile che io abbia un software per pagamenti elettronici che dialoga col nodo pagoPA tramite un linguaggio standard quando non c’e’ alcuna regola per far dialogare quel software con i miei 10-15 software che generano esigenze di pagamento. Gli incroci possibili nelle 20mila amministrazioni italiane sono davvero troppi. E di esempi se ne potrebbero fare a iosa.
Forse si’, bisognerebbe partire dalle basi, da quelle che ora va di moda chiamare ontologie, invece la tendenza imperante e’ partire dalle app…

4 Mi Piace

Caro @frantheman, uno dei tuoi post migliori cui ti riferisci l’ho ritrovato io - è questo, credo.

@Roberto_Polli, lascia che ti esprimiamo la nostra gratitudine per le tue risposte. È molto raro che un repsonsabile del Team - proprio dell’argomento in esame - riesca a trovare tempo per risponderci (né lo pretendiamo, dato che non è certo il vostro lavoro e avete ben altro da fare!), e lo apprezziamo molto.

Grazie @Luca_Valerio, si’, quello penso sia il piu’ significativo.
Mi unisco all’apprezzamento per il confronto.

Mi permetto di sottolineare questo punto:

Teoricamente ineccepibile ma… si pensa davvero che tutte le amministrazioni siano in grado di esprimere adeguate competenze sulle archietetture digitali? L’Agenzia delle entrate si’, l’inps si’, il Comune di Milano forse, un Ministero forse anche… ma un comune di 2000 abitanti che ha funzioni in una cinquantina di ambiti cosa puo’ esprimere? Li’ e’ il fornitore che comanda e non c’e’ modo di indirizzare il suo operato, ridurlo a piu’ interoperabili consigli. E questo e’ un’impresa ardua anche per le amministrazioni locali piu’ grandi, ardua e sicuramente costosa. Non tutte le amministrazioni possono permettersi di progettare, vuoi per mancanze di competenze vuoi per mancanza di soldi. Le amministrazioni comprano per lo piu’ prodotti pronti con i loro modo di comunicare (dove ci sono) immodificabili…

EDIT: quimdi, un suggerimento che mi sento di dare è: puntate su diffondere Ontopia o, meglio ancora, sui concetti di base che intende veicolare. Occorre uniformare il linguaggio, uniformare la strutturazione dei dati, distinguere ciò che è essenziale da ciò che è accidentale ecc. Poi schemi e API vengono da sé (forse)

5 Mi Piace

@Roberto_Polli date le difficoltà che affronto nella quotidianità, continuo a pensare che sia strategico ed ulteriormente irrinviabile l’inizio di un percorso che si ponga come obiettivo quello di individuare standard minimi di interoperabilità tra applicativi interni alla PA. I comuni piccoli e medio-grandi hanno forza insufficiente (sia tecnica sia economica) per gestire questi aspetti ed abbiamo necessità di essere supportati da strutture di aggregazione centrali che guidino e coordino sia strategicamente, sia tecnicamente, con il nostro contributo, questo percorso di evoluzione. Se oggi abbiamo ANPR è perchè anche i comuni hanno partecipato al progetto e lo hanno reso applicabile alla realtà.

3 Mi Piace

@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?