Digital revolution: trasformare le aziende in ecosistemi digitali

Antifragilità degli ecosistemi digitali

“Ciao Giovanni, allora che fai? sempre nella mia cara Roma a lavorare?”

“ciao Luca…. qual buon vento… era tanto che non ci sentivamo, mi cogli di sorpresa a quest’ora del mattino”.

Sono le 7.00 e sto guidando verso la capitale proprio per andare dal mio cliente. Al telefono mi chiama Luca un caro amico con il quale ormai sono in contatto da tanti anni, fin dai tempi dei primi numeri del magazine MokaByte. Con lui ci sentiamo regolarmente e abbiamo condiviso esperienze di vita e professionali da ormai quasi 20 anni. Ci saremo visti in presenza un paio di volte, ma è come se avessimo lavorato fianco a fianco nella stessa stanza di ufficio.

Non abbiamo orari e quando abbiamo voglia ci sentiamo o scriviamo.

Ma stamani, sarà che non mi sono ancora fermato all’autogrill per il caffé, la telefonata di Luca mi ha letteralmente fatto sobbalzare sul sedile dell’auto.

“Si Luca sono sempre a Roma. Ma te ne avevo parlato?”

“No no mi avevi detto che era Roma, ma sai che ho i miei informatori”

“Si mi immagino…. ”

“Ah Giovà, sei te che lo hai scritto sui social qualche giorno fa, non ti ricordi?”

“A sì è vero, hai ragione…. scusa sono ancora assonnato stamani”

“E come procede il lavoro? Mi avevi detto che si trattava di una cosa lunga e piuttosto ampia. Che stai facendo? hai già agilizzato tutto? in cosa sei coinvolto?"

“Sono ormai alcuni mesi che sono su questo cliente e ormai si possono toccare con mano gli effetti concreti del lavoro svolto. Abbiamo messo in piedi un team di persone coinvolte in differenti aree della trasformazione digitale, da quelli meramente organizzativi e strategici a quelli più tecnici e implementativi. L’aver seguito il gruppo su tutti questi argomenti mi ha permesso di avere una visione completa del lavoro di fare da collettore fra i differenti ambiti.

Inizialmente ho lavorato fianco a fianco con i manager per la definizione della visione di alto livello e della strategia implementativa; adesso supporto il loro lavoro cercando di interferire il meno possibile con le loro idee e i loro esperimenti”.

“Dal punto di vista implementativo, sul campo stai seguendo i team di sviluppo?”

“Si siamo partiti con la formazione Agile-Scrum poi li abbiamo supportati nella operatività del lavoro di Sprint. Qui ho lavorato all’inizio poi ho coinvolto alcuni colleghi”.

“A non sei solo sul cliente?”

“No, non potevo (e non volevo) seguire tutto io. In genere su progetti così ampi troviamo utile organizzare un piccolo team di agile coach che possano lavorare aiutandosi e confrontandosi a vicenda. Io adesso sto seguendo più gli aspetti organizzativi e di strategia della trasformazione”.

Racconto a Luca un po’ di dettagli del mio lavoro: di come spesso il mio contributo sia quello di facilitare il loro lavoro con sessioni di facilitazione per mettere chiarezza sullo stato di avanzamento dei vari stream; oppure supportare una decisione su un determinato esperimento “perché volete fare questa cosa? Che effetti vi aspettate di ottenere? E tali effetti sono in linea con gli obiettivi che vi eravate posti a inizio progetto?”.

“Ma quanto sei coinvolto con loro? stai fisso tutti i giorni della settimana?”\ “No, effettivamente, come è normale che sia, il mio contributo in questo periodo sta scemando, io ora servo più che altro per fare il punto, tenere sotto controllo il backlog delle iniziative e, di tanto in tanto, suggerire ogni tanto qualcosa di nuovo da fare.

“non sei più utile?” dice Luca ridendo.

“Bah…. Ormai sono autonomi, purtoppo spesso il mio lavoro è a tempo determinato. L’approccio pseudo OKR ha attecchito e loro per primi non partono con nuove iniziative se prima non hanno chiaro perché fare una cosa ma soprattutto come valutare se una attività ha successo oppure no e nel caso come replicarla per evitare che sia solo il caso a portare avanti il progetto. Direi un approccio scientifico.

Ogni tanto propongo qualche idea, qualche nuovo concetto preso magari dai miei studi o da esperienze fatte altrove e vedere se la cosa crea interesse”.

Faccio una pausa mentre cambio corsia per un sorpasso.

“Questo è proprio quello che ho fatto qualche giorno fa con il CTO quando ho iniziato a parlare di antifragilità. Il gruppo di lavoro è ancora alle prese con il tema DataMesh per creare domini e responsabilità sulla gestione dei dati. Ma lui guarda già avanti, sta ormai in fissa con il prossimo step, introdurre antifragilità nel sistema”.

La telefonata prosegue ancora un po’ finché arrivo e parcheggio quando mi congedo da Luca per scendere dall’auto e andare verso la portineria.

“Caro Luca sono arrivato a destinazione, devo lasciarti”

“Bene, senti, una cosa importante… sono laziali o romanisti?”

“Non so, lo sai che io non seguo il calcio. Seguo solo gli sport giusti, quelli con le ruote”.

“Mannaggia a te. Vabbé buona giornata”

“Ciao, grazie della compagnia durante il viaggio”.

Uscito di macchina mi dirigo verso la portineria. Ormai sono di casa e le procedure di accesso sono semplificate da quando mi hanno dato un mio badge personale. Mi dirigo verso il bar del primo piano. Alessio è già lì che mi aspetta con un mega sorriso: un po’ a presa di giro, si presenta con il libro di Taleb sotto braccio che tiene con finta non chalance come se fosse ormai normale per lui girare con tali letture sotto braccio.

Antifragilie, il libro di Nicholas Taleb \[1\] lo ha catturato e quando ci rivediamo spesso si ritaglia dei momenti non lavorativi per discutere con me delle implicazioni o delle implementazioni.

“Allora Alessio ormai sei un discepolo di Nicholas?”

“Molto bello ‘sto libro. Mi sto chiedendo però come inserire questi concetti con il lavoro che stiamo facendo sui servizi e sugli ecosistemi digitali?” mi chiede lui.

“Domanda lecita. Anche io me lo sono chiesto a lungo e non solo su questo progetto con voi. È una domanda che mi accompagna ogni volta che inizio a lavorare con un nuovo cliente”.

“È che risposte ti sei dato? Se te ne sei date”.

“Qualcosa si. Forse anche qui su questo progetto potremmo fare qualcosa di interessante”.

“Bene. andiamo in ufficio che mi racconti”

Dopo 5’ siamo nella sua stanza e sto facendo qualche scarabocchio sulla lavagna alla parete.

“Allora Immaginiamo di dover realizzare quello che abbiamo chiamato servizio digitale composito ossia dato dalla aggregazione di altri servizi che provengono da contesti differenti”.

Disegno il classico schema di un'applicazione composta.

“Se il servizio è bene progettato e implementato, l’utente, usandolo, potrà risolvere le proprie necessità senza rendersi conto di questa frammentazione sottostante.

Il servizio composto potrebbe essere quindi il risultato dell’interazione di prodotti digitali appartenenti allo stesso ecosistema: tali componenti si parlano fra loro e scambiano dati e servizi in modo coordinato e coerente”.

Alessio annuisce prontamente: “Si certo, di questo abbiamo già parlato a lungo le volte scorse, ed è quello che stiamo facendo. Ma da qui all’Antifragile, come ci si arriva?”.

Da “meccanismi” a ecosistemi

“Ecco. Immaginiamo adesso di introdurre nel nostro ecosistema un qualche stress o un qualche disturbo, come un carico di lavoro inusuale causato da molti utenti che cercano di usare un servizio offerto dal prodotto, oppure un cambiamento di un vincolo di dominio che porta alla “rottura” del servizio. Tale alterazione potrebbe causare un malfunzionamento in uno dei componenti sottostanti, che in modo non previsto tutto d’un tratto potrebbe divenire non più adatto al nuovo scenario. Questo potrebbe portare quindi a un malfunzionamento dell’intero servizio composto”.

“Si ovvio. È tutto incastrato. Se si rompe un pezzo, si rompe tutto… Non è resiliente. Ma forse basterebbe mettere in ridondanza qualcuno dei componenti sottostanti. Se si blocca un nodo, c’è quello accanto pronto a rispondere al suo posto”.

“In realtà quello che stiamo cercando di fare è di creare un sistema che non solo sappia resistere alle difficoltà, ma di gestire uno scenario più complesso. Qui infatti non stiamo parlando di un componente che si rompe e smette di funzionare, per esempio un database server che smette di rispondere alle interrogazioni.

Lo scenario che stiamo immaginando potrebbe essere ben peggiore. Il componente incriminato potrebbe essere ancora perfettamente funzionante, ma potrebbe funzionare in modo non adatto, non corretto o non efficace nel nuovo scenario. Creare ridondanza (per esempio con un cluster di server) potrebbe solo peggiorare la situazione, replicando e propagando qualcosa che si sta dimostrando inadatto o peggio ancora fragile. Ti ricordi la storia delle banane Cavendish? Replicare lo stesso DNA non è una buona cosa se quel codice genetico improvvisamente mostra una qualche vulnerabilità. Serve differenziare con qualcosa di alternativo. Stiamo dicendo che in un caso come questo serve un'evoluzione genetica dell’ecosistema. Il servizio dovrebbe aggregare componenti diversi, introducendo comportamenti diversi più adatti al mondo che è cambiato.

Alessio sembra convinto: “mi fai qualche esempio di qualcosa che d’un tratto, per funzionando ancora, non va più bene? E come il sistema può auto correggere il difetto genetico, se ho compreso bene, stiamo parlando di questo.

“Si in questi mesi stiamo lavorando coi nostri clienti su alcuni prodotti basati su questa logica. Per questo, proprio per costruire “la soluzione”, siamo partiti dalla raccolta di un po' di problemi, applicazioni realizzate per composizione di servizi che, a causa di un cambio di scenario, hanno smesso di fornire risposte corrette pur continuando a funzionare.

Il primo è un caso che ho visto direttamente su un progetto dove sono stato coinvolto qualche tempo fa.

In questo caso stavamo lavorando su un'applicazione di e-commerce che utilizzava un sistema di raccomandazioni basato su microservizi. Ognuno di questi servizi analizzava il comportamento degli utenti, le transazioni e le preferenze per suggerire prodotti.

Un bel giorno, a causa di una promozione speciale, il numero di accessi è aumentato significativamente e il sistema di raccomandazioni non è più riuscito a gestire il carico, generando suggerimenti poco sensati, obsoleti o non pertinenti. Pur continuando a funzionare tecnicamente, i risultati non erano più accurati o utili”.

“e qui cosa avete fatto”?

“Abbiamo lavorato dietro le quinte, cambiando il servizio che non reggeva il carico mettendone uno più robusto”.

“Ecco, proprio in questo caso, non poteva bastare creare un cluster di servizi per permettere di reggere il maggior carico?”

“Si a dire il vero qui si poteva fare anche in questo modo, ma abbiamo preferito cercare una soluzione più stabile riprogettando e riscrivendo il servizio. La cosa bella è che abbiamo lavorato con l’orchestratore in modo da cambiare il servizio in modo semplice e indolore per il resto dell’architettura. In teoria il sistema avrebbe potuto farlo da solo (dico questo in riferimento al concetto di antifragilità, di cui ti parlo dopo”.

Similmente ricordo il caso di un prodotto di Gestione Documentale che utilizza servizi compositi per classificare e archiviare automaticamente i documenti basati su parole chiave, categorie e contesto.

A seguito di un aggiornamento delle normative di classificazione dei dati (ad esempio, nuove regole GDPR), uno dei servizi di traduzione o categorizzazione dei dati non è stato aggiornato. Il sistema ha continuato a funzionare, ma classificava i documenti in modo errato o li archiviava in posizioni sbagliate, creando confusione e possibili violazioni normative. “

Di natura differente, ma analogo nella problematica ricordo un caso successo qualche tempo fa in cui io ero solo marginalmente coinvolto; mi chiesero infatti di supportare la parte di envisioning di un prodotto che doveva essere realizzato da una azienda italiana e che prevedeva al suo interno un meccanismo di raccolta dei commenti degli utenti del portale (un sistema di gestione di contenuti, un CMS). Il sistema poi doveva presentare contenuti agli utenti in base ai loro interessi, ricavati dai commenti degli utenti.

Questo sistema è costituito da microservizi che analizzano i dati degli utenti e gestiscono le preferenze di visualizzazione.

Una volta andati in produzione con il prodotto, il sistema ha funzionato piuttosto bene per un po’. Poi un bel giorno il comportamento degli utenti è cambiato, senza che i gestori del portale potessero intercettare cause e nuove tendenze (principalmente legate alla semantica dei messaggi lasciati dagli utenti). Questo ha reso inefficace il lavoro di uno dei microservizi responsabile della categorizzazione dei contenuti: anche se tecnicamente funzionante, il servizio ha iniziato a mostrare contenuti irrilevanti o non aggiornati, riducendo l'engagement degli utenti.

Alessio mi guarda un po’ perplesso: “Il primo forse no, ma il secondo e il terzo caso sono di fatto malfunzionamenti legati a difetti di progettazione o configurazione, derivati da una cattiva gestione della piattaforma… no?”

“si in linea di principio sì, ma non è questo il punto. Questi esempi illustrano la fragilità di un'applicazione composita, dove anche se un singolo componente non si adatta a un nuovo scenario può compromettere il funzionamento dell'intero sistema, pur continuando a essere tecnicamente operativo. E qualcosa di simile a quello che accade in una applicazione monolitica, solo che qui la complessità è molto maggiore.

Questi esempi evidenziano quindi come i problemi in sistemi compositi spesso richiedano un'evoluzione del sistema stesso, un vero e proprio "cambio del codice genetico" delle applicazioni. Quando un componente chiave di un sistema non riesce ad adattarsi a nuovi scenari, l'intero sistema può fallire nel fornire risultati corretti, pur rimanendo tecnicamente funzionante. È come se il sistema dovesse evolversi per sopravvivere in un nuovo ambiente, proprio come un organismo deve adattarsi a nuove minacce per continuare a prosperare.

Un parallelo può essere tracciato con il virus COVID-19, dove il nostro sistema immunitario, inizialmente, non era pronto a gestire questo nuovo nemico. Il corpo umano ha dovuto adattarsi rapidamente, con l'aiuto dei vaccini e altre misure, per sviluppare una risposta efficace contro il virus. Allo stesso modo, le applicazioni devono essere evolute e aggiornate per affrontare nuove sfide, che si tratti di un aumento del carico, cambi normativi o cambiamenti nei comportamenti degli utenti. Senza questa capacità di adattamento, le applicazioni rischiano di diventare obsolete o inefficaci, proprio come il nostro sistema immunitario sarebbe stato se non avesse sviluppato una risposta adeguata al COVID-19.

“Quindi stiamo dicendo che dovremmo cambiare decisamente approccio. Cioè non dovremmo più ragionare come si fa di solito: se si rompe un componente, entra in funzione il gemello, ma dar vita a un qualche meccanismo di diversificazione fatta di elementi differenti in grado di svolgere compiti equivalenti ma in modo differente e con risorse differenti…”.

Vedo con piacere che Alessio è entrato pienamente nel contesto. E rinforzo quanto ha appena ipotizzato: “È così. Per capirci, ipotizziamo che il servizio di cui prima si blocchi perché un componente sottostante smette di funzionare, per esempio il componente per il calcolo del prezzo. In tal caso, il servizio, o meglio il sistema che ha aggregato i vari elementi per creare quel servizio, dovrebbe scartare il componente che non funziona e sostituirlo con uno più adatto, cercandolo nell’ecosistema digitale. In tal modo, in caso di failure, il servizio cambierebbe in qualcosa di diverso. Probabilmente migliore. Il sistema ha ‘appreso’ qualcosa, si è evoluto e ora funziona in modo più adatto rispetto al nuovo contesto.

Potremmo chiamare questo comportamento antifragilità ecosistemica”.

"Mi stai dicendo che il sistema deve scegliere automaticamente un nuovo servizio quando quello esistente non funziona più bene... ma come fa a scegliere quello giusto?" chiede Alessio, appoggiandosi allo schienale della sedia con un'espressione tra il curioso e lo scettico.

"È una domanda cruciale" rispondo. "Il meccanismo si basa sul fatto che i servizi nell'ecosistema non sono elementi passivi. Quando vengono integrati nella piattaforma, si presentano, si registrano e si certificano automaticamente, dichiarando le loro capacità e caratteristiche."

"Aspetta un momento..." Alessio si sporge in avanti, poggiando i gomiti sulla scrivania. "Se questi servizi si auto-presentano con le loro caratteristiche, non sarebbe più logico mettere subito in campo il servizio più potente disponibile? Così saremmo sicuri di non avere problemi di prestazioni."

Sorrido, perché è esattamente il tipo di obiezione che mi aspettavo. "In realtà non è così semplice. Non è detto che stiamo cercando qualcosa di più potente. A volte quello che serve è qualcosa di completamente diverso, un servizio che magari all'inizio del progetto non era nemmeno necessario, o che addirittura sarebbe stato controproducente utilizzare."

"In che senso?" chiede Alessio, sempre più interessato.

"Pensa a un servizio di analisi dati" spiego. "All'inizio potresti aver bisogno di qualcosa di semplice e veloce per gestire pochi dati. Un servizio più potente sarebbe solo uno spreco di risorse. Ma se il contesto cambia - magari aumenta il volume dei dati o servono analisi più sofisticate - potresti aver bisogno di un servizio completamente diverso, con caratteristiche che prima non erano rilevanti. L'antifragilità sta proprio in questo: la capacità di evolversi verso soluzioni che inizialmente non avevamo nemmeno considerato, ma che nel nuovo contesto si rivelano più efficaci."

Un servizio composto: piattaforma di viaggi personalizzati “TravelHub”

“Bello. Ma fammi capire in concreto come potrebbe funzionare una cosa del genere” mi dice Alessio.

“Certo. Ti racconto un caso a cui ho lavorato qualche tempo fa”. Faccio una breve pausa, quasi a voler dare il tempo a entrambi di sedimentare quel che ci siamo detti fin qui, prima di vedere l’esempio che sto per raccontare.

“TravelHub è un servizio digitale che offre esperienze di viaggio personalizzate, integrando servizi da varie aziende, come compagnie aeree, hotel, servizi di trasporto locale e attività turistiche”.

“Si, di applicazioni così ne ho un paio installate sul mio telefono” mi fa Alessio. “Le uso per le vacanze e per i viaggi di lavoro”.

“È un servizio simile ad altri che ci sono in questo momento” continuo. “La peculiarità è che TravelHub è un sistema B2B, ossia può essere integrato con i sistemi informativi delle aziende. È quindi integrato con le anagrafiche aziendali e con le logiche di gestione del personale o con le strutture convenzionate con quella azienda”.

“Ah OK, un sistema integrato cross aziendale: In base alla nostra definizione è un X-O” fa Alessio.

“Si esatto. L’utente, usa il sistema per organizzare un suo viaggio oppure per prepararlo a un altro dipendente dell’azienda. Accede a TravelHub per pianificare e prenotare interi viaggi, senza doversi preoccupare della complessità sottostante legata all’integrazione dei diversi servizi”.

Prendo la penna dell’iPad e inizio a fare qualche schema della struttura di questo sistema sullo schermo..

“TravelHub agisce come un ‘direttore d’orchestra’ che coordina le interazioni tra i diversi musicisti dell'orchestra. Solo che al posto di tanti strumentisti diversi che devono suonare in modo armonizzato, qui ci sono i servizi. Quando un utente pianifica un viaggio, TravelHub chiama i propri partner per aggregare le opzioni di volo, alloggio e trasporto, creando un itinerario personalizzato basato sulle preferenze dell’utente. La piattaforma offre in modo unico alcuni servizi che sono la risultante di aggregazione di servizi/prodotti sottostanti, sia esterni all’azienda (compagnie aeree, catene di alberghi, servizi di noleggio auto, guide turistiche locali, assicurazioni di viaggio) che interne (sistema gestione ferie, archivio convenzioni, logistica sedi esterne o CRM per i clienti terzi).”

“Tutto chiaro”, mi rassicura Alessio.

“Immaginiamo ora che un servizio esterno, ad esempio la prenotazione di un albergo, incontri un sovraccarico o, peggio ancora, non riesca a fornire risposte perché un cambio di scenario sociale, politico, economico, lo rende inadatto. TravelHub rileva automaticamente l’anomalia e si ri-configura tramite l’utilizzo di altri componenti/servizi/prodotti che offrono la fornitura dell’alloggio senza interruzioni per l’utente”.

Non è magia…

“Ma… come fa la piattaforma a riconfigurarsi? Ha qualcosa basato su AI?” mi interrompe giustamente Alessio. “Di questo parleremo più avanti. Per ora, per quanto questa affermazione possa sembrare superficiale, possiamo dire che è un tecnicismo. Di una notevole complessità, ma è più legata al come farlo, non al perché”. “E il perché cos’è?” “Il perché è che noi vogliamo creare un sistema che, pur in caso di incidente, possa da un lato assicurare che l’esperienza utente rimanga fluida e che le preferenze dell’utente siano soddisfatte. Dall’altro evolvere verso qualcosa di nuovo che sia più adatto al nuovo scenario creatosi. Quell’incidente non dovrebbe più verificarsi”. “Si capisco dove vuoi arrivare. Questa non è l’applicazione della ridondanza: dopo aver gestito l’incidente, l’ecosistema di TravelHub fa un’analisi per comprenderne le cause e valutare la reazione dei diversi componenti. Questo esame approfondito porta a ottimizzazioni mirate — come l’aggiustamento delle soglie di allarme e il miglioramento delle logiche di routing — che rafforzano l’intera rete di servizi. Attraverso questo ciclo di apprendimento ed evoluzione, l’ecosistema non solo supera il momento di crisi ma si arricchisce di nuove competenze e capacità operative”. “Si, Alessio. Hai colto esattamente il punto”.

Antifragilità ecosistemica

Proseguiamo a parlottare ancora un poco; la conversazione sta andando bene. Da quando lo conosco ho imparato che Alessio è sempre attento a cogliere le innovazioni e le proposte anche “anticonformiste”, restando però sempre attento alla realizzabilità delle soluzioni. Continuo a raccontare: “L’antifragilità ecosistemica si manifesta nella capacità di TravelHub di adattarsi e migliorare in risposta a stress ambientali. Invece di essere vulnerabile a fallimenti singoli, il sistema si riconfigura, sfruttando nuovi sottocomponenti o strategie di riconfigurazione che migliorano la sua resilienza e funzionalità nel tempo. Questa capacità di evolversi attivamente in risposta a sfide inaspettate garantisce che l’esperienza dell’utente rimanga ottimale, indipendentemente dalle turbolenze sottostanti nel panorama dei servizi integrati. A noi interessa creare un sistema che evolva nel tempo, sia per essere più forte, sia per essere capace di fare sempre qualcosa di nuovo”. “Sembra veramente un sistema vivente. Ma…”. Alessio si alza e indica gli ascensori per andare verso l’ufficio. “Ma?”, chiedo io “C’è un pezzo che mi manca… Per ora tu ci hai fatto lavorare su aspetti prettamente tecnici: microservizi, piattaforma, composizione di applicazioni, ridondanza dei sistemi. Qui invece stai raccontando cose che hanno a che fare principalmente con aspetti organizzativi, culturali, direi perfino legali.” “Esatto. Per definire questo insieme di elementi si parla spesso di sistema socio-tecnico”. Alessio continua: “Perché se seguiamo la metafora dell’ecosistema naturale, se un servizio deve evolvere, vuol dire che si deve riorganizzare dinamicamente prendendo nuovi elementi per svolgere un lavoro. Quindi deve sapere chi fa cosa, come lo fa, come connettersi, quanto costa, che garanzie offre… Insomma mi sembra che la fai facile, ma qui mi pare che stiamo parlando di fantascienza”. Comprendo l’osservazione di Alessio. I dubbi sono leciti: “In effetti la sfida che ci si pone di fronte è più culturale e organizzativa che tecnologica, anche se una parte di tecnologia ancora non è del tutto pronta e ci vorrà ancora un po’ per avere soluzioni tecniche ancor più mature”. Stiamo mettendo molta carne al fuoco. Entrati nell’ascensore, mi prendo il tempo per una pausa. Il tempo di salire al piano mentre osserviamo il panorama dall’ascensore a vetri. Arrivati al corridoio entriamo nella stanza di Alessio.

Soluzioni pratiche dai presupposti culturali

“Allora Giovanni…Cosa hai in mente? Sei qui per raccontarmi di scenari futuribili oppure hai qualche proposta concreta per me?”. “In effetti molte delle cose dette possiamo già iniziare a farle oggi. Per altre serve che lavoriamo a creare i presupposti culturali. Vista la vostra posizione di mercato e la credibilità del vostro brand, è una cosa che potremmo guidare per esserne i promotori”. Alessio mi guarda con un misto di stupore e scetticismo: “Giovà, ho già un sacco di problemi da gestire, il mercato è difficile, la transizione energetica… la situazione geopolitica in Medio Oriente…”. “Comprendo…“ mi sposto verso la finestra accanto a lui. Con tono molto calmo e franco gli faccio la mia proposta: ”Facciamo che ti racconto cosa stiamo facendo presso altri nostri clienti e nel nostro lab. Ti mostro uno scenario completo e capiamo cosa può interessarti, così possiamo capire anche quel che potremmo fare insieme nei prossimi mesi”. Si siede rassegnato. Ormai riconosce il mio tono di voce e la luce nei miei occhi. Per la prossima mezz’ora non potrà interrompermi. “Partiamo dal tema della popolazione di un ecosistema. In natura gli esseri viventi trovano posto in un ecosistema in base a un delicato equilibrio dinamico che offre spazi di manovra, o di sopravvivenza, nei quali avviene un adattamento. Un certo insetto può sopravvivere se trova collocazione o adattamento in base a cosa è in grado fare, a cosa offre agli altri esseri viventi e a cosa sa prendere dagli altri elementi dell’ecosistema. Discorso analogo possiamo farlo per un servizio di business: la sua presenza nella piattaforma sarà garantita se qualcuno lo usa, ossia se offre qualcosa di utile per qualcuno. In ottica ecosistemica, si potrebbe dire che la sua presenza sulla piattaforma è garantita se quello che fornisce può essere usato in co-creazione con altri servizi di business”.

Ecosistemi naturali e digitali…. Da insetti a microservizi. Mentre parlo, mi rendo conto come l’uso metafora sia un ottimo modo per uscire da un contesto difficile ed entrare in un altro più semplice da comprendere perché più vicino alla realtà di tutti i giorni. Ma che poi per rientrare nel contesto iniziale non è semplice e il parallelismo fra i due mondi non può essere mai perfetto al 100%. Gli ecosistemi digitali sono, appunto, digitali e non naturali: certi meccanismi e certi termini non potranno mai essere identici quando ci spostiamo dal mondo ecologico a quello socio-tecnico e di business. Eppure, più andiamo avanti in questo percorso, più mi rendo conto che la metafora dell’ecosistema ha un suo valore e rende abbastanza bene tanti concetti che ritroviamo nelle nostre attività tecnologiche. Continuo: “Se con il tempo non viene più utilizzato in alcun processo di business — perché non offre funzionalità interessanti, oppure non alle prestazioni attese — quel servizio si estinguerà: tradotto, vuol dire che il costo che l’azienda produttrice di quel componente/servizio impone non sarà giustificabile e probabilmente verrà tolto dalla piattaforma”. “Be’ forse non ce lo dovevano mettere. Mi pare il classico caso di prodotto mal pensato o non utile per il mercato”, osserva Alessio. “Non è detto.” gli rispondo. “Magari era utile un tempo per fornire informazioni o svolgere un determinato compito, ma ora potrebbe non essere più necessario. Chi userebbe oggi un servizio di prenotazione di videocassette, stile Blockbuster? Eppure era molto usato qualche anno fa. Oppure il servizio potrebbe risultare non performante, magari perché usa tecnologia obsoleta o per altri motivi”.

Governance dei servizi

“OK chiaro, Giovanni. Ma quindi come facciamo a risolvere questa cosa?”. “A mio parere molti sono gli aspetti da tenere in considerazione per abilitare uno scenario come questo. Se dovessi sceglierne uno da cui partire, indicherei la governance dei servizi. Magari facendo esperienza degli errori fatti nei primi anni Zero di questo secolo con la Service Oriented Architecture, la SOA. All’epoca ci si preoccupava di lavorare sulle anagrafiche dei servizi — chi fa cosa, come si chiama, dove sta — sui contratti di invocazione — tecnicamente, come invocare un servizio— e altri aspetti. Ma poi ci si rese conto che questa cosa creava burocrazia e vincoli contrattuali che bloccarono la diffusione dei servizi. Oggi dovremmo rendere queste cose automatiche e dinamicamente aggiornate. E magari lavorare sugli aspetti politici e contrattuali fra le varie organizzazioni”. “Torniamo a quello che ti dicevo. Ma puoi farmi un esempio?” mi chiede Alessio. “Per esempio, quando un servizio viene pubblicato nell’ecosistema digitale, dovrebbe, tramite strumenti di AI, presentarsi automaticamente all’atto della pubblicazione sulla piattaforma con un messaggio intelligibile alla piattaforma del tipo ‘sono un servizio che fa questo e quello, posso essere utilizzato per fare questa cosa, costo tot e ho una serie di Service Level Agreement (SLA) di questo tipo; il mio produttore è questo e la responsabilità legale viene descritta da questo accordo; ecco il certificato digitale che attesta tutto ciò’. E con questa presentazione, è pronto per essere utilizzato”.

Alessio si fa molto serio: “Eh, bello… Ma se poi non rispetta l’impegno? Per esempio, se non garantisce i livelli di servizio enunciati negli SLA?” “Paga. Automaticamente, alla registrazione dovrebbe offrire gli end-point per abilitare la transazione monetaria. Sia per incassare che per pagare delle penali in caso di violazione degli accordi”. Improvvisamente il mio interlocutore cambia totalmente espressione, e scoppia a ridere: “Ah ah, altro che fatturazione elettronica, qui sì che non si scappa. Ma perché dici che serve una AI per fare questa cosa? In fondo si tratta di scambiare informazioni tecniche. Magari basta un file di testo in XML o JSON”. “Certo che si potrebbe. Ma una delle cose che abbiamo imparato con la SOA è il problema del mismatch semantico”.

Le parole sono importanti

Alessio continua a ridere. Anche io non riesco a trattenermi: stiamo pensando entrambi al conte Mascetti, “come se fosse antani…” “No dài, sono serio”. Riprendo il filo del discorso: “Voglio dire che, a parte il tracciato dei dati e i nomi utilizzati, c’è proprio un problema di discrepanza di significato. Quello che uno chiama ‘risorsa fruibile’, un altro lo potrebbe chiamare ‘servizio di locazione d’albero’. Quello che uno chiama ‘incasso’ un altro potrebbe determinarlo come ‘transazione’. Ma oltre al classico problema delle parole e del significato da attribuire, c’è tutto il tema dei dati e anche qui del significato da dare ad essi. Per far sì che il puzzle si componga— ricorda le composable applications — dobbiamo parlare una lingua comune. Ma questa non ci sarà mai. Meglio tradurre in modo intelligente quello che per te è A e da me si chiama B”. “E questo babelfish dei servizi chi lo fa?”, chiede Alessio. “Ancora non è del tutto provato dove sia megliocollocarlo. Probabilmente nell’ecosistema digitale stesso. Ma c’è chi dice, e forse sarebbe anche meglio, dentro ciascun componente. Ognuno è responsabile del proprio dominio, sia per quanto concerne i dati che per le funzionalità annesse”. “Ognuno con il suo chatGPT…” “Di fatto sì” concordo io. Alessio va oltre: “E chi li addestra? Se non si capiscono?”. “Eh… bella domanda… diciamo che dovrebbe valere il concetto simile all’evoluzione… come per la nascita delle lingue creole, inutile prevedere o modellare: chi si adatta e inizia a farsi capire, prosegue”. “Sì, Giovanni, ma quelli che stai descrivendo sono meccanismi naturali e culturali che si verificano perché ci sono degli esseri viventi, o delle persone, che li vivono sulla loro pelle. Però nell’ecosistema digitale qualcuno dovrà iniziare a dare le prime regole, le prime convenzioni…”. Alessio ha ragione a fare questa osservazione: come pensavo, la metafora è ottima, ma può spingersi solo fino a un certo punto. Gli rispondo: “Sì, un leader dell’ecosistema ci vuole. Poi gli altri si adatteranno oppure si alleeranno per creare altre convenzioni. Ma conviene partire con poche regole, magari condivise fra i primi che iniziano a collaborare. Poi altri si adatteranno o creeranno altri piccoli gruppi”. Alessio è meno scettico adesso ed è sicuramente più rassicurato nel suo non facile ruolo in cui deve gestire l’adozione di un paradigma che esce da quel che si è sempre fatto. Osserva: “Questo è molto interessante. Penso che sia ancor più utile per lo scenario che chiamavamo X-O, cross-organizations, dove ci sono diversi attori con diverse tecnologie, convenzioni organizzative, processi”. “Se ti va, dalla prossima settimana iniziamo a fare qualche esempio”. “Proviamo, magari iniziamo a coinvolgere qualche amico”.

Riferimenti

• [1] Nassim Nicholas Taleb, Antifragile. Prosperare nel disordine. Il Saggiatore, 2013 (titolo originale Antifragile: Things that Gain from Disorder. Penguin, 2013)

• [2] Giovanni Puliti, Antifragilità e l’antica arte di migliorare quando le cose peggiorano. I parte: L’antifragilità e la sua importanza per le organizzazioni. MokaByte 230, luglio 2017https://www.mokabyte.it/2017/07/15/antifragile-1/

• [3] Giovanni Puliti, Riflessioni antifragili. L’antifragilità e la capacità di imparare dai propri errori. MokaByte 251, giugno 2019https://www.mokabyte.it/2019/06/14/riflessioniantifragili-1/