Come misurare il debito tecnico: una guida per i CIO

Nel primo articolo abbiamo illustrato come Il debito tecnico consumi capacità futura di cambiamento dell’impresa; per questo deve entrare nei processi con cui CEO, CFO e CIO governano capitale, rischio e priorità di trasformazione.

Ma come capire quando il debito tecnico è troppo? Senza indicatori rigorosi che lo quantifichino, la ripartizione del capitale d’investimento avviene in un contesto di opacità decisionale. I CIO incontrano così significative difficoltà nel giustificare i budget di bonifica applicativa davanti ai Consigli di Amministrazione e ai CFO, i quali tendono ad assimilare tali richieste a semplici costi di manutenzione.

Misurare l’impatto economico del debito tecnico

Per superare questa stasi negoziale, occorre misurare l’impatto economico del codice obsoleto, adottare indici sintetici e individuare soglie analitiche oltre le quali la scelta strategica passa dalla manutenzione evolutiva alla sostituzione sistemica o alla migrazione su architetture di nuova generazione.

Prima di introdurre la metrica, è utile considerare la scala del fenomeno. Nel rapporto “Coding in the Red: The State of Global Technical Debt 2025“, pubblicato da CAST nel 2025, l’analisi di oltre 10 miliardi di righe di codice, 47.000 applicazioni e 3.000 aziende in 17 Paesi porta a stimare in 61 miliardi le giornate-sviluppatore necessarie per risanare il debito tecnico accumulato a livello globale. Per rendere più immediata la dimensione del dato, CAST osserva che, anche impiegando esclusivamente in questa attività l’intera forza lavoro mondiale degli sviluppatori – stimata in 25 milioni di professionisti – occorrerebbero circa nove anni per completare la bonifica del codice esistente.

Nel contesto internazionale, l’Italia registra un’intensità di debito tecnico particolarmente elevata, posizionandosi al secondo posto globale, immediatamente dietro agli Stati Uniti. Nello specifico, le applicazioni censite in Italia richiedono mediamente 1,99 giornate di lavoro di remediation ogni 1.000 righe di codice (LOC) analizzate, contro le 2,07 giornate rilevate negli Stati Uniti e le 1,98 in Francia.

Lo stesso report offre un’ulteriore scomposizione utile in sede di board: il 45% del codice mondiale è classificato come “fragile” (soggetto a rottura in condizioni impreviste), il 32% come “bloated” (cioè ridondante, con un impatto diretto sui costi di calcolo e sui consumi energetici) e il 31% come eccessivamente rigido, con effetti diretti sulla velocità di rilascio di nuove funzionalità.

Il Technical Debt Ratio e le soglie di decisione

La metrica più diffusa – anche se ancora poco utilizzata in pratica – per tradurre questi fenomeni in un numero decisionale è il Technical Debt Ratio (TDR), che mette in rapporto il costo necessario a sanare le criticità di un’applicazione con il costo di sviluppo ex-novo dell’applicazione, a pari copertura funzionale ma con tecnologie moderne e allo stato dell’arte:

TDR = (Costo di Remediation / Costo di Sviluppo del Sistema) × 100

Non è una misura di precisione contabile ma, nella pratica, è il modo più efficace per portare la qualità del software in una riunione con il CFO, in una forma che un CFO possa effettivamente comprendere e utilizzare.

Le soglie di TDR non sono uniformi e devono essere calibrate in base a criticità, rischio, costo del cambiamento e rilevanza strategica dell’applicazione. Alcuni contributi e modelli di settore utilizzano tuttavia due fasce come riferimenti orientativi per distinguere una situazione di allerta da una condizione in cui la sostituzione merita una valutazione prioritaria:

1. La fascia di allerta, tra il 20% e il 25%. Superata questa soglia, diversi studi di settore osservano un rallentamento sistemico della capacità di innovare: gli sviluppatori spostano una quota crescente del proprio tempo dalla costruzione di nuove funzionalità alla decifrazione e alla riparazione del codice esistente. L’IT smette, in questa fascia, di essere un generatore di valore per il business e diventa un collo di bottiglia nell’erogazione delle nuove funzionalità. Diventa prioritario allocare del budget dedicato esclusivamente alla riduzione del debito accumulato, per evitare l’aumento progressivo dei costi operativi, riportando il debito tecnico al di sotto della soglia “fisiologica” del 20%.
2. La soglia del 50%, come indicatore di criticità elevata. Un TDR prossimo o superiore al 50% segnala che il costo stimato della remediation è diventato particolarmente rilevante rispetto al costo di ricostruzione del sistema. Non costituisce una soglia universale né determina automaticamente la sostituzione dell’applicazione, ma giustifica una valutazione strutturata delle alternative: prosecuzione della manutenzione, rifattorizzazione, migrazione o sostituzione. La decisione deve considerare anche la criticità del sistema, il valore per il business, i rischi di migrazione e i requisiti di continuità operativa.

Vale la pena ribadire che le soglie suggerite hanno soprattutto una funzione orientativa: più che fissare automatismi, aiutano a strutturare il confronto tra le parti coinvolte e a portare a un livello di discussione condiviso segnali che altrimenti resterebbero impliciti. Sta poi a ciascuna organizzazione, in base al contesto specifico e alle proprie priorità strategiche, calarle nella pratica con la flessibilità che ogni decisione di questa rilevanza richiede.

I driver reali della modernizzazione in Italia

Fin qui abbiamo esaminato metriche e soglie del debito tecnico. Le motivazioni indicate dai CIO italiani mostrano ora come queste criticità si traducano nelle decisioni concrete di modernizzazione applicativa. Il confronto tra le rilevazioni 2024 e 2025 dell’Osservatorio Cloud Ecosystem & Sovereignty evidenzia un significativo cambiamento di priorità:

• Nel 2024 le prime tre motivazioni erano, in ordine: scarsa manutenibilità e fine del supporto vendor, limitata scalabilità, rigidità funzionale.
• Nel 2025 il podio cambia composizione: resta al primo posto l’obsolescenza tecnologica e la fine del supporto vendor, ma al secondo posto sale la rigidità funzionale e — soprattutto — al terzo posto entra la difficoltà a integrare tecnologie emergenti, in primis l’AI, che nel 2024 occupava solo la quinta posizione. Anche le criticità di sicurezza fanno il loro ingresso nella top cinque nel 2025, prima assenti dalle prime posizioni.

La modernizzazione applicativa non risponde più soltanto all’esigenza difensiva di garantire la continuità operativa e mantenere i sistemi entro i termini di supporto del vendor. In un solo anno è diventata sempre più anche una condizione abilitante per adottare l’AI e governare il rischio di sicurezza: due priorità ormai stabilmente presenti nell’agenda del board.

Una scorecard a quattro dimensioni

Per tradurre le metriche analitiche in indicazioni utilizzabili nella pianificazione pluriennale, la direzione IT può adottare una scheda di valutazione oggettiva (scorecard) strutturata su quattro dimensioni analitiche per ciascun sistema del portafoglio applicativo:

• Obsolescenza tecnologica e rischio di conformità. Valuta il livello di aggiornamento dei componenti software, la presenza di vulnerabilità note non risolte e lo stato del supporto formale garantito dai fornitori. Questa dimensione quantifica la probabilità di guasto e il livello di non-conformità rispetto alle direttive sulla resilienza operativa (quali DORA e NIS2) ed è in genere la componente più facile da quantificare oggettivamente.
• Scalabilità e flessibilità architetturale. Misura il grado di disaccoppiamento dei componenti, la presenza di architetture a servizi e la disponibilità di interfacce API standardizzate per l’integrazione con altri sistemi, inclusa oggi la capacità di esporre dati e funzioni ai modelli di AI, ragione per cui questa dimensione sta risalendo così rapidamente nelle priorità osservate.
• Costo operativo (run cost). Misura l’assorbimento delle risorse economiche e umane necessarie per il funzionamento ordinario dell’applicazione. Valuta sia la quota di tempo impiegata dalle strutture tecniche nella correzione dei difetti, sia l’inefficienza nell’uso delle risorse computazionali, in particolare delle risorse cloud.
• Aderenza funzionale ed impatto sul business. Valuta la distanza tra le prestazioni del sistema e le esigenze operative reali di dipendenti e clienti, misurata in ritardo di time-to-market per soddisfare le nuove esigenze evolutive o in frizione dell’esperienza d’uso da parte degli utenti interni ed esterni, vecchi e nuovi.

Dalla scorecard alle decisioni strategiche di portafoglio

L’integrazione tra i risultati della scorecard applicativa e il calcolo del TDR consente di collocare ciascuna applicazione nella matrice TIME (Tolerate, Invest, Migrate, Eliminate) proposta da Gartner.

Il framework valuta il portafoglio lungo due assi: il valore o l’aderenza funzionale per il business, cioè quanto il sistema sostiene processi, capacità e obiettivi aziendali, e il fit tecnico, che ne esprime qualità, manutenibilità, sicurezza, affidabilità e compatibilità con l’architettura target.

Dalla combinazione dei due punteggi derivano quattro indirizzi decisionali: investire nei sistemi ad alto valore e tecnicamente solidi; migrare quelli rilevanti per il business ma tecnicamente inadeguati; tollerare, con investimenti limitati, quelli tecnicamente accettabili ma a basso valore; eliminare le applicazioni deboli su entrambi gli assi.

L’applicazione di questa matrice consente di orientare le decisioni sulla base di parametri oggettivi condivisi tra la direzione tecnologica e le linee di business.

La scelta di dismettere o riprogettare un software cessa di essere percepita come un costo privo di ritorni e si trasforma in un’operazione di riallocazione del capitale, volta a ridurre l’onere finanziario d’esercizio e a liberare risorse per iniziative a maggior valore aggiunto.

Il TDR è un segnale utile, ma produce valore soltanto se viene letto insieme a criticità del sistema, costo del cambiamento, rischio, rilevanza strategica e risultati attesi. È questo il passaggio che trasforma una metrica tecnica in uno strumento manageriale: non basta sapere quanto debito tecnico è stato accumulato; occorre decidere quale quota tollerare, dove investire e quali sistemi sostituire. La qualità della misura, in ultima analisi, non sta nel numero che produce, ma nelle decisioni migliori che rende possibili.