Premesse
Ogni organizzazione, quando arriva a valutare un sistema di facility management, ha già una propria infrastruttura documentale in uso: chi si appoggia a uno storage cloud consolidato in azienda, chi mantiene ancora un archivio locale su server proprio, chi usa una combinazione delle due cose a seconda del tipo di documento.
La domanda tecnica interessante non è “dove salviamo i documenti”, ma “il nuovo sistema di facility management si adatta all’infrastruttura che abbiamo già, o ci obbliga silenziosamente a spostare tutto nel suo spazio proprietario?”.
Ho visto più di un’organizzazione scoprire, solo a implementazione avanzata, che il modulo documentale del proprio nuovo gestionale salvava tutto in uno storage del fornitore, non riscaricabile in blocco con la struttura originale, con l’effetto di aggiungere un ulteriore silo a quelli già esistenti invece di risolverli.
Come si progetta un sistema documentale che resti indifferente al provider di archiviazione sottostante?
Il principio architetturale corretto è l’astrazione: il modulo documentale dovrebbe parlare con un’interfaccia comune – carica, elenca, scarica, elimina – dietro la quale possono trovarsi provider molto diversi tra loro: uno storage locale su server aziendale, i principali servizi cloud ad ampia diffusione, o soluzioni di storage compatibili con lo standard S3, ormai un’interfaccia di fatto adottata anche da fornitori indipendenti dai grandi player.
Il resto dell’applicazione – allegati collegati a un intervento, foto caricate da mobile, documenti tecnici collegati a un asset – non dovrebbe mai sapere quale provider specifico sta effettivamente conservando quel file, perché quella scelta appartiene a un livello di configurazione interamente separato dalla logica applicativa.
Perché le credenziali di accesso al provider di storage non dovrebbero mai essere esposte al client?
Perché un client – un browser, un’applicazione mobile – è per sua natura un ambiente meno controllabile di un server: può essere ispezionato, il suo traffico intercettato, il suo codice decompilato. Se le credenziali di accesso allo storage cloud fossero incorporate o transitassero lato client, chiunque avesse accesso a quell’ambiente potrebbe potenzialmente accedere direttamente allo storage, bypassando ogni controllo applicativo di permesso.
Un’architettura corretta fa transitare ogni operazione di caricamento o download attraverso il backend, che detiene le credenziali del provider in modo sicuro e le usa per conto dell’utente solo dopo aver verificato che quell’utente abbia effettivamente il permesso di accedere a quel documento specifico, con il client che interagisce solo tramite un token di sessione applicativo, mai con le chiavi dello storage sottostante.
Come funziona una catena di fallback tra provider diversi, e perché è utile?
Un’organizzazione reale raramente ha una policy documentale uniforme al cento per cento: magari la maggior parte dei documenti va su un cloud aziendale, ma una specifica tabella o un caso d’uso particolare richiede di restare su storage locale per motivi di data residency.
Una catena di fallback gerarchica e configurabile – un override specifico per singola chiamata, che se assente ricade su una regola che forza il locale per quel contesto, che se assente ricade su un default configurato per quella tabella, che se assente ricade su un default di sistema, con lo storage locale come ultima rete di sicurezza sempre disponibile – permette di gestire questa eterogeneità senza dover scrivere logica applicativa dedicata per ogni eccezione, semplicemente componendo regole di priorità a livello di configurazione.
Come si affronta la migrazione di un archivio esistente da locale a cloud senza fermare l’operatività?
Migrare un archivio documentale accumulato in anni di attività – potenzialmente migliaia di file organizzati in una struttura di cartelle consolidata – verso un nuovo provider è un’operazione delicata, che non deve richiedere un’interruzione di servizio né il rischio di perdere la struttura organizzativa originale.
Un wizard di migrazione ben progettato preserva la stessa struttura ad albero nel nuovo provider, offrire un’anteprima preventiva di quanti file e quanti byte verranno spostati prima di avviare l’operazione, ed essere ripartibile in caso di interruzione: se la migrazione si interrompe a metà per un problema di rete, dovrebbe poter riprendere da dove si era fermata invece di dover ricominciare da capo o, peggio, duplicare i file già trasferiti.
Quali rischi di sicurezza comporta la gestione di download di documenti collegati a percorsi di file, e come si prevengono tecnicamente?
Un rischio tecnico classico, quando un sistema espone il download di documenti a partire da un percorso ricevuto come parametro, è l’attacco di path traversal: un utente malintenzionato che manipola il parametro del percorso per tentare di accedere a file al di fuori della cartella prevista, potenzialmente file di sistema o documenti di altri clienti nello stesso ambiente condiviso.
Una protezione tecnica solida normalizza sempre il percorso richiesto e verifica esplicitamente che resti contenuto entro la cartella autorizzata per quel contesto, respingendo qualunque tentativo di uscirne, indipendentemente da come il percorso malevolo sia stato codificato nella richiesta.
Che differenza fa, per il proprietario e per il responsabile IT, poter scegliere e cambiare provider senza dover riscrivere l’applicazione?
Per il proprietario, questa flessibilità si traduce in libertà negoziale: può scegliere il provider di storage in base a criteri propri – costo, localizzazione dei dati, accordi già in essere con altri fornitori IT – senza che questa scelta sia vincolata dal fornitore del software di facility management.
Per il responsabile IT, significa poter far rientrare la gestione documentale del FM nella stessa policy di sicurezza e di data residency già adottata per il resto dell’infrastruttura aziendale, invece di dover gestire un’eccezione isolata con regole proprie solo perché un fornitore ha deciso di imporre il proprio storage proprietario.
Come vivono questa flessibilità il building manager e la ditta esterna nel lavoro quotidiano?
Il building manager, che spesso deve allegare rapidamente un documento a un intervento o a un asset – un certificato, una foto, un manuale tecnico – beneficia di un’esperienza uniforme indipendentemente da dove il documento venga effettivamente conservato, senza dover conoscere i dettagli tecnici del provider sottostante.
La ditta esterna o il global service, che spesso lavora su più clienti con policy documentali diverse tra loro, trae vantaggio da un sistema che si adatta al provider già scelto da ciascun cliente, invece di dover imporre a tutti la propria infrastruttura preferita o duplicare i documenti tra sistemi diversi per ogni commessa.
Conclusioni
Un sistema documentale ben progettato non impone un provider: si adatta a quello che l’organizzazione ha già, con credenziali sempre gestite lato server, una catena di fallback configurabile per gestire eccezioni, un percorso di migrazione sicuro e ripartibile, e protezioni tecniche solide contro gli errori più comuni di gestione dei file.
È un ulteriore tassello del principio di apertura che attraversa tutta questa serie: la libertà del cliente non si misura solo nei formati dei disegni tecnici, ma anche in dove e come vengono conservati i suoi documenti. Nel prossimo articolo affrontiamo un tema complementare: come la guida e la documentazione d’uso del sistema stesso possano vivere dentro l’interfaccia, invece che in un manuale separato che nessuno consulta davvero.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui