Il debito tecnico non nasce solo dai grandi sistemi legacy, ma anche da tutte quelle soluzioni “temporanee” che creiamo ogni giorno per far funzionare i processi. In questo articolo alcune riflessioni su come nasce il debito tecnico invisibile e su cosa serve per governarlo prima che diventi il legacy del futuro.
Quando in WEGG ci confrontiamo con i referenti IT delle aziende, capita spesso di ascoltare la stessa storia, raccontata ogni volta con parole diverse.
Nel tempo i sistemi IT sono diventati sempre più complessi e stratificati, fino al punto in cui modificarli, integrarli o semplicemente farli evolvere richiede uno sforzo significativo. Applicazioni sviluppate anni fa continuano a sostenere servizi critici, con tutte le implicazioni in termini di sicurezza. Infrastrutture cresciute per accumulo e integrazioni fragili devono essere costantemente mantenute operative per garantire il corretto scambio dei dati.
Pensiamo, ad esempio, a sistemi di fatturazione basati su applicazioni custom, a ERP fortemente personalizzati o a integrazioni point-to-point che funzionano solo perché “nessuno le tocca”. In molti casi, la scelta apparentemente più prudente diventa proprio questa: non intervenire affatto.
Questa situazione ci richiama spesso alla mente la Centennial Light, la celebre lampadina installata nel 1901 nella caserma dei vigili del fuoco di Livermore-Pleasanton, in California, accesa quasi ininterrottamente da oltre un secolo. Nessuno osa spegnerla per timore che non si riaccenda più.
Un atteggiamento simile si riscontra anche nelle aziende, dove alcuni sistemi non vengono toccati non perché funzionino particolarmente bene, ma perché nessuno ne conosce davvero il funzionamento in modo approfondito. Si continua così a mantenerli in vita, spesso affidandosi a poche persone chiave o a fornitori storici, con l’unico obiettivo di “tenerli in piedi”.
In queste conversazioni emerge sempre anche un altro aspetto fondamentale: la manutenzione non crea valore.
È una spesa necessaria per garantire la continuità operativa, ma non genera vantaggio competitivo. Più cresce il debito tecnico, più il budget IT viene assorbito da attività come patch, aggiornamenti, gestione di incompatibilità e incidenti ricorrenti, riducendo lo spazio per iniziative realmente trasformative.
Non si tratta solo di una percezione. In molti settori una parte molto rilevante del budget IT viene assorbita dal mantenimento dell’esistente, lasciando poco margine per l’innovazione.
È questo l’aspetto più insidioso del debito tecnico: la perdita progressiva di flessibilità e velocità, che nel tempo riduce la capacità dell’organizzazione di restare competitiva. Non è un caso che anche l’adozione efficace dell’intelligenza artificiale dipenda in larga misura dalla qualità dei dati, dall’affidabilità delle integrazioni e dalla governabilità dell’ecosistema IT.
Quando parliamo di debito tecnico, però, tendiamo a pensare quasi esclusivamente ai grandi sistemi core: ERP, mainframe, applicazioni mission-critical. È il debito tecnico che conosciamo, quello che compare nei piani di modernizzazione e nei budget pluriennali, spesso associato a grandi programmi di trasformazione. Ed è vero: questo è debito tecnico.
Ma non è l’unico. Esiste anche un debito tecnico meno visibile, che nasce oggi, giorno dopo giorno, proprio nei punti in cui i processi non sono governati. È questo il legacy del futuro, quello che stiamo costruendo senza rendercene conto.
Per riempire un barattolo iniziamo inserendo dei sassi: rappresentano i grandi progetti di trasformazione, come le migrazioni al cloud, i programmi di modernizzazione applicativa o l’upgrade dei sistemi core, come SAP. Ma anche quando i sassi sembrano occupare tutto lo spazio disponibile, il barattolo non è mai davvero pieno.
Negli interstizi si infiltra la sabbia. È il debito tecnico che nasce da tutto ciò che non viene governato: un file Excel condiviso per gestire approvazioni, un database Access creato per tracciare richieste, uno script sviluppato “al volo” per automatizzare un passaggio operativo. Soluzioni che sembrano innocue, ma che nel tempo diventano indispensabili.
Questo fenomeno può essere definito personalismo tecnologico: situazioni in cui singole persone o team, mossi dalla buona volontà e dalla necessità di far funzionare le cose, colmano i vuoti dei processi con soluzioni provvisorie che finiscono per diventare strutturali.
È così che anche un semplice foglio Excel può trasformarsi in debito tecnico. Non per lo strumento in sé, ma per il ruolo che assume quando entra nei processi di business. Excel smette di essere un supporto individuale e diventa una piccola applicazione non dichiarata: contiene regole di business, logiche di calcolo, controlli impliciti spesso comprensibili solo a chi lo ha creato. Quando quella persona cambia ruolo o lascia l’azienda, la conoscenza incorporata nel file diventa difficile, se non impossibile, da recuperare.
A questo si aggiungono dipendenze operative e rischi di sicurezza: processi che funzionano solo con una certa versione del file, macro compatibili solo con specifiche release, assenza di controlli sugli accessi o di tracciabilità delle modifiche.
Il problema non è Excel in quanto tale, ma il fatto che viene utilizzato come componente strutturale di un processo di business senza le garanzie che normalmente associamo a un sistema IT governato.
È in questo contesto che nasce lo shadow IT, come risposta naturale del business all’esigenza di muoversi più velocemente di quanto l’IT tradizionale spesso riesca a fare. Questo debito tecnico invisibile porta con sé anche un debito manutentivo: quando è noto, drena risorse per gestire versioni e compatibilità; quando è ignoto, tende a manifestarsi nel momento meno opportuno, amplificando l’impatto degli incidenti.
Se il debito tecnico invisibile nasce perché le persone colmano autonomamente i vuoti dei processi, la risposta non può essere il semplice divieto. Bloccare strumenti, irrigidire i controlli o rallentare ulteriormente l’IT non elimina il problema: lo sposta soltanto altrove.
Serve invece un cambio di prospettiva. L’IT deve essere messo nelle condizioni di digitalizzare rapidamente quei passaggi operativi che oggi restano scoperti, prima che vengano risolti in modo informale e non governato. Ogni organizzazione convive con inevitabili vuoti di processo: integrazioni mancanti, flussi manuali, attività che esistono solo nella conoscenza delle persone. È proprio in questi spazi che nasce il debito tecnico invisibile.
Il punto, quindi, non è reprimere l’esigenza di velocità del business,ma intercettarla e governarla. Questo significa creare soluzioni leggere, digitali e integrate, capaci di evolvere nel tempo senza diventare nuovo legacy. Solo così è possibile conciliare rapidità operativa e controllo, evitando che le soluzioni temporanee di oggi diventino i vincoli strutturali di domani.
Quando emerge un nuovo bisogno digitale, le strade possibili sono sostanzialmente due: BUY o MAKE.
Se sul mercato esiste una soluzione che copre adeguatamente l’esigenza, il BUY è quasi sempre la scelta più sostenibile. Riduce il time-to-value, limita il rischio e sposta il focus dall’implementazione alla gestione del processo. È la strada che, quando percorribile, permette di evitare la creazione di nuovo debito tecnico fin dall’inizio.
Il problema nasce quando una soluzione pronta non esiste o quando il contesto aziendale è troppo specifico. In questi casi si ricorre al MAKE, spesso attraverso sviluppo custom. Ed è qui che entrano in gioco le complessità ben note dello sviluppo tradizionale: costi elevati, tempi lunghi, difficoltà di manutenzione e scarsa flessibilità nel tempo. Molte soluzioni nate per risolvere un’esigenza puntuale finiscono così per diventare, nel giro di pochi anni, nuovo legacy.
In WEGG, lavorando da anni sulla digitalizzazione dei processi, osserviamo come le piattaforme low-code possano rappresentare una risposta più sostenibile allo sviluppo tradizionale, soprattutto per colmare quei vuoti di processo che altrimenti verrebbero occupati da soluzioni informali e difficili da governare.
È però importante essere chiari: non tutte le piattaforme low-code sono uguali. Se adottate senza una visione di insieme, possono a loro volta generare frammentazione e nuovo debito tecnico, replicando gli stessi problemi che si vorrebbero risolvere.
Per ridurre davvero il debito tecnico invisibile, una piattaforma low-code non può limitarsi a velocizzare lo sviluppo. Deve essere progettata per il governo di una popolazione di applicazioni, non per la creazione rapida di soluzioni isolate. In concreto, questo significa adottare logiche enterprise che permettano di mantenere controllo, coerenza e sostenibilità nel tempo.
In particolare, una piattaforma low-code orientata al governo dovrebbe garantire:
Solo in questo modo il low-code può diventare uno strumento efficace per ridurre il debito tecnico, anziché un acceleratore di quello futuro. È con questo approccio che, nei nostri progetti di trasformazione digitale, adottiamo una piattaforma low-code enterprise come Mendix, che si caratterizza anche per la sua elevata integrabilità negli ambienti IT, convivendo e integrandosi anche in ecosistemi già strutturati come quelli di Microsoft e SAP.
Il vero cambio di paradigma è questo: non si tratta di scegliere tra velocità e controllo, ma di creare un ecosistema che permetta entrambe.
Il debito tecnico invisibile non nasce da scelte sbagliate, ma da esigenze reali affrontate senza una visione di governo. Riconoscerlo per tempo significa trasformare la velocità in un vantaggio competitivo, invece che in un vincolo strutturale.
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
