Perché si dice che i dati sono un debito

I dati sono un debito. Di tanto in tanto capita di leggere un blog che sostiene questa tesi, e oggi mi tolgo lo sfizio di esserne l’autore.

Sia chiaro, i dati sono anche un patrimonio. Il paradosso si risolve dicendo che i dati permettono di estrarre informazione e conoscenza, che hanno senz’altro un grande valore, ma – al contempo – richiedono manutenzione e cura, il che genera costi notevoli. Questi costi vanno dalla banale archiviazione e backup, sino al rispetto delle norme (tutela dei dati personali, proprietà intellettuale), passando per la necessità di tenere i dati aggiornati (o, almeno, di essere consapevoli del livello di aggiornamento/obsolescenza degli stessi). A parità di informazione e conoscenza ottenute (saggezza, se ci va bene), saperlo fare con meno dati è quasi sempre un vantaggio. Un corollario abbastanza ovvio, con cui molti si sono scontrati, è quello secondo cui duplicare i dati è quasi sempre male. Lo sa bene chi si è trovato a dover ri-sincronizzare anche solo due rubriche di contatti telefonici ed email, che abbiano avuto per un certo periodo un’evoluzione separata su due device diversi.

Tutto questo non è contraddetto dal successo dell’approccio big data. Se si hanno a disposizione molta banda e grande capacità di calcolo, diventa spesso efficiente estrarre informazione e conoscenza da flussi di dati prodotti (e, se vogliamo, “curati”) da altri. Tanti dati sono belli, soprattutto se altri pagano gli interessi sul debito: così, il vantaggio di estrarre informazione da flussi di dati non strutturati che provengono dai social network è anche (e forse soprattutto) che il costo di mantenere i dati e/o le informazioni è scaricato su una moltitudine di utenti, mentre si cerca di estrarne conoscenza (saggezza?!?) quasi in tempo reale per via algoritmica. Evitando di accollarsi il debito legato alla “curatela” dei dati stessi.

A molti lettori non sarà sfuggito che questo ragionamento sui dati è un sostanziale plagio del meme “code is a liability”, secondo il quale – a parità di funzionalità realizzate e problemi risolti – ogni riga aggiuntiva di codice è un debito, il cui servizio sarà pagato a caro prezzo. Una ricerca per le keyword “technical debt” può fornire ulteriori spunti.

In effetti, i due debiti si sommano (si potrebbe dire, forse, si moltiplicano) nei casi in cui organizzazioni complesse estraggono informazioni e conoscenza da grandi moli di dati usando grandi moli di codice. Come minimo, laddove ci sono tanti dati, magari sparsi in molti database, ci sono abbastanza sistematicamente un gran numero di query SQL (lo strumento più comune per estrarre informazioni dai tradizionali database relazionali). È quasi proverbiale che, se si vogliono avere le risposte giuste, bisogna fare le domande giuste. E le query SQL sono il modo più comune di fare domande in informatica negli ultimi trent’anni. Ma tutta la saggezza che guida questa maieutica delle query SQL è sparsa dentro il codice di più e più software applicativi, spesso senza che esista nelle organizzazioni alcun repository comune, o qualsiasi altro modo di aver contezza di come si origini la conoscenza su cui si basano molte decisioni strategiche. E porsi una nuova domanda può comportare costi e tempi significativi.

Anche chi concordasse con buona parte di questa analisi potrebbe rispondermi: bene, e allora? Che alternative ci sono? Si possono estrarre un po’ di insights dai big data, ma ci si accolla comunque il debito tecnico del codice che li elabora, resta il problema delle query sparse nel codice (anche se magari con tecnologie no-SQL), e si aggiunge il problema della dipendenza dai provider che forniscono accesso ai dati stessi (il Twitter o Facebook di turno). Insomma, alla fine della fiera, le organizzazioni non possono che fare affidamento su un certo numero di applicativi e su tutte le loro implicite domande, stratificate in righe e righe di codice e query SQL.

In questi giorni, mi è capitato di leggere alcuni post di Mitch De Felice, che un’alternativa allo status quo la propongono in modo abbastanza lucido.

In quattro post, tra i quali Linked Data – The Foundation for Interchanging of Information , DeFelice individua tale alternativa nei linked data, il formalismo proposto dal W3C per rappresentare i dati sul Web: “ To build an information framework that allows interoperability of information in heterogeneous environments requires the adoption of a declarative model. A declarative model that can map directly into an implementation construct is the quintessential element that truly represents the disruptive changes required in the information management space. […]

By storing your use cases as triples into a triple store (a graph database), this will allow you to build an enterprise view of information that can be queried through the W3C SPARQL query language. RDF and SPARQL is open specification schema-less solution, which makes it much faster and easier to ask ad-hoc questions without the performance hit. ”

Cosa forse più interessante, in A.I. concierge services – realizing the promise of big data , DeFelice si concentra su un caso d’uso emergente specifico: il grande mercato che ha seguito l’introduzione dell’assistente personale Siri da parte di Apple sul suo iPhone, con la relativa rivoluzione della customer experience (in cui stanno investendo enormemente colossi come Google, Microsoft, e Amazon).

Ipotizziamo che, per interagire coi suoi dipendenti e/o coi clienti, un’azienda voglia sviluppare il suo “assistente digitale”, che sappia far leva sulla più gran parte possibile delle informazioni e della conoscenza contenuta nei sistemi informativi (e, diciamocelo, non è un’ipotesi così balzana: nei prossimi anni, molte aziende – incluse molte pubbliche amministrazioni – dovranno semplicemente farlo). Una via passa per lo sviluppo interno, un’altra per l’affidarsi a fornitori specializzati. In ogni caso, si tratta di anni di investimenti: nel primo caso (in house) si rischia di non saper tenere il passo della tecnologia che evolve; nel secondo caso (outsourcing) si fa una scelta difficilmente reversibile, perché il fornitore diventerà in effetti un partner strategico e difficilmente sostituibile. Insomma, si rischia un forte lock-in.

Che si proceda in house o in outsourcing, quello che DeFelice consiglia è di lavorare per rappresentare la conoscenza della propria organizzazione utilizzando i linked data, cioè lo standard Resource Description Framework (RDF). RDF non è semplicemente un formato (in effetti, più formati possono rappresentarlo): è un approccio per descrivere la conoscenza sulla base di affermazioni base, del tipo “soggetto, predicato, oggetto”, che mira a favorire l’interoperabilità. L’uso di RDF andrebbe abbinato a quello dei vocabolari standard, che si sono man mano affermati in modo decentralizzato (per una panoramica: lov.okfn.org). In tal modo, nel caso il proprio progetto interno proceda troppo lentamente, si potrà sempre dire di aver almeno iniziato un processo di standardizzazione e si potrà far ricorso a competenze esterne; qualora, invece, si faccia affidamento su un fornitore esterno, il lock-in sarà minore, grazie all’adozione di un formalismo standard. Insomma, “definendo i vostri dati rispetto agli standard aperti del W3C, avete in effetti implementato una polizza di assicurazione sui vostri dati!”

(Questo post è distribuito con Licenza Creative Commons Attribuzione 4.0 Internazionale .)