In questo post, vorrei provare ad analizzare e confrontare i concetti di open data, ciò che a volte ho chiamato open services e l’SPC Coop (Sistema Pubblico di Connettività – Cooperazione Applicativa). Ne parlo perché vorrei spiegare un punto al quale tengo molto: per far nascere servizi applicativi evoluti è vitale abilitare una interoperabilità vera tra i backend di sistemi informativi pubblici e privati. So che in poche righe non è facile illustrare tematiche così complesse (ho scritto tutto in mezz’ora in risposta ad una discussione su Twitter), ma spero di riuscire quanto meno a chiarire la relazione tra diversi concetti che spesso vengono mescolati in modo poco organico.

Cosa si intende per interoperabilità? Si intende la possibilità per un sistema informatico di invocare direttamente un servizio (spesso si tratta di un web service) offerto da un altro sistema informatico. Questa interazione diretta permette di costruire quello che si chiama mashup applicativo.

Facciamo un esempio. Guardate questa applicazione:

http://e015.infoblutraffic.com

È una applicazione sviluppata da Infoblu (società Autostrade). Per offrire questa funzionalità, l’applicazione invoca web services e servizi REST offerti da SEA, ATM, Trenord, Trenitalia, Serravalle. Il vantaggio per l’utente finale è che questa filosofia e architettura dà la possibilità a Infoblu (e agli altri attori) di costruire applicazioni molto più evolute che integrano dati e servizi offerti da una molteplicità di operatori. In questo caso, i servizi sono query che estraggono dati dai sistemi informatici dei vari operatori. Ovviamente, ciò può evolvere e includere servizi transazionali come, per esempio, la prenotazione o l’acquisto di un titolo di viaggio o di qualunque altro bene o servizio.

Il punto chiave è che per costruire questo tipo di applicazioni evolute su Internet serve appunto l’integrazione dei backend che è molto più che mettere link da un sito ad un altro (lo dico perché questa è l’interpretazione di integrazione dei backend che mi ha dato una volta un operatore del settore …).

Questa idea non è certo né nuova né mia.

Per esempio, ne parlò a fine anni novanta il mio maestro Prof. Alessandro Osnaghi, direttore del centro tecnico con l’allora Ministro Bassanini. A quell’epoca, tutti parlavano di portali e se ne fece poco. Morale, ci furono un sacco di portali che non avevano “radici diffuse” perché non erano in grado di interagire con gli altri sistemi. Ma per fare applicazioni che permettono, per esempio, un’unica dichiarazione di nascita che alimenta anagrafe, agenzia delle entrate e sistema sanitario, deve essere possibile per il sistema che riceve l’informazione del nuovo nato (tramite un sistema di frontend) propagare in automatico l’informazione verso gli altri sistemi: è un semplicissimo esempio di integrazione dei backend. Se vogliamo, la mancanza dell’integrazione dei backend era il peccato originale (non l’unico …) che ha fatto fallire il portale del Turismo.

A metà anni 2000, venne introdotto l’SPC Cooperazione Applicativa. È un modello di interazione basato su web services che permette l’interoperabilità a livello di backend, ma solo tra sistemi delle PA. Ovviamente, nulla vieta di usare ciò che sta alla base di SPC Coop (e cioè i web services) per operare anche con soggetti privati. Ma dal punto di vista giuridico, SPC Coop è utilizzabile solo tra PA (a meno che non ci siano stati cambiamenti recenti dei quali non sono a conoscenza). Inoltre, dal punto di vista tecnico-organizzativo l’SPC Coop è molto articolato e complesso. Nei fatti non si è molto sviluppato (anche per questioni legati alla privacy che discuterò in un altro post). Certamente, l’idea di fondo è giusta, ma va sviluppata e raffinata, anche tenendo conto di come le tecnologie di Internet si sono nel frattempo evolute.

In questi anni, molti hanno detto che per risolvere i problemi legati allo sviluppo di applicazioni su Internet si può utilizzare il concetto di open data. Di solito, con open data si intende un insieme di dati estratti da un sistema informatico (snapshot) e resi disponibili secondo una qualche licenza open (Creative Commons o similari). L’enfasi, in realtà, è quindi più sull’apertura e sulla trasparenza del sistema pubblico, che sulla interoperabilità e la costruzione di servizi applicativi evoluti.

Quali sono i vantaggi degli open data? Sono per l’appunto trasparenza, apertura, e anche la possibilità di sviluppare alcune tipologie di applicazioni basate sui dati resi così disponibili.

Quali sono gli svantaggi? Qui un po’ semplifico e so già che molti mi salteranno addosso, ma pazienza. Gli open data di solito sono snapshot estratti dal sistema informatico sorgente, quindi una copia. Quando accedo ad un open data, normalmente accedo a questo snapshot (quello che viene chiamato il dataset pubblicato sulla piattaforma per open data).

Vediamo per esempio quello che si dice qui (http://www.scribd.com/doc/55159307/Come-Si-Fa-Opendata-Ver-2):

Occorre quindi individuare delle precise e puntuali responsabilità, cioè definire non solo quale sia l’ufficio che ha in carico la creazione e l’aggiornamento di uno specifico dataset, ma anche chi debba farsi carico della sua disponibilità sulla piattaforma usata per la distribuzione dei dati dell’Ente. La tendenza è l’individuazione di una redazione centrale che si preoccupi della pubblicazione dei dati sulla piattaforma, crei i metadati fondamentali affinché essi siano utilizzabili e si ponga come obiettivo di agevolare la circolazione e l’uso produttivo delle informazioni condivise dall’Ente. La figura professionale è quella del data manager, in un certo senso parallela a quella che fu la figura del webmaster ai tempi della nascita dei primi siti Web.

È per esempio quello che avviene in diversi portali open data come quello recentemente realizzato dalla Regione Lombardia (basato su Socrata). Socrata, per esempio, usa questo processo di publishing.

Publishing workflow

Questo approccio ha due tipi di limitazioni:

  1. Non riesco ad accedere a informazioni presenti nel sistema informatico originario in tempo reale. Certo, posso estrarre i dati molto di frequente, ma è inefficiente e spesso impraticabile. Come potrebbe l’applicazione di Infoblu sapere i ritardi dei treni nel momento in cui l’utente ne fa richiesta? Trenord dovrebbe forse estrarre e pubblicare i dataset per tutti i treni ogni minuto o poco più?
  2. Non posso avere transazioni e servizi “bidirezionali”. Come potrebbe l’applicazione di Infoblu essere estesa per prenotare un posto su un Frecciarossa (per esempio), interagendo direttamente con il servizio di backend che permette la prenotazione?

In poche parole, gli open data vanno bene per fare alcune cose, ma sono alla fine delle copie pubbliche e “open” dei dati presenti nei sistemi informativi originari, ma pur sempre delle copie. Non sono sufficienti per fare una reale integrazione e interoperabilità dei backend. Questo non vuol dire che sono inutili: servono per fare alcune cose soprattutto legate alla trasparenza o ad applicazioni particolari, ma sono insufficienti per risolvere il problema nella sua generalità.

Non per niente, sia la recente direttiva di Obama, sia alcuni recenti sviluppi nel mercato indicano che dobbiamo puntare alla sviluppo di quella che alcuni chiamano “the API Economy”, cioè un sistema di API che permettano lo sviluppo di applicazioni interoperabili.

Per questo continuo a dire che, usando una espressione simile a open data, servono open services. Come ho avuto modo di dire in diverse occasioni, si tratta di riprendere i concetti della cooperazione applicativa (presenti per esempio nell’SPC Coop), estenderli alla cooperazione tra soggetti pubblici e privati e adattarli ai diversi bisogni (spesso semplificando ciò che si fa in SPC Coop). Per esempio, non ha alcun senso che per estrarre i dati sui ritardi dei treni debba usare tutte le regole e policies previste da SPC Coop. Allo stesso tempo, serve una standardizzazione se vogliamo abilitare un mashup diffuso. È quello che si sta facendo, per esempio, per Expo.

P.S.: Si noti che mettere una API per accedere a open data costruiti come abbiamo visto qui su non risolve il problema. Servono API che espongono i servizi del sistema informatico originario.