mercoledì 7 novembre 2012

Il baco di fondo degli open data

Molto interessante questo ragionamento, opportunamente tecnico su la reale fattibilità degli Open Data

 
 

Inviato da Massimo tramite Google Reader:

 
 

tramite alfonsofuggetta.it di Alfonso Fuggetta il 03/11/12

Ho deciso di scrivere questo post perché vedendo tante discussioni sugli open data mi rendo conto che c'è un baco di fondo che deve essere affrontato, spiegato e chiarito una volta per tutte (scusate l'ambizione). E sarò piuttosto netto, anche a rischio di spingere al limite alcuni ragionamenti. Ma credo sia quanto meno utile per ribilanciare una discussione che mi pare stia veramente divergendo.

L'interazione tra diverse componenti software è stata studiata fin dagli anni 70, quando Dave Parnas scrisse un articolo che costituisce un fondamento dell'informatica: "On the criteria to be used in decomposing systems into modules". Quell'articolo diceva che un sistema informatico deve essere costruito utilizzando i principi dell'information hiding e della separazione tra implementazione e interfaccia. In poche parole, è l'articolo che definisce alcuni dei fondamenti che hanno portato agli Abstract Data Types, la modularizzazione, la programmazione ad oggetti, C++, Java, CORBA e poi i web services.

In altri termini, si è definito il concetto di loose service coupling tra sistemi software in contrapposizione al data coupling (o common coupling) basato sulla condivisione di variabili globali. Da sempre si sa che il common coupling è una forma debole di interazione perché rende difficile l'integrazione dei sistemi, il loro sviluppo e la loro manutenzione e evoluzione.

Con gli open data, non solo si fa del common coupling, ma lo si fa su una copia dei dati, neanche le "global variable" originarie! Quindi è quanto di più contrario a ciò che 50 anni di esperienza e di ricerca in informatica ci hanno insegnato. E non è certo una soluzione dire che si "può pubblicare molto di frequente"!  Che vuol dire "frequente"? "Frequente" per chi? E chi gestisce le copie? E come si accede all'originale? … Pannicelli caldi che ignorano la questione di fondo.

Coupling

Perché siamo passati dall'assembler al C e poi al C++ e Java? Perché sono stati introdotti i Java Beans e poi i componenti e gli oggetti? Perché il grande Jim Gray studiò il concetto di transazione? Per sfizi teorici? No, perché l'esperienza innanzi tutto ci ha detto dove stavano i problemi, cosa fare e soprattutto cosa non fare. Abbiamo sviluppato quei linguaggi e quei sistemi per aumentare decoupling, information hiding, modularizzazione, componentizzazione. Perché sono stati introdotti prima CORBA e poi i web services? Per aumentare il decoupling. E per rendere il coupling sempre più basato sul "behavior", cioè sulla invocazione di servizi che rappresentano le funzioni offerte e non i dati gestiti.

Gli open data partono esattamente da un approccio opposto. Perché? Perché si sono considerate delle legittime esigenze e si è cercato di dare in modo immediato e impulsivo una risposta che è certamente debole, parziale, limitata. Le esigenze sono quelle della trasparenza, della decentralizzazione nello sviluppo dei sistemi software, della velocità e della tempestività nella risposta alle istanze e esigenze della società. Esigenze legittime, ma la risposta è solo un pannicello caldo. Anzi, rischia di essere un dannoso placebo. Perché?

Perché non risolve i problemi di fondo e in più complica a dismisura i processi di integrazione. Tanto è vero che adesso bisogna inventarsi cose come i "linked open data" per cercare di mettere una toppa al problema  che sta a monte: come incapsulare la semantica di dati e servizi e costruire un mashup applicativo aperto e p2p, cioè un service coupling aperto in ambito Internet e Extranet. Questo è il tema e questo dovrebbe essere il terreno di confronto. Invece si sceglie la strada semplice del "dammi i dati che hai", creandone copie, cercando una scorciatoia che non risolve i problemi di fondo e dà solo risposte fallaci, temporanee o a problemi molto specifici (lo ripeto a scanso di equivoci, alcune istanze sulla trasparenza e pubblicità dei dati sono condivisibili e quindi in alcuni casi gli open data sono utili).

Ma se ciò che vogliamo è una strategia vera di sviluppo dell'egovernment e dei servizi Internet evoluti dobbiamo puntare a creare un vero sistema di interoperabilità moderno e aperto. Partendo da ciò che c'è (come l'SPC e altre esperienze nel settore come quelle che stiamo facendo a Milano) e definendo una strategia lungimirante, completa e coerente sul tema.

Altrimenti,  è inutile stupirci se la febbre continua a salire e non "passa mai", cioè non ci sono servizi o sono frammentati e poco significativi. È ovvio: ci siamo accontentati di somministrare della tachipirina che ha "nascosto" la febbre invece di dare l'antibiotico che è necessario per uccidere la causa ultima dell'infezione.

Questo è anche l'effetto della propaganda del "i problemi non sono mai tecnologici". Certo, e così da "ignoranti" in materia (nel senso "tecnico" del termine) si continuano ad ignorare decenni di studi ed esperienze reinventando, se va bene, la ruota, spesso quadrata.

Vogliamo andare avanti così?


 
 

Operazioni consentite da qui:

 
 

Nessun commento: