Open data, open services, SPC Coop

Posted · 13 Comments

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.

13 Responses to "Open data, open services, SPC Coop"
  1. Andrea says:

    Per valutare l’efficacia o l’importamza di una soluzione e’ bene capirne gli usi per cui viene pensata e sviluppata. Gli open data si rivologono a due specifiche esigenze non in alternativa fra loro. La prima e’ la trasparenza ammnistrativa e open government per cui anche snapshot di dati con una frequenza di aggiornamento bassa possono essere utili (si pensi a open coesione ) gli utilizzatori di questi dati sono i cottadini eventualmente tramite giornalisti. Una seconda fascia di applicazioni e’ legata allo sviluppo di applicazioni che utilizzano gli open data. In questo caso gli open data sono informazioni in “sola lettura” che richiedono un elevato tasso di aggiornamento e in alcuni casi (info traffico) un aggiornamento in continuo. Mi sembra che in Italia si prediliga la prima visione degli open data che e’ piu’ diretta al cittadino elettore, meno alle imprese. E’ chiaro che per sviluppare talune applicazioni siano necessario “salire di livello” dall”integrazione dati al livelll applicativo (con web api) o a livello di interfaccia (mashup) ma chiaramente questo richiede da parte della pa un investimento non indifferente, non solo in termini economici, ma anche “culturali”. Mi sembra che gli open data (specie se visti come supporto ad applicazioni e non come open gov) possano essere uno modo per avvicinare le pa al mondo di business. Sicuramente e’ necessaria una regia unica a livello di pa per dirigiere il processo e evitare la solita polverizzazione di approcci e filosofie sviluppate dalle songole pa

    • Andrea, dissento sostanzialmente.

      Il refresh frequente dei dati per fare l’infomobilità è un espediente “vecchio” e non certo la soluzione. È una toppa.

      Siccome sei un collega, vorrei invitarti a riflettere su cosa abbiamo fatto noi ricercatori informatici negli ultimi 30 anni. Perché sono stati introdotti concetti come i tipi di dati astratti e le classi? Per evitare l’accesso diretto al dato, alla variabile globale, per disaccoppiare il bisogno dall’implementazione. Il “cliente” di un ADT (Abstract Data Type) NON DEVE sapere come è implementato un servizio. Può essere benissimo che quel servizio usi dei meccanismi di caching o di estrazione periodica, ma questo deve essere una scelta implementativa nascosta al fruitore del servizio. Questi concetti in informatica sono scontati e ovvi e non mi capacito come invece nel caso degli open data vengano regolarmente dimenticati. Tra l’altro, un open data non è nemmeno una variabile globale, ma una sua copia!

      Secondo me, il motivo di questa deriva risiede nel fatto che ancora una volta si è preso un concetto e lo si è trasformato in un totem ideologico, esattamente come è successo nel caso dell’open source, perdendo completamente di vista ciò che abbiamo imparato e studiato in decenni di sviluppo dell’informatica. Siccome si vuole un governo trasparente (giusto!) e siccome gli open data possono contribuire (vero) allora tutto deve essere open data e qualunque altra cosa, per distorta correlazione logica, viene vista come un tentativo di limitare la trasparenza.

      Io credo che noi informatici per primi dobbiamo spiegare come stanno le cose senza farci condizionare dalla maledetta ideologia.

      • Andrea says:

        Da quanto possa aver capito un’organizzazione si apre alle altre tramite interfacce di integrazione quando vi trova una sua convenienza/necessita’/obbligo. Ora nella pa e’ ancora fortissima l’idea che l’obiettivo della pa e’ lo svolgomento di procedimenti amministrativi stando attenti solo al rispetto delle regole formali. Solo recentemente l’idea di pa come erogatore di servizi di pubblica utilita’ sista facendo strada anche nei livello dirigenziali della pa (centrali e locali). Per la prima visione non e’ fondamentale integrarsi con altre pa o aprirsi alle aziende a meno che non c’e’ una norma che lo impone (e nel caso lo si fa controvoglia). Il tema degli open data puo’ essere un ennesimo tentativo di far vedere che la pa e’ molto di piu’ di processi amministrativi. Il problema vero, come hai sollevato tante volte, e’ che in Italia open data sta diventando un feticcio come se possa risolvere tutti i problemi del nostro paese con il rischio di sovraccaricarlo di aspettative provocando come una reazione di sfiducia e aperta ostilita’ al tema nei prossimi anni quando si capiranno i limiti intrinsechi degli open data. La mancanza di visione strategica dell it nella pa come hai fatto notare in un altro posto e’ il cuore del problema da cui viene tutto il resto.

  2. Luigi Reggi says:

    Caro professore grazie per questo post molto chiaro ed efficace!

    Due cose, IMHO:

    1) SPC Coop mi è sempre sembrato, dai tempi in cui stavo al CNIPA, di una complicazione esagerata! Premetto però che non sono un informatico :))
    Soprattutto credo che, da quanto ne so, il suo fallimento derivi da problemi di collaborazione tra il livello nazionale e regionale/locale, per cui le regioni a un certo punto hanno attivato propri progetti alternativi per la coop applicativa (es. ICAR).
    Da qui la mia domanda: se il pre-requisito è la collaborazione fattiva tra autonomie, come la garantiamo? Come facciamo a definire standard comuni accettabili per tutti? Come non cedere ad una deriva “centralista”, sempre che sia giuridicamente applicabile?

    2) Sono d’accordo che “open data” inteso come “tutte le PA rislascino i dati in CSV” è utile ma non sufficiente. E’ vero anche che ci sono (molti? pochi?) “evangelist” di casa nostra che si limitano a lanciare questo messaggio alle amministrazioni e ai politici senza andare oltre.
    E’ vero anche, però, che molti cittadini/attivisti hanno ben presente che API e web services sono il “next step” rispetto al semplice rilascio snapshot in una ipotetica scala lineare di qualità dei dati rilasciati (stages, stelline, etc. a seconda dei gusti).
    Di esempi ce ne sono vari, ne cito alcuni.
    Sulla mailing list di Spaghetti Open Data le “review” non ufficiali ai vari portali open data (es. regione lombardia, provincia di roma, comune di milano e roma, etc.) si sono basate sulla presenza dei meccanismi di pubblicazione del tipo citato (socrata ma non solo). Inoltre, nella mia recente esperienza di apertura dei dati sulle politiche di coesione, il “real time” è difficile da ottenere per problemi di gestione interna ma è un obiettivo a tendere, un input arrivato dal ministro stesso. In francia ad esempio sono già un po’ più avanti almeno come back-end. Il PON Ricerca e Competitività sta pensando concretamente di attivare API.. chiaramente non è una priorità assoluta visto il tipo di dati e l’uso che se ne fa.

    • 1. Complicazione SPC
      È esattamente quello che intendevo dicendo che dobbiamo pensare a soluzioni che semplifichino, almeno in alcuni casi, l’SPC e lo aprano ai privati.

      2. Motivi del non decollo
      Credo ci sia un tema legato alla privacy che sto studiando e di cui voglio scrivere a breve.

      3. Come facciamo a collaborare?
      Per gli standard guardi quello che abbiamo fatto per Expo. E anche al modello che abbiamo usato sia per definire gli standard che per organizzare la partecipazione dei soggetti all’ecosistema.

      4. Evangelisti open data che parlano solo di quello
      Lo so. È la nuova ondata post open source. È ciò a cui mi riferivo nel mio post e nel commento ad Andrea.

      5. API
      È importante secondo me il commento che ho messo in P.S. nel post: non basta mettere API sul dataset pubblicato. Non è vera interoperabilità, è un piccolo passo avanti.

      6. API come priorità
      Deve essere una priorità. Se no le applicazioni tipo quelle per smartcity non le faremo mai.

  3. Giorgia says:

    Ho letto con interesse il post e i relativi commenti. Come accennavo su twitter, da informatica mi ritrovo in molti punti evidenziati dal prof. Fuggetta: di recente, a un workshop organizzato all’interno dello Smart City Exhibition su open city al quale ho partecipato ci è stato chiesto di scegliere tre parole per noi significative che avrebbero poi costituito una tag cloud sull’argomento. Le mie sono state interoperabilità, integrazione e sostenibilità. Leggendo il post le prime due me le ritrovo scritte a chiari lettere mentre la terza secondo me è implicita in diversi punti.
    Fatta questa premessa tuttavia, come scrivevo, IMHO ci sono dei “ma” da considerare che riguardano sia il tema open data, che il tema SPCoop.
    Parto da SPCoop, forse meno complesso (sempre da informatica). Non penso il problema del “non decollo” sia derivante dalla privacy. Come detta anche da alcuni miei colleghi in Agenzia (ex DigitPA), in molti casi non ci siamo nemmeno arrivati a questo punto! E penso pure che non sia un problema di “collaborazione tra il livello nazionale e regionale/locale, per cui le regioni a un certo punto hanno attivato propri progetti alternativi per la coop applicativa (es. ICAR)”. Anzi, qui è proprio diverso: da quello che ne so ICAR è un progetto cofinanziato dall’allora CNIPA per portare SPCoop nei territori! Questi progetti seguono comunque le linee guida e le regole tecniche nazionali approvate dalla Commissione di Coordinamento SPC che vede una rappresentanza anche locale. A tal riguardo, alcuni sforzi sono stati fatti per evidenziare la cooperazione tra ciò sviluppato a livello locale e quello fatto a livello più centrale (forse non si ritrovano facilmente, ma linee guida che parlano di queste problematiche sono state approvate dalla Commissione SPC e sono pubblicamente disponibili al sito ex DigitPA da un po’ di mesi).
    Il punto è che le PA hanno sviluppato servizi usando web services ma questi servizi non li pubblicano nel registro SICA, nonostante la norma dica di farlo. Perché? Forse è una questione di cultura e di un certo tipo di pratica comune difficile da cambiare. Quello che ho notato nella mia breve (per il momento) esperienza nella PA è che si è ancorati a prassi passate, che magari sono più dispendiose, più farraginose ma hanno funzionato, e quindi perché andare verso qualcosa di nuovo? Il nuovo (e poi tanto nuovo non lo è più!!) spaventa e si preferisce lasciar perdere. Da notare, il nuovo spaventa anche quelli che dovrebbero promuovere le cose nuove e innovative! Nelle recenti norme poi il Sistema Pubblico di Connettività, che dovrebbe essere un sistema da valorizzare e sicuramente da far evolvere verso nuove direzioni, viene molto poco menzionato (basti guardare la parte smart communties del decreto crescita 2.0!).
    Per il tema open data, sono piuttosto allineata con quanto scritto dal professore. E’ vero, sono uno snapshot di basi di dati. Tuttavia, anche qui vedo dei “ma”. Mettere tanti pdf sul sito istituzionale o anche tanti csv con dati derivati da tabelle di una base di dati, è sicuramente opera di trasparenza (ed è bene che ci sia nel nostro paese, guardate opencoesione) ma poi? Il punto è che bisogna, anche in questo caso, porre l’enfasi sul concetto di interoperabilità, e gli strumenti ci sono. Le recenti linee guida su interoperabilità semantica attraverso i linked open data, che a breve rilasceremo nella loro versione finale, vanno proprio in questa direzione. C’e’ una moda è vero, c’e’ un’onda, proviamo a cavalcare quest’onda per iniziare ad andare oltre quello che si è fatto fin qui e concepire un nuovo modo di trattare i dati, attribuendogli una semantica, facendo così capire che l’indice della PA (IPA) ha un’amministrazione accreditata CNR che è la stessa amministrazione che il CNR descrive dettagliatamente nella sua struttura, e che le amministrazioni accreditate presso l’indice della PA sono definite esattamente come sono definiti gli organismi pubblici, che so, in Grecia, in Germania. Il secondo “ma” deriva dalla mia esperienza pratica su SPCData. Proprio ragionando sulla semantica dei dati, ci siamo scontrati con tanti errori e con modellazioni non sempre appropriate o ancora peggio inesistenti, dove spesso non si ragiona in una logica di sistema. Quindi: se provassimo a usare questi strumenti anche per i dati non necessariamente pubblici? Non sarebbe più “facile” poi costruire quell’insieme di servizi (non solo nazionali) di cui abbiamo realmente bisogno?

    • Devo dire che non capisco molto i “ma”, nel senso che “ma” vuol dire differenza o un qualche dissenso. Non mi pare ce ne siano.

      Per quanto riguarda il primo punto:

      > Il punto è che le PA hanno sviluppato servizi usando web services ma
      > questi servizi non li pubblicano nel registro SICA, nonostante la
      > norma dica di farlo

      Appunto, perché? Ci sono tanti possibili motivi. Non ho detto che la privacy sia l’unico. Comunque, ci torno con calma.

      Per quanto riguarda gli open data, non ho detto che sono del tutto inutili. Per me sono un pannicello caldo. Ma ci torno con un altro post sul tema.

      P.S.: Il mio blog è moderato. Quindi deve darmi il tempo di vedere il commento per poterlo approvare.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>