Il tema dell’interoperabilità per lo scambio di informazioni e l’erogazione di servizi nella pubblica amministrazione è un tema tra i più importanti per lo sviluppo del digitale nella PA insieme alla gestione dell’identità anche in chiave anagrafica e alla sicurezza dei dati e dei sistemi.
Il tema non è nuovo visto che già nella metà degli anni ’90 l’Autorità per l’Informatica nella Pubblica Amministrazione (AIPA) aveva introdotto dei basilari principi di interoperabilità nella RUPA (Rete Unitaria della Pubblica Amministrazione).
Interoperabilità e cooperazione applicativa
Nel Codice dell’amministrazione digitale (CAD) viene definita l’interoperabilità come la “caratteristica di un sistema informativo, le cui interfacce sono pubbliche e aperte, di interagire in maniera automatica con altri sistemi informativi per lo scambio di informazioni e l’erogazione di servizi”. Questa definizione deve essere associata a quella di cooperazione applicativa definita nel CAD come “la parte del Sistema Pubblico di Connettività finalizzata all’interazione tra i sistemi informativi dei soggetti partecipanti, per garantire l’integrazione dei metadati, delle informazioni, dei processi e procedimenti amministrativi”.
In breve, la combinazione e l’applicazione dei due principi consente lo scambio dati tra PPAA e i soggetti interessati in modo standard, al fine di consentire procedimenti amministrativi complessi ovvero che coinvolgono più amministrazioni ovvero più banche dati anche esterne alla PA.
Sempre il CAD, in più punti, stabilisce il principio che le pubbliche amministrazioni gestiscono i procedimenti amministrativi utilizzando le tecnologie dell’informazione e della comunicazione. Lo specifico procedimento deve fornire opportuni servizi di interoperabilità o integrazione/cooperazione a carico dell’amministrazione. Tali servizi sono conformi alle Linee guida a carico di AgID.
Integrazione e interoperabilità di sistemi e servizi pubblici
L’opinione dello scrivente è che il comma cardine sia il comma 1-bis dell’articolo 64-bis del CAD.
In esso vengono stabiliti i principi di riferimento che le PPAA devono applicare per garantire l’integrazione e l’interoperabilità dei propri sistemi e servizi.
Per quanto attiene ai nuovi parametri progettuali è opportuno ricordare l’articolo 40-ter che stabilisce, a carico della Presidenza del Consiglio dei ministri (da leggere come cosiddetto Team Digitale), la sperimentazione di un sistema pubblico di ricerca documentale. Altri meccanismi operativi sono stabiliti nel CAD allo scopo di consentire l’alimentazione del fascicolo informatico da parte delle amministrazioni coinvolte nel procedimento amministrativo e dagli interessati. L’efficacia di quanto deve essere sperimentato, ai sensi del citato articolo 40-ter, risiede nell’identificativo del fascicolo informatico che è apposto con modalità idonee a consentire l’indicizzazione e la ricerca attraverso il sistema di ricerca di cui all’articolo 40-ter del CAD.
Questi concetti sono sviluppati nel Piano Triennale per l’Informatica nella Pubblica Amministrazione 2017-2019.
Come è noto le architetture di riferimento sono basate su piattaforme che a medio termine sono basate su architetture basate sul cloud.
E’ in corso un’attività complessa a carico di AgID per l’individuazione delle infrastrutture candidate a diventare PSN (Poli Strategici Nazionali). In questo contesto il Piano Triennale stabilisce l’esigenza dell’evoluzione dello storico SPC Coop (datato ottobre 2005). Già il CAD vigente permette di superare la necessità di convenzioni per lo scambio di informazioni tra PA secondo il principio che il dato è di tutta la PA e non della singola amministrazione.
Il Piano Triennale promuove l’adozione dell’approccio “API first” ivi definito come la “strategia di sviluppo e realizzazione di servizi e applicazioni che prevede lo sviluppo di un’API prima di realizzare un’applicazione o una pagina web o un’applicazione per il mobile. In altri termini, la definizione dei canali di erogazione del servizio è logicamente e cronologicamente successiva allo sviluppo dell’API”.
API, la definizione nel Piano triennale
Sempre nel Piano Triennale viene definito il concetto di API – Application Programming Interface: “Interfaccia per la programmazione di applicazioni, ovvero serie di convenzioni adottate dagli sviluppatori di software per definire il modo con il quale va richiamata una determinata funzione di una applicazione”. La definizione si completa con il riferimento al modello di interoperabilità contenuto nel capitolo 5 del Piano Triennale. Chi aderisce al Sistema Informativo della PA deve adottare questo modello quando sviluppa servizi abilitati all’integrazione applicativa.
Il paragrafo 5.3 del Piano Triennale indica in apposite Linee Guida a carico di AgID il riferimento che le PPAA dovranno adottare al fine di garantire l’interoperabilità dei propri sistemi con quelli di altri soggetti e l’implementazione complessiva del Sistema Informativo della PA.
Un elemento cruciale per la definizione del modello di interoperabilità è l’attualità e la corrente validità dei principi declinati nello European Interoperability Framework (EIF) versione 2.066. Questo documento è del 2010 ma ne è stata ribadita la validità nel 2016.
Nel capitolo 6 il Piano Triennale introduce il concetto di Ecosistemi che sono i settori o aree di intervento in cui si svolge l’azione delle PPAA. Per esempio, la sanità, la scuola, i beni culturali, il welfare, ecc. Ne sono individuati 13 e l’elenco è nella figura 7 del Piano.
Le tempistiche del Piano Triennale non sono rispettate a causa dei ritardi introdotti dalla formazione del nuovo Governo e della nomina del Direttore dell’AgID.
Considerando che alla data è imminente l’insediamento del Direttore AgID quest’ultima avrà in agenda certamente questo tema (insieme ai numerosi altri stabiliti nel Piano Triennale).
Nonostante questi ritardi il Team digitale e AgID hanno prodotto una serie documenti di “accompagnamento” al nuovo modello di interoperabilità e all’ecosistema di API.
Questo percorso e la documentazione di supporto è “navigabile” a partire da questo collegamento.
Integrazione dei servizi PA: i 4 livelli di interoperabilità
I responsabili del Team digitale spiegano quale percorso verrà attuato e con quali modalità. Viene specificato che il modello operativo “storico” della Porta di Dominio di SPC Coop è superato con le modalità descritte, insieme al nuovo modello di interoperabilità ed è in consultazione pubblica (terminata peraltro il 7 giugno 2018) a questo link.
Il modello proposto è certamente moderno e in linea con gli standard internazionali utilizzando come già detto il modello europeo EIF. La Governance del modello di interoperabilità che deve gestire l’integrazione dei servizi pubblici, tenendo in conto gli ecosistemi e le esigenze di interazione interna o esterna alla PA introduce quattro livelli di interoperabilità.
Essi sono i livelli di interoperabilità giuridica, organizzativa, semantica e tecnica. Questi si sviluppano su 12 principi europei che sono descritti in dettaglio nel paragrafo 1.2 del documento di modellazione.
Il documento prosegue la sua complessa descrizione del modello con la descrizione delle API di servizio, della creazione del catalogo di riferimento e ovviamente di cosa significhi erogare un servizio tramite un sistema di API.
Ben descritti anche i concetti di sicurezza che doverosamente abbracciano tutte le tematiche del caso al fine di poter garantire conformità alle esigenze di sicurezza anche per gestire i limiti e le condizioni stabilite nella normativa vigente. Questo significa che la sicurezza dell’interoperabilità si colloca anche nel contesto del rispetto del regolamento europeo 679/2016 sulla protezione dei dati personali. E’ noto il rilevante onere di questo regolamento sulla PA a partire dall’obbligo di nomina del Data Protection Officer.
Per quanto concerne i dettagli tecnologici contenuti nel modello di interoperabilità si fa riferimento a SOAP e REST con quest’ultimo che rappresenta lo stato dell’arte.
In questo documento non manca uno sguardo al futuro a breve termine con una analisi sintetica e prospettica del “datastore distribuito” e in particolare su quelli che utilizzano la tecnologia blockchain.
Chi scrive condivide pienamente il seguente concetto, espresso nel modello di interoperabilità:
“In conclusione, sebbene si tratti di una tecnologia che sta suscitando interesse, attualmente blockchain non sono considerate abbastanza mature per l’utilizzo nella Pubblica Amministrazione in settori strategici e il ModI 2018 ne sconsiglia al momento l’utilizzo. Inoltre deve ancora essere definito il modo di integrare ed interoperare tra PA utilizzando smart contract come interfacce di servizio, e le tipologie di transazioni che effettivamente hanno bisogno di requisiti tali per cui la blockchain sia la giusta soluzione”.
È utile rammentare che AgID e Team digitale propongono il percorso di migrazione nel documento pubblicato a questo collegamento.
Tale percorso è teoricamente completo ma potrebbe non essere adeguato alle esigenze della PA locale.
Infatti, la messa in opera delle regole di interoperabilità, di integrazione e cooperazione non avrà un percorso facile se alle Linee Guida, che conferiranno ufficialità istituzionale ai documenti citati e agli altri omologhi, non si affiancheranno meccanismi di collaborazione e supporto con le PPAA in probabile difficoltà.
Le esperienze di PagoPA e ANPR hanno dimostrato la debolezza e la conseguente inefficacia di regole “calate dall’alto” non associate a supporto, FAQ, documenti di buone pratiche e attività analoghe.
Difficoltà e aspetti cruciali
La principale difficoltà sarà quella di definire il perimetro operativo dell’amministrazione. Cosa è a suo carico, come verificare che la specifica è rispettata e soprattutto come garantire una migrazione morbida tra l’esistente e il nuovo modello, visto che l’erogazione dei servizi e dei procedimenti non può essere interrotta.
Un altro aspetto cruciale che è comunque di natura politica è nella definizione del ruolo infrastrutturale della PA. Questo per definire il ruolo delle software house pubbliche (a partire da Sogei) sia della PA centrale che di quella locale (le cosiddette in house).
Questo perché la specifica pubblica deve essere messa in opera tenendo conto della presenza di un mercato che non ha senso tagliare fuori de jure. Questo perché non è detto che la PA sia più economica ma anche perché togliere fiato al mercato significa sviluppare il paradosso che lo Stato fa concorrenza al mercato bloccando, a causa dei minori fatturati, le iniziative di ricerca e sviluppo e altro dell’impresa.
Lo Stato dovrebbe erogare servizi in modo economico, efficace ed efficiente. E’ bizzarro che sviluppi software e servizi ICT in concorrenza con il mercato senza i vincoli che esso stesso ha imposto al mercato.
Un’ultima considerazione va fatta sull’esigenza di una “strategia diritta”. Se ad ogni sospiro politico si ricomincia da capo non si arriva mai da nessuna parte.
Chi scrive lo sostiene da sempre: la messa in opera dell’ICT dovrebbe essere fuori da meccanismi politici per definizione. Questo è il principale problema del prossimo triennio di AgID in attesa di conoscere il destino del Team digitale.
