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

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

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

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?