Le sorti della trasformazione digitale più importante per la nostra PA, l’interoperabilità, sembrano affidate ad un catalogo centrale di API – Application Programming Interface, “connettori automatici” consultabili e accessibili tramite un servizio dedicato.
“Madamina, il catalogo è questo” cantava Leporello alla sconsolata donna Elvira nel Don Giovanni di Mozart. Si trattava di un elenco di tutte le conquiste del noto seduttore, tanto ricco e dettagliato da poterne ricavare inusitate correlazioni: “vuol d’inverno la grassotta, vuol d’estate la magrotta”. I cataloghi, spiegava Umberto Eco, servono a questo: rubricare un numero non prestabilito di elementi anche sparsi ed eterogenei (“Vertigine della lista”, Bompiani 2009). Per sua natura, un catalogo non serve se non a elencare, a mantenere tracce i cui usi eccedono le previsioni del redattore. Si tratta dunque di un dispositivo debole e aperto, in quanto non impone prescrizioni, vincoli formali o criteri di pertinenza.
PA, Mochi: “Senza interoperabilità non c’è semplificazione. Ecco dove agire”
Interoperabilità PA: i fondi PNRR, come sarà il catalogo centrale di API
Il problema dell’interoperabilità è in apparenza molto semplice: un’amministrazione, con l’automazione delle sue procedure, deve poter attingere facilmente dalle altre i dati che servono per espletarle. Similmente, deve poter trasmettere i dati in suo possesso alle altre amministrazioni interessate, anche al fine di attivare le loro procedure. Questi scambi informativi dovrebbero avvenire con la stessa fluidità e naturalezza con cui le persone addette agli uffici li produrrebbero parlando al telefono o scrivendosi lettere, come oggi ancora fanno.
Il Piano Nazionale di Ripresa e Resilienza (PNRR) dedica un intero capitolo (Investimento 1.3) all’interoperabilità, con una allocazione di 650 milioni, senza contare le numerose occorrenze della parola negli altri capitoli. Questa attenzione non è di sicuro una novità: sono almeno trent’anni che alle deplorazioni della gestione dei dati amministrativi fanno seguito piani, visioni, codici, perlopiù, alla fine, inattuati e disattesi. Nel Libro Bianco sull’Intelligenza Artificiale di AgID (2018), si diceva addirittura che l’IA avrebbe potuto facilitare l’intesa semantica delle amministrazioni nei loro scambi informativi. Il catalogo centrale di “connettori automatici” di cui si parla nel PNRR è forse un passo in questa direzione?
Umberto Eco, nel libro prima citato, avrebbe chiamato le API una forma, cioè una descrizione logica completa di qualcosa di ben identificato, come ad esempio le procedure amministrative con i loro dati caratteristici. Fondamentalmente, una API descrive il modo in cui un servizio deve essere attivato per mezzo di un programma informatico, nonché il modo in cui i dati che produce, a seguito dell’attivazione, vadano intesi dal programma stesso. Nel caso dei servizi di accesso ai dati, questo significa ad esempio definire il formato della query e dei valori ottenuti come risposta. Il catalogo centrale di API assume dunque l’aspetto di un elenco di forme, cioè una lista aperta di elementi chiusi.
Storia delle API, dagli anni ’70 a oggi
Le API di oggi sono la continuazione di mezzo secolo di storia.
Il genere di descrizioni formali a cui appartengono nasce agli albori della programmazione strutturata, negli anni ’70. Quando, negli anni ’80, i sistemi informatici iniziarono a distribuirsi e fare internet working, la descrizione delle interfacce applicative delle procedure remote (Remote Procedure Call) aggiunse un livello di astrazione rispetto ai singoli linguaggi di programmazione. Si iniziò allora a parlare di linguaggi descrittivi di interfacce applicative, che presero il nome di IDL- Interface Definition Language.
Negli anni ’90, la descrizione degli oggetti informatici distribuiti in rete venne affidata a middleware standardizzati come CORBA-Common Object Request Broker Architecture o proprietari come DCOM-Distributed Component Object Model, ciascuno legato a qualche linguaggio descrittivo. Negli anni 2000 l’internet working è passata sul web: sono nati i web service col loro WSDL – Web Service Definition Language.
PA e cataloghi: perché quello di vent’anni fa è più avanzato della proposta attuale
La PA italiana, fin dagli anni ’90, ha ragionato sull’uso degli IDL che l’industria le ha di volta in volta proposto. Un catalogo descrizioni di web service fu già predisposto ai tempi del Sistema Pubblico di Connettività, erano gli anni 2000. In che modo quel catalogo abbia favorito l’interoperabilità dei servizi pubblici ciascuno può oggi giudicarlo.
Sembra chiaro che l’elenco delle descrizioni delle interfacce applicative non potrà di per sé risolvere la situazione, ed è lecito chiedersi se valga la pena di spenderci molti soldi, visto anche che si possono mettere su anche gratis.
Il linguaggio descrittivo delle API, in genere, non offre nulla di specifico per quanto concerne l’interoperabilità. Anzi, rispetto a quello dei web services, fa un passo indietro, privilegiando gli aspetti tecnici, in primis la generazione automatica di codice, rispetto a quelli semantici, cioè di concettualizzazione del servizio. D’altra parte, le API sono pensate per servizi software logicamente centralizzati, cioè per il cloud computing, dove la semantica non è oggetto di alcuna negoziazione, essendo semplicemente imposta dal fornitore del servizio. Una situazione ben diversa da quel semantic web decentralizzato per cui i web services erano pensati.
Interoperabilità PA: senza un linguaggio comune, le traduzioni non basteranno
Aderire al modello delle API senza alcuna governance del modo in cui le interfacce applicative sono disegnate significherebbe di fatto che ciascuna amministrazione potrà adottare un proprio linguaggio, mantenendo intatta la Babele attuale.
L’eventualità che tali servizi vengano forniti in cloud, come auspica il Governo, non allevierebbe affatto il carico di dover provvedere complessi meccanismi di traduzione di tutti verso tutti per poter realizzare schemi di cooperazione applicativa.
L’idea di lasciare massima libertà espressiva ai singoli enti e guardare all’integrazione semantica, fondamentale per l’interoperabilità PA, come una annoyance da minimizzare con qualche artificio, se si affermasse, sarebbe particolarmente nefasta.
L’interoperabilità sarà ottenuta solo quando le singole sorgenti di dati e servizi si impegneranno verso un linguaggio comune, cioè un codice intersoggettivo che faccia da guida all’interpretazione. L’auspicio è che le ingenti risorse a disposizione vengano impiegate anche per costruire le condizioni sociotecniche necessarie a questo impegno, senza il quale il metallo del cloud resterà freddo e i cataloghi centrali serviranno al più a fare statistiche.
