00:00:03 Modularizzazione in IT e supply chains: introduzione.
00:00:26 Modularità fisica dei supply chain.
00:02:31 Strutture monolitiche dei primi sistemi IT.
00:04:08 Contesto IT dei sistemi monolitici.
00:05:31 Impatto di Internet sul design modulare del software.
00:08:02 Problemi nei sistemi software monolitici.
00:08:48 Inefficienze dei sistemi monolitici.
00:11:16 Transizione a sistemi modulari: esempi.
00:13:34 Fallimenti dei sistemi in applicazioni modulari.
00:14:34 Ridondanza, uptime in sistemi modulari.
00:16:00 Affidabilità dei grandi sistemi, fallimenti dei progetti software.
00:16:50 Esempio del fallito passaggio software di Lidl.
00:18:09 Concetto di “fail fast” nei progetti software.
00:19:30 Gestione delle sovrapposizioni, importanza del software “glue”.
00:22:46 Evitare disastri software.
Riepilogo
Nell’episodio di Lokad TV, Joannes Vermorel, il fondatore di Lokad, discute l’importanza della modularizzazione nell’infrastruttura IT aziendale, tracciando un parallelo con l’adattabilità dei supply chain. Egli fa riferimento ai sistemi IT monolitici degli anni ‘70 e ‘80, caratterizzati dalla loro inflessibilità a causa dei limiti tecnologici. Anche con il passaggio verso sistemi in rete a seguito dell’emergere di Internet, sottolinea la sfida continua per le aziende di modularizzare i loro sistemi IT. Vermorel propone una Service Oriented Architecture (SOA) come potenziale soluzione, evidenziando la necessità di servizi più piccoli e ben definiti. Avverte contro l’avvio di progetti su larga scala e sostiene un approccio “fail fast”, enfatizzando l’importanza della gestione del rischio e del recupero rapido in caso di fallimenti.
Riassunto Esteso
Nell’episodio attuale di Lokad TV, il conduttore Kieran Chandler coinvolge Joannes Vermorel, il fondatore di Lokad, in una discussione sulla modularizzazione nell’infrastruttura IT aziendale. Vermorel illustra il concetto di modularizzazione, tracciando paralleli principalmente con i supply chain nel mondo fisico, che considera le creazioni più modulari dell’umanità.
Utilizza esempi come trucks, pallets e containers per chiarire i suoi punti sulla modularità. Vermorel sottolinea la modularità intrinseca dei supply chain fisici evidenziando l’applicabilità universale dei barcode, che possono essere applicati a quasi qualsiasi cosa.
Sebbene i supply chain fisici mostrino una chiara modularità, Vermorel osserva che le infrastrutture IT aziendali spesso mancano di una flessibilità simile. Egli attribuisce questa mancanza di modularità alle prime fasi dello sviluppo IT nelle aziende, durante gli anni ‘70 e ‘80, quando le implementazioni IT iniziali e i sistemi ERP erano progettati come strutture autonome e monolitiche a causa dei limiti tecnologici dell’epoca.
Vermorel definisce un “monolite” in termini IT come un’applicazione unificata che non può essere suddivisa in parti più piccole. Spiega come questo approccio monolitico contrasti con la modularità osservabile nei supply chain fisici, dove varie componenti possono essere combinate o separate a seconda delle necessità.
Nonostante la loro complessità, Vermorel spiega che i primi mainframe erano intrinsecamente coerenti in quanto funzionavano come un’unica unità con tutte le operazioni centralizzate. Nota come questa forma di progettazione dei sistemi appaia superata per la generazione attuale, abituata a sistemi distribuiti e applicazioni basate su rete, segnando un cambiamento significativo nello sviluppo dell’infrastruttura IT nel corso degli anni.
Vermorel fa notare che il panorama ha iniziato a cambiare con l’avvento di Internet alla fine degli anni ‘90, portando al design di software con parti isolate collegate da una rete. Tuttavia, osserva che molte aziende continuano a lottare con la modularizzazione, nonostante il valore dei sistemi IT modulari sia ben compreso in teoria.
Spiega come molti fornitori abbiano adattato queste vecchie architetture monolitiche ai modelli cloud e Software as a Service (SaaS), con il risultato di sistemi che offrono una manutenzione migliorata ma non migliorano la modularità. Egli afferma che questa mancanza di modularità impedisce alle aziende di isolare e modificare specifiche funzionalità.
Per superare questo problema, Vermorel propone una Service Oriented Architecture (SOA), un approccio che scompone le capacità in parti più piccole e ben definite. Fa riferimento ad Amazon come esempio di azienda che ha adottato con successo questo approccio modulare fin dall’inizio.
Sostiene un’architettura orientata ai servizi con API che consentono di esportare e sfruttare i dati tra le diverse divisioni di un’azienda. Pur riconoscendo che un approccio decentralizzato presenta il potenziale per un maggior numero di punti di fallimento rispetto a un sistema monolitico, Vermorel sostiene che queste sfide possano essere mitigate tramite ridondanza e ingegneria di alta qualità.
Vermorel stima che tra un terzo e la metà di tutti i progetti IT nei supply chain falliscano. Fa riferimento al caso di Lidl in Germania, che ha perso mezzo miliardo di euro a causa di una fallita transizione SAP. Afferma che il passaggio da piccoli fornitori a grandi fornitori riduce solo leggermente il tasso di fallimenti, ma non li elimina.
Per quanto riguarda la gestione di applicazioni multiple, Vermorel suggerisce di scegliere applicazioni con un ambito ristretto per minimizzare le sovrapposizioni e consiglia di non acquistare grandi framework dai fornitori. Per gestire efficacemente più app, afferma che le aziende dovrebbero sviluppare un “glue” interno in grado di collegare queste applicazioni, facilitato da un’architettura orientata ai servizi.
Infine, Vermorel condivide consigli su come prevenire disastri come la fallita transizione SAP di Lidl. Sottolinea l’importanza di pensare in termini di gestione del rischio e di adottare un approccio “fail fast”. Sconsiglia di affidarsi a idee illusorie nella gestione dei progetti e ribadisce l’importanza di pianificare per possibili fallimenti e di trovare modi per recuperare rapidamente.
Trascrizione Completa
Kieran Chandler: Ciao e bentornati a un altro episodio di Lokad TV. Questa settimana discuteremo della modularizzazione, il processo di suddivisione dei processi informatici della nostra azienda da un sistema standalone a una serie di altri sotto-programmi o addirittura app. Come sempre, sono affiancato da Joannes Vermorel. Quindi, Joannes, di quale parte dei processi aziendali parliamo di rendere più modulare oggi?
Joannes Vermorel: Oggi ci concentriamo in particolare sull’infrastruttura IT e sul panorama applicativo della tua azienda. La modularizzazione è interessante. Se pensi al mondo fisico, è evidente che i supply chain sono incredibilmente modulari. Probabilmente sono le cose più modulari mai inventate dall’umanità. Per “modulare” intendo che, se vuoi trasportare merci via strada, puoi utilizzare camion. I camion sono incredibilmente modulari perché puoi caricare praticamente qualsiasi cosa che non superi la capacità di un camion, e un camion può circolare su qualsiasi strada, andando da qualsiasi luogo a qualsiasi altro. Se hai bisogno di camion extra, potresti praticamente usare qualsiasi tipo di camion, e questi possono aumentare la capacità di trasporto del tuo supply chain.
The same thing applies to pallets and containers. You can put almost anything on a pallet or in a container as long as it doesn’t exceed capacity. A container is extremely modular. You can move it from a cargo ship to a truck. All those pieces are incredibly modular. You can put a barcode on pretty much anything that is not too small. It’s an incredibly modern invention. If you have something like a diamond, you would probably put it in a box and then put the barcode on top of the box. You can combine all these simple elements at will, nearly infinitely. It’s very Lego-like; simple parts that you can combine in incredibly varied ways. That’s the physical supply chain, which is incredibly modular.
La stessa cosa vale per pallets e containers. Puoi mettere quasi qualsiasi cosa su un pallet o in un container, purché non superi la capacità. Un container è estremamente modulare. Puoi spostarlo da una nave da carico a un camion. Tutti questi elementi sono incredibilmente modulari. Puoi applicare un barcode praticamente su qualsiasi cosa che non sia troppo piccola. È un’invenzione incredibilmente moderna. Se hai qualcosa come un diamante, probabilmente lo metteresti in una scatola e poi apporresti il barcode sopra la scatola. Puoi combinare tutti questi elementi semplici a piacimento, quasi all’infinito. Questo è il supply chain fisico, che è incredibilmente modulare.
Kieran Chandler: Tuttavia, la cosa interessante è che quando ci spostiamo nel mondo IT, entriamo in una prospettiva completamente diversa in cui spesso la modularizzazione viene persa. Penso che l’origine di ciò risalga ai primi anni ‘70 o ‘80, quando le aziende iniziarono ad avere i loro primi sistemi informatici e le prime implementazioni ERP.
Kieran Chandler: Quindi, stai dicendo che quelle implementazioni iniziali, quei primi sistemi IT, in quanto adottavano un approccio unico, sono ancora ciò che utilizziamo oggi. È corretto?
Joannes Vermorel: Sì, infatti. Se ripensi all’IT o al software degli anni ‘70, ‘80 o addirittura dei primi ‘90, fare qualsiasi cosa attraverso una rete era come la scienza dei razzi. Era possibile, ma era un incubo ingegneristico. Era molto più facile dire: prendiamo una grande macchina, idealmente un mainframe IBM dell’epoca, e vi carichiamo tutta la logica. Quindi, tutti usavano un terminale collegato a quella macchina, e tutta la logica girava come un monolite su quella macchina.
Kieran Chandler: Quindi, cosa intendi per monolite?
Joannes Vermorel: Con “monolite” intendo dire che è come un’app che è un tutt’uno. Non può essere smontata. Deve rimanere integro, altrimenti non è nulla.
Kieran Chandler: Temo di essere un po’ della generazione millennial, quindi questo tipo di idea potrebbe essere anteriore a me. Ma fondamentalmente, stai dicendo che tutto è connesso a un’unica macchina, giusto? E che poi ci colleghiamo tutti e lavoriamo da lì?
Joannes Vermorel: Esattamente. I mainframe erano hardware relativamente complessi, quindi anche se era una sola macchina…
Kieran Chandler: Stiamo parlando principalmente di ERP, cioè sistemi di Enterprise Resource Management. Questi sistemi sono tipicamente progettati per essere estensibili, permettendo l’aggiunta di capacità e funzionalità extra. Tuttavia, non sono modulari, il che significa che non puoi separare queste capacità per mantenerle completamente isolate.
Joannes Vermorel: La cosa interessante è che ciò che ha davvero cambiato probabilmente è stato Internet. Non mi riferisco all’invenzione di Internet, ma al fatto che, verso la fine degli anni ‘90, con la crescente popolarità di Internet, le persone hanno iniziato a pensare a come progettare il software in modo da isolare le parti, con la rete nel mezzo. In questo modo, il flusso di lavoro non risulta più un incubo ingegneristico. Prima di ciò, se non sapevi costruire un sistema software complesso composto da molte parti, avere una rete nel mezzo era un incubo ingegneristico. Questo know-how, questa cultura e gli strumenti sono emersi principalmente come sottoprodotto dell’adozione di Internet da parte del grande pubblico.
Kieran Chandler: Internet esiste da molto tempo ormai, quindi perché stiamo ancora parlando di modularizzazione? Perché questi software agiscono ancora in modo così monolitico?
Joannes Vermorel: Al momento, la mia diagnosi è che, se prendi una media azienda che opera un complesso supply chain o una multinazionale con molte sedi, tutto ciò che è fisico è incredibilmente modulare. Tuttavia, quando si passa all’IT, tutto risulta completamente monolitico. Credo che le aziende e il mercato in generale facciano ancora fatica ad apprezzare il valore di avere qualcosa di estremamente modulare in termini di IT. Fisicamente, è abbastanza ovvio, e i supply chain stanno ancora migliorando la loro modularità. Tuttavia, per quanto riguarda il panorama applicativo, è più astratto, più difficile percepire la modularità come tale.
Kieran Chandler: Qual è il problema con questo approccio monolitico? In che modo influenza le aziende nel mondo reale?
Joannes Vermorel: Immagina l’equivalente fisico della mancanza di modularizzazione. Immagina che nel tuo supply chain, ogni volta che vuoi cambiare un camion, devi cambiarli tutti. Ad esempio, se passi da un camion a un altro, ti serve un tipo diverso di carburante. Così, tutte le tue stazioni di servizio dovrebbero essere modificate, il che significherebbe avere serbatoi che contengono carburante, dove servirà un secondo tipo di carburante. Sarebbe immenso.
Joannes Vermorel: Il problema, vedi, è paragonabile alla situazione del software. Quando manca la modernizzazione, è come se cambiassi una parte, devi cambiare tutte le altre. Se cambi un camion, devi cambiare l’intera flotta. Immagina di cambiare gli scaffali di un magazzino e di dover cambiare tutti gli scaffali di tutti gli altri magazzini, altrimenti non sarebbero compatibili. Poi ti rendi conto: okay, forse posso decidere di aggiornare la mia flotta di camion verso camion elettrici, ma questo rappresenterebbe una mossa strategica enorme e molto complicata. Preferiresti comunque avere qualcosa di relativamente modulare, dove camion elettrici e camion a combustione coesistono armoniosamente per un lungo periodo. Quando manca la modernizzazione, significa che non puoi avere questo tipo di coesistenza. Non puoi cambiare alcuni punti del tuo supply chain senza cambiare tutto.
Joannes Vermorel: La prova aneddotica più frequente di questa mancanza di modernizzazione è che per spostare fisicamente da un magazzino a un altro, le aziende possono farlo in un giorno semplicemente spostando le merci dai ripiani del magazzino A a quelli del magazzino B. Ma migrare il software collegato al magazzino A affinché tutto sappia che tutte le merci sono nel sistema che gestisce il magazzino B, richiederebbe circa sei mesi.
Kieran Chandler: È interessante. Come fanno le grandi aziende a fare questo se operano in un sistema monolitico? Come migrano verso un sistema più modulare?
Joannes Vermorel: Penso che torneremo a una delle aziende che abbiamo menzionato in quasi ogni episodio, come Amazon. Non sono gli unici ad aver adottato un approccio estremamente modulare. In Germania, Zalando, come si può seguire sui blog, ha ora completamente adottato un approccio molto modulare e la parola chiave in IT per questo, quando si desidera avere questa modularità, è probabilmente Service Oriented Architecture, SOA.
Service Oriented Architecture significa fondamentalmente che si voglia isolare le capacità in blocchi che sono a loro volta come piccoli monoliti, ma molto più piccoli, e che siano ben definiti per fare una cosa e farla bene. E colleghi tutte queste cose attraverso la tua Service Oriented Architecture, il che significa che ogni singolo servizio, inteso come un’app che fa una cosa e la fa bene, espone delle API in modo tale da poter essere integrato facilmente nel panorama applicativo. È progettato per essere facilmente integrabile programmaticamente in qualunque ambiente applicativo arbitrario, senza fare quasi alcuna assunzione su quali siano le altre parti del panorama applicativo.
Jeff Bezos di Amazon pubblicò un memo molto famoso, credo nel 2002, in cui disse a tutti i suoi team che ogni singola divisione doveva avere una service-oriented architecture con API, in modo che i dati che hai nel tuo silo possano essere esportati per essere sfruttati in qualsiasi altra divisione dell’azienda e che possiamo interagire programmaticamente con qualunque cosa tu stia costruendo.
Kieran Chandler: Il problema, a mio avviso, è che diventi dipendente da molte app più piccole, programmi più piccoli, aziende più piccole in definitiva. Non introduce questo molti più punti di guasto singolo? Mentre con un approccio più monolitico, hai una grande e solida azienda, un grande sistema ERP che sarà sempre operativo e in cui hai maggiore fiducia.
Joannes Vermorel: È vero, e in un certo senso questo è una delle sfide di un sistema distribuito. Se il tuo hardware fallisce nell'1% dei casi, allora significa se hai un mainframe.
Kieran Chandler: Hai menzionato che il software può guastarsi tre volte all’anno. Se hai 10 app, ciascuna con l'1% di probabilità di essere inattiva in un determinato giorno, significa che, approssimativamente, ogni 10 giorni qualcosa non funziona nella tua rete. È davvero una sfida. Quali soluzioni suggeriresti per questa situazione?
Joannes Vermorel: La ridondanza è la prima cosa che mi viene in mente, ma mi piacerebbe discutere le implicazioni in termini di calcolo distribuito, e magari poi possiamo parlare di piccole contro grandi aziende e della disparità tra i fornitori. Dal punto di vista del calcolo distribuito, l’obiettivo è garantire che ogni singolo blocco sia altamente ridondante. Questa è l’essenza del cloud computing. Vuoi avere un software fortemente ridondante in modo che il tuo uptime sia molto elevato.
La buona notizia è che, poiché le tue app sono più piccole e semplici, è molto più facile ottenere un uptime molto elevato con una piccola app semplice rispetto a una app molto complessa. Ci sono molti servizi componenti su internet che sono letteralmente sempre attivi. Google Mail, per esempio, è letteralmente sempre attivo. Il sito di Yahoo è fondamentalmente sempre attivo. Anche Facebook è sempre attivo. Quindi, è possibile progettare queste proprietà “always-on” per le tue app, il che migliora complessivamente l’affidabilità del tuo sistema.
Kieran Chandler: Che dire della transizione da un grande fornitore a molti piccoli fornitori?
Joannes Vermorel: La realtà è che i tassi di fallimento nel software sono elevati. Le persone non si rendono conto che, forse, nel 50% dei casi, le iniziative software falliscono. La mia stima sarebbe che tra un terzo e la metà di tutti i progetti IT di supply chain falliscono per aziende di dimensioni praticamente qualsiasi. Qualche settimana fa, Lidl in Germania ha perso fondamentalmente mezzo miliardo di euro in una transizione SAP fallita. È stato un progetto di sette anni che si è concluso in fallimento, e alla fine hanno rinunciato. Ma non è l’unico esempio; questo accade abbastanza frequentemente.
I grandi fornitori probabilmente hanno un tasso di successo migliore, ma se parliamo in termini approssimativi, si passa da un piccolo fornitore con un tasso di fallimento del 50%, che è piuttosto negativo, a un grande fornitore con un tasso di fallimento del 30%. Quindi, quando si passa da una piccola a una grande azienda, il rischio diminuisce leggermente, ma solo un poco.
Se opti per un approccio altamente modulare, sì, molte cose falliranno, ma avrai l’opportunità di riprovare e ripetere fino al successo. Ogni componente ha la possibilità di fallire, ma poiché l’ambito è più semplice, l’app stessa è più piccola, puoi fallire rapidamente e riprovare.
Il problema con l’approccio di Lidl è che sono abbastanza sicuro che inizialmente non avessero pianificato una migrazione di sette anni. Probabilmente era una migrazione di due anni che si è trasformata in tre, poi in quattro, e così via, perché continuavano a fallire, a riprovare e a fallire di nuovo. Dopo sette anni, hanno finalmente deciso di arrendersi, probabilmente perché tutti avevano perso ogni speranza che il progetto potesse avere successo.
Kieran Chandler: Quindi, se siamo d’accordo che queste app, una volta trovata quella giusta e magari iterata un po’, possono essere affidabili… Sembrano funzionare e sembrano svolgere lo stesso compito di un sistema di maggiori dimensioni. Che dire dell’interazione tra queste app? Perché spesso, un’app può fare qualcosa di diverso molto bene e può esserci un po’ di sovrapposizione e conflitto all’interno di quel sistema. Come si gestisce questo aspetto?
Joannes Vermorel: Innanzitutto, quando scegli la composizione del tuo panorama applicativo, vuoi davvero scegliere app che abbiano un ambito ristretto. Questo approccio va completamente contro ciò che fanno la maggior parte delle Request for Proposals (RFP). Quando le aziende cercano di acquisire un software, spesso optano per una RFP e vogliono tutto – tutte le funzionalità, tutti i campanelli e fischietti. Ma questo è l’opposto di ciò che dovresti cercare. Vuoi qualcosa di estremamente mirato, in modo da ridurre al minimo le sovrapposizioni per progettazione.
Se acquisti grandi framework, è una ricetta per avere sovrapposizioni. I fornitori enterprise sono interessati a venderti grandi framework perché possono estenderli con molte funzionalità. Ti vendono qualcosa, e poi ti venderanno gli add-on sopra di esso. Quindi, direi alle persone che gestiscono grandi supply chain, di stare molto attenti quando ti viene venduta una piattaforma.
Una piattaforma è buona, ma due piattaforme possono diventare un incubo. Appena hai diversi fornitori che ti vendono piattaforme, finirai per avere un mare di sovrapposizioni. La soluzione è scegliere con cura la composizione dei tuoi ingredienti.
Per quanto riguarda il “collante”, l’approccio è che in genere è qualcosa che si desidera sviluppare internamente. Questo potrebbe andare contro l’intuizione sul perché si dovrebbe sviluppare qualsiasi tipo di software internamente. La risposta è che se sei un’azienda di una certa dimensione, il tuo panorama applicativo è completamente unico per te.
Anche se usi tutte le app standard, avrai bisogno di più app. Non esiste al giorno d’oggi un ERP che possa gestire email, videoconferenze e così via. Non puoi concentrare ogni singola funzionalità software di cui hai bisogno in un’unica app. Probabilmente userai Microsoft Excel come tutti gli altri, quindi avrai bisogno di un luogo dove archiviare file e così via.
Non è realistico dire che abbiamo un unico software. Qualsiasi azienda di dimensioni rilevanti sarà comunque una collezione di software. La ricetta esatta, ovvero l’elenco dei software che gestiscono letteralmente la tua azienda, sarà comunque completamente unica per te. Nessun’altra azienda è organizzata esattamente come te.
Kieran Chandler: È completamente unico, questo è il tuo DNA. Puoi avere questo collante che implementi internamente. Questo è il punto fondamentale della service-oriented architecture: rendere questo collante semplice e snello da implementare, in modo da poter avere un team IT molto snello che richiede sforzi minimi. Per realizzare questo software personalizzato che semplicemente unisce le cose. Quindi, per concludere, se sono un CEO, come evito un altro disastro in stile Lidl?
Joannes Vermorel: Innanzitutto, penso che sia essenziale pensare al rischio anziché cercare di minimizzarlo. Il disastro in stile Lidl è stato causato da persone che dicevano: “Non vogliamo correre alcun rischio”, e quindi optavano per il più grande fornitore disponibile cercando di avere il prodotto che fa tutto. In sostanza, è l’approccio in cui diciamo di volere qualcosa che sia corretto per progettazione, e vogliamo implementare qualcosa che rivoluzioni l’intera azienda in una volta sola. Questo è il peggior tipo di approccio in termini di gestione del rischio.
Devi pensare completamente in modo opposto, ovvero: “Come posso avere qualcosa che fallisca rapidamente se deve fallire?” Vedi, il problema con il rischio è che quando hai un progetto massiccio, non sai per un lungo periodo se hai fallito o meno. Ciò che desideri è avere qualcosa che fallisca rapidamente, in cui, se fallisci, il fallimento sia su piccola scala. E se hai bisogno di una sostituzione, hai un ambito gestibile, e lo fai con tanti piccoli blocchi.
Quindi, pensalo come l’opposto di prevenire il rischio. Sto dicendo che passando da un grande fornitore a un piccolo fornitore, potresti aumentare il rischio dal 50% di fallimento al 50%. Alla fine, se un 30% di probabilità di fallimento significa che la tua azienda va in bancarotta o che la supply chain si blocca, non è un rischio che puoi permetterti. Quindi, devi pianificare il fallimento comunque.
Il mio pensiero è che, poiché un alto grado di rischio è inevitabile, bisogna optare direttamente per un piano di fallimento. Cerca di avere fallimenti piccoli, rapidi e ben circoscritti in modo da poter iterare, anziché dire che faremo tutto correttamente al primo tentativo, il che è un pensiero illusorio. Poi, intraprendi un percorso che probabilmente durerà sette anni, per finire per perdere mezzo miliardo di euro nel processo. Questo è il tipo di pensiero illusorio in merito alla gestione dei progetti.
Kieran Chandler: Ottimo, mi piace. Il consiglio di Lokad del giorno: se devi fallire, falla in fretta. Geniale. Quindi, questo è tutto per questa settimana. Torneremo di nuovo la prossima settimana con un altro episodio. Fino ad allora, grazie per averci seguito.
