FAQ: Tecnologia dell'Informazione (IT)

The Lokad app is a webapp provided as SaaS (Software as a Service). Lo scopo di Lokad è fornire analisi predittive per ottimizzare the supply chain (better stocks, better prices, etc.). L’app Lokad è concepita come uno strato analitico che opera in parallelo ai sistemi transazionali (ERP, WMS, CRM, etc.). Viene offerta con una tariffa mensile forfettaria che solitamente include l’app stessa insieme a servizi professionali. Questi servizi professionali, forniti dagli ingegneri di Lokad (Supply Chain Scientists), riducono quasi interamente la necessità di supporto tecnico da parte del dipartimento IT per questo ambito. L’unico contributo fondamentale atteso dal dipartimento IT è l’installazione di una pipeline dati che invii file flat (tramite SFTP o FTPS) a Lokad, e potenzialmente reintegri i risultati generati.

Destinatari: Il dipartimento IT
Ultima modifica: 30 novembre 2023

Panoramica tecnica

L’app Lokad è multi-tenant. Ogni tenant (ovvero conto cliente) ha il proprio file system dedicato e il proprio repository di codice dedicato. Il file system è accessibile tramite FTPS, SFTP e un’interfaccia web. Questo file system è pensato per grandi file flat (fino a 100 GB per file) e prevede il versioning dei dati (come Git). Il repository del codice viene usato per ospitare script Envision. Envision è un DSL proprietario (Domain Specific programming Language) sviluppato da Lokad. Questo DSL è fortemente specializzato per casi d’uso di ottimizzazione predittiva. Gli script Envision sono usati per eseguire le principali analisi numeriche (inclusi algoritmi di machine learning, solver, …) e per generare dashboard ricche di dati.

L’app viene ridistribuita completamente ogni martedì tra le 10:00 e le 14:00 (orario di Parigi). I tempi di inattività sono generalmente inferiori a 5min. Lokad si assume la piena responsabilità di tutte le questioni relative al versioning.

Non ci si aspetta che il dipartimento IT acquisisca competenze specifiche riguardo allo stack di Lokad. Tuttavia, se siete curiosi, esiste una documentazione tecnica completa.

Panoramica del contributo IT

Ci aspettiamo che il dipartimento IT installi una pipeline dati che invii una breve serie di estrazioni rilevanti di file flat verso Lokad tramite SFTP o FTPS. Le estrazioni vengono eseguite sui sistemi transazionali (es: ERP). Abbiamo una forte preferenza per estrazioni grezze di tabelle (senza filtro, senza join, senza trasformazioni), che richiedono uno sforzo minimo. Dal punto di vista ETL, richiediamo solamente la parte ‘E’ (estrazione) nella sua forma più semplice (copia semplice). Per quanto riguarda il formato, Lokad è compatibile con qualsiasi file flat ragionevolmente tabellare.

Si prevede che la pipeline dati venga eseguita almeno quotidianamente e sia completamente automatizzata. La quantità di lavoro per il dipartimento IT dipende dall’ambito dell’estrazione dati (quali sistemi? quali tabelle?). Tuttavia, a titolo indicativo, l’installazione della pipeline dati richiede di solito circa 15 to 45 man-days, anche per le grandi aziende. Una volta che la pipeline è in funzione, Lokad richiede normalmente solo un monitoraggio minimale da parte del dipartimento IT, che generalmente richiede 1 o 2 man-days al mese.

Panoramica della sicurezza

L’app è ospitata nei data center Microsoft Azure situati nell’UE. Non trattiamo dati personali, in quanto non sono necessari per il funzionamento. Al momento di definire l’ambito dell’estrazione dati, escludiamo qualsiasi colonna o campo che possa contenere dati personali.

Per l’autenticazione, la nostra preferenza va a SAML. Raccomandiamo vivamente che gli utenti accedano a Lokad tramite un’identità federata come Azure Active Directory, Office 365 o Google Workspace. Ciò elimina tutti i problemi relativi alle password.

Su richiesta, i nostri clienti possono effettuare audit di sicurezza e test di penetrazione. I dettagli dipendono dagli accordi negoziati.

Per ulteriori dettagli, vedere Sicurezza in Lokad.

Panoramica della timeline

La Quantitative Supply Chain riguarda più un percorso che un punto d’arrivo. Tuttavia, la leadership della supply chain che impegna l’azienda a realizzare un’iniziativa di Quantitative Supply Chain richiede visibilità sulla timeline del progetto. Anche se ritorni positivi possono essere ottenuti in un paio di mesi, spesso ci vogliono fino a due anni per sbloccare il pieno potenziale della Quantitative Supply Chain. Nel seguente testo, forniamo una panoramica di una timeline tipica associata a un’iniziativa di Quantitative Supply Chain per un’azienda di medie dimensioni. Per le grandi aziende, le timeline dovrebbero essere il doppio.

Avvio del progetto: I rappresentanti di entrambe le parti si presentano e programmano riunioni settimanali. Queste riunioni settimanali dureranno fino al raggiungimento della fase di Produzione. Il Supply Chain Scientist presenta le diverse fasi di implementazione e i vari deliverable che il cliente può aspettarsi. Il resto della chiamata è dedicato a rivedere vari dettagli della supply chain e le caratteristiche IT dell’integrazione. Dopo la chiamata, viene prodotto un riepilogo che documenta gli aspetti organizzativi del progetto e viene inviato al cliente.

Specifiche dei dati: Poco dopo la riunione di avvio, il Supply Chain Scientist produce le specifiche dei dati necessarie per l’implementazione del progetto. Queste specifiche vengono revisionate e validate insieme al cliente. In particolare, questo documento definisce i dati da estrarre dai sistemi IT del cliente. A titolo indicativo, l’estrazione dovrebbe rimanere il più possibile fedele ai dati originali così come esistono nei sistemi IT del cliente.

Primo caricamento dati: Dopo la validazione delle specifiche, il cliente carica il primo set di dati sui server di Lokad. Generalmente, in questa fase, il caricamento non avviene ancora tramite un processo automatizzato, poiché di solito sono necessari diversi tentativi per raggiungere un consenso sui dettagli fini delle specifiche dei dati.

Validazione dei dati: Il Supply Chain Scientist esegue un’indagine approfondita del contenuto del dataset del cliente. In particolare, vengono introdotti controlli di coerenza per monitorare la qualità dei dati secondo diverse metriche. L’obiettivo è assicurarsi che 1) il dataset venga correttamente aggiornato dal processo di caricamento, 2) il dataset rifletta correttamente la realtà del business e 3) il dataset sia sufficientemente coerente e completo per scopi di ottimizzazione della supply chain.

In termini di deliverable, durante questa fase il Supply Chain Scientist fornisce al cliente vari dashboard che valutano lo stato dei dati. Questi dashboard possono essere utilizzati dal cliente anche per scopi che vanno oltre l’iniziativa di Quantitative Supply Chain, ad esempio nell’ambito del processo interno di assicurazione della qualità dei dati.

Audit a metà progetto: 6 settimane dopo l’avvio iniziale, viene organizzata una riunione per valutare lo stato di avanzamento del progetto. L’obiettivo di questo “audit” è affrontare, nel più breve tempo possibile, i problemi che potrebbero verificarsi durante l’implementazione, in particolare quelli che potrebbero ritardare la fase di produzione. Da Lokad, questo “audit” consiste in uno scambio tra il Supply Chain Scientist e il cliente, basato su una checklist comunicata al cliente in anticipo, subito dopo la riunione di avvio.

Automazione del caricamento: Una volta che entrambe le parti validano la qualità complessiva del dataset caricato finora, il cliente implementa un processo automatizzato che trasferisce il proprio dataset a Lokad in modo regolare - idealmente quotidianamente. Allo stesso tempo, dal lato di Lokad, la logica di monitoraggio della qualità dei dati - con i suoi numerosi controlli - viene programmata per essere aggiornata dopo ogni caricamento.

Impostazione dell’ottimizzazione: Da questo punto in poi, il Supply Chain Scientist dispone di tutti gli elementi necessari per implementare l’ottimizzazione delle decisioni precedentemente concordate con il cliente. Pertanto, egli implementa script per generare diversi output quantitativi: suggerimenti operativi per gli acquisti, suggerimenti per le spedizioni, etc. Le cifre prodotte da questi script possono essere visualizzate sotto forma di dashboard. In questa fase, questi dashboard rappresentano solo una versione preliminare dei dashboard finali e devono essere rivisti insieme al cliente.

Feedback e messa a punto: Le richieste del cliente di apportare qualche modifica o “ritocco” ai vari output solitamente portano a una messa a punto degli script scritti dal Supply Chain Scientist. Esistono molti parametri e metodi che possono essere adottati per allineare adeguatamente le caratteristiche della supply chain in ottimizzazione con la logica ottimizzativa. Quando la metodologia stessa ha importanza strategica per il cliente, ciò viene discusso esplicitamente tra il cliente e il Supply Chain Scientist.

Produzione: Dopo diversi cicli di messa a punto e revisione, il cliente raggiunge un punto in cui inizia a fidarsi della logica implementata dal Supply Chain Scientist. A questo punto, il cliente può iniziare a utilizzare il servizio in produzione, ovvero eseguire direttamente le decisioni della supply chain così come calcolate inizialmente dal software. Quando il cliente convalida che la soluzione è pronta per la produzione, il Supply Chain Scientist consegna una documentazione che assicura la manutenibilità della soluzione.

Supporto e manutenzione: La soluzione è operativa e viene utilizzata dal cliente mentre il Supply Chain Scientist monitora il corretto svolgimento quotidiano della pipeline dati. Vengono organizzate regolarmente chiamate tra il cliente e il Supply Chain Scientist per verificare che l’ottimizzazione fornisca il grado di performance atteso della supply chain. Inoltre, le supply chain non sono statiche, pertanto cambiamenti nel business o nell’IT, piccoli o grandi, devono essere revisionati: un nuovo magazzino, variazioni di mercato, nuovi processi, etc. Il Supply Chain Scientist propone modifiche adeguate per accogliere tali cambiamenti. Le chiamate di checkpoint sono programmate con una frequenza concordata, solitamente mensilmente.

Domande Frequenti (FAQ)

1. Gestione delle Release

1.1 Come funzionano le release per Lokad?

Lokad gestisce tutte le release internamente, il che contribuisce a garantire la massima trasparenza per i clienti. Qualsiasi release che potrebbe avere impatti su un cliente viene coordinata con loro - tramite i team tecnici del cliente - con largo anticipo. In generale, Lokad adotta un approccio prudente alle release: se una release programmata non offrisse un tempo di preparazione sufficiente per il cliente, essa verrebbe temporaneamente posticipata.

Le release di Lokad sono molto granulari, e il design solitamente permette al cliente di rinunciare ad un particolare elemento tecnico di una release complessiva. Pertanto, se dobbiamo posticipare l’implementazione di un elemento per cui il cliente non è ancora pronto, la release complessiva può comunque procedere (implementando gli altri elementi non impattanti).

1.2 Quanto sono frequenti le release?

Lokad rilascia una nuova versione ogni martedì, solitamente intorno alle 11:00 (CET).

1.3 Fornite un piano delle prossime release?

Sì, vedere Gestione delle Release 1.2.

1.4 Un cambiamento di versione comporta una reinstallazione o solo una patch?

Lokad ridistribuisce, tramite mezzi automatizzati (script), la propria soluzione. Non patchiamo i sistemi in produzione. Se dobbiamo distribuire una “security patch”, ridistribuiremo la soluzione attraverso i consueti mezzi automatizzati.

1.5 Quanto tempo ci vuole per applicare una release maggiore?

Il processo automatizzato richiede circa 1 ora. Esiste un rilascio a fasi (macchina per macchina), poiché intendiamo mantenere la piattaforma di Lokad operativa e accessibile durante la release. L’operatività durante un rilascio è discussa in Gestione delle Release 1.7.

1.6 Chi è responsabile della corretta esecuzione della release?

Il team di Lokad si assume la piena responsabilità della corretta esecuzione della release.

1.7 C’è downtime durante la release?

Per lo più no, ma tenete presente che la soluzione di Lokad è un sistema distribuito dedicato a calcoli su larga scala. In quanto tale, l’impatto di una release varia tra i sistemi front-end e back-end. I sottosistemi rivolti al cliente, come i dashboard, sono progettati per zero downtime. I sistemi back-end, come quelli incaricati dell’esecuzione di job batch, potrebbero essere messi in pausa per alcuni minuti (almeno per alcuni job). Tuttavia, questi job batch possono essere programmati, quindi una pianificazione proattiva dovrebbe consentire il completamento dei job batch al di fuori della finestra temporale della release.

1.8 Qual è il vostro processo o strategia di testing per una release?

Lokad utilizza processi automatizzati dedicati al testing e a garantire la correttezza di una release imminente. Questi processi includono ampie suite di test automatizzati (misurati in migliaia): test unitari, test funzionali, test di performance, etc. Abbiamo inoltre sviluppato strumenti dedicati che ci permettono di riprodurre intere sequenze di esecuzioni di job passate all’interno della piattaforma Lokad. Questi strumenti ci consentono di verificare che gli script Envision abbiano lo stesso comportamento prima/dopo una release imminente. Inoltre, possiamo verificare che i profili di performance degli script esistenti rimangano in linea con le aspettative di pianificazione, come definite dai nostri clienti.

1.9 Avete più ambienti?

Sì, tuttavia, gli ambienti alternati (a livello di piattaforma, oltre a quello di produzione) solitamente non sono destinati ai nostri clienti. Oltre all’ambiente di produzione e a quelli di sviluppo transitori, disponiamo di un ambiente “evergreen” che corrisponde all’ultima versione stabile del nostro repository di codice. Questo valida un sottoinsieme specifico dei nostri processi di testing automatizzato. I nostri clienti possono accedere al nostro ambiente “evergreen” per verificare che una determinata release imminente si comporti come previsto. In pratica, questa situazione è infrequente.

Se l’obiettivo è quello di poter eseguire (affiancati) più varianti degli script Envision, allora un account Lokad può essere partizionato in più “ambienti”. Se l’obiettivo è quello di poter eseguire qualsiasi tipo di test, allora può essere fornito un secondo account Lokad per scopi di test temporanei. Questo secondo approccio mantiene l’account cliente primario (utilizzato per la produzione) isolato da questi test.

1.10 Quante versioni differenti possono coesistere?

Lokad è un SaaS multi-tenant che esegue la stessa versione unica per tutti i suoi clienti, tuttavia, Lokad ha la capacità di operare tante versioni distinte quante desidera il cliente.

1.11 Un cliente può rinunciare a un rilascio?

Poiché Lokad è un SaaS multi-tenant che esegue la stessa versione unica per tutti i clienti, non è possibile rinunciare a un rilascio. Tuttavia, dal punto di vista commerciale, ciò risulta irrilevante in quanto ogni “modifica” viene implementata attraverso l’esecuzione di script Envision all’interno della soluzione Lokad.

Per situazioni in cui un rilascio può essere temporaneamente posticipato, vedere Gestione dei Rilasci 1.1.

1.12 Avete le note di rilascio? Le fornite ai vostri clienti?

Sì. Queste note vengono condivise internamente (con i nostri Supply Chain Scientist). Se esplicitamente concordato come parte di un contratto, queste note di rilascio possono essere rese accessibili a un cliente. In pratica, le note di rilascio della piattaforma Lokad interessano solo le persone che lavorano con il codice Envision.

1.13 Qual è il processo per cui un cliente richiede un’evoluzione della soluzione?

La maggior parte dei nostri clienti beneficia di un’offerta “software + esperto”, dove un team dei Supply Chain Scientist di Lokad è responsabile dell’implementazione e della manutenzione della soluzione supply chain del cliente. Queste situazioni sono note come “supply chain as a service”. In questi accordi, il cliente interagisce regolarmente con uno (o più) Supply Chain Scientist. Inoltre, la maggior parte dei clienti beneficia di un comitato direttivo settimanale o mensile per discutere lo stato attuale della soluzione ed eventuali evoluzioni desiderate. Questo metodo viene utilizzato da Lokad per raccogliere tutte le richieste di evoluzione e proporre una road map per l’implementazione dei cambiamenti.

1.14 È possibile amministrare il web service dell’applicazione e configurare i suoi parametri?

Sì, nel senso che la piattaforma Lokad è per sua natura programmatica. La logica “analitica” di Lokad assume la forma di script Envision - Envision essendo il DSL (Domain-Specific Language) progettato da Lokad per l’ottimizzazione predittiva della supply chain.

Pertanto, in un certo senso, ogni configurazione singola di parametri è disponibile sfruttando gli script Envision all’interno dell’account.

2. Performance

2.1 Il vostro SLA (Service Level Agreement) copre un uptime del 99.xy%?

Sì. L’SLA fa parte del nostro accordo contrattuale standard. Tuttavia, la nozione di uptime nel contesto di un sistema informatico distribuito - dedicato all’ottimizzazione predittiva della supply chain - è complessa. Considerate i seguenti scenari: - Lokad riceve dati del cliente (un passaggio giornaliero) con 2 ore di ritardo rispetto al programma. Ciò potrebbe ben compromettere l’efficienza ordinaria delle nostre euristiche di allocazione delle risorse. Questo, a sua volta, potrebbe prolungare il tempo necessario per eseguire i batch job di Lokad (ad es., 75 minuti anziché i consueti 60). Alcuni potrebbero considerarlo un downtime di 15 minuti, ma ciò è al di fuori del nostro controllo.

• Lokad riceve gli stessi dati del cliente in tempo, ma i dati mostrano un notevole calo dei livelli di stock. Ciò innescherebbe un’interruzione dei batch job (dal lato di Lokad) e allertarebbe un Supply Chain Scientist per indagare sul problema. Il Supply Chain Scientist nota che un ordine di rifornimento automatizzato è insolitamente elevato. Il Supply Chain Scientist decide che è necessaria una valutazione diretta da parte del cliente. Il giorno successivo, il cliente conferma che i dati di stock erano corrotti e che ciò avrebbe comportato una significativa svalutazione di stock. Alcuni potrebbero considerarlo un downtime di 24 ore, ma in questo contesto sembra praticamente eccessivo.

Il pericolo maggiore per una soluzione di ottimizzazione della supply chain non è essere leggermente in ritardo; è essere completamente sbagliati. Una volta presa una decisione sulla supply chain, come (erroneamente) innescare un lotto di produzione, annullarla può risultare estremamente costoso. Incoraggiamo i nostri clienti a non legarsi in modo arbitrario a indicatori isolati, poiché questo atteggiamento può incentivare a fornire un lavoro complessivamente inferiore, purché sembri soddisfare un KPI (ad esempio un uptime di x.y%).

2.2 Garantisci un tempo di risposta per le richieste degli utenti entro X secondi?

Sì, sotto i 500ms, ma con delle riserve.

Abbiamo progettato quelle che equivale più o meno a delle “dashboard a tempo costante”. Sotto il cofano, la visualizzazione di una dashboard richiede una singola richiesta in rete, e nel nostro back end collocamo tutti i dati della dashboard per mantenere basso il numero di richieste (solitamente misurato in cifre singole). Questo design contribuisce notevolmente a “garantire” la bassa latenza della tipica richiesta utente durante la visualizzazione di una dashboard. Questa scelta di design impedisce inoltre che la dashboard diventi affollata di riquadri - ciascuno dei quali richiederebbe ulteriori richieste in rete - rallentando così l’esperienza utente complessiva.

Per quanto riguarda la durata dei batch job, attraverso Envision possiamo fornire garanzie - in fase di compilazione - che un batch job verrà completato. Possiamo anche garantire tempi di completamento sostanzialmente riproducibili per i nostri batch job. Queste garanzie sono ottenute tramite analisi statica e un attento design del linguaggio Envision - che rende possibili alcune classi di analisi statica. Questo approccio ha dei limiti, ma è di gran lunga superiore ai design che non offrono alcuna garanzia.

Tuttavia, la latenza end-to-end non è interamente sotto il nostro controllo. Ad esempio, non controlliamo la qualità della connessione internet utilizzata dai nostri clienti. Un grande foglio di calcolo di Lokad impiegherà tempo a scaricarsi su una rete a bassa larghezza di banda.

2.3 Avete log di audit delle prestazioni del sistema?

Sì. Raccogliamo log di prestazioni molto dettagliati per tutte le risorse computazionali coinvolte: CPU, memoria, storage, larghezza di banda, ecc. Questi log vengono utilizzati, tra le altre cose, per garantire che una nuova versione, ancora non rilasciata, della piattaforma soddisfi le nostre aspettative in termini di prestazioni. Testiamo questo confrontando le prestazioni della nuova versione con quelle delle versioni precedenti, come evidenziato da questi log.

2.4 È possibile monitorare risposte lente o congestioni?

Sì. La piattaforma Lokad è dotata di un scheduler interno che può monitorare l’esecuzione tempestiva dei batch job. Il design di Lokad garantisce per lo più una risposta a tempo costante per tutte le richieste - ad eccezione delle operazioni a lunga esecuzione, trattate come batch job.

Poiché Lokad è una piattaforma multi-tenant, una grande parte del monitoraggio delle prestazioni non è direttamente accessibile ai nostri clienti (in quanto copre le prestazioni della piattaforma nel suo complesso). Come ci si può aspettare, i team di Lokad monitorano continuamente le prestazioni della nostra piattaforma.

2.5 Avete dei bilanciatori di carico?

Sì. I bilanciatori di carico di Lokad sono destinati principalmente all’affidabilità piuttosto che alla performance. Il bilanciamento del carico a livello di rete è effettuato attraverso il layer di networking della piattaforma di cloud computing che utilizziamo (Microsoft Azure). Tuttavia, la distribuzione del carico interno di elaborazione dati, gestita dalla piattaforma Lokad, non è gestita tramite bilanciatori di carico, ma tramite un orchestratore interno associato al nostro compiler stack.

2.6 Raggruppate risorse come connessioni DB, sessioni, ecc.?

Sì. Tuttavia, la piattaforma Lokad non si basa su un database transazionale per operare. Pertanto, non ci sono connessioni al DB da raggruppare. Ciononostante, raggruppiamo molte altre risorse, ogniqualvolta ciò abbia senso dal punto di vista delle prestazioni.

2.7 Supportate l’elaborazione parallela?

Sì. Envision (il nostro DSL) è progettato attorno al concetto di esecuzione automaticamente parallelizzata. La piattaforma Lokad sfrutta attivamente la parallelizzazione a più livelli: a livello di core CPU tramite operazioni SIMD (Single Instruction/Multiple Data); a livello di CPU attraverso esecuzioni multi-thread; e a livello di cluster tramite computing distribuito. Poiché l’elaborazione parallela è un aspetto fondamentale del design di Envision, la quasi totalità dei carichi di lavoro eseguiti sulla piattaforma Lokad beneficia di un’ampia parallelizzazione, per default, senza alcuno sforzo specifico da parte dei nostri clienti o dei nostri Supply Chain Scientist.

2.8 Supportate la cache dei dati a cui si accede frequentemente?

Sì. Tuttavia, la cache viene spesso introdotta come soluzione provvisoria per far fronte ai limiti di prestazione dei database transazionali. Dato che la piattaforma Lokad non include database transazionali, non utilizziamo la cache per questo scopo.

2.9 Comprimete i dati per ridurre il traffico di rete?

Sì, comprimiamo la maggior parte del traffico di rete. Tuttavia, non possiamo comprimerlo tutto in quanto ciò presenterebbe una vulnerabilità di sicurezza nota come BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH si verifica quando è presente una combinazione di 3 fattori.

1. Una risposta è compressa.

2. Una risposta contiene un segreto.

3. Una risposta contiene una stringa che può essere raccolta dall’attaccante che crea la richiesta.

Per difendersi da BREACH, Lokad disabilita la compressione su tutte le risposte in cui la terza condizione è verificata. Compriamo inoltre i dati per ragioni che vanno oltre la riduzione del traffico di rete; in primo luogo, per ridurre i costi di storage dei dati; e in secondo luogo, per ridurre i ritardi di computazione.

2.10 Effettuate test di prestazioni?

Sì. Lokad dispone di un’ampia infrastruttura di strumentazione automatizzata orientata alle prestazioni. Questa serie di strumenti ci consente di valutare, prima di ogni rilascio, il delta prestazionale della versione in arrivo rispetto a quella ottenuta con la versione attualmente distribuita. Questo strumento ci permette di riprodurre gli stessi carichi di lavoro, così come osservati in produzione, e di monitorare le prestazioni risultanti; non solo in termini di tempo reale, ma considerando tutte le risorse computazionali rilevanti (memoria, larghezza di banda, I/O, CPU, ecc.).

2.11 Monitorate le prestazioni a livello di transazione?

Sì. Tuttavia, poiché la piattaforma Lokad non utilizza un database transazionale, non ci sono “transazioni” da monitorare (nel senso tradizionale). L’equivalente più vicino è l’esecuzione degli script Envision. Per questi script, monitoriamo le prestazioni a un livello molto granulare, che è all’incirca analogo al monitorare in dettaglio l’esecuzione del piano di query (dal punto di vista di un database transazionale).

Consultate Autorizzazione 3.6 e Logging e Monitoraggio 5.3 nella nostra documentazione di Sicurezza per ulteriori informazioni sulle “transazioni” nella soluzione Lokad.

2.12 Qual è l’impatto sulle prestazioni di avere utenti concorrenti sulla soluzione?

Praticamente nessuno. Il design di Lokad garantisce che le dashboard possano essere servite in tempo costante anche per un gran numero di utenti (secondo gli standard B2B). Questo approccio è in netto contrasto con molte architetture alternative, in particolare i database transazionali e i cubi di Business Intelligence.

Tuttavia, dato che un singolo utente potrebbe (se in possesso dei privilegi di sistema appropriati) innescare carichi di lavoro arbitrariamente elevati, il numero di utenti concorrenti è, nella migliore delle ipotesi, una preoccupazione secondaria quando si tratta delle prestazioni della soluzione. Per quanto riguarda l’ottimizzazione predittiva della supply chain, i batch job utilizzati per eseguire le analisi di interesse rappresentano oltre il 99% del carico di lavoro. La rimanenza, inferiore all'1%, è dedicata a servire le richieste degli utenti.

2.13 Il sistema è progettato per scalare verticalmente e orizzontalmente?

Sì. Dal nostro punto di vista, la scalabilità verticale e orizzontale sono complementari, e il design della piattaforma Lokad sfrutta entrambe. L’orchestratore interno - quello responsabile della parallelizzazione - inizia tipicamente con la scalabilità verticale, poiché questa facilita in larga misura la colocalizzazione dei dati. Successivamente, l’orchestratore sfrutta la scalabilità orizzontale se il carico di lavoro è sufficientemente elevato da beneficiare dell’esecuzione su più macchine.

2.14 Scalate automaticamente il compute e lo storage secondo necessità?

Sì. La piattaforma Lokad è multi-tenant. Grazie alla multi-tenancy, realizziamo allocazioni su larga scala a bassa latenza delle risorse compute. Ciò significa che l’auto-scaling compute fornito da Lokad è di ordini di grandezza più veloce rispetto all’avvio di grandi VM (macchine virtuali) da un fornitore di cloud computing. L’auto-scaling dello storage è per lo più eseguito sfruttando le proprietà di auto-scaling del key-value store persistente, come fornito dalla piattaforma di cloud computing sottostante (Microsoft Azure).

2.15 Come gestisce la vostra applicazione i requisiti del “Big Data”?

La piattaforma Lokad è stata progettata specificamente per il processamento di “Big Data”. A partire da gennaio 2023, l’intera piattaforma Lokad gestisce circa 1 petabyte di dati su tutta la nostra base clienti. La nostra piattaforma può elaborare file individuali fino a 100GB, e elaboriamo regolarmente tabelle con decine di miliardi di righe. Vai a Sicurezza di Lokad 4.10

Questo punto è particolarmente tecnico e va oltre lo scopo di questo documento. Per una spiegazione approfondita, consigliamo la serie in 4 parti di Victor Nicollet sul design della Envision Virtual Machine.

2.16 La soluzione basata su cloud di Lokad può essere configurata tenendo conto di vincoli stringenti di larghezza di banda e latenza (dal lato cliente)? Ad esempio: larghezza di banda = 3Mbps (download) / 1Mbps (upload), latenza = 600-800ms

Sì, la webapp progettata da Lokad è stata ingegnerizzata per supportare scenari in cui la connettività è “scarsa” (sia in termini di larghezza di banda che di latenza). Queste problematiche vengono affrontate principalmente attraverso scelte fondamentali di design tecnologico. Queste scelte architetturali distinguono inoltre Lokad dal mainstream. Le problematiche relative alla larghezza di banda sono affrontate in due modi. Innanzitutto, siamo parsimoniosi per quanto riguarda i componenti di terze parti JavaScript. Abbiamo meno di 1MB di asset da recuperare inizialmente. In secondo luogo, la piattaforma offre il controllo completo sulla quantità di dati da includere in una qualsiasi dashboard. Pertanto, se la connettività è scarsa, è possibile rendere la dashboard opportunamente “leggera”. Per quanto riguarda le problematiche di latenza, le nostre dashboard sono state ingegnerizzate per raggruppare tutti i dati rilevanti della dashboard in un’unica richiesta HTTP. Questo minimizza l’attrito subito dagli utenti finali a bassa latenza.

2.17 Quali sono le capacità medie e di picco del throughput dei dati della soluzione, rispetto a un benchmark di 1 (basso) e 5 (alto) messaggi al secondo?

La piattaforma Lokad non opera con messaggi. Allo stesso modo, le interazioni con la piattaforma Lokad non avvengono tramite messaggi. Tuttavia, il throughput è importante per elaborare rapidamente vasti dataset di dati transazionali. La piattaforma Lokad gestisce, in totale, oltre 1 petabyte di dati. Gestiamo regolarmente oltre 1 terabyte al minuto per grandi batch di calcoli.

Un throughput molto elevato è importante per evitare ritardi operativi durante l’elaborazione di dataset molto grandi (decine di terabyte) con calcoli complessi che includono passaggi di machine learning e ottimizzazione matematica.

2.18 Quali dimensioni dei messaggi può gestire la soluzione? Fornire dettagli riguardo ai valori minimi, massimi e medi.

La piattaforma Lokad non opera con messaggi. La cosa più simile sarebbero i “flat files”. Questi flat files possono essere inviati a - e recuperati da - Lokad. La piattaforma Lokad può elaborare file che individualmente raggiungono dimensioni fino a 100GB. Tuttavia, questa non è una pratica raccomandata in quanto di solito risulta un po’ scomoda (non per Lokad, bensì per i clienti che dovranno familiarizzare con strumenti esterni per produrre e consumare i file di grandi dimensioni).

3. Incidenti

3.1 Qual è il processo per un cliente per segnalare un incidente?

La maggior parte dei nostri clienti beneficia di un pacchetto che include l’accesso al nostro team di Supply Chain Scientist. Questi Supply Chain Scientist sono il primo punto di contatto per la segnalazione degli incidenti. In caso di incidente, suggeriamo ai clienti di telefonare direttamente al proprio Supply Chain Scientist - se il problema è urgente - o di inviare una email. I Supply Chain Scientist si occupano della gestione degli incidenti, comprese eventuali escalation all’interno dell’organizzazione di Lokad.

3.2 Offrite un sistema di ticketing?

Sì. Lokad utilizza un sistema di ticketing di terze parti. Tuttavia, a partire da gennaio 2023, abbiamo iniziato a sviluppare una soluzione interna che offre un’integrazione stretta con il resto della nostra piattaforma.

3.3 Supportate la segnalazione degli incidenti a strumenti di terze parti?

Sì, a condizione che vi sia un accordo contrattuale dedicato.

Nel contesto dell’ottimizzazione predittiva del supply chain, gli “incidenti” possono variare ed essere difficili da definire. Generalmente, i nostri clienti non considerano gli eventi minori a livello di piattaforma (come brevi interruzioni) come “incidenti”. Piuttosto, le anomalie reali del supply chain - che possono o meno riflettere problemi con gli script Envision implementati nell’account del cliente - sarebbero candidati migliori. I dipartimenti IT esterni sono raramente coinvolti nella risoluzione di questi incidenti.

3.4 Come garantite un’alta disponibilità?

Lokad è diventata una delle prime ad adottare piattaforme di cloud computing (c. 2010) proprio per garantire una maggiore disponibilità. Oltre a rendere l’infrastruttura ridondante (vedi Incidenti 3.5), il design della soluzione di Lokad enfatizza fortemente la semplicità. In contrasto con soluzioni software aziendali comparabili, abbiamo significativamente meno dipendenze complesse (per quasi un ordine di grandezza). Un enorme livello di complessità assente dalla nostra soluzione è un database transazionale. Avendo meno componenti mobili, abbiamo molte meno modalità di fallimento, il che ci aiuta a mantenere un’alta disponibilità per i nostri clienti (che sono distribuiti su diversi fusi orari).

3.5 Avete un’infrastruttura ridondante (in caso affermativo, in che modo)? Evitate i punti di singolo fallimento?

Sì. I nostri sistemi critici sono ridondanti, proprio per evitare punti di singolo fallimento. I sistemi ridondanti includono i sottosistemi che supportano protocolli stateful come SFTP. Inoltre, l’archiviazione dei dati non è solo ridondante, ma anche geograficamente ridondante. Questa ridondanza viene sfruttata durante le nostre release per preservare il tempo di attività mentre il roll-out è in corso.

3.6 Come recuperate dai guasti hardware?

Il recupero dalla maggior parte dei guasti hardware è effettuato in modo trasparente dalla piattaforma di cloud computing che Lokad utilizza. La ridondanza integrata nella piattaforma Lokad assicura che i guasti hardware transitori non impattino il tempo di attività mentre la piattaforma di cloud computing rialloca una nuova risorsa non difettosa. Per l’archiviazione persistente dei dati, Lokad sfrutta solo servizi (cioè, key-value store) che sono essi stessi protetti contro i guasti hardware attraverso i propri livelli di ridondanza.

3.7 Avete un backup?

Sì. Abbiamo un ambiente di backup dedicato a scenari di disaster recovery severi (oltre ad un downtime a livello di data center). Questo ambiente di backup è completamente isolato dall’ambiente di produzione. L’ambiente di backup può leggere da quello di produzione (ma non scrivere), mentre l’ambiente di produzione non può né leggere né scrivere da quello di backup.

3.8 Avete un piano di disaster recovery?

Sì. A livello tecnico, il piano di disaster recovery copre la completa re-istanziazione della piattaforma Lokad. Questa parte sfrutta ampiamente i processi automatizzati che abbiamo in atto per le nostre release settimanali. A livello aziendale, il piano di disaster recovery prevede di contattare ogni cliente, solitamente seguendo un processo concordato con ciascuno. Per la maggior parte dei nostri clienti, i Supply Chain Scientist designati fungono da principali punti di contatto per la durata del recupero.

3.9 La soluzione supporta il recupero al punto nel tempo (PITR) per il database e per i dati esterni al database? Qual è il Recovery Point Objective (RPO) della soluzione?

La soluzione di Lokad presenta un design di protezione continua dei dati attraverso il backup incrementale in tempo reale sia del suo event store che della sua fonte di contenuti. Pertanto, possiamo effettuare il PITR per qualsiasi momento (fino al livello del minuto).

Abbiamo un RPO di 1 minuto per disastri a livello di data center - se i dati non sono compromessi. Raggiungiamo questo obiettivo sfruttando scritture geograficamente ridondanti del nostro key-value store persistente. Se il key-value store viene compromesso, Lokad si ripristina dal suo backup (mantenuto il più isolato possibile dai nostri sistemi di produzione), anch’esso ospitato in una diversa località geografica. In questo caso, abbiamo un RPO di 12 ore.

3.10 La soluzione è in grado di generare allarmi per violazioni di integrità? La soluzione ha la capacità di aggiungere o estendere controlli di integrità secondo le necessità?

Sì, sebbene questo tipo di problema rifletta principalmente un design software basato su un database transazionale. La piattaforma Lokad non opera con un database transazionale, ma con un event store, adottando un design basato sull’event sourcing anziché su uno relazionale. Questo non elimina la necessità di far rispettare l’integrità dei dati, ma tali preoccupazioni vengono gestite in modi alternativi.

Per quanto riguarda il trattamento dei dati dei clienti, Envision (il DSL di Lokad) ha ampie capacità orientate al controllo della qualità. Tramite Envision, è possibile verificare l’integrità e generare allarmi. Questa logica può essere estesa o modificata in qualsiasi modo ritenuto opportuno dal cliente.

3.11 I backup sono periodicamente testati per verificare la corretta funzionalità di ripristino dei dati?

Sì. Il design basato su event sourcing di Lokad, combinato con il suo content-addressable store, rende il test del backup e della funzionalità di ripristino dei dati molto più semplice rispetto alla maggior parte dei design mainstream che sfruttano database relazionali (come SQL).

Vedi anche Incidenti 3.7.

3.12 I piani di disaster recovery sono periodicamente testati per verificarne la corretta funzionalità?

Sì. La strategia di deployment di Lokad sfrutta script automatizzati end-to-end, riducendo deliberatamente al minimo gli interventi umani - con un’eccezione notevole rappresentata dalla possibilità di attivare un completo redeployment della produzione. Questo approccio fortemente automatizzato facilita il test della funzionalità di disaster recovery.

Vedi Incidenti 3.8.

3.13 Il recupero può essere eseguito per singoli clienti e/o ambienti dei clienti?

Sì. I nostri strumenti interni supportano la possibilità di ripristinare l’account di un cliente selezionato (incluso il ripristino dell’account/ambiente a un determinato punto nel tempo). Tuttavia, considerando che la piattaforma Lokad stessa presenta ampie capacità di versioning (ad es., gli script Envision sono versionati, e le versioni precedenti sono accessibili dall’interno dell’app), questa funzionalità viene raramente utilizzata.

3.14 I piani di backup e disaster recovery soddisfano gli obiettivi di RTO (Recovery Time Objective), RPO (Recovery Point Objective) e i requisiti degli scenari di disastro dei clienti (come definiti e concordati con i rispettivi clienti)?

Sì. Il Recovery Time Objective (RTO) si riferisce qui alla quantità di tempo in cui la piattaforma Lokad potrebbe essere teoricamente inattiva senza causare danni significativi al cliente, nonché al tempo impiegato per ripristinare la piattaforma e i suoi dati in modo che possa riprendere le normali operazioni dopo un incidente significativo.

L’RTO dipende molto dai dettagli dei processi specifici supportati/forniti da Lokad. Ad esempio, un cliente che si affida a Lokad per programmare ordini di acquisto mensili all’estero può avere un RTO di 1 settimana. Al contrario, un cliente che si affida a Lokad per ottimizzare la distribuzione giornaliera delle scorte da un magazzino a più punti vendita può avere un RTO di 1 ora.

In pratica, possono essere previste diverse contingenze tecniche per migliorare sostanzialmente l’RTO (cioè, ridurre il downtime teorico). Ad esempio, le failover decisions possono essere calcolate in anticipo. Queste decisioni possono essere utilizzate nel caso in cui la piattaforma Lokad non sia disponibile. Rispetto alle decisioni ottimizzate “regolari”, le failover decisions possono mostrare una performance del supply chain leggermente degradata, poiché (per definizione) non sfrutterebbero i dati assoluti e più recenti.

Per i nostri account gestiti, è responsabilità del Supply Chain Scientist di Lokad elaborare congiuntamente un processo - insieme ai team operativi del cliente - che garantisca un RTO elevato, ma anche che assicuri un impatto minimo sul business in caso di un incidente effettivo. Dal nostro punto di vista, questa sfida è innanzitutto un problema di supply chain piuttosto che IT.

Vedi anche Incidenti 3.9.

3.15 Se un difetto non è riproducibile nell’ambiente di test, può Lokad verificare che il difetto si sia verificato dai log e dai dati di supporto, oltre a garantire che il difetto sia corretto in conformità con il Service Level Agreement (SLA)?

Sì, i difetti possono essere riprodotti nei nostri ambienti. La stretta riproducibilità di tutti gli stati dei dati e di tutti i calcoli è un principio fondamentale del design della piattaforma e dell’architettura di Lokad. Ad esempio, il file system all’interno della piattaforma Lokad è interamente versionato (come Git), proprio per affrontare questa problematica.

Va notato che i log sono più efficaci per la risoluzione di problemi banali, come il downtime dei server. Quando si tratta di risolvere problemi complessi e difetti in un ambiente di dati su larga scala - dove sono coinvolti terabyte di dati - i log spesso non sono sufficienti.

Pertanto, mentre Lokad mantiene e consulta i log quando appropriato, non ci affidiamo ai log per affrontare i difetti o verificare che i difetti siano stati corretti. Invece, sfruttiamo principalmente scelte progettuali superiori per offrire maggiore visibilità, tracciabilità e riproducibilità.

Queste scelte progettuali deliberate ci consentono di identificare, riprodurre e correggere i difetti in un modo che affidarsi unicamente ai log non permetterebbe.

Si prega di consultare Architecture of Lokad per un’analisi dettagliata delle diverse scelte progettuali chiave che adottiamo per evitare intere classi di problemi software comuni.

3.16 Tenete traccia di tutte le richieste di servizio e delle chiamate di assistenza (inclusa la categoria di ciascuna chiamata) effettuate dalla società cliente? I record includono: l’identità della persona che chiama e della persona chiamata; la natura dell’errore, del problema o dell’incidente segnalato; il tempo di risposta di Lokad; l’esito della chiamata di assistenza; la risoluzione; i tempi di risoluzione; e la disponibilità del sistema?

Sì, la piattaforma di Lokad dispone di capacità di gestione di task/ticket/issue che forniscono i dettagli elencati.

Per quanto riguarda le “risoluzioni”, vale la pena notare che la filosofia del quantitative supply chain di Lokad (QSC) consiste nel trovare il compromesso finanziariamente più vantaggioso quando ci si trova di fronte a un problema. QSC non è, tecnicamente, un approccio di “problem fixing”, poiché i problemi del supply chain non sono quelli che si “risolvono” definitivamente, ma vengono attenuati attraverso compromessi finanziariamente consapevoli.

In breve, Lokad possiede gli strumenti e i processi per risolvere tempestivamente i “problemi facili” (come il downtime dei server) in maniera diretta. Per quanto riguarda i problemi di supply chain più grandi e rilevanti (come l’allocazione delle scorte al dettaglio o le questioni di replenishment dell’inventario), questi sono tipicamente discussioni più aperte e in corso con i clienti su quali compromessi massimizzano il loro ritorno sull’investimento.

4. Architettura

4.1 Quali linguaggi di programmazione utilizzate?

La piattaforma Lokad è sviluppata in C#, F# e TypeScript. La piattaforma include anche Envision (il DSL di Lokad), che viene utilizzato per implementare le soluzioni di supply chain specifiche per ciascun cliente.

4.2 Quale suite di sviluppo utilizzate?

I team di ingegneria software di Lokad utilizzano Microsoft Visual Studio. I team di Supply Chain Scientist utilizzano la piattaforma Lokad stessa, che dispone della propria suite di sviluppo.

4.3 Quali sistemi operativi supportate?

Lokad è una piattaforma basata sul web e supportiamo tutti i sistemi operativi che permettono l’accesso a un browser web moderno (es.: Firefox). Internamente, la piattaforma Lokad è compatibile sia con Linux che con Microsoft Windows, sebbene tutti i nostri sistemi di produzione siano distribuiti su Linux (Ubuntu).

4.4 Quale sistema di database utilizzate o supportate?

Lokad supporta tutti i sistemi di database che possono produrre esportazioni in flat file. Questo include praticamente tutti i sistemi di database del mercato, compresi i modelli più vecchi. Internamente, Lokad non utilizza un sistema di database, ma un key-value store. Al momento della stesura (gennaio 2023), utilizziamo Blob Storage fornito da Microsoft Azure.

4.5 Quale sistema di caching utilizzate?

Lokad ha progettato i propri sottosistemi di caching in C#/.NET. Questi sottosistemi sono strettamente integrati con il resto della soluzione e non rispecchiano i tradizionali sistemi di caching principalmente destinati a mitigare problemi di prestazioni con un database relazionale (che Lokad non possiede).

4.6 Come gestisce la soluzione i certificati?

Lokad sfrutta Let’s Encrypt tramite il rinnovo automatico dei certificati.

4.7 Quali sono i prerequisiti tecnici per utilizzare la soluzione?

Il principale prerequisito tecnico è un sistema di transazioni che tiene traccia dell’inventario. Inoltre, è utile se il cliente possiede esperienza nell’estrazione dei dati (come file flat) dai propri sistemi transazionali, ma questo certamente non è un requisito indispensabile.

4.8 Elenca eventuali ulteriori licenze di terze parti necessarie per operare la soluzione di Lokad (ad es., OS, SQL,…).

N/D. Lokad non richiede alcuna licenza di terze parti per operare. Esiste un’ampia gamma di strumenti open source per supportare l’integrazione di Lokad (cioè, file flat trasferiti tramite FTPS o SFTP); pertanto, non è necessaria alcuna licenza di terze parti, nemmeno indirettamente, per beneficiare della piattaforma di Lokad.

4.9 Il servizio richiede plug-in per il browser o software speciali?

Lokad è una webapp. Non richiede plug-in per il browser né software speciali.

4.10 Quali sono le interfacce in ingresso e in uscita dell’applicazione?

La soluzione di Lokad offre un’interfaccia web - accessibile tramite HTTPS - e protocolli per il trasferimento di file, ovvero SFTP e FTPS.

4.11 Come si garantisce che non si verifichino perdite di dati tra i tenant?

La soluzione di Lokad separa i dati dei tenant attraverso il suo design intrinseco, il quale garantisce che non si verifichino perdite di dati (nemmeno accidentali). Inoltre, tutto il codice rilasciato in produzione viene sottoposto a peer review, offrendo così un ulteriore livello di protezione. Infine, indirizziamo i ricercatori di sicurezza (persone che effettuano pentest) a indagare specificamente sulla possibilità di perdite di dati. Forniamo loro l’accesso a più account Lokad - in un ambiente dedicato e completamente isolato che rispecchia quello di produzione - affinché possano verificare in maniera approfondita questa caratteristica della nostra piattaforma.

4.12 La soluzione può essere containerizzata?

Sì, ma vi è scarso o nessun vantaggio nel containerizzare la piattaforma di Lokad. La containerizzazione apporta valore quando esistono dipendenze complesse (ad es., un database transazionale, un sistema di caching isolato, ecc.). Non utilizziamo container né in produzione né in sviluppo, il che migliora la nostra sicurezza eliminando intere classi di vulnerabilità. Invece, manteniamo la soluzione sufficientemente semplice affinché il deployment possa essere eseguito anche con piccoli script shell.

4.13 È possibile disaccoppiare i componenti GUI dal backend?

Sì, i componenti GUI (in questo caso, interfacce web) sono stand-alone. Questo design contribuisce a garantire una maggiore disponibilità. Gli utenti finali possono accedere ai loro cruscotti degli account Lokad anche se un’improvvisa interruzione interessa uno degli altri sottosistemi.

4.14 L’applicazione Lokad supporta funzioni di localizzazione (come il cambio della lingua)?

Sì, l’applicazione supporta funzioni di localizzazione. Tutte le interfacce utente prodotte dalla piattaforma di Lokad possono essere localizzate in qualsiasi lingua. In particolare, l’intero stack tecnologico adotta UTF-8, per ospitare tutti i set di caratteri esistenti al di là di quello latino. In particolare, ogni interfaccia utente prodotta dalla piattaforma di Lokad può essere re-localizzata - dopo la consegna - in un’altra lingua.

4.15 È possibile per gli utenti finali aggiornare o creare nuove traduzioni dopo la consegna dei dati post-processati da Lokad?

Sì, vedi quanto indicato al punto 4.14 sopra.

4.16 Il sistema dispone di un aiuto integrato? In tal caso, in quale/i lingua/e?

Sì, Lokad viene fornito con una documentazione pubblica molto estesa (in inglese). Tuttavia, l’utilizzo della piattaforma Lokad comporta la creazione di interfacce utente personalizzate e il nostro processo regolare prevede almeno due forme di documentazione o supporto.

Innanzitutto, i cruscotti realizzati all’interno della soluzione Lokad sono concepiti per essere documentati contestualmente - direttamente nel cruscotto stesso. In particolare, disponiamo persino di una scheda Markdown dedicata alla documentazione in formato rich text. In secondo luogo, i nostri deliverable includono un “Joint Procedure Manual”. Nel complesso, il manuale fornisce un’analisi dettagliata non solo della meccanica della soluzione, ma anche del motivo per cui ogni elemento è stato selezionato (e come esso soddisfi le specific supply chain needs del cliente).

4.17 La webapp è responsive?

La webapp di Lokad, insieme ai materiali di supporto (come la documentazione tecnica), è stata progettata per essere responsive. Tuttavia, alcune funzionalità avanzate, come la modifica del codice, risultano impraticabili per dispositivi mobili e/o tablet. Pertanto, il design è concepito per massimizzare la responsività per le attività previste, svolte su PC e dispositivi più piccoli.

4.18 Se il sistema è una webapp, quali browser e versioni supportate? Qual è lo standard minimo richiesto per i browser internet?

Lokad è una webapp e supporta i principali browser “evergreen” come Chrome, Firefox e Safari. Non tentiamo di supportare browser più vecchi per motivi di sicurezza, poiché supportare quei browser implica implicitamente un rischio per i nostri clienti. In altre parole, un browser vulnerabile può essere sfruttato da un attore malintenzionato per esfiltrare dati. Detto ciò, siamo anche abbastanza conservativi riguardo alle nuove funzionalità dei browser. In linea di massima, evitiamo di supportare funzionalità che non siano state adottate da tutti i principali browser per almeno un anno.

4.19 Per le applicazioni mobili e per tablet, quali sistemi operativi (e versioni) supporta Lokad?

N/D. Poiché Lokad è una webapp offerta come SaaS, i nostri clienti non sono preoccupati del supporto del sistema operativo. Internamente, Lokad viene sviluppato su Windows, mentre l’intero ambiente di produzione ospitato su cloud è basato su Linux. Pertanto, siamo abbastanza fiduciosi nella vasta portabilità della soluzione di Lokad. Anche se al momento non sentiamo alcuna necessità di cambiare questa configurazione, qualora emergessero prove valide, ci adatteremo di conseguenza.

4.20 La webapp di Lokad può fornire notifiche agli utenti finali? In tal caso, quale tecnologia/protocollo viene sfruttato?

Sì, Lokad ha la capacità di inviare notifiche attraverso hook HTTP programmabili. Questi hook possono essere sfruttati per utilizzare un sistema di terze parti, spesso già presente nella società cliente, per inviare una notifica via email o qualsiasi altro tipo di notifica ritenuta appropriata. Gli hook sono inoltre tipicamente impiegati per segnalare la disponibilità di dati da recuperare dalla piattaforma di Lokad tramite SFTP o FTPS.

4.21 Esistono elementi condivisi nella soluzione comuni a tutti i clienti (come funzioni di monitoraggio, backup o soluzioni di gestione patch, ecc.)?

Sì, poiché Lokad è un’app multi-tenant, le capacità a livello infrastrutturale sono condivise tra i tenant, ovvero gli account cliente. Ciò include il monitoraggio del tempo di attività, delle prestazioni e, per motivi di sicurezza, backup, gestione patch, aggiornamenti, ecc.

4.22 La soluzione permette funzionalità di messaggistica a destinazioni multiple (cioè, l’abilità di inviare un messaggio a più destinatari o applicazioni)?

La piattaforma di Lokad non opera mediante messaggi. Tuttavia, forniamo funzionalità di HTTP-hook che possono essere usate per generare notifiche messaggistiche arbitrariamente complesse, tipicamente tramite sistemi di terze parti a basso costo. Tali notifiche sono talvolta impiegate dai team di supply chain per monitorare il completamento tempestivo di batch di calcolo mission-critical sulla piattaforma di Lokad.

4.23 Tutti i sistemi e componenti critici utilizzano la medesima fonte temporale (NTP) oppure sincronizzano gli orologi in altro modo affidabile?

Sì. Lokad utilizza il servizio NTP predefinito fornito con Ubuntu - ntp.ubuntu.com. Più nello specifico, ntpd viene eseguito come servizio di sincronizzazione temporale, sincronizzandosi con una fonte di tempo NTP esterna accessibile via rete.

4.24 Esiste un inventario degli asset o un database di gestione della configurazione (CMDB)?

Sì, disponiamo di un software di gestione degli asset IT per supportare i nostri processi. Questa piattaforma ci aiuta a mantenere un inventario completo degli asset e funge da nostro database di gestione della configurazione (CMDB). Attraverso questo sistema possiamo monitorare, gestire e allocare in modo efficiente i beni hardware e software all’interno dell’organizzazione. I nostri team hanno la possibilità di identificare rapidamente lo stato, la posizione e la configurazione di ogni asset, garantendo risposte tempestive a cambiamenti, aggiornamenti o eventuali problematiche.

Inoltre, il nostro strumento offre funzionalità che consentono una gestione dettagliata del ciclo di vita, assicurando che gli asset siano catalogati con precisione dalla fase di approvvigionamento fino al fine vita. Le capacità di auditing automatizzato, unite a funzionalità di reporting dettagliate, garantiscono una completa visibilità e controllo sul nostro ambiente IT, facilitando la conformità e un’allocazione efficiente delle risorse.

4.25 Ogni connessione a una rete esterna viene terminata tramite un firewall (es. Internet, reti partner)?

No, non terminiamo ogni connessione a una rete esterna tramite un firewall, sia che si tratti di Internet o di reti partner. La nostra decisione si basa su considerazioni reali circa l’efficacia e le implicazioni di tali misure.

Dal nostro punto di vista, sebbene i firewall siano tipicamente considerati una difesa in prima linea, possono ironicamente espandere la superficie di attacco. Maggiore è il numero di componenti e sistemi integrati, maggiori sono i potenziali punti deboli che introduciamo. I firewall, per loro natura, operano come processi ad alto privilegio. Ciò significa che diventano obiettivi primari per attacchi informatici e, se compromessi, le conseguenze possono essere devastanti. Un esempio lampante è rappresentato dall’attacco SolarWinds, in cui i sistemi stessi destinati a proteggere le informazioni sono stati sfruttati, causando significative violazioni.

Inoltre, la presenza di firewall rigidi può risultare controproducente in senso pratico. La nostra esperienza ha dimostrato che tali sistemi spesso incentivano i dipendenti a cercare mezzi alternativi per accedere e condividere informazioni. Questo solitamente comporta il bypass totale della rete aziendale (impedendo ogni forma di monitoraggio), utilizzando connessioni personali 4G o 5G dai propri dispositivi. Queste pratiche aumentano involontariamente il rischio di violazioni della sicurezza e perdite di dati.

Pertanto, sebbene siamo fortemente impegnati nella sicurezza, il nostro approccio è olistico e guidato da considerazioni pratiche, piuttosto che dal ricorso esclusivo a misure tradizionali.

4.26 La rete dispone di un ambiente DMZ che trasmette, elabora o memorizza sistemi critici (come server web, DNS, servizi di directory e accesso remoto), nonché dati dei clienti?

No, Lokad non utilizza un ambiente DMZ tradizionale all’interno della nostra rete per trasmettere, elaborare o memorizzare sistemi critici e dati dei clienti. Invece, abbiamo adottato un approccio zero trust alla sicurezza della rete.

Questo modello non si basa sui DMZ, ma opera sul principio di “never trust, always verify.” Ogni richiesta di accesso viene convalidata e autenticata, indipendentemente dalla sua origine, sia essa interna o esterna all’organizzazione.

Ciò garantisce una postura di sicurezza più robusta e olistica, poiché non dipende da difese perimetrali come una DMZ, ma si concentra invece sulla protezione di ogni singolo punto di accesso e transazione dati. Riteniamo che l’approccio zero trust offra una protezione superiore per i nostri sistemi critici e per i dati dei clienti.