Domande non risposte sono il futuro dei data scientist?

La domanda da cui parte questo post sembra allo stato attuale poco più che una provocazione ma se si analizza con attenzione il fenomeno big data potrebbe non esserlo tra poco.
Per spiegare il concetto in un intervento sui possibili futuri della datascience ho rielaborato una slide di una recente mia presentazione pubblica in cui evidenziavo le attività principali del data scientist.
DataScience
In questa analisi evidenziavo come i processi sempre più strategici sono, nella modellazione a cinque step, il primo e l’ultimo cioè il porsi le domande giuste e comunicare i risultati in maniera efficace.
Certo la mia considerazione non vuole svilire i passaggi forse più tipici e anche più tecnici della datascience ma vuole evidenziare quali sono oggi e sempre più in futuro gli skill che serviranno a rendere “utile” un progetto o prodotto ad alto contenuto di dati e algoritmi.
Data-intelligence e data-telling saranno fattori chiave per due motivi fondamentali:

1) Oggi all’interno delle aziende e della società  i team di data scientist sono percepiti, magari non sempre a torto, come un circolo di iniziati. Questo non favorisce l’integrazione dei data scientist per esempio in ambito aziendale con strutture più vicino ai clienti o agli utenti escludendoli dal contesto dove è presente il processo creativo delle domande “interessanti”, quelle che partendo dal contesto e quindi dai dati creano prodotti innovativi o risolvono problemi alla comunità (data-intelligence). In aggiunta la comunicazione e il racconto (data-telling) dei risultati ottenuti dalla analisi dei dati e dalla creazione di modelli diventa importante per trasmettere il valore della risposta e a stimolare, in un circolo virtuoso e agile, le successive domande “intelligenti”. Ecco che la data-intelligence e il data-telling diventano gli strumenti per i data scientist per entrare sempre di più nel centro dei sistemi decisionali aziendali contribuendo a realizzare quel concetto di “data-driven organization” che è il presente di poche organizzazioni ma che deve essere il futuro di tutte quelle che vogliono averlo (il futuro). Essendo, almeno per ancora qualche decennio (Kurzweil permettendo), immersi in organizzazioni fatte di persone umane è fondamentale fare crescere i due skill dei datascientist che hanno a che fare con la relazione con altri team e con la società civile.

2) Il trend di miglioramento tecnologico che afferisce ai tre step centrali della datascience, e cioè ottenere i dati, lavorarli e creare algoritmi, è in crescita esponenziale. Visti i massicci investimenti che in tutto il mondo start-up e grande aziende stanno mettendo in questa area assistiamo all’uscita sul mercato di tantissimi strumenti nuovi che hanno come obiettivo la facilitazione se non in alcuni casi il tentativo di automatizzazione di ciascuno di questi step. Senza spingerci a estremi ancora lontani, vedi l’algoritmo definivo , già oggi il tempo che ciascun data scientist deve dedicare alle parti centrali del processo si è sensibilmente ridotto e non è facile immaginare un miglioramento incrementale veloce nei prossimi anni. Non ritengo, come scritto in questo peraltro interessante articolo, che il lavoro dei data scientist possa essere automatizzato entro il 2025 ma sono invece convinto che si sposterà pesantemente dal punto di vista della distribuzione del tempo sicuramente verso gli estremi.

Solo il futuro saprà togliere il punto interrogativo alla domanda da cui siamo partiti ma mi sento di condividere quello che il sociologo Derrick de Kerckove scrive nel consigliatissimo piccolo saggio “la rete ci renderà stupidi?”  sull’importanza di allenare alcuni skill piuttosto di altri :

“Nell’era dei big data, le risposte dipendono unicamente dalle domande. Meglio imparare a fare bene le domande che a dare le risposte, benchè giuste”

 

Domande non risposte sono il futuro dei data scientist?

Ma di chi sono i big data? e chi li regola?

Sono chiaro fin dall’inizio: non riuscirò a rispondere completamente a questa provocatoria domanda in questo post ma vorrei partire da questo interrogativo per esplorare e stimolare la discussione su alcune tematiche legali sempre più cruciali per l’importanza che i dati stanno assumendo sia a livello economico sia all’interno della nostra vita.
Il 1° Giugno al Polo Tecnologico di Pavia ho tenuto una conferenza sul tema Big Data cercando di incrociare e raccontare una serie di tematiche non solo tecnologiche del fenomeno. Come si può vedere dalle slides presenti sul mio profilo di SlideShare ma anche dal numero elevato di domande e di interventi all’evento, argomenti come la proprietà dei dati e la modalità con cui questi sono gestiti e utilizzati sta diventando oggetto di attenzione anche da parte di noi “consumatori” e non più solo delle aziende.
Questa attenzione è sicuramente aumentata nel corso del tempo perchè il volume dei dati disponibili è cresciuto grazie e soprattutto alle nostre interazioni nel web (web 2.0) e a quello delle nostre cose (Internet of Things)

Dati_BigData Diventa quindi lecita la domanda: ma di chi è la proprietà di questi dati? Per esempio di chi è la proprietà dei dati relativi ai comportamenti di guida raccolti dalle scatole nere sempre più presenti sulle nostre automobili e che influenzano il prezzo delle nostre polizze assicurative? Di chi li genera cioè nostri? Di chi è proprietario dello strumento di raccolta? Delle compagnie assicurative che li usano? Oppure di chi è la proprietà del  dato relativo ad un like di un nostro amico  su un nostro post di Facebook? del nostro amico? di chi ha scritto il post cioè noi? di Facebook stessa che ha memorizzato il dato?
Alla conferenza l’amico nonchè giurista Simone Aliprandi proponeva la puntuale e corretta risposta “i dati non sono di nessuno” spostando giustamente l’accento sul concetto più proprio di banca dati (e quindi per quanto riguarda l’Europa del “diritto sui generis“) e su quello di copyright (diritto d’autore) delle informazioni che nascono da connessione creative degli stessi dati.  Questa è un’ottima risposta sul piano legale ma che non è facile risolvere univocamente  al pari di un’equazione matematica per chi lavora in ambito dati e deve ricondurla nella concretezza del suo contesto/progetto. Oltre a questi due “ostici” concetti (banca dati e diritto d’autore) si aggiungono, quando si parla di big data e in più in generali di dati, le problematiche legate al diritto alla privacy e all’oblio.
Privacy e oblio hanno avuto una dilatazione spazio-temporale con l’avvento di Internet per una serie di motivi precisi che provo ad elencare:
1) i motori di ricerca hanno reso disponibile il dato in qualunque parte del mondo  ci sia un accesso alla rete.
2) la memoria digitale, la replicazione esponenziale dei dati e i motori di ricerca stessi hanno dilatato lo spazio temporale in cui i dati e le informazioni possono essere ricercate e reso assolutamente economica la ricerca stessa. Fino a meno di 30 anni fa solo pochi luoghi, le biblioteche in primis, consentivano le ricerche all’interno di documenti cartacei in maniera abbastanza estesa (scala nazionale).
3) gli algoritmi dei motori di ricerca in qualunque ambito hanno e continuano a migliorare la ricerca utilizzando sempre di più la grande mole di dati relativi agli ambiti in cui stiamo cercando. Emblematico è il caso segnalato dal giurista Carlo Piana in questo articolo e relativo all’uso che viene fatto dei big data da parte dell’algoritmo di autocompletamento di Google per migliorare la nostra ricerca e che incappa, a volte, anche in contestazioni legali.

In questo contesto, in presenza di regolamentazioni nazionali profondamenti differenti, non è strano che Internet sia diventato un ente sovrannazionale che spesso sovverte le regole presenti e le “big corporation” che dominano i servizi sulla rete diventano loro stesse  giudici gestendo per esempio il diritto all’oblio. Non è un caso che nel 2014 con una sentenza storica la corte di giustizia Europea abbia obbligato Google (e non il gestore del server dove era presente il documento) a de-indicizzare un documento contenente informazioni relativo ad un pignoramento immobiliare di un cittadino spagnolo. In questo contesto Google è diventato di fatto giudice di se stesso, stabilendo chi possa o meno avere diritto all’oblio.
Post3In questo contesto molto “liquido” e con una regolamentazione disomogenea a livello mondiale ma in cui i servizi a base “big data” vengono gestiti, realizzati ed erogati  in  aziende e/o  datacenter di tutto il mondo è stata approvata nel Maggio 2016 la nuova data-protection law europea che nell’arco di due anni deve essere recepita da tutti gli stati membri.

post5

Per una volta la comunicazione dei contenuti dell’ambiziosa normativa è stato curato abbastanza bene e nel sito sono disponibili documenti (factshhets) che sinteticamente e con un lessico non estremamente complesso cercano di far comprendere l’utilità e lo scopo della nuova regolamentazione a tutti gli stakeholder.
Cerco di seguito di evidenziare i punti più importanti del regolamento perchè in parte prova a rispondere alla domanda iniziale del post, cioè chi regolamenta i big data:

  1. il diritto all’oblio : specifica in dettaglio come deve essere consentito a ciascuna persona il diritto a gestire i propri dati presenti on-line.
  2. data-protection by default: le proprietà relative alla condivisione dei dati (per esempio nei social network) devono essere il più cautelative possibili nelle condizioni standard, lasciando solo all’esplicità volontà dell’utente allargarne le maglie.
  3. data-protection by design: fin dalla fasi di progettazione di un servizio gli aspetti relativi alla protezione dei dati personali devono essere esplicitamente considerate.
  4. interoperabilità dei dati: deve essere facilitato al consumatore il passaggio dei propri dati da un servizio ad un altro analogo definendo standard di interoperabilità. Deve essere possibile, per esempio, come evidenziato da Ernesto Belisario al data-driven innovation summit di Roma, passare i propri dati storici della corsa da Runtastic a Strava in maniera semplice e veloce senza alcuna barriera.
  5. Armonizzazione delle leggi sulla protezione dei dati all’interno della UE: non potranno esistere all’interno dell’UE stati con leggi diverse relativamente a questo ambito legislativo.
  6. Adeguamento al rispetto delle leggi UE anche dei paesi non UE per poter erogare servizi a cittadini UE: di fatto questo obbliga le grandi Corporation americane a rispettare questa normativa pena la perdita del mercato europeo. L’applicazione di questo punto sarà una vera scommessa e sono molto curioso di vedere cosa succederà in concreto.
  7. Semplificazione normativa: si vorrebbe aumentare la consapevolezza del cittadino e del consumatore in tema di protezione dei propri dati semplificando la scrittura e quindi la compresione dei documenti di consenso e trattamento dei dati personali.
  8. Big data enabler: aumentando la fiducia dei consumatori si pensa che questa data protection law potrebbe favorire l’uso dei dati e quindi l’allargamento del mercato dei servizi. Questo punto dipenderà molto da quanto saremo bravi in Europa a concretizzare questo regolamento e a renderlo veramente semplice e facile da adottare da parte delle imprese non facendolo rimanere terreno per adepti

Post2

I prossimi due anni saranno molto importanti per verificare se, anche in Europa, sapremo finalmente superare la dicotomia tra tecnologia e legge supportando la crescita anche in questo ambito e andando oltre il pasticcio improduttivo della cookie law

Ma di chi sono i big data? e chi li regola?

Perchè le API sono necessarie in un mondo “big data” che cerca di decentralizzarsi

Come avevo scritto qualche settimana fa  la decentralizzazione è il cuore pulsante dei big data o meglio di quel fenomeno che a partire dagli anni ’90 attraverso la nascita del web ha accelerato la creazione di quello che in un eccellente libro , Stefano Quintarelli ha definito il nostro “futuro immateriale”.
Quasi quattro anni (Agosto 2012) sono passati da quando Forbes in un celebre articolo dal titolo “Welcome to the API economy” annunciava la sempre più forte centralità di questo paradigma che si stava affermando  non solo dal punto di vista tecnologico ma anche da quello economico, culturale e sociale.

Api
Ma partiamo dalla definizione di Wikipedia che descrive le API come un “insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di un certo programma”: nulla di nuovo rispetto a quello che succedeva anche qualche decennio fa in campo informatico. Ma quello che è cambiato negli ultimi 15 anni e che ne ha fatto crescere l’importanza in maniera progressiva sono stati queste “piccole” evoluzioni tecnologiche:
l’utilizzo del procollo http che ha portato le api a poter sfruttare la rete per interconnettere applicazioni e sistemi distribuiti sulla rete internet (Web service)
l’evoluzione del fenomeno mobile che ha moltiplicato i sistemi distribuiti in rete (smartphone e ora anche Internet of Things) che necessitano di scambiarsi dati in modo resiliente e veloce. Da qui l’evoluzione delle API verso il paradigma REST e dal formato XML a quello Json, più leggero e meglio gestibile dalle applicazioni.
la crescita enorme di dati generati e quindi disponibili (fenomeno Big data) che ha reso fortemente economico gestire il relativo scambio senza flussi massivi ma con veloci e leggere interfacce e transazioni quando gli utenti (uomini o macchine) ne hanno bisogno e questi sono disponibili in qualunque server in giro per il mondo.

APIFramework

Questa evoluzione tecnologica delle API ha facilitato da una lato il superamento di una serie di problematiche funzionali e di business e dall’altro ha consentito di creare nuovi mercati dove nel giro di poco tempo aziende da piccole start-up si sono trasformate in colossi economici mondiali. Di seguito proviamo ad elencare i 7 principali benefici e casi d’uso che afferiscono al paradigma della API economy:

1) Sicuramente la monetizzazione di asset strategici e immateriali quali dati, informazioni e algoritmi ha avuto dalla diffusione di uso delle API un’accelerazione enorme. Questo ha portato dall’inizio degli anni 2000 alla creazione di aziende che hanno fondato una parte considerevole del loro business su questo tipologia di transazioni. E’ il caso per esempio di Twitter che ha in questo tipo di business una delle componenti più importanti del suo fatturato. Ma anche Google e Facebook hanno ulteriormente accelerato in questa direzione recentemente creando prodotti sulla base di algoritmi creati per realizzare prodotti per i propri clienti: il caso del recente lancio delle Vision Api di Google ne è un caso emblematico. Ma anche aziende più tradizionali, che non nascono con il Web, come il New York Times stanno spingendo molto nel creare piattaforme API che facilitino l’integrazione e l’uso dei propri asset. Data e information provider in giro per il mondo traggono ovviamente grossi benefici da questa evoluzione tecnologica che facilita la diffusione dei propri asset in maniera liquida: il portale API di Dun & Bradstreet ne è un ottimo esempio perchè evidenzia la capacità di integrare in un marketplace anche dati esterni (di altri data-provider) concretizzando quello che mi piace definire come il “dato aumentato”.

2) La distribuzione e conseguente decentralizzazione che il paradigma API ha portato è stato sicuramente abilitante alla sempre più forte diffusione del Cloud nelle sue diverse forme comprese quella ibrida. Poter integrare facilmente diverse API nelle proprie soluzioni permette di cogliere tutti i benefici di scalabilità del Cloud quando per specifiche API si evidenza necessità di performance molto variabili nel tempo. Sulla facilità di integrazione proprio delle API, semplificando la complessità architetturale sottostante, ha creato la sua posizione dominante la soluzione cloud di Amazon che ha non a caso il nome Amazon Web Services. Bluemix di IBM è un altro esempio dove API Economy e Cloud si fondono per dar vita ad un tentativo di facilitare l’innovazione facendo incontrare in maniera virtuosa domanda e offerta.

3) La capacità di integrare API di terze parti costruendo un’esperienza di valore per segmenti di utenti/mercati è un’altra tendenza abilitata dalla API economy. Molte aziende stanno creando o espandendo i propri business sfruttando questo paradigma. Forse il caso più recente ed ecclatante è quello di Slack, una piattaforma di team collaboration orientata al mondo tech, che ha fatto dell’integrazione con altri servizi  e con la possibilità addirittura di crearli ex-novo la forse primaria ragione di successo portandolo ad una diffusione veloce  (2.7 milioni di uenti attivi al giorno, inclusi 800.000 utenti a pagamento) e di conseguenza ad una valutazione elevatissima di circa 3,8 miliardi di dollari. Ma anche Uber ha per esempio aperto una piattaforma API per consentire a terze parti di sfruttare la sua flotta per le consegne, un uso creativo e innovativo del proprio asset immateriale.

4) L’utilizzo di framework API anche all’interno di organizzazioni strutturate e dove il tempo ha costruito, soprattutto a livello dati, silos molto difficili da superare è una altra direzione di applicazione molto interessante. Nei casi in cui non è necessaria una integrazione diretta a livello di sistema di persistenza del dato le API consentono di far dialogare diversi sistemi dipartimentali evitando costosi progetti di integrazione rendendo tra l’altro possibile la reingegnerizzazione di sistemi legacy per fasi successive. SalesForce ha creato una straordinaria storia di successo sulla base del superamento attarverso la propria applicazioni di silos dati aziendali che confluiscono nella sua soluzione automatizzando tutta la parte di gestione delle reti commerciali. E lo ha fatto integrando nella sua piattaforma, spesso via API,  dati sia dai silos aziendali sia da servizi di altri fornitori.

5) Il fenomeno OpenData trova nella forma di utilizzo via API la forma migliore per garantire l’utilizzo del dato in real time (non fattibile utilizzando forme batch come i file csv) e per l’interoperabilità in applicazioni di facile uso da parte degli utenti, come più volte evidenziato da Alfonso Fuggetta. In area anglosassone i portali api sono ormai ampiamenti diffusi nelle pubbliche amministrazioni sia locali che nazionali. Ne sono uno splendido esempio quello della città e dello stato di New York. Anche in Italia qualcosa si sta muovendo a traino dei casi più interessanti come quello dei dati relativi ai fondi strutturali erogati dalla Unione Europea ed esposti dal sito  Open Coesione.

6) Per favorire uno sviluppo di applicazioni in modo agile, incrementale e modulare le API sono un ottimo strumento che consente di definire in itinere il Minimum Viable Product (MVP) permettendo di integrare nelle applicazione i servizi più a valore e testando con i Clienti direttamente sul campo il loro utilizzo. L’integrazione di API rest oltre a disaccoppiare i sistemi consente una modalità più semplice di gestire l’interattività tra team diversi di sviluppo magari localizzati in aree diverse del globo. Le API sono un facilitatore del paradigma agile consentendo un time to market più veloce al business.

7) Si stanno anche creando anche marketplace specifici, con propri modeli di business, che aggregano API di terze parte consentendo a sviluppatori, accedendo ad un solo ambiente di trovare diverse soluzioni per differenti problemi. Oltre al caso già citato di Bluemix un esempio eccellente di origine italiana ma trapiantato in Silicon Valley è quello di Mashape che oltre ad offrire l’infrastruttura per pubblicare API private (come per esempio anche Apigee) fornisce anche un “mercato” dove si possono pubblicare API per vendita diretta di dati e servizi. Ad oggi ce ne sono più di 1350 pubblicate in questa forma

Insomma i motivi per entrare nella API economy sono tanti: l’interoperabilità tra sistemi, aziende e team di sviluppo è sicuramente il più importante ma non è facile  trarne beneficio perchè non è solo una questione tecnologica ma di cultura e di visione di business. Insomma come recita un famoso aforisma di W.Gibson “il futuro è già qui, solo che non è distribuito in maniera uniforme”.

 

 

Perchè le API sono necessarie in un mondo “big data” che cerca di decentralizzarsi

Popper, Datascience & Lego: “Tutta la vita è risolvere problemi”

Ho sempre amato Popper, uno dei più importante filosofi della scienza, sia per il celebre principio di falsificabilità che è alla base della distinzione tra scienze e pseudoscienze, sia per la critica all’induzionismo estremo. Sintetizzando questo concetto egli sostiene che non basta osservare ma bisogna sapere cosa osservare. In questo senso la deduzione, che si nutre anche dell’osservazione non passiva della realtà, svolge un ruolo fondamentale nella creazione di teorie scientifiche e nella risoluzione di problemi. Questo processo è stato reso particolarmente evidente in due recenti e mediatiche scoperte scientifiche quali quelle del bosone di Higgs e delle onde gravitazionali, in cui la deduzione (fisica teorica) è stata confermata dalla induzione (fisica sperimentale) a distanza di molto tempo. E in questi processi di verifica induttiva la datascience ha avuto un’importanza fondamentale visto che tecnologia, algoritmi e specialisti di analisi dati la fanno ormai da padroni in questi grandi esperimenti. Anche nei processi deduttivi l’osservazione dei dati, soprattutto se guidata da una conoscenza del contesto e del problema che si vuole risolvere, porta un supporto importante nella realizzazione di quegli schemi mentali creativi necessari alla definizione di ogni teoria scientifica falsificabile.
Ma la citazione di Popper nel titolo del post fa riferimento anche ad un aspetto specifico e critico nell’utilizzo della datascience e in particolare alla domanda, che mi capita sempre meno spesso di sentire, su quale sia il punto di partenza di qualsiasi progetto relativo ai dati e in particolare quelli per i quali “sprechiamo” l’attributo Big Data.
Non ho alcun dubbio nell’indicare che sia fondamentale partire da un problema implicito o esplicito (chiarirò più avanti il concetto) degli stakeholder del progetto: il Cliente nei progetti di business o i Decision maker e la Comunità stessa in progetti non commerciali.

Sicuramente estremamente errato è partire dalla infrastruttura tecnologica. Cito a questo proposito un bellissimo post “Put data Science before Data Infrastructure” di  David Johnston, datascientist di Thoughworks che evidenzia come una qualità fondamentale per ogni analisi dei dati è sapere cosa osservare e perchè osservarlo.

DataScience1

Certamente molte tecnologie “Big Data”, cito l’ecosistema Hadoop per esempio, sono abilitanti ma non bisogna dimenticare che sono solo un mezzo, una condizione in alcuni casi necessaria ma mai sufficiente al buon risultato finale.

Talvolta è certamente possibile partire dai dati, soprattutto quando una vera domanda da parte degli stakeholder non esiste o meglio è implicita perchè questi ultimi non sono in grado di identificarne l’esistenza. Sicuramente la crescita esponenziale della disponibilità di dati può aumentare queste situazioni ma come punto di partenza diventa molto rischioso soprattutto in ottica business per gli investimenti correlati a questi progetti che possono non trovare un mercato. Questa è la via intrapresa da Linkedin nei suoi primi anni di vita quando, trovatosi grandissime moli di dati relativi a professionisti di tutto il mondo, ha lasciato che i datascientist interni realizzassero prodotti basati sui dati (soprattutto in ambito soluzioni per Human Resources) che il marketing tradizionale e i potenziali Clienti non riuscivano neppure ad immaginare. Certamente quando si riescono a creare prodotti (risolvere problemi) vincenti in questo modo l’oceano blu che si apre nel mercato è veramente importante. Ma sono poche le aziende che, per cultura e per organizzazione, riescono a sfruttare queste situazioni.

In altri casi è possibile partire dagli algoritmi per capire se è possibile far emergere dai dati (anche i “soliti dati”) delle situazioni (pattern) che possano rispondere a problemi impliciti o espliciti di Clienti o di Decision maker. In questo celebre post il datascientist Brandon Roher prova ad incrociare domande/problemi generici ad algoritmi più o meno innovativi nel campo del machine learning. Partendo proprio dagli algoritmi il deep learning ha fornito convincenti risposte a problemi ancora irrisolti, per esempio nel riconoscimento di cose e persone nelle immagini . Ma anche in questo caso la strada verso risultati concreti è molto ardua e riservata ad un numero ancora limitato di datascientist-driven companies.

In questo senso la visione popperiana di mettere al centro il problema, applicato alla datascience, è sicuramente vincente. Come scrive Popper ” .. il metodo consiste nel proporre tentativi di soluzione del nostro problema, e nell’eliminare le soluzioni false come erronee. Questo metodo presuppone che noi lavoriamo con un gran numero di tentativi di soluzioni. Una soluzione dopo l’altra viene messa a prova ed eliminata.” E oggi questo metodo, figlio del galieiano metodo sceintifico, applicato alla Datascience trova nella tecnologia NoSQL, negli algoritmi “big data” e nei datascientist  un forte abilitatore nonchè un grande acceleratore.

In questa evoluzione conoscere il contesto in cui si muove il progetto/problema e definirlo al meglio rimane la parte più difficile. Oggi più di ieri perchè  su questo aspetto che tocca problematiche organizzative, culturali e sociali non abbiamo (soprattutto in Italia) fatto gli stessi passi avanti che siamo riusciti a realizzare negli altri aspetti, ahimè solo abilitanti (tecnologia, algoritmi, dati ecc.).

Sulla base delle considerazioni sopra descritte mi piace descrivere il flusso che coinvolge qualunque progetto di datascience in maniera modulare quasi fosse una costruzione “lego”. Sotto riporto una immagine che esemplifica questi concetti
LegoDataScience

Cercherò di fare alcune considerazioni in futuri post di ciascuno di questi livelli, di come si possano spesso compenetrare (soprattutto quelli centrali), di come lo spessore (l’importanza) di ciascuno di questi sia variabile funzione del progetto .
Vedremo anche come, a sua volta, questo pattern (ovvero singolo progetto), possa combinarsi con altri perchè spesso i due strati superiori (i problemi risolti e i relativi dati) costituiscono la base per altri progetti/programmi  più complessi o più complicati.
Credo che sia importante aver “fissato” (anche visualmente) la centralità della definzione del problema all’interno di qualunque progetto di datascience e quindi nell’ideale diagramma di Conway da cui siamo partito nel precedente post mi sento di sottolineare più che mai l’importanza del cerchio inferiore, cioè della conoscenza del contesto a 360°: dai dati agli stakeholder per essere in grado veramente  di “risolvere problemi tutta la vita”.

Popper, Datascience & Lego: “Tutta la vita è risolvere problemi”

Si fa presto a dire big data … (parte 1)

Oltre che ad essere il motto di questo blog, la frase “si fa presto a dire big data …” è stata ed è la miglior sintesi della maggior parte di convegni, webinar e  riunioni di lavoro a temache relative ai dati degli ultimi miei anni lavorativi. Purtroppo il termine “Big Data”, essendo una buzzword, è pronunciato spesso a sproposito sia per attirare l’attenzione che per giustificare qualunque tipo di progetto. Per questo oltre a far riferimento ad una delle migliori definizione e descrizioni del termine big data cioè la voce inglese di wikipedia proviamo ad entrare un po’ più in dettaglio in questo post per darne un’interpretazione più specifica e rigorosa.

LogoABDrev1

Il termine big data incomincia ad essere associato a progetti e a relativi prodotti a partire dalla seconda metà degli anni 2000 per differenziarli da quei progetti dati realizzabili con tecnologie mature già presenti sul mercato. Questo fenomeno si è espanso su più direttrici:
1) quella tecnologica. Cioè nella capacità di gestire grandi volumi dati e/o veloci volumi di dati. Le nuove tecnologie di memorizzazione dati di tipo NoSql rappresentano al meglio questa direttice.
2) quella algoritmica. Cioè la nascita o il grande miglioramento di metodologie che riescono ad estrarre valore da grandi moli di dati e che sono tipicamente definiti machine-learning.
3) quella relativa ai dati. Cioè l’aumentata disponibilità in termini sia di volumi che di frequenza di aggiornamento dei dati su cui possono fare leva progetti e analisi. Fenomeni come Open Data, il web stesso e Internet of Things hanno e stanno accelerando questa direttrice.
4) quella umano-organizzativa. Cioè l’evoluzione delle tradizionali figure di data-analyst verso le più poliedriche figure dei datascientist secondo la migliore definizione data nel 2010 da Drew Conway in un celebre post del suo blog. Queste figure riuscendo ad unire la capacità di usare nuovi algoritmi alle nuove tecnologie di elaborazione e memorizzazione dei dati, conoscendone la semantica e il contesto riescono a chiudere il cerchio del valore del progetto.

Esporeremo in dettaglio nel nostro viaggio tutte e quattro le direttrici ma quando almeno due sono presenti in misura importante all’interno di un progetto allora, secondo me, sì possiamo spendere l’aggettivo Big Data.
E’ chiaro che il numero di due è una scelta un poco arbitraria e che deriva dall’esperienza ma la presenza di una semantica “fumosa” non aiuta a sfruttare al meglio il fenomeno.  E poi non capita così spesso soprattutto in Italia che siano presenti anche due sole direttrici …

 

 

Si fa presto a dire big data … (parte 1)

Perchè agile big data?

 

Ho sempre ritenuto importante dare una spiegazione al nome delle cose. Senza addentrarmi nella filosofia del linguaggio e nella diatriba che coinvolge secoli di pensatori ritengo fondamentale partire proprio da qui.

Agile vuole far riferimento a quelle metodologie che, partite da un nuovo modo di sviluppare software alla fine degli anni ’90 e dal metodo Lean Toyota, si sono sviluppate in maniera “virale” fino ad avere uno spazio importante  all’interno dell’innovazione, del Project Management e anche del Management in generale.

Big Data è sicuramente diventato un termine usato e abusato in differenti contesti, spesso senza conoscerne: il significato, le sue dinamiche e i suoi possibili impatti positivi e negativi sulla vita lavorativa e non di ognuno di noi. E’ comunque innegabile che il valore dei dati è cresciuto esponenzialmente negli ultimi anni. Scopo di questo blog è raccontare, in viaggio, questo cambiamento in maniera non esaustiva ma puntuale e passionale.

Il punto di vista, o meglio le istantanee di questo viaggio saranno quelle di un data-lover,  che si racconta abbia pronunciato come prima parola un numero e che ha fatto di questa passione una ragione di vita lavorativa e non.

Provare a rendere possibile questo ossimoro (agile e big data) nella quotidianità è una sfida che vivo tutti i giorni e raccontare questa sfida è un modo per affrontarla al meglio!

Perchè agile big data?