Un’infrastruttura aziendale cresce spesso per aggiunte successive. Un servizio risolve la posta, un altro la condivisione dei file, un apparato gestisce la rete e un portale raccoglie alcuni eventi. Ogni scelta può essere sensata nel momento in cui viene fatta. Con il tempo, però, diventa difficile ricostruire il quadro: chi amministra gli accessi, dove passano i dati e quale dipendenza sta impedendo alle persone di lavorare?
EDON nasce intorno a questa domanda. Il progetto distingue il governo dei servizi aziendali da quello della rete, rendendo più espliciti i ruoli, le integrazioni e le attività necessarie per mantenerli operativi.
Quattro lettere, un punto di partenza
EDON è l’anagramma di NODE. Il riferimento è a Node.js, il primo runtime su cui è stato costruito Atlas: l’ambiente che ne eseguiva il codice. Il nome conserva quindi una traccia concreta delle origini del progetto. Basta cambiare l’ordine di quattro lettere per passare dal nome di una tecnologia al nome di un ecosistema.
Questa origine ha qualcosa di familiare per chi costruisce software. Prima dei cataloghi, delle pagine prodotto e degli schemi di architettura, ci sono scelte pratiche: dove eseguire un programma, come far dialogare i suoi componenti, come trasformare un’idea in qualcosa che si possa usare. Nel nome EDON rimane il legame con quel livello del lavoro, dove un progetto prende forma attraverso il codice.
L’anagramma permette di portare con sé questa memoria senza chiedere a chi usa i prodotti di conoscere la tecnologia da cui deriva. Per un’azienda, il valore di Atlas si misura nelle attività che rende possibili: accedere ai documenti, gestire le identità, comunicare, recuperare una copia dei dati. Il nome ricorda il punto di partenza; i servizi raccontano a cosa serve il progetto oggi.
Da “node” all’idea di nodo
C’è anche una lettura del nome che va oltre la sua origine tecnica. In inglese, node significa “nodo”. Possiamo usarlo come immagine per descrivere l’infrastruttura: un punto in cui si incontrano persone, informazioni e servizi, collegato ad altri punti attraverso una rete.
Immaginiamo una normale mattina in azienda. Una persona accede con la propria identità, apre un file condiviso, consulta la posta e chiama un collega. Dietro gesti così quotidiani ci sono autorizzazioni, dati e comunicazioni che devono trovare il loro posto. Atlas riunisce questi servizi in un ambiente che l’organizzazione può amministrare. Visto da questa prospettiva, il nodo è il punto di incontro tra il lavoro delle persone e i sistemi che lo sostengono.
È una metafora utile anche per ricordare un limite: nessun nodo esiste da solo. Contano i collegamenti, le dipendenze e le responsabilità di chi lo gestisce. Un servizio ben organizzato deve avere accessi comprensibili, copie recuperabili e procedure di manutenzione. Il controllo dell’infrastruttura si costruisce anche in queste relazioni.
Un nome che accompagna l’ecosistema
L’origine del nome passa da Atlas; oggi EDON identifica un ecosistema con ambiti distinti. Atlas si occupa dei servizi aziendali e dei dispositivi. Argos governa rete, connessioni e sicurezza. Citadel offre a partner e clienti un punto di gestione centralizzata delle istanze autorizzate. EDON Client porta l’accesso ai servizi anche sui dispositivi degli utenti, compreso il telefono quando sono fuori sede.
Per capire il senso di questa distinzione, immaginiamo l’apertura di una nuova sede. Servono identità e strumenti di lavoro, collegamenti con le altre reti e persone autorizzate a intervenire sui sistemi. Sono esigenze collegate, ma richiedono decisioni diverse. Leggere l’insieme come un ecosistema aiuta a scegliere quali componenti adottare e a chiarire il ruolo di ciascuno.
Le quattro lettere restano un piccolo promemoria di questa storia: un nome nato da Node.js e da Atlas, che oggi accompagna un progetto più ampio. Chi incontra EDON può fermarsi ai servizi di cui ha bisogno oppure andare più a fondo nell’architettura. L’obiettivo è che, a ogni livello, sia possibile capire cosa si sta usando e mantenere il governo delle proprie scelte.
La frammentazione si vede durante un problema
Immagina che una persona non riesca più ad aprire un documento condiviso. La causa può riguardare il dispositivo, le credenziali, i permessi, il servizio file o il percorso di rete. Se ogni elemento è gestito separatamente, il tempo viene speso anche per trovare chi possiede le informazioni necessarie.
Lo stesso accade durante le modifiche pianificate. Cambiare una rete o aggiornare un servizio richiede di sapere chi lo utilizza, quali collegamenti servono e come verificare che il lavoro possa riprendere. Una visione delle responsabilità riduce l’ambiguità nella diagnosi e nella pianificazione; non elimina la necessità di competenze e procedure.
Atlas: governare i servizi e i dispositivi
Atlas è il nodo dei servizi aziendali: identità, posta, calendari, chat privata, telefonia, file e backup. L’obiettivo è rendere questi servizi parte di un ambiente amministrabile, collegando la gestione quotidiana alle esigenze dell’organizzazione.
Con più interfacce, Atlas può operare anche sulle reti IT e OT per attività come inventario e manutenzione di dispositivi remoti. Questo collegamento va progettato con accessi definiti: raggiungere un dispositivo per gestirlo non significa rendere indistintamente comunicanti tutte le reti a cui il nodo è connesso.
Argos: governare come comunica la rete
Argos si occupa di connettività, regole di rete, collegamenti tra sedi e visibilità sul traffico. Qui le domande sono quali comunicazioni autorizzare, quali priorità assegnare e quali eventi richiedano una verifica. Separare questo ambito dai servizi aiuta a individuare dove intervenire quando cambia una policy o un collegamento.
Atlas e Argos possono essere valutati insieme o integrati nel contesto esistente. La separazione dei ruoli non è, da sola, una garanzia di continuità: guasti, manutenzioni e recupero vanno analizzati per la configurazione effettiva, incluse le dipendenze condivise.
Il controllo comprende la privacy
Gestire internamente posta e file consente di scegliere dove conservarli, chi può accedervi e quali integrazioni esterne attivare. L’azienda non deve necessariamente affidare la gestione dei contenuti a una piattaforma esterna per disporre di servizi di comunicazione e collaborazione.
Questa scelta comporta responsabilità concrete. Occorre limitare gli accessi amministrativi, aggiornare i sistemi, verificare i backup e stabilire regole di conservazione. Per la rete, rispettare i contenuti cifrati è un confine utile; anche i metadati osservati richiedono una gestione attenta.
Un’adozione che parte dalle domande
Prima di scegliere una configurazione, individua i servizi essenziali, i gruppi di utenti e i dispositivi coinvolti. Stabilisci chi decide gli accessi, chi esegue la manutenzione e chi può avviare un recupero. Poi scegli una prima prova delimitata, con criteri di riuscita verificabili.
Per esempio, un progetto pilota può concentrarsi sulla condivisione dei file per un piccolo gruppo: autenticazione, permessi, accesso dai client e recupero di un documento cancellato. Un secondo passaggio può verificare il comportamento della rete durante una manutenzione prevista. I risultati aiutano a progettare l’adozione successiva senza affidarsi a promesse generiche.
Valutare la configurazione
Le capacità descritte vanno confrontate con la revisione e la configurazione che si intende usare; i requisiti software non sostituiscono un dimensionamento sul carico reale. Il progetto non presenta benchmark o livelli di servizio che non siano stati validati.
Le schede dei prodotti, l’architettura e la documentazione sono il punto di partenza per questa verifica. Governare l’infrastruttura significa anche poter spiegare cosa si è scelto, perché e come si interverrà quando qualcosa cambia.