Premesse
Quando parlo con un cliente di “personalizzazione senza sviluppo”, spesso mi risponde citando qualche modulo di configurazione che il suo attuale gestionale già offre: un campo aggiuntivo qui, un’etichetta personalizzata là, una tabella di appoggio per una tendina nella maschera. È una personalizzazione di superficie, che non tocca il problema vero: cosa succede quando serve gestire un tipo di funzionalità mai previsto dal fornitore, o un processo specifico della propria azienda, con le proprie tabelle, i propri campi e le proprie regole di visibilità?
Nella maggior parte dei casi la risposta è un preventivo di sviluppo, giorni, settimane o mesi di attesa, e un costo che spesso scoraggia dal farlo di nuovo. Questo è il punto in cui si vede la differenza tra un software che ha tabelle di configurazione come funzionalità parziale, aggiunta sopra un’architettura tradizionale, e uno che ha il No-code come principio con cui è stato progettato fin dal primo giorno, a livello di database e di motore applicativo.
Cosa cambia, a livello di database, se il modello dati vive nella configurazione e non nel codice?
Cambia la struttura stessa dell’applicazione. In un’architettura tradizionale, ogni entità gestita – un asset, un locale, un contratto – corrisponde a una tabella fisica il cui schema è cablato nel codice dell’applicazione: aggiungere un campo richiede una migrazione di schema, una modifica al backend, una modifica al frontend, un rilascio. In un’architettura config-driven, esiste invece un livello di metadati – tabelle che descrivono altre tabelle, campi che descrivono altri campi, con tipo, formato, permessi e regole di visualizzazione – interrogato a runtime per costruire dinamicamente interfacce, validazioni e permessi.
Concretamente, questo significa che aggiungere una nuova categoria di asset, un nuovo processo o un nuovo cruscotto diventa un’operazione di inserimento di righe in tabelle di metadati, alla portata di un amministratore di sistema interno, non un progetto di sviluppo software che tocca schema del database, backend e frontend. Il fornitore non deve scrivere una riga di codice per far comparire una nuova entità gestita come una griglia interattiva, completa di filtri, permessi e azioni personalizzate.
Fino a che punto si estende, in pratica, questo principio in un sistema ben progettato?
Ben oltre la semplice tabella dati, se il principio è applicato con coerenza. I menu di navigazione, le azioni disponibili su ogni record – un’azione che apre un form, che aggiorna un campo, che invia un’email, che concatena più operazioni in sequenza – i tematismi con cui si colora una planimetria in base a un valore, i controlli con cui si valida un campo in base a una regola aziendale: tutto questo dovrebbe essere definibile da configurazione, non cablato nel codice dell’applicazione. È la differenza tra un prodotto con qualche parametro esposto e una vera piattaforma applicativa generica sopra cui si costruiscono soluzioni specifiche.
Perché questo approccio non è in contraddizione con sicurezza e prestazioni?
È un’obiezione tecnica legittima, che sento spesso: un sistema che genera dinamicamente interfacce e query a partire da metadati rischia di essere più lento o più esposto a errori rispetto a un sistema con schema fisso scritto a mano. In realtà l’esperienza dimostra che questo rischio si gestisce con le stesse tecniche usate in qualunque sistema enterprise ben progettato: permessi a livello di riga (Row-Level Security) e di singolo campo applicati in modo trasparente e centralizzato su ogni configurazione, così che ogni nuova entità erediti automaticamente le stesse regole di sicurezza senza doverle riscrivere; cache dei metadati, spesso multilivello, per non pagare il costo della flessibilità ad ogni singola richiesta, invalidata in modo esplicito quando la configurazione cambia; tolleranza a disallineamenti tra la configurazione e lo schema fisico del database, così che un campo di metadati che punta a una colonna non ancora creata non generi un errore fatale ma un comportamento controllato.
Un motore no-code ben progettato non è un generatore superficiale di moduli: è un sistema enterprise che applica sicurezza e ottimizzazioni una sola volta, in un unico punto architetturale, e le eredita automaticamente ogni nuova entità configurata sopra di esso.
Che tipo di query e di validazioni deve saper generare, tecnicamente, un motore di questo tipo?
Deve saper tradurre una configurazione dichiarativa – “questo campo è obbligatorio”, “questo campo è visibile solo a questo gruppo di utenti”, “questa colonna è una chiave esterna verso quella tabella” – in query SQL parametriche sicure, generate dinamicamente ma sempre protette da SQL injection, con filtri e ordinamenti applicati in modo coerente indipendentemente da quale entità viene interrogata. Deve inoltre gestire in modo trasparente le relazioni tra tabelle, incluse quelle con chiavi composte, per costruire automaticamente viste annidate o collegamenti drill-down senza che ogni nuova relazione richieda codice dedicato. È un livello di ingegneria non banale, che distingue un motore di configurazione robusto da un semplice generatore di form.
Quale impatto ha sul rapporto tra cliente e fornitore nel tempo?
Cambia radicalmente il tipo di dipendenza. In un sistema “a sviluppo”, ogni nuova esigenza genera un ticket, un preventivo, un’attesa: il cliente resta strutturalmente dipendente dai tempi e dalle priorità del fornitore, e ogni fornitore, per quanto onesto, ha un incentivo economico implicito a mantenere questa dipendenza. In un sistema config-driven, il cliente acquisisce autonomia reale: può adattare lo strumento alla propria organizzazione via via che cambia, senza dover rinegoziare ogni volta un intervento esterno. Questo non elimina il ruolo del fornitore, che resta prezioso per l’evoluzione della piattaforma e per la consulenza su come configurarla al meglio, ma sposta l’equilibrio da un rapporto di dipendenza a uno di collaborazione.
Come vivono questa differenza, concretamente, le diverse figure coinvolte?
Il proprietario la vive come una garanzia di controllo dei costi nel tempo: sa che l’evoluzione del sistema non genererà una sequenza infinita di preventivi di sviluppo. Il building manager la vive come autonomia operativa quotidiana: può rispondere lui stesso a una nuova esigenza organizzativa, senza aprire un ticket e aspettare settimane. Il responsabile IT la valuta soprattutto sul fronte della sostenibilità tecnica: vuole verificare che la flessibilità non comprometta le prestazioni del sistema quando il numero di entità configurate cresce, e che la sicurezza resti centralizzata e non delegata a controlli sparsi difficili da mantenere coerenti. La ditta esterna o il global service, infine, spesso trae vantaggio da questa flessibilità quando deve adattare lo stesso strumento a clienti diversi, ciascuno con le proprie convenzioni, senza dover richiedere personalizzazioni separate per ognuno.
Conclusioni
Il no-code non va valutato guardando quante caselle di personalizzazione un software mette a disposizione, ma chiedendosi se il modello dati e le regole di business vivono in configurazione fin dalla progettazione del database e del motore applicativo, con sicurezza e prestazioni garantite in modo centralizzato.
È una differenza che si vede solo nel tempo, quando arriva la prima esigenza che il fornitore non aveva previsto, e si scopre se lo strumento sa adattarsi da solo o richiede un nuovo progetto di sviluppo. Nel prossimo articolo vedremo come questo stesso principio si applica al passaggio, spesso sottovalutato, dal foglio Excel a un sistema che genera dati vivi come sottoprodotto del lavoro quotidiano.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui