La Platform Economy dal “Business to Consumer” al “Business to Business”

Giulio Roggero ci illustra in cosa consiste la Platform Economy in un'ottica B2B

Tra le nostre aree di coaching, la Platform Economy acceleration track si connota per la sua natura composita e trasversale, comprendendo elementi organizzativi, architetturali ed economici. Ma che cosa vogliamo realizzare quando si parla di Platform Economy? In questo post, cerchiamo di affrontare l’argomento in modo discorsivo e lineare, partendo dal concetto di piattaforma e facendo qualche esempio.

 

La metafora del mercato

Partiamo con un esempio forse banale ma piuttosto chiaro: da quando la civiltà umana ha cominciato a produrre beni e servizi, è nata l’esigenza di scambiare tali prodotti. È la basilare leggi della domanda e dell’offerta in cui assume un ruolo fondamentale il concetto di mercato.

Senza andare a guardare i sofisticati meccanismi dei mercati finanziari, prendiamo come riferimento un normale mercato rionale: c’è un’infrastruttura rappresentata dalla piazza in cui il mercato si svolge, ci sono dei banchi in cui vengono offerti prodotti diversi in vendita (frutta, verdura, e così via), e ci sono i persone che chiedono di acquistare tali prodotti, perché ne hanno necessità.

Tutti questi elementi, però, devono essere in qualche modo organizzati e “disciplinati”: se in un mercato viene venduta una sola merce, che magari non interessa a un sufficiente numero di acquirenti, gli scambi non si svolgeranno bene e il mercato chiude. E viceversa, anche il mercato che offrisse prodotti di qualità, variegati e a buon prezzo non funzionerebbe se fosse nascosto alla vista di coloro che desiderano acquistare quei prodotti. Oppure, se alcuni banchi della frutta o della verdura sono sovraffollati al punto da rendere faticoso e troppo lungo il processo di acquisto, il mercato non funziona.

Un mercato rionale.
Un mercato rionale.

 

Dal mercato fisico al business digitale

Se trasferiamo questa metafora nel panorama attuale del business digitale, vediamo aziende che sono partite da queste considerazioni e sono riuscite a creare un sistema tramite il quale mettere in relazione il tradizionale mondo fisico con un’interfaccia digitale in grado di “disciplinare” la domanda e l’offerta di un servizio/prodotto.

Da una parte c’è un’offerta di qualcosa, dall’altra c’è la domanda di quella “merce”; in mezzo la piattaforma che consente alle due esigenze di incontrarsi in modo più semplice e lineare possibile.

Pensiamo a Uber per il tradizionale mercato dei taxi, o a Airbnb per quel che riguarda l’affitto di alloggi per un periodo limitato: queste aziende hanno realizzato una “infrastruttura” che svolge un complesso ruolo di abbinamento della domanda e dell’offerta nel mondo fisico attraverso un’interfaccia digitale facile da utilizzare per gli utenti, sia che si trovino dalla parte dell’offerta o da quella della domanda.

In questi casi è evidente come la tecnologia, che è fondamentale per il funzionamento di tutto il business, svolga però “solamente” il ruolo di abilitatore del servizio: chi cerca l’autovettura che lo porti alla sua destinazione o chi mette in affitto l’alloggio per qualche giorno non deve conoscere la tecnologia che c’è sotto, ma si limita solo a utilizzare l’interfaccia della piattaforma.

Schema concettuale di un’app di Platform Economy, tipo Uber o Airbnb. Nel caso di Airbnb, ad esempio, i “producer” offrono case, i “consumer” le prendono in affitto, la “platform” facilita l’incontro fra le due esigenze (“match”). I “curators” della piattaforma garantiscono che le cose vadano per il meglio a livello di qualità del servizio, di sicurezza, e di affidabilità delle parti.
Schema concettuale di un’app di Platform Economy, tipo Uber o Airbnb. Nel caso di Airbnb, ad esempio, i “producer” offrono case, i “consumer” le prendono in affitto, la “platform” facilita l’incontro fra le due esigenze (“match”). I “curators” della piattaforma garantiscono che le cose vadano per il meglio a livello di qualità del servizio, di sicurezza, e di affidabilità delle parti.

 

Variazioni sul tema

E non ci sono solo questi due esempi eclatanti: grandi marchi dell’abbigliamento sportivo, ad esempio, hanno portato il loro mondo fisico (scarpe, indumenti sportivi etc.) all’interno di piattaforme digitali. Vanno in tal senso le acquisizioni di Runtastic da parte di Adidas o quella di Runkeeper da parte di Asics, in modo da avere la loro app di fitness tracking al pari di quello che succede con Nike+ e il suo uso sul’iWatch di Apple.

Ad essere precisi, nel caso delle grandi aziende di materiale sportivo, il discorso è un po’ diverso rispetto alla piattaforma “neutra” rappresentata da Uber o Airbnb, perché qui non ci si limita a mettere in collegamento domanda e offerta, quanto piuttosto si prende una community che ha delle esigenze e si propongono ad essa dei prodotti ben precisi. Però, a livello di “funzionamento” siamo nello stesso dominio: c’è una piattaforma utilizzabile facilmente dall’utente finale, e che a questo espone anche una serie di prodotti che poi è facile acquistare con pochissimi semplici passaggi.

 

Dal B2C al B2B

Questi esempi Business to Consumer sono ben noti, funzionano bene — al netto delle limitazioni normative che possono interessare un determinato settore come quello dei taxi — e sono ormai collaudati da anni di utilizzo da parte di milioni di utenti.

Ma, oltre al B2C, può aver senso parlare di piattaforme in un ambito Business to Business? Venendo al mondo B2B — che è poi quello in cui più spesso ci troviamo ad operare con il coaching Agile — in questi ultimi anni mi sono reso sempre più conto di come la platform economy possa davvero risultare cruciale nella crescita e nell’evoluzione delle aziende.

In molti casi, infatti, è apparso chiaro come — al di là degli interventi di coaching con le persone e di aggiustamento dell’organizzazione dei team di lavoro — nelle aziende mancassero una visione d’insieme e una precisa consapevolezza relative a come gestire il ciclo di vita di un servizio digitale, a quale stile architetturale adottare per i propri sistemi informativi, a come trattare l’organizzazione dell’informazione e dei dati che sono sempre più eterogenei, anche considerando tutto il pregresso, il legacy.

In certe aziende di grandi dimensioni, lo sviluppo di tanti sistemi informativi, lungo l’arco di molti anni, ha finito per creare un’organizzazione delle persone che riproduce in definitiva proprio la struttura di quei sistemi: è difficile andare a cambiare l’organizzazione se non si cambia anche ciò che è sottostante ad essa e ha determinato la sua conformazione attuale.

Prendiamo ad esempio un ipotetico istituto bancario: si potrebbe essere in presenza di due aree di business diverse (finanziamento a iniziative imprenditoriali e mutui casa a privati, tanto per dire) che hanno sviluppato negli anni approcci, sistemi e organizzazione dei dati completamente diversi, anche se poi fanno attività simili e potrebbero condividere informazioni.

 

Dai silos alle architetture di integrazione

Questa organizzazione per pezzi di software verticali e indipendenti vanifica tutte quelle possibilità di fare meglio le cose rappresentate dal riuso, dal controllo, dallo scambio di dati. Tutte le volte che è necessario “fare sinergia”, questa diventa a sua volta un’iniziativa isolata: si individuano, aggregano e mettono in relazione solo alcune serie di dati, e ogni volta che occorre fare nuove aggregazioni, bisogna ripartire con un nuovo progetto. Questo è un costo enorme: ogni volta si rifà un lavoro per capire quali informazioni occorrono, esporle in modo sicuro, identificare gli utenti che utilizzano un determinato servizio, propagare questi servizi in modo performante e scalabile e così via.

È evidente che questi problemi nascono perché quei servizi non erano stati pensati, a loro tempo, per essere integrati o scalati. Ma questo non vuol dire che non lo si possa fare, e la chiave sta nel disaccoppiare i sistemi core dell’azienda dai sistemi che espongono i processi e i servizi all’esterno (B2C) e all’interno (B2B) dell’azienda. Non è niente di nuovo: architetture client–server prima, architetture di integrazione come SOA poi hanno fatto fronte a questi problemi da una ventina d’anni a questa parte, ma di certo in una maniera che non è concettualmente e operativamente semplice, come ben sanno coloro che usano i vari Service Registry and Repository SOA…

 

Platform economy per le aziende

Se torniamo al discorso della domanda e dell’offerta, c’è una lezione che i servizi basati su piattaforme ci hanno insegnato, ed è quella di mettere in relazione le due parti in modo da soddisfare entrambe, attraverso una interfaccia che sia facile da usare.

Molte grandi aziende possiedono degli asset di dati e informazioni da offrire non solo verso l’esterno, ma anche e soprattutto verso il loro interno. E spesso questi dati non sono immediatamente a disposizione, ma anzi giacciono “sepolti” nei meandri dei sistemi informativi dell’azienda. Il salto di qualità sta nel far capire al business, al marketing, che dentro l’azienda possono esserci tanti dati preziosi su cui costruire nuove iniziative. Ma questo deve essere fatto in maniera “fruibile”, e la creazione di una piattaforma in grado di raccogliere, aggregare, esporre in modo semplice tali informazioni è la possibile soluzione.

L’architettura “a spaghetti” può essere razionalizzata con un approccio “a piattaforma” (immagine da mia-platform.eu).
L’architettura “a spaghetti” può essere razionalizzata con un approccio “a piattaforma” (immagine da mia-platform.eu).

 

Ad esempio, il marketing deve creare un servizio a misura dell’esperienza utente che c’è o che vuole indurre, e in questo desiderio non deve essere “frustrato” da un IT che dice: “Bello, ma non si può fare perché non abbiamo le informazioni e comunque a raccoglierle e renderle disponibili ci vuole tanto tempo”. Invece dobbiamo creare un sistema per cui sia possibile fare questo tipo di operazioni, anche con delle sperimentazioni, e in cui vengano valorizzati tutti gli asset creati magari in tanti anni e con spese significative.

Si tratta di creare uno strato, con delle regole ben chiare — che possiamo definire APIcentric e di seguito vedremo perché — in cui le API definiscono il livello più alto dei servizi IT.

 

Un esempio: Google Maps

Per comprendere quanto siano importanti API ben esposte, pensiamo a Google Maps. Oggigiorno ritroviamo la classica mappa integrata all’interno di numerose applicazioni e i dati geolocalizzati relativi a traffico, meteo, attività commerciali e così via finiscono all’interno di una miriade di sistemi. La cosa importante però, non è solo che si tratta di dati esposti da API facilmente utilizzabili dall’IT; la cosa importante è che queste API sono facilmente comprensibili anche al dipartimento business e a quello marketing di una azienda, che magari non saprà esattamente come funzionano tecnicamente, ma capisce perfettamente cosa fanno, quali dati possono offrire, e che questi possono essere facilmente integrati dentro nuove applicazioni. È un cambiamento di paradigma, perché ora il business si aggancia più facilmente, in modo “agnostico”, alla logica dei dati e dei componenti dell’azienda.

Ecco quindi in cosa consiste la platform economy B2B per le aziende: creare un’economia di scala a partire dai propri dati e dai propri servizi che sia accessibile a terzi. In questo modello, business e IT collaborano all’interno dell’azienda per creare valore grazie a una piattaforma incentrata sulle API che c’è nel mezzo e che rimane aperta. La piattaforma diventa essa stessa l’asset centrale per l’IT e, a partire da essa, business e marketing possono condurre le loro iniziative e i loro “esperimenti”; e nulla vieta che questo sia fatto anche in outsourcing, coinvolgendo altre aziende che comunque dovranno “agganciarsi” a delle API che espongono i dati.

 

Piattaforme aperte

Anche in Italia ci sono aziende che hanno già abbracciato questo approccio: ad esempio, Banca Sella ha sviluppato GestPay, il primo gateway italiano che integra ApplePay, e ha fatto questo creando un ecosistema di API, vale a dire una raccolta di API che consente a qualsiasi azienda, iniziativa, progetto etc. di integrare quei servizi bancari all’interno del proprio sistema e della propria applicazione.

E non si parla solo di sistemi legati al mondo delle banche e della finanza, ma anche di dati aperti della pubblica amministrazione come avviene sul portale della Agenzia per lItalia Digitale

 

Organizzazione, architetture, tecnologia

Realizzare una piattaforma di questo genere presuppone ovviamente una serie di “requisiti” sul piano dell’organizzazione dei team di sviluppo, dello stile architetturale e delle tecnologie impiegate, nonché una attenta pianificazione degli investimenti e del modello di business, tenendo ben presente che tale modello di business può anche essere di cost saving.

La nostra Platform Economy acceleration track punta anche a dare un quadro chiaro e completo di questi aspetti, affinché il platform design non resti solo una enunciazione, ma si concretizzi in azioni concrete da intraprendere da parte dell’azienda.

 

Organizzazione

A livello organizzativo, una piattaforma presuppone di avere team crossfunzionali, come raccomandato dalle metodologie agili e in particolare da Scrum, che siano responsabili di tutto il ciclo di vita del servizio e che siano verticali, ossia legati a uno o più servizi. Questi team pensano a sviluppare qualcosa per l’utente, che si tratti di una API o invece proprio di un servizio fatto e finito.

I team crossfunzionali rappresentano la base “organizzativa” per implementare una piattaforma.
I team crossfunzionali rappresentano la base “organizzativa” per implementare una piattaforma.

 

Inoltre, tutti insieme, questi “team di servizio” lavorano alla piattaforma, la fanno evolvere. Quindi c’è un codice piattaforma che si sviluppa grazie al contributo di più team per tutto il ciclo di vita. Un aspetto fondamentale è che il codice piattaforma sia ben distinto, anche a livello di repository, dal codice dei singoli servizi che sono invece “affare” dei singoli team e che, oltre ad essere ben disaccoppiati dalla piattaforma, staranno proprio su repository diversi.

I cicli di vita dei servizi seguiranno i principi della continuous integration, del continuous delivery e del continuous deploy. In tal senso, avere una piattaforma su cui questi servizi si appoggiano finisce per amplificare la portata delle varie attività “continue”: per esempio, il continuous delivery ci consentirà un rilascio continuo, anche di un fase di pre-test, per raccogliere al meglio i requisiti da parte del business.

Un esempio di pipeline per il continuous delivery/deploy.
Un esempio di pipeline per il continuous delivery/deploy.

 

Con una pipeline automatizzata che mette in preproduzione il codice scritto, sarà possibile toccare con mano i risultati in tempi davvero brevi. Il continuous deploy rappresenta il rilascio in produzione che, con queste premesse, perde i connotati di “evento”, ma diviene una normale attività nel ciclo continuo di creazione, valutazione e messa in produzione del software reso possibile dalla pipeline automatizzata e dal fatto che la piattaforma espone un modello di dati e fornisce la possibilità di agganciarsi ad esso fin dai momenti embrionali della creazione di un servizio.

 

Architettura

A livello architetturale, al momento attuale lo stile più raccomandato e “osannato” è quello a microservizi, che poi non è altro che il disaccoppiamento adeguato dei servizi, limitati al loro contesto applicativo. È chiaro che è anche possibile aggregare e modificare la granularità dei microservizi, ma essi vanno sempre pensati come cloud native: anche se la nostra piattaforma resterà alla fine su un datacenter interno all’azienda, è bene che possieda le caratteristiche per essere nativamente cloud (sessioni isolate per servizio e non cross-servizi, adeguata scelta della persistenza del filesystem etc.).

Schema di architettura a microservizi: in questo caso, viene mostrato l’esempio logico di mia-platform.
Schema di architettura a microservizi: in questo caso, viene mostrato l’esempio logico di mia-platform.

 

Tecnologia

Avendo parlato di cloud, appare evidente come si debba costruire la nostra piattaforma su sistemi a container che diventano un vero alleato per isolare processi e logiche da chi poi espone quei servizi a livello di infrastrutture. Docker, Kubernetes sono strumenti ormai affermati e affidabili e oggi vanno per la maggiore, anche se non possiamo certo sapere cosa accadrà tra cinque o dieci anni.

Altro aspetto tecnologico importante nelle piattaforme è il disaccoppiamento backend–frontend, perché non posso sapere su quale dispositivo finale verrà fruito il servizio; ma anche se cambia l’interfaccia utente con cui viene utilizzato il servizio e vengono creati nuovi device, il modello dati e la logica applicativa che ci sono sotto restano inalterati. Qui sta la forza della piattaforma e del modello delle Open API che devono essere documentate secondo precisi criteri e devono risultare indipendenti dal linguaggio di programmazione che le espone e anche da quello che le consuma.

In ogni caso, anche con la tecnologia occorre pensare in senso evolutivo, perché il linguaggio che usiamo oggi non sarà magari quello che verrà usato tra dieci anni. Riuscire a creare una piattaforma a microservizi poliglotta, cioè multilinguaggio, è un’assicurazione sul futuro, perché consente di scegliere oggi la tecnologia di oggi più adatta a fare quello che si desidera, ma senza impedire un domani di continuare a utilizzare quanto c’è, senza dover riscrivere tutto.

Volendo sintetizzare tutto questo, diciamo che dobbiamo realizzare una piattaforma che sia API-centric per quanto riguarda la tecnologia, e user-centric a livello di business.

 

La lezione della platform economy

Quanto abbiamo imparato dal successo di iniziative globali di platform economy può essere trasferito all’interno delle aziende per realizzare piattaforme in grado di mettere in connessione una offerta (di dati, informazioni etc.) e una domanda da parte del business, del marketing per la realizzazione di servizi utili e in grado di creare valore per l’azienda. Chiaramente, tutto ciò si applica primariamente a grandi aziende, ma sarebbe fuorviante pensarlo solo in dimensione enterprise: non va sottovalutata infatti l’importanza che questo tipo di approccio può rivestire anche per aziende innovative come le startup.