Premessa: la storia e la teoria che ci sta dietro

Su MokaByte stiamo pubblicando una serie di articoli scritti nello stile del cosiddetto business novel. Si tratta di un genere piuttosto diffuso nel panorama nordamericano dell’editoria specializzata, in cui si affrontano temi di tipo professionale e aziendale non con un saggio, ma con racconti o un romanzo in cui problemi, ipotesi per risolverli, soluzioni adottate e riflessioni teoriche si intrecciano alle vicende dei personaggi, alle loro azioni.

Più che spiegare un tema, si racconta una storia, allo scopo di parlare di argomenti complessi ma con un taglio leggero e vicino all’esperienza, sperando di rendere il tutto più coinvolgente per il lettore.

In questo caso, la nostra storia parla della creazione di ecosistemi digitali e di come le organizzazioni e le aziende adottino dei cambiamenti che portano allo sviluppo di tali ecosistemi digitali.

Per agevolare la comprensione della teoria inserita all’interno del racconto, abbiamo pensato di estrapolare dalla nostra narrazione i concetti teorici e di inserirli in articoli di approfondimento a sé stanti, come quello che state leggendo.

Sia gli articoli narrativi che quelli “teorici” fanno riferimento al mio lavoro di agile coach all’interno dell’azienda di consulenza e coaching per cui opero.

La metafora del mercato rionale

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 legge 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 chiuderà. 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 fossero sovraffollati al punto da rendere faticoso e troppo lungo il processo di acquisto, il mercato non funzionerebbe.

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 breve: 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.

Nel caso di Airbnb, ad esempio, i producer offrono case in affitto breve, 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

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.

Dal B2C al B2B

Questi esempi Business to Consumer sono ben noti, funzionano bene — tenendo comunque in considerazione le limitazioni normative che possono interessare un determinato settore come quello dei taxi o degli affitti brevi — 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 di cui ci occupiamo in questa serie — in questi ultimi anni appare sempre più chiaro come la platform economy possa davvero risultare cruciale nella crescita e nell’evoluzione delle aziende.

In molti casi, infatti — accanto agli interventi di coaching con le persone e di aggiustamento dell’organizzazione dei team di lavoro — nelle aziende mancano 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 un quarto di secolo 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.

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 API–centric 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.

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.

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.

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.

Architettura

A livello architetturale, al momento attuale lo stile più raccomandato è 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 data center 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.).

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. 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 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.