Ecosistema e piattaforma
C’è un modo di dire americano che, almeno in questo caso, prendo volentieri a prestito: the big picture, l’immagine completa, il quadro a grande dimensione, la visione globale. Quello che, arrivati a questo punto del nostro percorso di “rivoluzione digitale” nelle aziende con cui stiamo lavorando ormai da quasi un anno, mi appare chiaro è che guardando the big picture si individuano gli elementi che costituiscono il nostro ecosistema digitale, se ne vedono le connessioni In-Organisation (I-O) e Cross-Organisation (X-O), se ne comprendono le interazioni e se ne può intuire qualche sviluppo. Ma si vede anche che il modo pratico affinché questo insieme di elementi interconessi possa funzionare in maniera seamless e frictionless è rappresentato dal concetto di piattaforma e dalla sua implementazione.
Uno degli aspetti della mia vita lavorativa di cui sono più contento è di essere riuscito, nel tempo, a lavorare spesso con persone piene di idee e di spunti e capaci di suscitare riflessioni e prospettare soluzioni anche con una “banale” chiacchierata. Dirigenti d’azienda con cui ho lavorato per tanti anni, colleghi con cui mi sono sempre confrontato, esperti che ho conosciuto in giro per convegni e conferenze. Probabilmente in parte è fortuna, in parte è dovuto a una inarrestabile curiosità che mi ha spinto a cercare sempre nuove stimolanti esperienza.
Tra queste persone c’è colui con cui parlerò oggi. È un esperto di primo livello sul tema delle piattaforme digitali su cui, ormai da parecchi anni, lavora con la sua azienda essendo riuscito a realizzare una soluzione implementativa adattabile a situazioni disparate.
Ma prima di tutto è un amico. Lo coinvolsi tanti anni fa nella scrittura di articoli sul magazine MokaByte. Poi nel libro “Guida galattica per agilisti”. Ma sopratutto è stato il promotore della azienda dove ora lavoro e che insieme ad altri “complici” abbiamo fondato.
Giulio è un ingegnere “atipico” rispetto a un certo cliché che forse sarebbe ora di superare: assolutamente informale eppure rigoroso, notevolmente visionario e innovatore, sempre legato alla concretezza di quel che sta realizzando, molto aperto alle novità e alle proposte meno scontate, ma senza prendere le sbandate che abbiamo visto percorrere da certi imprenditori troppo innamorati del loro sogno per rendersi conto dell’irrealizzabilità della propria visione, una volta messa a confronto con la realtà.
Per questo oggi ho deciso di vedermi con lui di persona, il che assume un valore particolare: nonostante la frequentazione assidua per videoconferenza, messaggi e quant’altro, è davvero tanto tempo che non ci vediamo in presenza.
Muoversi sopra (e sotto) la piattaforma
Trovo Giulio nella sala relax mentre si gode lentamente un caffè. Vedo che ha le cuffie Bluetooth negli orecchi e di questi tempi non sai mai se uno sta parlando al telefono o in una riunione online con altre persone. Mimo il gesto del saluto e il gesto della telefonata con una espressione di domanda come a dire “posso? Sei al telefono?”
Ma lui non è al telefono. Sta realmente prendendo solo un caffè. Bravo, uno dei pochi che fa ancora solo una cosa per volta. Se gli chiedi del tempo per parlare puoi star certo che quando lo trova, è dedicato a te e te solamente.
“Ciao Giovanni, no no niente call. Oggi giornata tranquilla, poche telefonate”, ribatte scherzando.
Ridiamo entrambi e ci sediamo. È passato tanto tempo dall’ultima volta che ci eravamo incontrati dal vivo, ma non si nota. Siamo amici da tanto e spesso ci sentiamo per telefono o messaggio.
Difatti Giulio conosce già, almeno a grandi linee, il progetto su cui sto lavorando e il percorso fatto fin qui con il mio cliente automotive. E sa perché oggi gli ho chiesto udienza.
Dopo un qualche convenevole e un breve riepilogo dello stato di avanzamento del lavoro, Giulio prende la parola col suo tipico modo di fare calmo ma diretto e pragmatico
“Giovanni, io credo che sia arrivato il momento di integrare il lavoro che sta facendo sulla parte organizzativa e di product management, con qualcosa sulla parte tecnologica, di iniziare quindi a implementare qualche strumento di tecnologico a supporto della trasformazione organizzativa.
Da quel che mi dicevi, adesso la situazione è matura per introdurre qualcosa di questo tipo che magari abbia un impatto percepibile sul business… ho capito male?”
“No no hai capito bene e sono d’accordo che sia il momento di iniziare a implementare qualche pezzo di prodotto secondo la nuova logica a servizi, magari cross dipartimentale o addirittura collegando qualcosa che sia oltre i confini aziendali.
È da un po’ che ci penso, ho ipotizzato varie strategie e punti di attacco, ma non mi sono ancora convinto su quale sia il modo migliore per partire. Da dove iniziamo per implementare la piattaforma? Non vorrei arrivare con proposte distruttive, ma agendo in modo progressivo…”
Giulio resta in silenzio. Ha una lunga esperienza sull’implementazione di applicazioni platform, mi immagino che avrà provato molte soluzioni differenti sia dal punto di vista architettura le (il cosa) che della strategia per introdurre una piattaforma in una azienda (il come).
Inizia a scrivere qualche disegno alla lavagna: sono schemi che conosco bene, riconosco i classi pcii silos aziendali, i servizi esposti sul layer di frontiera e quelli interni, linee di relazione tra le diverse aziende (B2B) e i rapporti con i clienti (B2C).
Domini applicativi vs. necessità risolta
“In genere un sistema basato su una piattaforma ha uno schema più o meno di questo tipo. Il tema non è tanto se tale schema è corretto o adatto al caso in esame, le platform applications sono (devono esserlo) sufficientemente flessibili e riorganizzabili per essere ricomposte in base alle necessità. Quindi il modello corretto lo si trova, anzi emerge man mano che costruiamo la piattaforma.
Il punto è proprio questo. Non è molto utile, anzi sarebbe controproducente farlo, pensare a una soluzione “big bang” (tutto e subito ne dal punto dello schema tecnico ne per il modo in cui ci si arriva.
“Si chiaro, sono d’accordo”.
“Allora, Giovanni, proviamo a semplificare lo scenario con un modello più piccolo che ci permetta di capire come partire e poi semmai aggiungere complessità un poco per volta. Per esempio prendiamo un paio dei domini delle aziende con cui state lavorando: il dominio dealer — o chiamalo ‘concessionario’, ‘venditore’, come vuoi — e il dominio cliente. Ecco, se io mi dovessi mettere a ‘costruire’ completamente questi domini, avrei bisogno di tempo, di denaro e di lavorare parecchio prima di averli pronti. Non è un lavoro sbagliato di per se, ma nasconde un rischio grosso: creare queste entità dovremo spendere soldi e impegnare risorse per un lasso di tempo in cui probabilmente non avremo alcun impatto sul business. Gli effetti, i benefici, arriveranno certamente ma forse troppo in là nel tempo e in azienda qualcuno non comprendere la necessità di questo tipo di lavoro. È un rischio concreto”. Giulio ha descritto in modo chiaro e semplice quel che io già temo da un po’ di tempo. “D’accordissimo. Dovremmo selezionare e isolare qualche pezzo e partire da lì. Ma cosa?” Continuo ad ascoltare quanto ha da dire. “Lo possiamo scoprire con loro, insieme a loro. Partiamo da qualcosa che un loro bisogno, qualcosa di cui parlano spesso. E poi adottiamo un approccio incrementale, iniziamo a costruirlo e ci diamo delle scadenze intermedie con cadenze regolari. Man mano che costruiamo quel pezzo di business glielo facciamo vedere e magari anche provare”. “Beh non mi dici nulla di sconvolgente, in fondo questo è l’approccio classico di Agile, è l’obiettivo tipico di Scrum. Di fatto mitighiamo il rischio di fare la cosa sbagliata e dal punto di vista psicologico dell’apparente inutilità” lo incalzo. “Corretto. In tanti anni di lavoro sul campo mi sono sempre più convinto che fra i molti benefici delle piattaforme digitali, c’è il fatto di essere abilitatori di alcuni concetti fondamentali del pensiero agile. Il fatto di poter costruire uno scenario di business in modo rapido, di poterlo inserire nel contesto aziendale in maniera indolore ma sopratutto di poterlo modificare in base ai feedback ricevuti dal campo, sono cose di grossissimo valore. Poter sperimentare rapidamente e a basso costo è indispensabile per vedere i benefici del modello iterativo incrementale, try&update, tipico delle metodologie agili”. “Secondo te qual è la caratteristica più importante di una piattaforma che permette tutto questo?” “Il fatto di usare la stessa tecnologia, i micro servizi, per creare sia piccoli elementi di business (i mattoni elementari), che poi puoi comporre per creare servizi più grossi che eroghino funzionalità di business utili per chi deve erogare un servizio all’utente finale (quello che in azienda si chiama il business appunto). Ma sopratutto il fatto di poter disporre di una serie di funzionalità offerte dalla piattaforma in modo automatico, senza doverli ogni volta realizzarle da capo. Parlo di governo dei servizi, discovery, sicurezza, alta affidabilità, logging, versionamento, delocalizzazione e altro ancora. Come ai tempi degli application server dei primi anni duemila, quando ci siamo stufati di fare sempre le stesse cose per mettere in esecuzione un componente software. Oggi vale lo stesso concetto ma a una scala molto più ampia. Vogliamo concentrare i nostri sforzi su pezzi di valore. Non ha senso perdere tempo e risorse per costruire ogni volta la parte infrastruttururale. Ma sopratutto questa parte deve permettere di creare in modo veloce quello che realmente è peculiare del prodotto che stiamo realizzando.
“Dal punto di vista del piano temporale come ti muoveresti?”. “Quello che ti proporrei è di iniziare fornire con frequenti rilasci, piccoli servizi di business che risultano utilizzabili fin da subito. Diciamo che stabiliamo dei punti fermi nel nostro panorama temporale: per fare un esempio, non vincolante, a un mese, a sei mesi, a un anno. E poi ci diciamo: qual è il problema che vogliamo risolvere da qui a un mese? Deve essere qualcosa di piccolo, ovviamente, che però deve avere un effetto positivo e visibile sul dealer e/o sul cliente. Ti devi chiedere quale sia quella funzione, quel ‘qualcosa’ che possiamo implementare e che faciliterà il lavoro che devono fare appunto il dealer o il cliente o tutti e due”. Annuisco e intervengo rileggendo i miei appunti raccolti nelle ultime sessioni col business appunto: “Qualcosa abbiamo già individuato in tal senso. Per esempio una cosa su cui stiamo già lavorando è una funzionalità di traduttore del VIN, il Vehicle Identification Number (numero di identificazione del veicolo). I concessionari hanno la necessità di ricavare tale informazione in modo semplice e univoco, perché i produttori dei vari Paesi usano standard diversi per comporre questo numero identificativo, con formati diversi e addirittura numero di caratteri non corrispondente, per i veicoli più vecchi”. “Ecco,” riprende Giulio, “un traduttore da un codice a un altro può essere molto utile ai dealer che devono cercare su sistemi diversi un veicolo. Potremmo addirittura centralizzare la ricerca su tutti i sottositemi. Questo è uno strumento semplice, che però ha vari vantaggi. Oltre a facilitare un lavoro, mette già in connessione sistemi diversi che possono essere nascosti dalla piattaforma e consente di preparare la struttura anche tecnologica che poi servirà per installare la piattaforma. Tu vedi un servizio unico, non sai cosa c’è sotto. L’aspetto cruciale è che tutti possano iniziare, in tempi brevi, a usare questo servizio e che questo sia utile per loro. Questo potrebbe essere visto come un piccolo intervento con un piccolo componente che risolve un problema puntuale. Ma lo potremmo ottenere in tempi rapidi senza dover apportare stravolgimenti al resto dell’architettura. Perché una piattaforma deve potersi inserire in modo soft in un sistema, altrimenti otterremo troppe obiezioni e problemi. Poi potremmo passare ad altre funzioni diverse, ma simili per approccio: la profilazione del cliente, per esempio. Lo storico dei veicoli posseduti…”.
Tempi di esercizio ed evoluzione della piattaforma
Chiedo a Giulio quel che so già mi verrà chiesto da alcuni dei manager delle aziende, ossia quanto tempo ci voglia per installare e far partire l’infrastruttura tecnologica su cui poi gireranno le funzioni della piattaforma embrionale, come quelle appena descritte. Giulio dà una risposta piuttosto secca: “Nel mese di tempo che ci siamo dati c’è tutto lo spazio per fare anche l’installazione di tutto. Chiaramente poi bisogna vedere come e dove si installa la soluzione: un’infrastruttura self-hosted sulle macchine dell’azienda presuppone tempi e costi maggiori, mentre, con una soluzione cloud, in un giorno tutta l’infrastruttura è montata. Va comunque considerato che si può partire con il cloud e migrare poi in seguito alla soluzione self-hosted… non sono vicoli ciechi. Oltretutto le migrazioni sono fattibili in continuità senza down time o con tempi di disconnessione davvero minimi. Deve essere per forza così, perché uno dei motivi che convincerà all’adozione è anche la garanzia di una business continuity. Non è che a ogni incremento, a ogni ‘versione’ tu poi devi ricostruire tutta l’infrastruttura, la sicurezza, l’autenticazione, l’autorizzazione etc. Essa evolverà in maniera incrementale e senza strappi”. Incalzo Giulio: “Questo concetto della piattaforma che passa di versione mi fa venire in mente come spesso l’utente percepisca il cambiamento sostanzialmente come cambiamento di interfaccia, più che della logica che ci sta sotto o dei dati che la alimentano. Quanto influisce questo aspetto sul processo di crescita della piattaforma?” “Dipende molto dalla governance che si vuole adottare: si può pensare di cercare una massima uniformità nel tempo oppure decidere di cambiare di più, chiaramente solo ad ogni major version”.
L’IT muove il business
“Credo inoltre”, continua Giulio, “che in un discorso del genere pesi anche questa considerazione: sono cambiate delle sensibilità all’interno delle aziende. Si è capito ormai che l’IT muove il business e le due cose vengono viste sempre meno in maniera separata. Noto, ad esempio, che i C-Level dell’IT sono sempre meno persone di formazione strettamente tecnica, ma invece sempre più persone provenienti dal business che sanno parlare con i tecnici e sanno tradurre le esigenze del business ai tecnici e, viceversa, spiegare al business ciò che l’IT può o non puà fare. E questi C-Level hanno un vantaggio: sanno che i tempi del business sono molto più veloci di quelli tecnici e quindi cercano anche di ‘prevedere’ in anticipo quali potranno essere le richieste del business, in modo da non trovarsi poi in affanno. Poi è chiaro che non è sempre così, che ci sono realtà in cui diventa difficile far parlare questi due mondi… Ma il fatto è che oramai il business si fa sempre più con il digitale e quindi diventa importante che questi due mondi si parlino e si comprendano. Noi che veniamo dal mondo Agile parliamo spesso di feature team ma altri usano il termine fusion team che forse, per quello che esprime, è anche più giusto. Se il digitale non fuziona, il business non viene erogato”. Di Giulio continua a sorprendermi sempre questo costante “ping pong” tra una visione di business ad alto livello e un pragamatismo tecnologico ancorato alla concretezza. “Per questo”, continua Giulio, “quando diciamo che Business e Digital/IT lavorano insieme non vogliamo dire che hanno lo stesso backlog, perché alla fine devono fare cose diverse. Ma intendiamo dire che daranno lo stesso nome alle stesse cose e guarderanno le stesse dashboard, cercando di capirsi bene. La piattaforma ti garantisce questo: che tutti guardiamo la stessa cosa, perché non ci sono più ‘cose’ al di fuori della piattaforma, ma tutto è contenuto in essa ed esposto dalle sue interfacce, in maniera svincolata dalla provenienza del dato”.
Marketing interno per arrivare a completamento
“Un aspetto importante nel nostro processo incrementale è che lo possiamo ripetere, più volte, come dicevo. Prima implementi una funzione piccola ma utile, che risolve un problema. Poi ne fai un’altra, sempre in tempi brevi, poi un’altra ancora…”. Lo interrompo: “A questo punto, però, Giulio ho un dubbio. Se implemento una soluzione puntuale, e poi un’altra e poi un’altra, per quanto siano efficaci in tempi rapidi, non c’è il rischio di perdere di vista la visione globale (sia per l’infrastruttura tecnica che per il modello di business), la cosiddetta big picture che da vita al cosiddetto ecosistema digitale?….”. “Be’, si,è un rischio che può succedere.” dice Giulio. “Ma non è che tu continuerai all’infinito con questo sistema. Aver dimostrato che una forma embrionale e limitata di piattaforma è stata in grado di risolvere alcuni problemi, per quanto piccoli, e di avere un impatto sul business, per quanto minimo, ci mette nelle condizioni di introdurre il sistema completo. Dobbiamo fare quello che si chiama marketing interno, ossia cominciare a pubblicizzare e a ‘vendere’ la soluzione completa all’interno dell’azienda. Con i primi pezzetti implementati noi abbiamo comunque creato, solo per dirne alcuni, un componente di autenticazione, uno di sicurezza, una connessione per il database… abbiamo messo dentro dei dati che magari poi servono anche ad altri, come mi dicevi per il discorso del Digital Bazar… Non ti sembra?”. “Certo”, confermo. “A questo punto, ci sarà qualcuno in azienda che, opportunamente interessato dalla nostra azione di marketing interno, vorrà connettere alla piattaforma il suo caso, accedere ai dati che gli interessano, realizzare la funzione di cui ha bisogno. E in questo modo la piattaforma cresce, si aggiungono nuovi componenti e nuove funzioni, si accede ad altri dati che magari sono di interesse per altre persone ancora e così via. Con questo sistema ad apposizione, per rimanere nella tua metafora dell’ecosistema, la piattaforma funge da terreno fertile su cui possono crescere tante piante diverse che a loro volta attireranno insetti e altri animali e costituiranno un ecosistema sempre più complesso. La piattaforma diventa, appunto, una base sotto la quale ci sono tutti i dati e i meccanismi e sopra la quale si va a prendere ciò che serve di volta in volta, senza più preoccuparsi troppo di come inizialmente quel dato o quella funzione è entrata nel sistema, almeno a livello di utente finale. L’impatto sul business dell’azienda, in particolare di azienda grande in senso internazionale, diventa potenzialmente enorme”.
Piattaforma come prodotto
Giulio ormai è un fiume in piena. Sempre placido e calmo, ma con due occhi eccitati, prosegue inarrestabile: “Abbiamo parlato di marketing interno, e il marketing si fa con un prodotto. Quindi la piattaforma che consideriamo uno strumento deve diventare un prodotto: deve avere un nome e una riconoscibilità, deve esserci un luogo in cui trovo le informazioni al riguardo, che sia un forum, un blog o un wiki. Serviranno dei momenti di dimostrazione e di formazione. Ci saranno degli early adopters che faranno migliorare il prodotto nelle prime fasi ancora ‘imperfette’. E servirà un platform team che prenderà in carico tutta una serie di attività di manutenzione e miglioramento della piattaforma. È la stessa cosa che gestire il lancio e l’affermazione di un qualsiasi altro prodotto”. “Ti seguo”, lo guardò mente mi segno qualche appunto, “ma in certi casi ci saranno anche degli oppositori all’adozione di questo prodotto, no? Ci saranno, che so, dei manager a cui interessa principalmente di portare a compimento il loro pezzetto di business, con il loro silos e il loro monolite, e che si disinteressano totalmente della piattaforma”. Giulio valuta un po’ la mia obiezione. Poi aggiunge: “se la piattaforma funziona davvero e ha un impatto sul business, alla fine sarai quasi ‘costretto’ ad adottarla. Semplicemente perché con questa fai meglio o in meno tempo le cose che dovresti fare comunque con maggior dispendio di tempo e/o energie. E se la piattaforma non ha questo appeal vuol dire che è fatta male, in maniera non adatta all’azienda in cui dovrebbe funzionare. Allora è giusto che fallisca… Ma se la piattaforma ha dei risultati tangibili… alla fine tutti, dai C-Level all’utente meno predisposto, saranno invogliati ad adottarla”.
Opportunità, rischi, errori
“Guarda Giovanni, ti racconto una cosa che ho visto qualche tempo fa a una conferenza. È stata presentata una slide che mostrava un’idea di piattaforma disegnata da un C-Level e la cui implementazione doveva essere in carico all’IT. Stiamo parlando di un’azienda molto molto grande. Che cosa ci dice tutto questo?”. Non capisco subito dove vuole arrivare Giulio, ma so che sta per dirmelo, ma lo anticipo: “ma scusa, come ha fatto il manager di alto livello a ‘progettare’ questa idea di piattaforma? Chi glielo ha detto?”- “Per come era fatta, la piattaforma ricordava le prime incarnazioni del concetto di piattaforma, tipo quella di Uber di dieci anni fa per capirci: ci sono n canali, n applicativi, un core di dati… non è niente di eccezionale. Ma la risposta a quello che ti chiedevo prima è che il motivo per cui l’ha fatta… è che ne aveva bisogno, gli serviva qualcosa del genere, era una sua esigenza, o meglio un’esigenza dell’azienda. Indipendentemente dalla soluzione tecnologica o dal prodotto specifico ”. “Chiaro” gli faccio eco. “Ma non sempre è così”. “Perché tu stai pensando a certe ‘grandi’ aziende italiane che però sono piccole rispetto alle enterprise company internazionali. E in queste aziende davvero enterprise una piattaforma può avere un impatto sul business nettamente tangibile, anche con certi errori che si possono commettere”. “Quali?” Giulio non ci pensa e risponde velocemente: “Ci sono varie sfide in questo percorso, con tante opportunità, ma anche rischi ed errori. Il primo errore, secondo me, è pensare di farsi la piattaforma in casa, da soli. Questo porta ad avere ogni team o ogni dipartimento a lavorare sulle stesse cose, per reinventare ogni volta la ruota, pensando che il suo business, le sue caratteristiche sono così speciali da risultare diverse da tutte le altre. Che un po’ è anche vero, ma non significa che servano mille piattaforme diverse. Questo è un rischio grosso che si elimina con una forte collaborazione interna, con un approccio open source che riguardi le conoscenze e le pratiche interne all’azienda. È chiaro che serve una governance, che servono delle linee guida chiare sul modo in cui gestire la codebase comune. Ma è questa la direzione in cui procedere. L’altro aspetto pericoloso è dimenticarsi di far vedere i risultati concreti e in tempi brevi che la costruzione della piattaforma riesce ad avere sul business: diversamente si rischia di vedere il progetto chiuso prima del tempo, con delusione oltre a perdita di tempo e di soldi. Far vedere il valore di business che viene generato è cruciale”. “Si torna sempre al tema delle misurazioni, che non è facile”, intervengo. “Non è facile”, mi conferma Giulio. “Pensa a tutte le aziende che hanno adottato questo approccio a piattaforma: quante di queste non avrà dei reali benefici? E cosa succederà di conseguenza? Disillusione. Ma la disillusione è il risultato delle aspettative disattese. Ed è per questo che diventa fondamentale fissare delle aspettative realistiche e raggiungibili per fare business con il digitale”.
Senza smentirsi
La nostra chiacchierata prosegue ancora un po’ anche se il nocciolo ormai l’abbiamo affrontato. Ho raccolto molti spunti e sono sicuro di tornare dai “miei” manager con le idee molto più chiare e una giusta prospettiva. “Giulio, a questo punto ne approfittiamo per mangiare insieme”. “Certo” mi risponde. “Ma una cosa veloce eh. Subito dopo ho una telefonata importante”. E come potevo dubitarne?