00:00:07 Importanza della progettazione software nelle modern supply chains.
00:01:22 Problemi comuni di progettazione software nella gestione della supply chain.
00:02:37 Sfide dei sistemi software in real-time nelle supply chains.
00:04:55 Come operazioni complesse possono influenzare i sistemi in real-time.
00:07:13 Sistemi in real-time intasati da operazioni non in real-time.
00:09:13 Importanza delle scelte di design e della scala temporale nel software per la supply chain.
00:12:31 Differenze tra software single tenant e multi tenant.
00:14:11 Sfide con più versioni di software in applicazioni single tenant.
00:15:33 Vantaggi del software multi tenant e il passaggio verso modelli SaaS.
00:17:56 Importanza di comprendere le assunzioni fondamentali nella progettazione software per i professionisti della supply chain.
00:19:18 Assunzioni fondamentali di design di Lokad, incluso il processamento in batch e la multi tenancy.
00:21:35 Riflessioni conclusive sulla comprensione delle scelte nel software e il loro impatto sulle operazioni future.
00:23:36 Pensieri finali.
Sommario
In un’intervista con Joannes Vermorel, fondatore di Lokad, si discute dell’impatto della progettazione software sull’supply chain optimization. Le sfide sorgono spesso da problemi di design piuttosto che da bug o crash, che possono rendere il software lento, non intuitivo e difficile da configurare. La gestione dei dati in real-time è una caratteristica chiave che può influenzare le operazioni. Tuttavia, concentrarsi su operazioni rapide e semplici può ostacolare processi complessi come la previsione o le analisi a livello di rete. È cruciale comprendere le assunzioni di progettazione software per prevenire problemi dovuti a discrepanze tra il design del software e l’uso previsto dall’azienda.
Sommario Esteso
In questa intervista, il conduttore Kieran Chandler discute con Joannes Vermorel, fondatore di Lokad, l’impatto della progettazione software sulle operazioni aziendali, in particolare nel contesto dell’ottimizzazione della supply chain. Vermorel sottolinea l’importanza della progettazione software nelle modern supply chains, che si basano su molteplici strati software, come ERPs, MRPs, WMSs, OMSs, ed EDIs, per funzionare in modo efficiente. Le sfide affrontate dai clienti di Lokad spesso derivano da problemi nella progettazione del software, piuttosto che da evidenti bug o crash. Questi problemi di design possono rendere il software lento, non intuitivo e difficile da configurare. Come spiega Vermorel, tali problemi sorgono spesso da una discrepanza tra le decisioni fondamentali adottate per il design del software e la realtà effettiva della supply chain che il software intende servire. Joannes Vermorel sottolinea l’importanza cruciale della progettazione software nell’ottimizzazione della supply chain. Le sfide affrontate dai clienti di Lokad spesso derivano da problemi di design che rendono il software lento, non intuitivo e difficile da configurare, a causa di una discrepanza tra le decisioni fondamentali adottate per il design del software e la realtà effettiva della supply chain. La capacità di gestire i dati in real-time è una caratteristica chiave dell’architettura software che può influenzare le operazioni della supply chain. Tuttavia, quando il software è progettato per operazioni rapide e semplici, diventa difficile eseguire operazioni più complesse, come previsioni o analisi a livello di rete, che richiedono un’elaborazione dei dati più sofisticata. Vermorel spiega che i problemi affrontati dai professionisti della supply chain che utilizzano tale software non sono sempre evidenti, poiché spesso si manifestano come un lento accumulo di problemi, che lui definisce “morte per mille tagli”. Una delle caratteristiche chiave dell’architettura software che può influenzare le operazioni della supply chain è la sua capacità di gestire i dati in real-time. Vermorel sottolinea che, sebbene il vero processamento dei dati in real-time non sia possibile a causa della velocità finita della luce, molti supply chain software sono progettati per approssimare il processamento dei dati in real-time. Per esempio, quando un articolo viene prelevato da uno scaffale, il software decrementa immediatamente il stock level. Questo approccio in real-time, tuttavia, può avere conseguenze non previste. Quando il software è progettato per operazioni rapide e semplici, diventa difficile eseguire operazioni più complesse, come le previsioni o le analisi a livello di rete. Tali operazioni complesse richiedono un livello più sofisticato di elaborazione dei dati, che potrebbe non essere fattibile in un sistema ottimizzato per aggiornamenti in real-time e su piccola scala. Joannes Vermorel sottolinea l’importanza cruciale della progettazione software nell’ottimizzazione della supply chain. Le sfide affrontate dai clienti di Lokad spesso derivano da problemi di design che rendono il software lento, non intuitivo e difficile da configurare, a causa di una discrepanza tra le decisioni fondamentali adottate per il design del software e la realtà effettiva della supply chain. La capacità di gestire i dati in real-time è una caratteristica chiave dell’architettura software che può influenzare le operazioni della supply chain. Tuttavia, quando il software è progettato per operazioni rapide e semplici, diventa difficile eseguire operazioni più complesse, come previsioni o analisi a livello di rete, che richiedono un’elaborazione dei dati più sofisticata. Vermorel spiega che i problemi affrontati dai professionisti della supply chain che utilizzano tale software non sono sempre evidenti, poiché spesso si manifestano come un lento accumulo di problemi, che lui definisce “morte per mille tagli”. Vermorel spiega che, nell’ultimo decennio, molte aziende software serie hanno adottato la multi-tenancy. Per le app web come Lokad, essere multi tenant è abbastanza semplice, mentre per il software che opera sui computer dei clienti può essere più complicato. Una soluzione a questo problema è la strategia “evergreen”, come esemplificato da Google Chrome e Microsoft Office 365. Queste applicazioni si aggiornano automaticamente, senza intervento dell’utente, mitigando così i problemi derivanti dalla presenza di più versioni dello stesso software. He osserva che, nell’ultimo decennio, molte aziende software serie hanno adottato la multi-tenancy. Per le app web come Lokad, essere multi tenant è abbastanza semplice, ma per il software che opera sui dispositivi dei clienti può essere più complicato. Una soluzione a questo problema è la strategia “evergreen”, come esemplificato da Google Chrome e Microsoft Office 365. Queste applicazioni si aggiornano automaticamente, senza intervento dell’utente, mitigando così il problema di avere più versioni dello stesso software.
Una questione chiave è la necessità di funzionalità in real-time in certi scenarios, come nel caso della scansione di articoli su un nastro trasportatore ad alta velocità. Quando nel sistema vengono introdotte operazioni non in real-time, le prestazioni complessive possono risentirne, causando rallentamenti e ritardi.
Vermorel evidenzia l’importanza di prendere le giuste decisioni fondamentali di design, che dovrebbero essere strettamente allineate ai problemi che il software si propone di risolvere. Nel contesto del software per la supply chain, vengono adottate varie assunzioni di base e, se queste non vengono rispettate, possono sorgere problemi in seguito. La scala temporale su cui il software opera è una considerazione cruciale. Vermorel descrive i diversi tipi di software necessari per varie scale temporali, che vanno da tempi di risposta sub-millisecond per il funzionamento dei nastri trasportatori, fino alla pianificazione a lungo termine che coinvolge decisioni sulla collocazione degli impianti che possono spaziare tra anni o addirittura decenni. Ogni aumento di un ordine di grandezza nella scala temporale richiede un tipo diverso di software con capacità uniche. Da Lokad, l’attenzione è solitamente rivolta a scale temporali che vanno da un giorno a un anno, il che richiede un approccio diverso nella progettazione del software. Vermorel accenna anche alle differenze tra software single tenant e multi tenant, una considerazione fondamentale per gli sviluppatori di software, anche se meno familiare a molte aziende. Si discute delle differenze tra software multi tenant e single tenant, dei vantaggi del modello SaaS e delle assunzioni fondamentali che hanno guidato la progettazione software di Lokad. Vermorel spiega che il software multi tenant serve a più clienti utilizzando lo stesso codice, mentre il software single tenant prevede che ogni cliente abbia la propria versione personalizzata. Lokad è multi tenant, con un unico codice aggiornato settimanalmente. Questo approccio presenta diversi vantaggi, tra cui una gestione delle versioni semplificata e minori problemi di sicurezza. Vermorel contrappone questo al software single tenant, che consente personalizzazioni per cliente ma richiede la gestione di versioni multiple, con il conseguente aumento delle problematiche operative. Egli osserva che, nell’ultimo decennio, molte aziende software serie hanno adottato la multi-tenancy. Per le applicazioni web come Lokad, essere multi tenant è piuttosto semplice, ma per il software che opera sui computer dei clienti può essere più complicato. Una soluzione a questo problema è la strategia “evergreen”, come esemplificato da Google Chrome e Microsoft Office 365. Queste applicazioni si aggiornano automaticamente, senza l’intervento dell’utente, riducendo i problemi legati alla gestione di versioni multiple dello stesso software.
Egli osserva che, nell’ultimo decennio, molte aziende software serie hanno adottato la multi-tenancy. Per le app web come Lokad, essere multi tenant è abbastanza semplice, ma per il software che opera sui client può essere più complicato. Una soluzione a questo problema è la strategia “evergreen”, come esemplificato da Google Chrome e Microsoft Office 365. Queste applicazioni si aggiornano automaticamente, senza intervento dell’utente, mitigando così i problemi legati alla presenza di più versioni dello stesso software.
Discutendo la progettazione software di Lokad, Vermorel sottolinea l’importanza di comprendere le assunzioni fondamentali di un fornitore. Avverte contro i fornitori che affermano che il loro software possa fare tutto e insiste sul fatto che il design riguarda dei trade-offs, con aspetti sia positivi che negativi. Incoraggia i potenziali clienti a chiedere ai fornitori le loro assunzioni fondamentali e a diffidare di chi fornisce solo risposte vaghe e ottimistiche. Le assunzioni fondamentali di progettazione di Lokad includono la modalità di elaborazione in batch, scelta secondo Vermorel perché consente una migliore ottimizzazione e gestione delle risorse. Un principio chiave è dare la priorità a calcoli intelligenti piuttosto che alla velocità. Lokad preferisce ottenere calcoli accurati e dettagliati anche se richiedono più tempo, invece di calcoli più rapidi ma meno precisi. Il software è progettato per l’elaborazione in batch piuttosto che in real-time, permettendo una maggiore espressività e potenza nell’analisi. Un’altra assunzione fondamentale è l’importanza della multi-tenancy e dell’adozione delle capacità offerte dal cloud computing. Lokad punta a sfruttare il scale-out anziché lo scale-up, utilizzando più macchine più piccole per elaborare grandi quantità di dati invece di affidarsi a un singolo supercomputer potente. Vermorel sottolinea l’importanza che i professionisti della supply chain comprendano le assunzioni fondamentali del design del loro software. Questa comprensione aiuta a prevenire problemi derivanti da una discrepanza tra il design del software e l’uso previsto dall’azienda. I fornitori possono affermare che il loro software sia versatile e adatto a diverse situazioni, ma in realtà alcune limitazioni di design possono ostacolare la sua efficacia in certe applicazioni.
Testo Integrale
Kieran Chandler: Oggi andremo a capire come queste decisioni possano in realtà limitare fortemente un’azienda e a comprendere alcune delle assunzioni fondamentali che le stanno alla base. Quindi, Joannes, parliamo un po’ di come una cattiva progettazione software possa effettivamente impattare su un’azienda. Quali sono alcune delle sfide che osservi?
Joannes Vermorel: La prima sfida è che la progettazione software è estremamente importante per le supply chains. Le supply chains moderne funzionano grazie al software. Ci sono trucks, macchine, nastri trasportatori, ma anche grandi blocchi di software come ERP, MRP, WMS, OMS, EDI e tanti altri strati. Le supply chains moderne non operano senza un’abbondante quantità di software. Quando discuto con i clienti di Lokad, spesso si trovano in difficoltà di fronte al panorama applicativo della supply chain. Ci sono molti problemi legati al software, ma non si tratta necessariamente di bug o crash. I problemi di design sono molto più diffusi; rendono il sistema lento, non intuitivo e la configurazione richiede un tempo infinito. Quando si tenta un’analisi delle cause, si nota frequentemente che i problemi sono in realtà problemi di progettazione software, in cui le decisioni fondamentali sul design sono state prese e si sono completamente discostate dalla realtà effettiva della supply chain in questione.
Kieran Chandler: Quindi, quali sono alcune delle caratteristiche dell’architettura software che possono essere così importanti? Quali sono alcune delle sfide che hai riscontrato con i tuoi clienti?
Joannes Vermorel: Prendiamo, per esempio, il real-time. Molti software per la supply chain oggi sono orientati a operazioni in real-time. Con real-time intendo che se decidi di prelevare un’unità dallo scaffale, il sistema decrementa immediatamente il livello di stock. Sembra una cosa molto ragionevole. Tuttavia, non appena si ha questo tipo di software progettato per il real-time, qualsiasi calcolo sofisticato diventa difficoltoso da eseguire. La ragione è che, se il tuo software è progettato per essere super veloce per operazioni semplici, avere un’operazione complessa, come una previsione o un’analisi a livello di rete, risulta problematica, perché il sistema è pensato per operazioni molto rapide e di piccola scala, e quando devi elaborare una quantità moderatamente complessa di dati, la difficoltà aumenta.
Kieran Chandler: E se hai una versione estremamente dettagliata, rallenterà tutti, compresi quei processi che dovrebbero essere super veloci, come semplicemente scannerizzare un codice a barre e far partire un segnale. Ho scannerizzato e poi puoi procedere al prossimo articolo. Quanto sono evidenti alcune di queste sfide? Bisogna avere comprensione per chi opera nella supply chain. Voglio dire, c’è davvero molto in gioco e, dopo tanto tempo trascorso con questo software, ci sono un’infinità di processi che avvengono “sotto il cofano”. Quindi, quanto è evidente che queste sfide esistono?
Joannes Vermorel: Non è evidente, perché di solito non si presenta come un bug palese che faccia crashare il sistema. È più una morte per mille tagli. Lasciatemi illustrare: avete un sistema che dovrebbe funzionare in real-time. Quando qualcosa viene scannerizzato su un nastro trasportatore ad alta velocità, dovreste essere in grado di far emettere un beep a tre articoli al secondo, o qualcosa del genere. Dovreste operare a velocità tali da garantire tempi di risposta in millisecondi.
Ora, cosa succede se, di tanto in tanto, un calcolo richiede alcuni secondi anziché millisecondi? Se, occasionalmente, avete un’operazione che impiega qualche secondo e il sistema in real-time è ben progettato, probabilmente la maggior parte delle altre operazioni rimarrà super veloce, quindi il danno è limitato. Tuttavia, se la sfortuna colpisce e nello stesso istante ci sono per esempio dieci operazioni diverse che richiedono diversi secondi per essere elaborate, allora tutte le risorse di calcolo vengono esaurite in quel preciso momento.
Così, ciò che accade è che il sistema che doveva scannerizzare e fornire un feedback in millisecondi impiega improvvisamente un secondo. Non è l’ideale, ma si può convivere. Tuttavia, di tanto in tanto, ci si ritrova ad aspettare due o tre secondi anziché una risposta lampo. Tra l’altro, capita persino nei supermercati locali: al punto cassa il segnale acustico degli articoli è molto fluido, ma ad un certo punto parte un beep, segue un’attesa di tre secondi, e poi un altro beep.
Qui avete un sistema in real-time che è stato in qualche modo intasato da un’operazione non in real-time. Non so cosa sia successo, magari un aggiornamento di Windows o qualche altro evento strano che rallenta la macchina. Ma in un sistema in real-time non è permesso eseguire operazioni intelligenti o complesse, perché ciò degraderebbe le operazioni superveloci che si intendono mantenere.
Quando dico “death by a thousand cuts”, è perché la prima volta che fai qualcosa non in tempo reale in un sistema in tempo reale, probabilmente non succederà nulla di grave. È raro, quindi stai abbastanza bene. Ma il problema è che accumuli sempre più cose non in tempo reale, e improvvisamente quei problemi che erano molto rari iniziano a diventare sempre più frequenti, fino a diventare super frequenti. Poi la gente impazzisce, dicendo, “Perché questo nastro trasportatore non funziona più velocemente? Potrebbe.”
La risposta è perché c’è una macchina che dovrebbe scansionare il codice a barre, e dobbiamo aspettare che il sistema risponda. Ho visto situazioni in cui il sistema impiegava 30 secondi per rispondere dopo aver scansionato un codice a barre. Si trattava di stampare qualcosa da mettere sulla scatola, ma il nastro trasportatore era limitato dalla velocità con cui il sistema poteva trasmettere l’ordine alla stampante per stampare qualcosa sulla scatola. C’erano persone che aspettavano semplicemente che la stampante stampasse.
Hai a disposizione molte scelte di progettazione che devono centrare le scelte fondamentali, in modi profondamente allineati ai problemi che stai cercando di risolvere.
Kieran Chandler: Quali sono le principali assunzioni di base che vengono fatte nel software supply chain, e quali hai osservato che non funzionano davvero?
Joannes Vermorel: Ci sono molti modi per affrontare questo. Prima di tutto, considera la scala temporale in cui desideri operare. Abbiamo sistemi che devono operare con tempi di risposta sub-millisecondo, che è ciò che serve per far funzionare letteralmente un nastro trasportatore, fino a decisioni in cui devi pensare a un decennio avanti, come la localizzazione delle fabbriche. Ogni volta che aggiungi un ordine di grandezza, cambi fondamentalmente il software.
Kieran Chandler: Puoi fare qualche esempio di diverse scale temporali e dei corrispondenti tipi di software?
Joannes Vermorel: Certo. Il sub-millisecond è un tipo di software; da 1 a 10 millisecondi, sarà un altro tipo di software; da 10 a 100 millisecondi, ne verrà un altro, che è tipicamente il software ERP con tempi di risposta da 10 a 100 millisecondi. Da 100 millisecondi a 1 secondo, ottieni quel genere di cose che puoi trovare in una web app. Poi, se inizi a pensare da 1 a 10 minuti in avanti, non sei più in tempo reale, ma puoi iniziare a fare calcoli sofisticati. Ad esempio, un’app di navigazione come Waze deve fornire un percorso entro 30 secondi, ma non deve essere in tempo reale.
Se stai ottimizzando un percorso per le consegne con camion, in genere puoi impiegare diversi minuti per ottenere i risultati, perché non deve essere in tempo reale. In Lokad, siamo generalmente più concentrati su intervalli che vanno da 1 giorno a 1 anno. Questo è il nostro punto ideale, e significa che possiamo praticamente ignorare tutto il resto. Se superiamo un anno, entriamo nel campo del design della supply chain, che è più incentrato sulla mappa e cambia il problema.
Kieran Chandler: Parliamo un po’ dell’implementazione del software. Quali sono le principali differenze tra il software single tenant e multi-tenant?
Joannes Vermorel: La differenza tra single tenant e multi-tenant sta nel numero di clienti che servi con lo stesso software. Se sei multi-tenant, come Lokad, è lo stesso software a servire tutti i nostri clienti. Abbiamo una sola versione distribuita online in ogni momento, e aggiorniamo questo software settimanalmente. L’altra modalità, che era più comune prima dell’avvento del SaaS, è il single tenant. Questo approccio prevede di fornire a ciascun cliente la propria copia del software, il che spesso si traduce in personalizzazioni per i grandi clienti.
Produrre il software significa che improvvisamente ti ritrovi con molte varianti del tuo software che girano contemporaneamente, il che è un grande problema operativo perché significa che se c’è un bug in una versione, devi correggere quella versione, ma devi assicurarti che il bug venga risolto anche in tutte le altre versioni. A proposito, questo è un problema in cui, per le aziende di software, esistono vere e proprie anti-economie di scala. Più sei grande, più problemi hai con la versione. A proposito, questo problema sta colpendo molto severamente Oracle, per esempio, con il database Oracle. Hanno molte versioni pesantemente personalizzate e ottimizzate per le prestazioni. Non ho informazioni riservate, ma dalle sole informazioni pubbliche si può vedere che, letteralmente, in diverse divisioni ingegneristiche di Oracle, stanno faticando con il fatto di avere molte varianti del software in circolazione. Ovviamente, Oracle dispone di enormi capacità ingegneristiche, ma resta comunque una grande sfida. Quindi, il single tenant ti dà la possibilità di una personalizzazione per cliente, ma poi devi gestire il sovraccarico per cliente. Il multi-tenant, invece, ti offre il vantaggio di avere un’unica base di codice per tutti, senza personalizzazioni, ma in cambio puoi evolvere molto più rapidamente e avere anche molti meno problemi di sicurezza.
Kieran Chandler: Quando dici che il mercato sta spostandosi molto verso quel modello SaaS, perché questo modello è così tanto migliore? Offre un maggiore grado di flessibilità per l’azienda?
Joannes Vermorel: Sì, nell’ultimo decennio praticamente tutti i vendor di software seri si sono orientati verso il multi-tenancy, persino le applicazioni desktop tradizionali classiche. Perché ovviamente, se sei una web app come Lokad, essere multi-tenant è abbastanza semplice. Ridistribuisci le cose sui tuoi sistemi ed è fatto. Ovviamente, quando hai software che operano sui computer dei clienti, come ad esempio il tuo browser, per esempio Internet Explorer o Google Chrome, è più complicato perché non hai il controllo sui computer dei clienti. Ma indovina cosa hanno fatto i vendor di software? Hanno adottato la strategia evergreen. Ad esempio, Google Chrome non ti chiede più di aggiornare il browser. Quando Google decide che la tua versione di Chrome è obsoleta e deve essere sostituita, Google aggiorna il browser a distanza. Ovviamente, la prossima volta che ti connetti a Internet, non possono magicamente aggiornare il tuo software se non hai connettività. Ma supponendo che tu abbia connettività e che non abbia fatto nulla di particolare per impedire l’aggiornamento, questo avverrà praticamente da solo, senza il tuo intervento. E se guardi cosa sta facendo Microsoft con Office 365, è la stessa cosa. In passato, avevi una serie di versioni di Microsoft Office quando passavi da una versione di Excel all’altra. Oggi, è on-demand, e Microsoft si occupa dell’aggiornamento. Hai un abbonamento, il software è installato sul tuo computer, ma può aggiornarsi da solo alla versione successiva. E se lo lasci fare, a meno che tu non disattivi le opzioni di aggiornamento, Microsoft sta semplicemente aggiornando tutte le applicazioni desktop per mitigare il problema di avere molte versioni dello stesso software.
Kieran Chandler: Parliamo un po’ di Lokad allora. Hai detto che ci sono certe assunzioni di base che devono essere fatte nella progettazione del software e che possono davvero influire sulle operazioni future. Quindi, quali sono state le assunzioni di base che avete fatto qui a Lokad?
Joannes Vermorel: Ce ne sono un sacco, ma prima di entrare nel merito delle assunzioni di base, vorrei fare una nota. Se incontri un vendor di software che
Kieran Chandler: Che ti dice “tutto il mio software, sai. Siamo capaci di tutto quello che non abbiamo fatto”. Sai, quindi assunzioni sul software. Se ti danno solo – posso suggerire, quando incontri un vendor di software per la tua supply chain, chiedi loro quali sono le assunzioni di base. E se ti dicono qualcosa di vago come “siamo progettati per la sicurezza”, fantastico. “Siamo progettati per la velocità”, sì, anche io. “Siamo progettati per l’efficienza dei costi”, sì. Sai, queste sono delle affermazioni super vaghe, assolutamente positive. Ma quando discutiamo di progettazione, un punto di vista progettuale è un compromesso. È qualcosa che ha aspetti positivi e negativi. Quindi, se puoi discutere con il vendor di software, e tutto ciò che possono darti sono gli aspetti positivi, probabilmente non comprendono nemmeno la natura della progettazione del software in primo luogo. Quindi, Joannes, quali sono le assunzioni di base che avete incorporato in Lokad?
Joannes Vermorel: La prima è stata la modalità di elaborazione batch. Quindi, cosa significa? Significa che ciò che vogliamo è essere in grado di elaborare tonnellate di big data e di fare calcoli molto intelligenti. Ovviamente, preferiamo essere molto intelligenti piuttosto che essere molto, molto veloci, il che significa che, per noi, avere calcoli che tipicamente vengono eseguiti nell’arco di minuti, e il fatto che possano essere eseguiti in secondi è un bonus. Ma se non ci riesci, non è un grosso problema. Preferiamo ottenere numeri migliori anche se ci vuole un po’ di tempo. A proposito, non significa che ci siano parti nostre che guardano quel tempo di rotazione, è solo una presentazione dei risultati. Quindi, magari ci vorrà circa mezz’ora per eseguire un calcolo massiccio, ma quando vuoi accedere a quei risultati, allora deve essere in tempo reale, anche se è pre-computato. Vedi, questa è stata un’assunzione di design fondamentale. Niente in tempo reale, oppure è batch. E il motivo è che vogliamo essere il più espressivi e potenti possibile e, dunque, essere il più intelligenti possibile per, direi, un’analisi globale a livello mondiale. Quindi, questa è un’assunzione fondamentale. Un’altra era che volevamo avere la multi-tenancy. Ovviamente, al giorno d’oggi la maggior parte delle persone lo fa, ma ci sono ancora aziende che, soprattutto nel settore enterprise, sono indietro. E direi, multi-tenancy fatta in ogni sua parte.
Kieran Chandler: Puoi spiegare la differenza tra scalable e scale out?
Joannes Vermorel: Le capacità offerte dal cloud significano che vogliamo avere capacità di scale out piuttosto che scale up. La domanda è: se vuoi elaborare terabyte di dati, puoi farlo accumulando un sacco di macchine piccole o hai bisogno di un supercomputer per farlo?
Kieran Chandler: Quindi, qual è la nostra principale conclusione qui oggi?
Joannes Vermorel: La nostra principale conclusione è che, in termini di dati a disposizione e in termini di scelte sul software, tutto ciò può limitare fortemente ciò che farai in futuro. Quindi, devi comprendere appieno le scelte che stai facendo.
Kieran Chandler: Puoi approfondire?
Joannes Vermorel: Il mio suggerimento sarebbe che i professionisti della supply chain diventino più consapevoli delle assunzioni di design fondamentali che caratterizzano il loro panorama applicativo. Hanno molte app, e possono darmi mezza dozzina di assunzioni critiche sul codice che spiegano i dettagli del prodotto. Potrebbe sembrare super tecnico, ma se non comprendi queste assunzioni di base, ne soffrirai molto quando ti renderai conto che stai tentando di fare qualcosa per cui, per design, questo non sarà un buon prodotto. Spesso ho visto molte aziende in cui, letteralmente, i loro problemi emergono da una mancata corrispondenza tra il design del software e ciò che stanno cercando di fare con esso.
Kieran Chandler: Puoi fare un esempio?
Joannes Vermorel: I vendor cercano di essere molto sicuri di sé, sai, come venditori stai tentando di vendere il tuo software. Vuoi mostrarti sicuro e dire al cliente che il tuo software supply chain andrà bene in tutte le situazioni, e che ci pensiamo noi. Ma la realtà è che se un cliente usa il tuo software per qualcosa che esula dalle tue capacità progettuali, non puoi semplicemente “aggiustarlo” con del nastro adesivo. Non puoi semplicemente aggiungere una funzionalità. Gli ingegneri del software sul back end ti diranno, “Boss, mi dispiace, non possiamo farlo. Sarà un inferno.”
Kieran Chandler: Bene, concludiamo. Grazie, Joannes. Questo è tutto per questa settimana. Molte grazie per averci seguito, e ci vediamo la prossima volta. Arrivederci per ora.
