Quando è l'ultima volta che avete fatto un audit sulla vostra infrastruttura? Non per aggiornarla o per pianificare un nuovo progetto, ma esclusivamente per valutare i costi sostenuti nel mantenerla operativa nelle condizioni attuali.
È una domanda che molti rimandano e che si trasforma in un costo, non presente in nessun bilancio ma che pesa ogni giorno sulla vostra organizzazione: il debito tecnologico.
Nei numeri precedenti di questa rubrica abbiamo seguito un filo preciso: abbiamo parlato di come:
la sicurezza sia prima di tutto una responsabilità di progettazione,
la continuità operativa sia una scelta, non una reazione all'imprevisto,
la governance dell'AI richieda strutture e non solo intenzioni
la dipendenza dai fornitori tecnologici sia un rischio che si costruisce nel tempo.
Oggi quel filo ci porta dentro l'infrastruttura stessa, nel punto in cui tutte queste variabili convergono e dove le decisioni non prese diventano il problema più concreto da gestire.
In questo nuovo articolo di Imagine a NEW PLAN esploriamo il debito tecnologico: cosa è, come si accumula, dove si nasconde e da dove conviene partire per cominciare a misurarlo davvero.
Buona lettura
La prima cosa da chiarire è che il debito tecnologico non è una questione tecnica (nel senso stretto del termine) e non è qualcosa che riguarda solo chi gestisce i server o supervisiona gli aggiornamenti. È il risultato accumulato di scelte architetturali prese in un contesto che non esiste più e di scelte non prese in un contesto che nel frattempo è cambiato.
L'immagine più onesta è quella di un immobile che funziona ancora ma ha l'impianto elettrico degli anni '90. Ci si vive, ci si lavora, e la maggior parte dei giorni non succede nulla. Ma ogni nuovo intervento è più complicato del precedente, ogni adeguamento richiede di aprire pareti che nessuno vuole aprire, e il rischio non sparisce perché non si guarda. Si sposta semplicemente in avanti, fino al momento in cui qualcosa cede o il costo di un aggiornamento risulta incompatibile con il budget disponibile.
Dal punto di vista della governance, il problema è ancora più specifico: ogni giorno in cui si sceglie di non intervenire è comunque una scelta e, come tale, ha conseguenze su affidabilità e capacità di risposta agli imprevisti. Decidere “di non decidere” non è una posizione neutrale ma una che accumula rischio e che sposta sulle persone, sul team IT e su chi presidia i sistemi, il peso di compensare quello che l'infrastruttura non riesce più a fare da sola.
Il debito tecnologico non si manifesta tutto insieme. Si distribuisce in modo diffuso, spesso in aree che sembrano stabili proprio perché nessuno le tocca da tempo.
Qui di seguito abbiamo identificato le quattro dimensioni in cui questo rischio tende a concentrarsi.
Scarica il PDF completo sulle 4 dimensioni.
| Dipendenze non documentate | Componenti fuori supporto |
|
Nei sistemi che hanno attraversato anni di integrazioni successive, le dipendenze tra componenti diventano opache.
Questa opacità è di per sé un rischio: non si può proteggere quello che non si riesce a mappare, e non si può pianificare la continuità operativa senza sapere cosa dipende da cosa. |
Hardware e software che hanno superato la fine del ciclo di vita del vendor non ricevono più patch di sicurezza. In molte organizzazioni esistono componenti in questo stato che gestiscono workload critici, tenuti in vita perché "funzionano" e perché sostituirli richiederebbe un progetto che nessuno ha tempo di avviare.
La criticità risiede sia nella vulnerabilità tecnica sia nel fatto che tali componenti risultano frequentemente non rilevati dai processi di audit e compliance, rappresentando così il primo punto debole sfruttato in caso di incidente. |
| Overhead umano strutturale | Incapacità di evoluzione |
|
Quando i sistemi non si integrano bene, sono le persone a compensare: diamo al via a procedure manuali decise sul momento, con esportazioni di dati tra un applicativo e l'altro, con controlli che dovrebbero essere automatici e invece richiedono presidio.
Questo overhead non appare come costo diretto e comporta un assorbimento della capacità operativa, introducendo inoltre potenziali margini di errore che potrebbero essere mitigati mediante l'utilizzo di un'infrastruttura più coerente. |
Un'infrastruttura caratterizzata da un elevato livello di indebitamento tende a mostrare resistenza ai cambiamenti, poiché il rischio di conseguenze impreviste risulta particolarmente elevato.
Di conseguenza, l'organizzazione rimanda le attività di migrazione e incontra difficoltà nell'implementazione di nuove soluzioni, se non previa revisione e ottimizzazione di quelle già esistenti. |
C'è un aspetto del debito tecnologico che lo rende particolarmente difficile da affrontare: come abbiamo detto è un costo che non trova una voce di bilancio. I suoi effetti però sono reali e si vedono nelle ore di lavoro extra allocate, in incidenti ricorrenti, in progetti che costano il doppio del previsto ma non si consolidano in un numero che qualcuno porta in un board meeting.
Questa invisibilità è anche il motivo per cui il problema si sposta sempre in avanti. Finché non c'è un'emergenza visibile, il debito tecnologico compete con altre priorità che hanno numeri più facili da argomentare.
Un esempio frequente è quello delle migrazioni cloud che partono con stime ottimistiche e si allungano di mesi: spesso non perché il progetto sia stato pianificato male, ma perché le dipendenze con i sistemi on-premise esistenti erano più complesse di quanto nessuno avesse mappato.
La conseguenza è che senza quella fotografia, ogni decisione di investimento tecnologico è parzialmente cieca. Si può scegliere la direzione giusta e comunque procedere più lentamente del necessario, con costi superiori al previsto, proprio perché manca la visibilità sul punto di partenza .
E qui vi lasciamo con una domanda per il prossimo confronto con il vostro team IT:
"Siamo in grado di stimare il costo reale -in ore, in rischio, in vincoli progettuali -di ogni componente critico della nostra infrastruttura?"
Se la risposta non è immediata, o non è condivisa, è già un'informazione rilevante.
Un infrastructure assessment non è qualcosa da fare prima di un grande progetto di migrazione. Consigliamo di farlo entrare nei vostri processi come una pratica periodica, con la stessa logica di una revisione contabile: non serve aspettare che qualcosa vada storto per avere un'immagine chiara dello stato delle cose.
Cosa significa? Non basta sapere quante macchine ci sono e quali versioni software girano ma serve:
mappare le dipendenze critiche tra i sistemi,
identificare i componenti fuori supporto e il rischio associato,
verificare la copertura di monitoring sulle aree più esposte
confrontare il Recovery Time Objective teorico - quello che compare nei documenti -con quello reale, cioè con il tempo effettivo che servirebbe per ripristinare i servizi critici in caso di incidente.
chi, all'interno dell'azienda, ha la responsabilità di garantire la continuità, la sicurezza e la capacità di intervenire tempestivamente quando si verificano malfunzionamenti.
dove si trova il debito,
quanto pesa
quali rischi porta con sé
Questa ultima verifica è spesso la più rivelatrice. Molte organizzazioni hanno un RTO dichiarato che non corrisponde alle capacità effettive dell'infrastruttura, non perché qualcuno abbia dichiarato il falso, ma perché nessuno l'ha mai testato in condizioni reali e nessuno ha aggiornato la stima quando l'infrastruttura è cambiata.
È esattamente da qui, ad esempio, che nasce Zero Time, il Disaster Recovery Assessment di Quanture: un'analisi dell'infrastruttura che determina RPO e RTO effettivi, restituendo un report chiaro sullo stato attuale della tua infrastruttura, fornendo una base concreta per progettare un piano di disaster recovery che sia realmente praticabile — non solo documentato.
L'obiettivo, in ogni caso, non è avere un'infrastruttura nuova. È avere un'infrastruttura conosciuta: documentata, monitorata, con responsabilità chiare su ogni strato e con una stima onesta di cosa succederebbe se qualcosa smettesse di funzionare.
Il debito tecnologico è una delle poche variabili di rischio che cresce nel tempo senza che nessuno abbia deciso di farlo crescere. Non richiede un incidente per diventare un problema serio: richiede solo che passi abbastanza tempo senza che qualcuno si faccia le domande giuste:
chi, all'interno dell'azienda, ha la responsabilità di garantire la continuità, la sicurezza e la capacità di intervenire tempestivamente quando si verificano malfunzionamenti?
dove si trova il debito?
quanto pesa?
quali rischi porta con sé?
Rispondere a queste domande non risolve il problema, ma è il presupposto per decisioni strategiche che ambiscono ad essere più di una semplice reazione a situazioni impreviste. Se la vostra organizzazione non dispone di una mappatura aggiornata dell'infrastruttura, o se l'ultima analisi risale a prima degli ultimi cambiamenti strutturali, questo è il momento opportuno per intervenire. La nostra esperienza ci porta a collaborare con aziende che si trovano spesso in questa fase, consentendoci di identificare le migliori modalità di avvio del percorso.
Vi invitiamo a contattarci per un primo confronto.
Imagine a NEW PLAN è la rubrica mensile di Quanture su tecnologia, governance e sostenibilità d'impresa. Tutti gli articoli sono disponibili su blog.quanture.com.