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…

Un passo indietro, due avanti

La chiacchierata con Alessandro mi aveva in un certo senso rassicurato: le sue considerazioni su come funzionano le organizzazioni grandi, con la loro tendenza alla burocratizzazione, mi avevano fornito una sorta di “rinforzo”; e mi aveva trovato molto in sintonia il suo racconto di numerosi aneddoti, alcuni dei quali molto divertenti, che ben delineavano certi antipattern organizzativi che tante volte abbiamo riscontrato in azienda.

Ma, facendo un passo indietro, nell’ultimo incontro in azienda con Alessio — quando avevamo sperimentato un giorno di primavera anticipata lavorando sulla terrazza della palazzina — gli avevo detto che avrei coinvolto degli amici. Perché sospettavo che, così come le riflessioni di Alessandro mi avrebbero fatto fare un passo in avanti su tanti aspetti organizzativi e “sociali” senza perdere di vista il lato tecnico, un incontro con Alberto avrebbe aiutato a farne un secondo, parlando di aspetti tecnici ma senza perdere di vista quelli organizzativi e “sociali”. I sistemi sono fatti di persone e tecnologie che creano una realtà socio-tecnica: se così non fosse, parleremmo di meccanismi, più che di ecosistemi digitali.

E quindi ora sono a confrontarmi con Alberto [1], che già mi aveva dato utili spunti qualche mese prima in riferimento al modo in cui consideriamo e gestiamo i dati nei nostri sistemi. Alberto lavora nella stessa azienda di Alessandro: una realtà di produzione software con cui la mia azienda di coaching e consulenza lavora a stretto contatto per la progettazione e la realizzazione delle soluzioni tecniche che individuiamo nei percorsi di trasformazione digitali dei nostri clienti.

Stavolta ci vediamo in videoconferenza, e non di persona, ma l’occasione è adatta per cominciare a parlare di come vanno le sue attività di scialpinismo in montagna.

“Eh, c’è stata poca neve nei mesi scorsi, anche se ne è arrivata parecchia tutta alla fine… Comunque mi son potuto permettere qualche bella gita, eh. Certo, non come mio fratello in bici… ormai lui va in bici quasi tutti i giorni”.

“Beato lui”, gli rispondo. “Chiamalo scemo…”.

Ridiamo entrambi. Il ricordo del lockdown e delle tante rinunce del periodo 2020-21 è ancora presente, ma quei tempi sembrano ormai finalmente archiviati.

Da app interconnesse a vero ecosistema digitale

“A me viene spesso un dubbio”, attacco. “Ed è che tante volte alcune delle cose che diciamo, che proponiamo alle aziende come percorsi possibil in base alle loro necessità, appaiano un po’ come ‘fantascienza’. Mi chiedo in certi casi se siamo noi coach — o consulenti o chiamali come vuoi — a spingerci troppo avanti, o se siano le aziende che, anche giustamente, abbiano un approccio conservativo che impone loro di non volare troppo alto, o che altro…”.

Alberto mi ascolta con attenzione e sembra capire esattamente, per esperienza vissuta, il ragionamento che sto facendo. Oltretutto, in questo momento, ho la fortuna di avere a che fare con una realtà molto recettiva e dinamica. Ma quel retropensiero che certe idee siano percepite come troppo complesse per essere attualizzabili mi resta sempre vivo…

“Sì, capisco” risponde Alberto. “Io penso che sia anche un discorso di esigenze immediate. Ci sono temi interessanti, come appunto gli Ecosistemi digitali, con tutte le loro implicazioni. E allora le persone in azienda si dicono che, sì, è proprio quello che gli serve. Ma poi in realtà la loro esigenza è, al momento, molto più limitata. Magari gli serve solo un ambiente in cui le varie applicazioni semplicemente si parlino senza problemi, si scambino informazioni. Tu compri una roba da una parte, l’app manda i dati dall’altra parte, oppure il login non lo devi fare quattro volte…”

“Eh, sì…”. Mi soffermo un attimo a pensare. Diciamo che, per il momento, questa cosa ddella composable application che prende pezzi da altri cloud, li aggrega, crea prodotti nuovi per loro ancora è vista come un obiettivo lontano. A ben pensarci, questo potrebbe essere un bene, perché abbiamo tutto il tempo per pensarla meeglio; e, come sempre, in questi casi se tu la pensi prima, poi quando tutti la vogliono ce l’hai già pronta. Oppure potrebbe essere totalmente inutile perché è una direzione in cui magari il mercato deciderà di non andarci. Però io sono abbastanza fiducioso che abbia senso continuare ad andare in quella direzione. È anche un po’ il nostro ruolo quello di provare a pensare, anticipando un po’ quel che potrà accadere”.

Il futuro è già presente

Alberto riprende: “In realtà su questo discorso delle composable app le aziende non se ne rendono conto, ma le persone già le usano in maniera estensiva. Netflix è così. Quando tu apri Netflix, l’app ti presenta tutte quelle righe: ‘Continua a guardare…’, ‘Ti suggeriamo anche…’ e così via. Ci hai fatto caso che questi elementi in realtà non sono mai nello stesso ordine? E perché? Perché l’app chiama dei servizi. Se il primo servizio c’è e risponde , bene; e allora la riga appare dove dovrebbe essere, per esempio ‘Continua a guardare’. Ma se in quel momento il servizio non è disponibile, ne viene presentato un altro, per esempio ‘Ti suggeriamo anche…’ o come si chiama. È cambiato il concetto rispetto al passato: non è che io dò all’utente l’errore, non è che se la scritta non è disponibile, blocco tutta l’applicazione, no. Tiro su qualcos’altro e ti dico: ‘intanto guarda cosa c’è tra le nuove uscite in base a quello che hai visto’. Insomma, suggerisco questo sulla base dei tuoi gusti. Poi, alla fine, quando il servizio diventa nuovamente disponibile, appare anche ‘Continua a guardare’… Ma intanto posso continuare a usare l’app e a guardare qualcosa che mi interessa. Non resto di fronte a una schermata bianca o nera con scritto ‘errore 404’ o qualcosa di simile…”.

“Ecco, questo è molto chiaro e spiega tante cose. Ho capito”.

Chaos engineering e resilienza

Alberto riprende: “Ma questo funziona perché, strutturalmente, in Netflix hanno un livello di sviluppo altissimo. Loro iniettano caos nel loro sistema, la famosa Chaos Monkey, in modo che sia fin da subito sviluppato in maniera resiliente. Il loro sistema è costruito sul fatto che qualche servizio, in maniera casuale, viene costantemente tirato giù, senza che lo sviluppatore sappia quale sia. E però il sistema deve comunque andare. L’esperienza utente non deve degradarsi: infatti, anche se qualcosa manca, l’utente non dice: ‘Basta! Chiudo Netflix perché non va’. No, Netflix va sempre”.

“Questo però sempre nell’ottica di servizi che vengono dal loro cloud.”, gli dico. “Ma invece quel discorso che va oltre la singola azienda, che chiamavamo cross organization? Ancora forse è presto?”.

“No,” riprende Alberto “loro già applicano questo approccio, o quantomeno c’è già qualcuno che sta progettando con quell’ottica. Hanno dalla loro anni di esperimenti, raccontati da Miles [2], uno degli autori di Chaos Engineering. Lui lavorava in Amazon, ma era anche un vigile del fuoco volontario e questa attività gli aveva fatto capire alcune cose. Infatti rilevava che i vigili del fuoco — volontari o professionisti — passavano l’80% del tempo a fare addestramento ed esercitazioni, impiegando il restante 20% per gli interventi veri e propri. L’autore notava che poi, quando si arrivava nelle situazioni reali, i vigili del fuoco erano piuttosto tranquilli anche in mezzo a situazioni pericolose, per il fatto che erano abituati a quei contesti grazie alle innumerevoli esercitazioni. Del resto, avendo fatto già tanto addestramento, è anche normale che fosse così. Se sei tanto addestrato, se ti eserciti continuamente a stare in situazioni pericolose come le fiamme, o l’incidente o quel che altro vuoi, quando ti ci trovi realmente sul posto di intervento, ti accorgi che sei la persona più calma e dici: ‘Ho fatto proprio questo fino a ieri, quindi so come si fa’. E allora Miles decise di portarsi questa esperienza dentro Amazon, pensando di creare un team in AWS che, come i pompieri, non andasse in panico se succede qualcosa che non va, perché sanno già cosa fare. In questo modo, il disservizio viene ridotto al minimo, praticamente quasi impercettibile per l’utente finale. Quindi ha iniziato a fare questi esperimenti, tipo darsi malato e poi spegnere qualche servizio per vedere come avrebbe reagito il team. Lui era quello che sapeva tutto di AWS e veniva a mancare nel momento del bisogno. E come reagisce il team? Cosa può fare? Come si comporta?”.

Due aspetti dell’Antifragile

Parlando di sistemi che reagiscono al caos indotto, Alberto mi dà il gancio per introdurre il tema dell’Antifragilità, di cui avevo parlato nell’ultimo incontro con Alessio.

“Nell’ultimo incontro con il mio referente in azienda, gli avevo accennato che potevamo creare un’applicazione composta — una composable app — in cui si realizzano delle aggregazioni di servizi, eventualmente anche con delle capacità di autodiscovery per andare a cercarsi da sola i servizi adatti. Alessio, il manager con cui principalmente mi relaziono, mi guardava un po’ con aria al tempo stesso interessata e scettica. Gli spiegavo che, in un’ottica di Antifragile, l’interesse nostro non era solo che il sistema stesse in piedi, ma che fosse in grado, diciamo così, di ‘autoripararsi’ per superare momenti di stress o disturbo, uscendone rafforzato. Questo è ciò che fa un vero ecosistema digitale. L’esempio che gli facevo era l’applicazione composta che usa vari servizi. Tra questi ce n’è uno che calcola il prezzo dei vari articoli. A un certo punto, o per motivi tecnici di indisponibilità o per ragioni ‘ambientali’ — modifica dei parametri da parte di un ente regolatore terzo, cambiamenti nella valuta di riferimento, chiusura di un mercato per motivi geopolitici o che ne so — quel componente non può più fornire il suo servizio nel modo in cui serve a noi. Allora noi dobbiamo creare un sistema in grado di scoprire un servizio che possa prendere il posto di quello che non va più bene. In un’ottica antifragile,  il sistema non si rompe, ma cambia automaticamente e migliora. Questo è qualcosa di molto attuale, ma rischia di apparire come pura teoria finché non la realizziamo in qualche modo, proponendo al nostro cliente qualcosa di concreto”.

Servizi antifragili

Alberto ha ascoltato con grande attenzione. Capisco di aver toccato un tema per lui molto importante, perché, subito dopo, comincia a parlare con un discorso che sembra avere già molto chiaro in testa: “Ci sono due temi; il primo è l’antifragilità anche dal punto di vista del software. Quando io progetto un software, semplifico il modello di business e trasformo questo modello in codice che possa risolvere il mio problema, la mia necessità. Finché le attività reali che gestisco con il mio sistema restano nel confine delle attività reali mappate nel mio modello e codificate nel mio software, tutto bene. Ma, visto che hai parlato di Antifragile [3], non ci dimentichiamo che il libro precedente del suo autore, Taleb, era Il cigno nero [4]. Perché succede sempre che qualcosa di inaspettato, di non prevedibile o addirittura di inconcepibile, finisca per mettere in crisi il nostro sistema, perché quel modello che avevo pensato non lo contempla. Sì, possiamo avere già in fase di progettazione l’approccio basato sul ‘Ragioniamo per assurdo. Cosa succederebbe nel caso in cui…’. Ma poi sappiamo benissimo che la realtà è molto più ampia dei nostri ragionamenti preventivi e che non riusciremo mai a progettare un modello omnicomprensivo. Sicuramente il Domain Driven Design ci aiuta a fare le cose nel modo migliore e ci ricorda di creare agggregati piccoli, molto piccoli. Che hanno i loro limiti — saranno meno disponibili e dovrai farne di più — ma che comunque rimuovono tanti problemi degli aggregati grossi. Però, alla fine, succederà qualcosa che farà ‘scoppiare’ il modello. E a questo punto, proprio in ottica antifragile, guardi cosa ha fatto scoppiare il sistema, ma soprattutto guardi quello che è rimasto in piedi per riprogettare il tutto in modo migliore a partire da ciò che è rimasto, dal residuo. È l’approccio della Residuality Theory di Barry O’Reilly [5]”.

Dati antifragili

Alberto continua: “Poi c’è un secondo aspetto, che è quello dei dati, dell’informazione. Anche i dati possono essere antifragili. Concretamente, dipende dal modo in cui effettuiamo la persistenza del dato. Se io effettuo una persistenza solo dell’ultimo stato del dato, sto costruendo un sistema fragile. Ma se io mi conservo via via tutti i passaggi che hanno portato il dato in quello stato… non lo so se sono antifragile, ma di sicuro sono molto meno fragile. Metaforicamente è la differenza tra avere la foto di una scena o avere tutti i fotogrammi dell’intero film che arriva a quella scena. Tecnicamente, posso contemplare più variazioni del significato del mio dato e posso riaggregarlo in tanti modi diversi, perché conservo di volta in volta tutti i singoli passaggi: ti posso dire perché il dato è cambiato, sulla base di quello che l’ha fatto cambiare. Magari dando un nome a questa riga che vado a salvare; chiamalo record, chiamalo documento, chiamalo con il suo vero nome: evento.

“Evento, infatti” gli faccio eco.

Alberto continua: “Esatto. Se io gli dò un nome molto vicino al mio business, io so che quel dato è cambiato perché, per esempio, sul carrello è successo questo e quest’altro e quest’altro ancora. Devo stare molto attento perché  per un po’ di volte cambierà e avrò la versione v1, v2, v3 di questo evento. Ma a un certo punto, però, non è che l’evento cambia così tanto e mantiene sempre lo stesso significato. A un certo punto, diventerà qualcosa di diverso, con un significato diverso: potrebbe essere un altro evento perché è leggermente diverso, o perché fa qualcosa di diverso rispetto al primo. Avendo salvato tutti i ‘fotogrammi’ posso capire dove c’è stata una variazione, un cambiamento che ha modificato tutto, che comunque ha fatto andare in un’altra direzione”.

“Sì, è chiaro”.

“Ora, dove sta l’aspetto ‘antifragile’ di tutto questo?”, riprende Alberto. “È successa una variazione nel tuo sistema e con gli eventi puoi capire dove e dopo cosa è successa. Il mio sistema deve cambiare, il mio sistema deve evolvere. Quel sistema che avevo, quel mio servizio che avevo, non va più bene o non va bene per tutte le situazioni. E allora magari capisco che devo modificarlo in modo che, se mi arriva una richiesta di un certo tipo, vado su un servizio, e se mi arriva una richiesta di un altro tipo, vado su un altro servizio perché adesso so rispondere a tutte e due le richieste”.

“Ma in questo sistema, ricostruire la ‘storia’ dei dati con gli eventi vuol dire che io a mano devo guardare i dati e come sono cambiati, quindi la sequenza degli eventi?” chiedo ad Alberto.

“No, aspetta”, subito si inserisce lui. “Se si vuole creare un sistema che evolva in un certo modo, o che, in qualche modo, ‘impari’ dagli eventi, il discorso ‘a mano’, va proprio dimenticato. Bisogna cercare di automatizzare tutto: mi automatizzo i test sulla mia architettura per fare in modo che rispetti delle regole che mi sono dato, ci deve essere un automatismo che dice se inserire un servizio va bene o no, e così via”.

I vantaggi di un sistema a eventi

“Tutto questo mi appare sensato. Ma in che modo posso concretizzarlo se io volessi proporre qualcosa al mio cliente?”, chiedo ad Alberto. “Noi stiamo lavorando sull’integrazione di servizi in un ecosistema digitale. Lo scenario è quello di un prodotto cloud, che serva agli utenti che devono comprare automobili, magari sull’aftermarket, ma anche che gestisca i passaggi delle auto in officina, prenotazioni, noleggio e via dicendo”.

Alberto ci pensa un po’. Capisco che vuole rispondere alla mia richiesta cercando di mettere bene in relazione quel che ha appena detto con lo scenario che gli ho prospettato. “Questo passaggio a scambio di informazioni tra i servizi che devono essere integrati, fatto a eventi, ti dà un vantaggio anche sul dato. Se io scambio degli eventi di integrazione, cioè degli eventi con cui ti comunico queste cose, questi eventi possono anche essere sottoscritti da un sistema di analytics. Io a questo punto sono interessato a prendere informazioni dalle abitudini di acquisto del cliente. Immaginiamo di voler capire i gusti del cliente Alberto: con gli analytics vedo che lui va sempre in montagna a sciare, che spende i soldi per gli sci o l’attrezzatura alpinistica. A quel punto, a parità di spesa affrontabile, non gli propongo un’automobile ‘sportiva’ bassa, ma un SUV o un fuoristrada di alto livello…”.

“Sì, è quello che facciamo” intervengo. “Ma in questo, perché la gestione dei dati a eventi è così importante?”.

“Eh,” mi fa Alberto, “perché mi consente di sottoscrivermi ai vari eventi e, sulla base di queste sottoscrizioni, di raccogliere i diversi dati aggregandoli in maniera congruente e disaccoppiata. Non devo confrontarmi con la classica tabella con 850 colonne di cui in realtà me ne servono solo quattro e il mio analyst perde due giorni solo a pulire l’informazione… No, io sottoscrivo solo le informazioni che mi servono e quindi ho un dataset di informazioni specifico per quello che sto cercando e faccio arrivare al mio analyst solo le informazioni che mi chiede. Quindi al front desk dico che mii servirebbe sapere ogni quanto il cliente spende, per che cosa spende, la tipologia di spesa che fa. A quel punto mi raccolgo i vari servizi e dico loro di darmi solo queste informazioni”.

“Ma allora, tecnicamente, potrebbe trattarsi di un sistema in cui un bus riceve le comunicazioni da tutti i servizi che fanno qualcosa…” rifletto a voce alta.

Alberto amplia la mia riflessione: “In questo modo, sei libero di modificare il tuo servizio, a patto che il messaggio che pubblichi resti uguale o compatibile. Con questo messaggio comunichi quando fai modifiche al servizio che pubblichi. Il vantaggio dove sta? Se ti do il minimo di informazioni, solo quelle che chiedi, intanto non non stiamo creando un accoppiamento troppo stretto, manteniamo al minimo la dipendenza. Tornando all’esempio di prima, il sistema ha chiesto che tipologia di spesa fa Alberto, ma solo per quanto riguarda le attività sportive in montagna. Poi succede che, già che ci siamo… ma sì, prendiamo anche luogo e data di nascita, città di residenza e così via, tanto prima o poi mi serviranno. Ecco, il problema è proprio quel ‘tanto prima o poi’. Invece, chiedendo quelle informazioni se non ne ho bisogno, contribuisco a creare ulteriore accoppiamento, perché poi il mio servizio quei dati se li aspetta sempre”.

Nulla di nuovo sotto il sole?

La spiegazione mi ha convinto, ma mi ha riportato alla mente esperienze del mio passato, nel periodo in cui mi occupavo anche di architetture dei sistemi informatici. Mi viene naturale chiedere ad Alberto se queste cose — il bus, l’orchestrazione, i messaggi, le code e gli eventi sincroni e asincroni, tutti concetti di SOA — non siano alla fine ben poco nuove e invece già ben note da tanti anni. “Scusa, Alberto. Ma in tutto questo che cosa c’è di nuovo”.

“Ah no,” prorompe “non ci sono cose nuove, parliamoci chiaro”. Ridiamo tutti e due. “A me, personalmente, l’interesse per andare a rivedere e rivalutare cose ‘vecchie’ è scattato quando ho riletto un articolo di Fred Brooks dell’86 [6]. In esso l’autore distingueva a proposito dello sviluppo software due tipi di complessità: la complessità essenziale e quella accidentale. Lui diceva che la complessità essenziale è quella per cui un cliente ha un problema da risolvere, tu costruisci un modello, codifichi del software, progetti un sistema che siano in grado di affrontare e risolvere la complessità del problema del cliente. Ecco questa è complessità essenziale. Però, per arrivare a questa soluzione, c’è tutta una complessità accidentale — degli extra come ‘dove si fa il deployment?’, ‘come viene distribuito in rete?’, ‘come gestisco la scalabilità e l’evoluzione futura?’ e così via — che il cliente non percepisce o non vede. Brooks credeva che la complessità accidentale sarebbe andata costantemente a diminuire, lasciando più tempo ed energie da dedicare alla complessità essenziale. Ma io credo che non sia andata così”.

Ci penso un po’. In effetti la visione di Brooks aveva delle ragioni e certi aspetti della complessità accidentale oggigiorno mi sembrano effettivamente diminuiti. “Perché la pensi così, Alberto?”, lo incalzo. “Non è andata così?”.

“Non proprio”, mi risponde. “Pensa a un concetto come il Bounded Contex che, a livello di design rappresenta un enorme aiuto: il ‘business’ che devo modellare lo racchiudo qui dentro, provvedo a farne tanti piccoli aggregati, e ho risolto. Benissimo, in questo modo ho risolto la complessità essenziale. Ma la complessità accidentale non l’ho ancora risolta: devo andare su AWS, su Azure, su Google. Non sto più sul server in cantina… E poi, funziona la connettività? Ho pensato a come rendere disponibile la applicazione anche quando qualche servizio non è dispobibile, come si diceva per Netflix? Alla fine, mi rendo conto che ho ‘allargato’ il confine del contesto: ciò che era accidentale è finito per diventare essenziale. Adesso non è più tutto ‘in casa’ ma la mia applicazione è su una serie di nodi di un cluster di Kubernetes. Se non ho quella roba lì che funziona sotto, non funziona proprio il sistema che avevo creato per risolvere la complessità essenziale”.

Sistemi distribuiti

“Questa è un’ovvia conseguenza dell’affermazione dei sistemi distribuiti”, rifletto a voce alta. “I concetti che studiavamo in informatica per risolvere i problemi di ‘business’ e che erano quasi innovativi tanti anni fa, adesso sono la quotidianità, ma hanno a loro volta creato dei problemi nella loro applicazione concreta”.

Alberto mi fa eco: “Certo. Ci sarebbero tantissime cose da dire ed esempi da fare. E, come giustamente dicevamo prima, tutto questo non nasce oggi, ma è il frutto di cose di venti o trenta anni fa che adesso, in una prospettiva informatica, assume una forma più compiuta. Oggi parlare di ‘programmazione orientata agli oggetti’ suona vecchio. Ma alla fine, sia l’OOP che l’Actor Model, parallelo ai primi tentativi di programmazione a oggetti, dicevano qualcosa che oggi è chiaro: se io voglio trasferire la realtà in un modello di sistema, le entità che fungono da repliche del mondo reale devono comunicare fra loro.  Che poi io li chiami ‘oggetti’ o che li chiami ‘attori’, cambia poco: nella realtà le cose si ‘parlano’ e quindi anche i miei oggetti devono comunicare, scambiandosi messaggi”.

“Infatti”, lo interrompo. “All’inizio i metodi si chiamavano messaggi; quando si chiamava un metodo, voleva dire mandare un messaggio…”

Alberto riprende: “All’inizio questa era teoria. Poi è diventata la realtà e si sono cominciati a fare i sistemi in questo modo. Certo, è dovuto passare del tempo, perché all’inizio era inconcepibile anche avere decine di PC in una piccola azienda. Adesso un cluster di Kubernetes va bene. Mi ricordo che una volta — nei primissimi anni Duemila, subito dopo l’introduzione dell’Euro — ero a lavorare in una banca per un’azienda di investimenti e loro avevano fatto il primo sito italiano per la compravendita di fondi, che però era riservato solamente a clienti istituzionali: banche e simili. Si potevano effettuare transazioni solo sopra una certa soglia di valore, che non era certo quella possibile al rispamiatore o al piccolo investitore. Insomma… Erano talmente intimoriti che tecnicamente qualcosa non funzionasse — ritorna la complessità accidentale — al punto di avere tre linee ADSL e tre server tutti uguali, dei cluster HP in fila uguali, dal costo di 60-70000 euro l’uno, di cui due spenti e uno in funzione. Per l’epoca erano costi significativi, ma assolutamente trascurabili per una banca che faceva quel volume di transazioni: fai un po’ di operazioni e con gli interessi già ti sei ripagata le macchine. Però di certo non se li sarebbe potuti permettere la piccola azienda. Adesso invece fai tre macchine virtuali che vanno giù e vanno su. Se lo fai su Azure costa ancora, se lo fai su AWS costa un po’ meno, però queste macchine virtuali non costano comunque quei soldi là. E non le devi cambiare dopo tre anni…”.

Riflessi concreti del modello distribuito

“Certo che, a guardare in retrospettiva, ne son cambiate di cose… Ma l’affermazione del modello dei sistemi distribuiti, al di là degli aspetti tecnici, ha avuto anche delle ricadute sul nostro comportamento, sul modo in cui ci aspettiamo che ormai funzionino i sistemi. Dico non tanto in senso tecnico, che l’utente comune non è in grado di percepire, ma su aspetti più legati all’esperienza utente e alla soddisfazione delle proprie richieste. Non trovi?”

“Sì, è così”, risponde Alberto. “Uno degli esempi più evidenti è Amazon. Partiamo da un aspetto tecnico: potremmo immaginare che Amzon funzioni in modo sincrono, cioè quando io voglio comprare un prodotto, mi interfaccio direttamente con il magazzino che può avere o meno quel prodotto. A livello tecnico otterremmo una istantaneità e una ‘consistenza’ del dato innegabili. Ma il fatto è che siamo tornati a ragionare come quando avevamo il server in cantina… Come faccio a scalare su un miliardo di utenti questa operazione? E allora Amazon funziona diversamente. Metto la roba nel carrello, magari cerco qualcosa ancora, e poi faccio l’ordine. Questi sono tutti eventi che vengono registrati. Alla fine faccio l’ordine e verrà verificato se il prodotto è sempre disponibile, dove è e così via. E mi verrà inviata una conferma, che magari arriva dopo dieci minuti. E che, se ci pensi, è un messaggio… Ho rinunciato alla sincronicità, al real-time, in favore di un ‘valore’ diverso, che è l’affidabilità e la precisione di quanto mi viene detto a proposito della consegna del mio articolo. È un messaggio che arriva in un secondo tempo, ma sappiamo che arriva. In questo senso, sì, ci sono aspetti tecnici e aspetti comportamentali, sociali. Tecnicamente si perde qualcosa nella ‘consistenza’ del dato? Sì. Ma se il mio sistema diventa distribuito, non posso più pensare di essere atomico, di essere consistente ovunque: io suddivido il mio business in tanti piccoli business, in piccoli pacchettini, in piccoli bounded context, ed è ovvio che sarò consistente lì dentro, ma di fuori non posso pensare di esserlo allo stesso modo”.

Ritorno al futuro

Mi soffermo un attimo a pensare e mi rendo conto che è passata più di un’ora in cui Alberto mi ha dato tanti spunti. Senza volerlo, ci siamo lasciati andare a considerazioni di “storia dell’informatica” perché ormai gli anni iniziano a passare…

“Forse abbiamo un po’ divagato”, gli dico. “E io devo tornare dai miei clienti in azienda a completare il lavoro”. Ci mettiamo a ridere.

Riprendo: “Però, come conclusione di questa conversazione potremmo dire questo: avevo necessità di fare chiarezza da un punto di vista tecnico, architetturale e implementativo su come trasformare in qualcosa di concreto quel che ho proposto all’azienda che sto accompagnando nella sua rivoluzione digitale. E abbiamo potuto mettere insieme antifragilità e sistemi a eventi, ecosistemi digitali e programmazione a oggetti, teoria della residualità e architetture a microservizi. Non è poco”.

“Non è poco”, ripete Alberto. “Poi andrà implementato tutto, e sarà comunque impegnativo. Ma il fatto è che abbiamo gli strumenti per ritornare al futuro”.

Riferimenti

[1] La scheda personale di Alberto Acerbis sul sito Intré
https://www.intre.it/author/alberto_acerbis/

[2] Russ Miles, Learning Chaos Engineering. O’Reilly Media, 2019

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

[4] Nassim Nicholas Taleb, Il cigno nero. Come l’improbabile governa la nostra vita. Il Saggiatore, 2009 (titolo originale The Black Swan: The Impact of the Highly Improbable. Random House, 2007)

[5] Barry O’Reilly, An Introduction to Residuality Theory: Software Design Heuristics for Complex Systems. “Procedia Computer Science” 170 (2020), pp. 875–880
https://t.ly/fo9Fl

[6] Frederick P. Brooks Jr., No Silver Bullet. Essence and Accident in Software Engineering. 1986
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf