Il valore del poliglottismo tecnologico nell’era dei “Big Data”

L’uscita di questo recente post  nel sito Dzone che parla di come sia percepita e gestita all’interno delle più importanti organizzazioni internazionali la tematica della persistenza dei dati mi permette di approfondire il suo valore strategico nell’ottica di sfruttare al meglio il fenomeno big data.
Partiamo dalla definizione di persistenza dei dati: la capacità di rendere utilizzabile e accessibile un dataset nel tempo e su diversi tipi di memorie e di sistemi. In particolare, in ottica big data, la capacità di rendere accessibile una base dati in diversi tipi di sistemi di memorizzazione  è il fattore chiave per sfruttare al meglio quello che l’evoluzione tecnologica ci ha messo a disposizione. Avevo già parlato in uno dei primi post di come una delle direzioni in cui si sta sviluppando il fenomeno big data sia proprio quello della tecnologie NoSQL ovvero quei database che si differenziano dai database relazionali che hanno (e continuano parzialmente a farlo) dominato la scena dagli anni ’80. Sarebbe tra l’altro più corretto sia dal punto di vista etimologico che semantico definire questo tipo di database “Not only SQL” proprio per sottolineare come esistono diversi casi d’uso, soprattutto quando le quantità di dati crescono, per i quali il modello relazionale non rappresenta la soluzione migliore. Come si può vedere dalla classifica più diffusa a livello mondiale dei sistemi di gestione dati, db.engine.com, i database relazionali sono largamente utilizzati ma non sono più l’unica scelta a disposizione e soprattutto il trend è tutto a favore dei sistemi NoSQL
Poli2
Tipicamente si  classificano i sistemi NoSQL  in 5 categorie:
1) Graph database: sistemi che memorizzano i dati in nodi e relative relazioni e che sono molto adatti a supportare algoritmi che “attraversano” in modo intensivo la rete del grafo. Un esempio tipico di questi algoritmi è  il calcolo del cammino minimo tra due o più nodi che sfrutta strutture più efficientin presenti  nei graph database rispetto al  classica “join” dei database relazionali.
2) Document database: sistemi che non memorizzano i dati in tabelle con campi uniformi per ogni record come nei database relazionali, ma in cui ogni record è memorizzato come un documento che possiede determinate caratteristiche. Tipicamene la forma in cui sono memorizzati i dati è XML o Json. Questa tipologia di sistemi è molto adatta a dati in cui non è molto importante e dinamica la parte relativa alle relazioni e dove sono molto frequenti gli accessi in lettura.
3) Key-value database: sono abbastanza simili ai document database ma il volume di dati associato a ciascuna chiave è tipicamente molto più piccola e sono ancora meno adatti a gestire le relazioni. La loro struttura è praticamente quella, per chi conosce Python, della struttura dato dizionario. Sono adatti per grandi volumi di operazioni sia di scrittura che di lettura .
4) Columnar database: hanno una tipologia di memorizzazione dei dati orientata alla colonna piuttosto che alla riga, come succede nei database relazionali. Questo li porta ad essere più efficienti nell’analizzare e aggregare i dati per colonna piuttosto che analizzare il singolo record in tutti i suoi campi. Sono molto più adatti quindi ad utilizzi di tipo OLAP (online analytical processing) più che che OLTP (online transactional processing).
5) Search engine database: sono molto orientati alla ricerca di dati anche e soprattutto attraverso un utilizzo di fitri in successione da parte degli utenti (faceting). Questa tipologia di sistemi non sono veri database primari ma sono sempre più affiancanti a database NOSQL o relazionali perchè facilitano e rendono efficiente una delle operazioni che in questi non è sempre ottimale e  cioè la ricerca in grossi moli di dati.

La numerosità di queste nuove forme di sistemi di gestione dei dati rende quanto mai importante saper scegliere la tipologia che più si adatta allo scopo della nostra applicazione. Addirittura è sempre più frequente la presenza di più sistemi di persistenza dei dati all’interno di una sola applicazione.Come si può vedere da questa figura
Poliglottismo1in una recente indagine, condotta a livello mondiale sul numero di sistemi di persistenza dati usati all’interno della stessa applicazione il numero due è appaiato con il 38%  all’uno  con il 40%. Ormai più del 50% delle applicazioni usano più di un sistema di persistenza dati! Con ormai oltre 150 sistemi di gestione dati con una importanza e diffusione rilevante (assumendo come soglia lo score 0.50 della classifica di db.engine.com) a livello mondiale saper scegliere al momento giusto non basta più perchè l’inerzia dovuta ad acquisire le conoscenze necessarie per usare questi sistemi all’interno di progetti è alta. Diventa sempre più strategico investire a livello aziendale e anche di singoli team nella conoscenza delle diverse tipologie e di alcuni istanze di queste magari anche utilizzandoli in proof of concept per essere pronti a sceglierli ma soprattutto ad averne una buona esperienza pratica.
Il poliglottismo tecnologico e in particolare il poliglottismo dei sistemi di persistenza dati è sempre più un fattore strategico di successo soprattutto per le data-driven company che vogliono sfruttare a pieno la grande e diversificata mole di dati che sempre più in tempo reale guida il business e le relative strategie. E se con i DBaas (Db as a service) la complessità sistemistica si abbassa, si alza sempre di più all’interno di questa diversificazione tecnologica a crescita esponenziale la capacità di scegliere e usare in tempi rapidi il sistema più adatto.

Il valore del poliglottismo tecnologico nell’era dei “Big Data”

Limiti & innovazione, dati & tecnologia

La recente lettura di due piccoli ma intensi saggi sul concetto di limite e innovazione mi permette di fare qualche osservazione su queste due tematiche e su come si intreccino sempre di più, nella civiltà moderna, con i dati e la tecnologia.

Partiamo dal primo: il piccolo saggio “limite” di Remo Bodei, filosofo dell’università di Pisa e della Università della California a Los Angeles.
LimiteRemoBodeiNel libro Bodei, raccontando come nella storia dell’uomo il concetto di limite abbia avuto differenti interpretazioni, arriva a riflettere su come il suo superamento sia diventato, in moltissime discipline, una caratteristica della società moderna. Ma non è sempre stato così: a lungo le innovazioni tecnologiche e la creatività sono state viste con sospetto o considerate nocive. Si parte nel mondo greco-romano dalla frase “Niente di troppo” sul muro esterno del tempio di Apollo a Delfi, al mito di Icaro per passare all’artigiano che sotto Tiberio inventò il vetro infrangibile ma che fu decapitato per la paura che il suo uso facesse deprezzare l’oro. Ma forse il caso più “attuale” fu quello di Vespasiano che premiò l’inventore di una macchina per spostare grandi pesi in campo edilizio, ma che ne vietò la diffusione per non togliere lavoro alla sua plebicula. Riuscite forse ad immaginare qualcosa di simile oggi? Per esempio la proibizione dell’uso di algoritmi, di intelligenza artificiale o della robotica per difendere l’occupazione degli strati meno istruiti della popolazione mondiale?
Mi verrebbe da rispondere che questo non è possibile perchè oggi il superamento dei limiti, in campo tecnologico e economico, è chiamato innovazione ed è considerato un valore su cui si fonda il progresso e la società capitalistica in particolare.

E qui entra in campo l’altro saggio di cui parlavo e cioè “Per un pugno di idee” di Massimiano Bucchi che racconta in maniera leggera, quella leggerezza tanto cara a Italo Calvino, storie di innovazione che hanno cambiato la nostra vita (dalla tastiera all’iPod passando per il Walkman arrivando fino al genoma da 1000 dollari).
InnovazioneBucchi

Dalle storie del libro e  dalla sua introduzione emergono idee e considerazioni  importanti che mi permetto, aggiungendo alcuni atomi di storia personale, di parafrasare in cinque piccoli punti e cioè che l’innovazione:
1)«È un processo complesso e non lineare in cui entrano in gioco numerosi
elementi , processi e attori»
2) È qualcosa di più di una nuova tecnologia anche se nel mondo attuale spesso la tecnologia è un elemento fortemente abilitante
3) È spesso un «momento di cambiamento concettuale, sociale e culturale»
4) Non è fatta di «Venture capital, start-up e spin-off»: questi  sono strumenti che possono facilitarla, ma non sono l’innovazione stessa.
5)  Non è in una persona o in un team ma deve permeare le organizzazioni.

Ma cosa c’entrano i dati e la tecnologia con il concetto di limite e di innovazione in concreto? Diciamo che oggi, forse con una accelerazione fortissima negli ultimi 15 anni, l’innovazione, in tutte le discipline, si è nutrita e si nutre di dati e di tecnologia relativa al processo degli stessi per produrre risultati importantissimi. Dal bosone di Higgs alle onde gravitazionali, dalla mappatura del genoma al riconoscimento delle immagini nei social network e non solo, tutto passa attraverso la capacità di processare grosse moli di dati. Questo sia per realizzare algoritmi sia per utilizzarli real time: le driverless car sono un esempio concreto. Ma anche recentissime forme di intelligenza artificiale, forse le prime degne della definizione più canonica, passano proprio da nuove forme di apprendimento di grosse moli di dati, come ha dimostrato il recente super-algoritmo di Google, che sfruttando algoritmi deep-learning ha battuto il campione mondiale di Go.

Ma in questo contesto ha ancora senso parlare di limiti? La domanda è lecita proprio per l’aumentata rapidità con cui l’uomo riesce a superarli.
In questo caso la mia risposta è affermativa perchè il senso del riflettere sta soprattutto nel provare a capire cosa oggi non abbia funzionato a dovere  in questa corsa sfrenata dell’innovazione moderna e cioè per esempio:
1) i necessari limiti relativi alla privacy e alla gestione dei dati personali non ancora gestiti al meglio e in maniera disomogenea a livello mondiale
2) il limite del sistema economico attuale che non è riuscito a distribuire in maniera omogenea i miglioramenti economici e sociali che il progresso ci ha regalato. E l’aumento dell’indice di Gini relativo alla distribuzione dei redditi a livello mondiale è il migliore indicatore di questo limite
3) il limite, espresso dalla legge di Martec, dovuto al fatto che la tecnologia progredisce esponenzialmente mentre le organizzazioni secondo una curva logaritmica e forse la mente umana cambia con una velocità ancora più bassa adattandosi molto lentamente ai processi dell’innovazione

MartecsLaw

Proprio sulla base di questi limiti , senza proporre provvedimenti alla Vespasiano, penso sia fondamentale portare al centro dei processi di cambiamento, nelle organizzazioni e nella società, l’uomo: ma l’innovazione ce ne darà il tempo? Forse questo sta diventando un’emergenza per la nostra specie …

Limiti & innovazione, dati & tecnologia

Data value per il Cliente prima della data monetization

Appare sempre forte in tutte le organizzazioni che hanno come asset i dati o che si stanno accorgendo di avere dati nei loro asset  quella che io chiamo “l’ansia da data-monetization”. Il fenomeno “Big data”, che ho cercato di inquadrare in questo blog nel giusto contesto, ha contribuito ad accrescere la consapevolezza, all’interno di aziende di qualsiasi settore, che la crescita del volume dei dati e la tecnologia possano creare nuovi asset di valore. Ma dalla consapevolezza o dall’idea all’effettiva creazione di valore esiste una distanza siderale che la maggior parte delle organizzazioni non sa colmare in maniera corretta per la mancanza di fattori umani e strategici sui quali l’innovazione procede molto lenta.
RicercaBigDataOsservatoriCome avevo già scritto, infatti, capire il problema che viene risolto con specifici dataset, algoritmi o framework tecnologici è l’aspetto più complesso della datascience, perchè significa avere consapevolezza contemporaneamente della semantica dei dati e dei bisogni del Cliente. Questa difficoltà porta ad anteporre troppo spesso la creazione di prodotti che siano vendibili sul mercato all’analisi delle reali esigenze dei Clienti che useranno i prodotti stessi. Questa è, a mio giudizio, una delle tre principali cause del fallimento dei progetti Big Data a livello mondiale.
La seconda causa nasce spesso dall’approccio organizzativo di questi progetti: anzichè usare approcci lean e agile, che si adatterebbero molto bene alla complessità del contesto, si usano più frequentemente approcci waterfall tradizionali con la creazione di molti “strati” decisionali e operativi che rallentano i primi rilasci e allontano il team di progetto dal Cliente. Proprio in questa ottica di diminuire la distanza con il Cliente il numero 3 è già un numero imperfetto! Infatti oltre al Product owner, che secondo la migliore definizione di Pichler deve avere un piede nel team e uno nel mercato, solo una figura di Product Manager che conosca in maniera approfondita Clienti e mercato è a mio giudizio accettabile. Ma in molte start-up di successo questa figura collide. In aggiunta l’approccio agile e la sua logica di Minimum Valuable Product portano a capire molto presto con il Cliente eventuali errori di progettazione o di analisi che possono essere corretti in maniera iterativa in tempi rapidi. Solo in questo modo, accorciando la distanza tra il progetto e chi lo usa, si riesce a fare in modo che il data value non sia sacrificato troppo presto sull’altare di ricavi e profitti che invece sul medio periodo, non tanto paradossalmente, vengono penalizzati proprio da questa miope strategia.
La terza causa è probabilmente dovuta all’evoluzione che questo tipo di progetti ha avuto negli ultimi 10 anni e che ha di fatto fornito molta più centralità, rispetto al passato, ai datascientist, o comunque a figure che conoscono dati e tecnologia e che invece hanno poca centralità nei processi decisionali dei progetti stessi. E questo diminuisce ulteriormente la capacità di capire il valore che si sta creando ai Clienti.

Sono sempre più convinto che se la maggior parte delle aziende non risolverà queste tre problematiche, cioè non metterà al centro dei progetti “data-driven” l’analisi delle esigenze del Cliente, l’approccio agile e le figure che meglio conoscono i dati, “l’ansia da data-monetization” diventerà presto “nevrosi da data-monetization” a vantaggio di quelle realtà, spesso geograficamente posizionate in area anglofona, che lo hanno capito.

Insomma tra big data e big profit la via non è breve e scontata e passa sempre attraverso il valore che si crea al Cliente. Le modalità per provare a percorla al meglio sono e saranno oggetto di discussione di questo blog senza presunzione di dare risposte definitive!

Data value per il Cliente prima della data monetization

La decentralizzazione è il cuore pulsante dei Big Data

Riflettendo su quali siano stati i passaggi tecnologici e non che hanno reso possibile il fenomeno  Big Data appare chiaro come la decentralizzazione sia la caratteristica che accomuna molti momenti importanti di questa evoluzione. Cerchiamo di fare un passo indietro andando a descrivere i passaggi più significativi e vedendo come, in questi, la decentralizzazione sia stato una chiave di successo.

P2P_Topology

L’inizio. Possiamo identificarlo nel 1991 con la definizione di Tim Berners-Lee del protocollo di comunicazione HTTP: questo momento sancisce la nascita del World Wide Web, che poggia anche sul protocollo di trasmissione TCP/IP, definito qualche anno prima nella realizzazione della rete Internet: l’insieme di reti pubbliche interconnesse su scala mondiale. La topologia della rete Internet e i sopra-citati protocolli di fatto rispondono alla logica di decentralizzazione massima tale da non rendere nessun nodo critico al funzionamento della rete e tale che anche i contenuti sulla rete siano distribuiti sui milioni di server tra loro connessi, in modo molte volte ridondato.

world-wide-web-341418_960_720

La prima crescita. La nascita e il grande sviluppo del Web fa comunque nascere servizi, e siamo a cavallo tra il vecchio e il nuovo millennio, quasi sempre free,  che raggiungono velocemente centinaia di milioni di utenti. Stiamo parlando di prodotti realizzati dalle più grandi aziende che dominano ancora oggi il web e cioè Google, Yahoo, Amazon e subito dopo  Facebook e Linkedin. La grandissima richiesta di computazione e di servizi real time mette in crisi l’approccio architetturale tradizionale, quello basato su database relazionali e su supercomputer posti in grandi datacenter proprietari. E anche in questo caso il paradigma della decentralizzazione viene in aiuto ispirando da un lato l’approccio computazionale distribuito alla base dell’ecosistema Hadoop e dall’altro il cloud computing che consente di distribuire i dati e le applicazioni su più datacenter, rendendo il tutto molto più robusto e resiliente in caso di criticità di singoli nodi o di una parte della rete stessa. E Hadoop e il Cloud, con la loro capacità di distribuire le elaborazione di dati e di conservarli in maniera efficiente, sono alla base ancora oggi del fenomeno Big Data.

hadoop-elephant-cloud

Per questo mi piace rappresentare il nostro mattoncino rosso (la parte tecnologica del nostro lego Big Data) costituito da molte componenti distribuite.

LegoRossoSpezzato

La crescita dirompente. Ma anche alla base della crescita dei dati è evidente l’importanza che ha avuto la decentralizzazione. Infatti nella seconda metà degli anni 2000 l’ondata “social” del web è stata possibile perchè si è passati da una generazione dei contenuti da parte di pochi (Web 1.0) alla generazione da parte di tutti (Web 2.0). Di fatto è stata decentralizzata la generazione di contenuti presenti nel web con una esplosione della numerosità dei dei dati disponibile on-line che è una delle direttrici in cui si è maggiormente sviluppato il fenomeno Big data, non a caso quella da cui ha preso il nome.

Web2.0

Per chi conosce i sistemi complessi tutto quello che ho scritto non apparirà assolutamente strano perchè nel mondo attuale diventato complesso nel suo pieno significato etimologico non è un caso che le topologie e i pattern che hanno il sopravvento sono quelli ad alto grado di  decentralizzazione e ridondanza.

La domanda che molti si pongono a questo punto è quale sarà il prossimo ambito dove la decentralizzazione manifesterà la sua forza creatrice . Forse si potrebbe scommettere sulla blockchain, cioè un archivio distribuito di transazioni applicabile in molti processi della vita reale. Finora è rimasta abbastanza ai margini di questa rivoluzione tecnologica in corso ma molte aziende e organizzazioni stanno pensando ad applicazioni concrete che possano migliorare la vita di tutti noi andando oltre alla attuale forma applicata più conosciuta: la moneta digitale  Bitcoin. Ma questa è un’altra storia che approfondiremo un po’ più avanti!

La decentralizzazione è il cuore pulsante dei Big Data

L’importanza degli algoritmi nel futuro della datascience

In uno dei post precedenti avevo evidenziato le 4 principali “forze” grazie alle quali si sta  sviluppando il fenomeno “big data” e cioè: la crescita della disponibilità dei dati, l’evoluzione della tecnologia di gestione dei dati, lo sviluppo e il miglioramento degli algoritmi e le nuove figure professionali, i datascientist, che sono i protagonisti umani di questa rivoluzione in corso. Oggi mi vorrei soffermare a considerare la diversa velocità di queste forze e cosa serve, probabilmente, in questo momento storico per uniformarle il più possibile, rendendo il tutto a maggior valore per gli utilizzatori.

CrescitaDati
Da un lato infatti abbiamo due forze: quella della crescita dei dati e della relativa  tecnologia che in maniera virtuosa si accelerano in maniera esponenziale. Negli ultimi 2 anni sono stati generati il 90% dei dati attualmente disponibili su scala planetaria e contestualmente tutta la filiera tecnologica legata ai dati, dalla memoria alla capacità elaborativa, è migliorata in qualità (robustezza e disponibilità) e diminuita in costo ($/byte e $/capacità computazionale) grazie al cloud e ai nuovi paradigmi di calcolo distribuito (per esempio l’ecosistema Hadoop).

A fronte di questo miglioramento non c’è stato una equivalente crescita in termini numerici di esperti di dati (sia datascientist che manager) e la capacità di utilizzo dei dati stessi non è cresciuta nelle linee di business e nei decisori delle organizzazioni.
Ancora in questi giorni è stato pubblicato un studio McKinsey molto importante sui fattori strategici che portano valore ai progetti “big data” nelle aziende dove si individua proprio nella capacità di “scalare” nei data-analytics skills il fattore più critico di successo. Ma la scarsità di competenze in questo settore è un trend mondiale su cui nessuno ha dubbi ed è anche misurato dalla grande crescita salariale di queste professioni negli ultimissimi anni.

PostAlgoritmo
Di conseguenza gli algoritmi, che si posizionano tra questi due poli (dati e tecnologia da un lato e fattore umano dall’altro) rivestono a mio parere un ruolo fondamentale per la capacità di semplificazione e sintesi che possono rivestire rendendo di valore reale e attuale quella grande massa di dati che oggi la tecnologia ci mette a disposizione. In aggiunta sono la componente che può mitigare la scarsità di persone capaci di analizzare i dati in azienda, accelerando e semplificando le analisi stesse e  democratizzandole di conseguenza.PostAlgoritmi6
Non è un caso che Evagelous Simoudis, uno dei più importanti investitori di lungo corso in Silicon Valley nel settore dei dati e degli analytics, qualche giorno fa in un popolare post uscito sul sito della O’Relley scrive a chiare lettere che “per sostenere il fenomeno big data e migliorare l’uso delle informazioni, abbiamo bisogno di applicazioni che velocemente ed in maniera poco costosa estraggano correlazioni associando le intuizioni ad azioni concrete di business”.
PostAlgortimi3
Del resto la stessa Gartner, nell’ultimo Symposium 2015 a Orlando, aveva evidenziato la prossima  evoluzione della “Data Economy” nella “Algorithmic Economy perchè non sono importanti i “big data” in sè ma quello che si riesce a fare con essi.

LegoVerdeAlgoritmi
Il nostro mattoncino “verde” è quindi fondamentale per riuscire a realizzare costruzioni “lego” big data sempre più grandi e utili: ne parleremo e lo analizzeremo in concreto in prossimi post.

 

 

L’importanza degli algoritmi nel futuro della datascience

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”

Conway datascientist Venn diagram: il valore e l’utopia

Questa è sicuramente l’immagine che meglio rappresenta il nuovo modo di estrarre valore dai dati (datascience) attraverso quelle figure, i datascientist, definiti da Hal Varian, Chief economist di Google, come “la professione più sexy del XXI secolo”.

Data_Science_VD

La rapida evoluzione tecnologica degli ultimi 15 anni, le cui direttrici ho sintetizzato nel precedente post, ha reso particolarmente importante avere figure all’interno dell’azienda che abbiano  forti competenze tecnologiche (hacking skills), ottime conoscenze matematico statistiche (che consentano anche di sfruttare le nuove evoluzioni degli algoritmi) e a cui non manchi la conoscenza di dominio (dei dati e del contesto di business)  per potersi fare le domande giuste e risolvere i problemi a maggior valore. Come si vede dall’immagine solo all’incrocio delle tre competenze chiave si posiziona la nuova scienza dei dati e ci troviamo di fronte a un nuovo tipo di professionalità. Qui abbiamo il valore assoluto, non raggiungibile dalla sola sovrapposizione di due dei tre skill che rischiano di convergere in situazioni dove il risultato è parziale o porta a cattive interpretazioni (come la “danger zone”,  in assenza di competenze matematico statistiche). Chapeau a Conway per averlo focalizzato con questo dettaglio visuale già nel lontano 2010. Ma è così facile trovare persone con la presenza di questi tre skill? E soprattutto con la crescita di importanza dei dati all’interno delle aziende è un modello facilmente scalabile? La mia personale opinione è negativa e si basa sia su esperienze personali in Italia sia sulla lettura dei dati su scala mondiale dove Mckinsey rileva solo negli Stati Uniti la mancanza (entro il 2018) di quasi 200.000 datascientist e più di 1 milione di data-manager. Da queste considerazioni nasce l’aggettivo “utopia” nel titolo del post. Ma esiste una soluzione o per lo meno si può arrivare ad un utile compromesso? Probabilmente sì attraverso una strada organizzativa più complessa e meno rapida ma potenzialmente anche più efficace nel medio periodo. L’opzione è creare un team che rispetti la matrice di Conway e cioè che abbia all’interno persone la cui somma di competenze porti alla definizione di datascience. Nel medio periodo, in un’ottica di lifelong learning, ciascun membro del team, colmando i propri gap, potrebbe arrivare ad essere un vero datascientist. Ma è una strada percorribile? Si … ponendo particolare attenzione alla selezione del team e all’utilizzo di metodologie agili nella sua crescita. Ma questa strada merita considerazioni supplementari che affronterò in un post specifico … stay tuned

Conway datascientist Venn diagram: il valore e l’utopia