Copertina: Foto di Pramod Tiwari su Unsplash

Avvertenza

Questa storia non è proprio vera. Ma non è affatto finta.

È il resoconto verosimile di un processo di trasformazione aziendale e organizzativa basato su fatti ed eventi reali che però sono stati opportunamente modificati, adattati e combinati per far loro assumere un significato più generale e per dare al racconto anche un valore “didattico”: la narrazione di una trasformazione organizzativa ispirata ai principi e alle pratiche Lean/Agile e alle conoscenze e alle tecniche dell’Organisational Design.

Pertanto i nomi, l’azienda, i luoghi non fanno riferimento a elementi precisamente identificabili e i personaggi sono da intendersi come di fantasia. Anche se poi magari qualche persona potrà riconoscersi in essi.

La storia comincia nei primissimi mesi del 2021 ed è tuttora in svolgimento…

Antifragilità degli ecosistemi digitali

Il tempo sta passando veloce su questa terrazza della palazzina aziendale. Lo spazio è semplice, ma davvero accogliente. In questo stranissimo inverno, siamo incappati in una giornata primaverile, di quelle che un tempo ci si sarebbero presentate un mese dopo. Con Alessio abbiamo parlato per un po’ dei concetti base illustrati da Nicholas Taleb nel suo libro Antifragile [1].

“OK, ma tutto questo cosa c’entra con il lavoro che stiamo facendo sui servizi e sugli ecosistemi digitali?” mi chiede lui.

“Ci arrivo. Immaginiamo di dover realizzare quello che abbiamo chiamato servizio digitale composto ossia dato dalla aggregazione di altri servizi che provengono da contesti differenti. L’utente, usandolo, potrà risolvere le proprie necessità senza rendersi conto di questa frammentazione sottostante, se tale servizio svolge il proprio compito in modo armonico. Il servizio composto potrebbe essere quindi il risultato dell’interazione di prodotti digitali appartenenti allo stesso ecosistema: tali oggetti si parlano fra loro e scambiano dati e servizi in modo coordinato e coerente. Fin qui mi segui?”.

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 inusuale o il cambiamento di un vincolo di dominio, ad esempio. Tale alterazione potrebbe causare un malfunzionamento in uno dei componenti sottostanti, che si dimostra 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”.

“Attenzione, non ho detto che si tratti di un nodo che non funziona più, per esempio un server che si rompe e smette di rispondere. Quello di cui sto parlando potrebbe essere ben peggio. Qui non stiamo tanto parlando di un nodo o un componente che si blocca, ma di qualcosa che mette in crisi quel pezzo per uno scenario differente. Se tu avessi un cluster, tutto il cluster sarebbe bloccato e sarebbe certamente peggio. Servirebbe qualcosa di alternativo”.

Alessio sembra convinto: “Sì, chiaro anche questo. Ma come si può fare? Quell che dici tu, Giovanni, prevederebbe che, per ovviare al problema dovremmo creare non una ridondanza di elementi identici. Cioè non dovremmo più ragionare come si fa di solito: se si rompe un compenente, entra in funzione il gemello. Ma allora dovremmo pensare a una 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”.

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. “Li 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’orcherstra. 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

Sono molto soddisfatto di come sta andando questa conversazione. Del resto so che Alessio è molto 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 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, i chip ancora non stanno arrivando dall’Estremo Oriente e stiamo rallentando la produzione a causa della situazione geopolitica in Medio Oriente…”.

“Sì comprendo… Senti… “ 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. Come 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/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. Anzi 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”.

Capisco che, quando si fanno metafore che fanno riferimento a un dato mondo per parlare di un altro “dominio”, poi il parallelismo non può essere mai perfetto al 100%. E gli ecosistemi digitali sono, appunto, digitali e non naturali, per cui certi meccanismi e certi termini non potranno mai essere identici quando ci spostiamo dal monto 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 potrebbedeterminarlo 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 2017
https://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 2019
https://www.mokabyte.it/2019/06/14/riflessioniantifragili-1/