Modello TIME (Tollerare, Investire, Migrare, Eliminare) per i portfolio di app

La riunione di razionalizzazione delle applicazioni inizia alle 9:00. Entro le 11:00, il team ha classificato dodici delle quattrocento applicazioni in questione. Tre di queste dodici classificazioni sono già state contestate, riviste e contestate di nuovo. Il programma batch COBOL che gestisce le buste paga non è chiaramente da eliminare, ma è da tollerare o da investire? Il vecchio sistema di fatturazione, che tutti concordano essere tecnicamente inadeguato, è chiaramente da migrare, ma migrare verso cosa, e che fine faranno i diciassette programmi che ne dipendono? La riunione è programmata fino a mezzogiorno. A mezzogiorno, qualcuno suggerisce di continuare la settimana successiva. Entro il mese successivo, l'iniziativa ha silenziosamente cessato di produrre risultati.

Il modello TIME di Gartner è il framework di gestione del portfolio applicativo più utilizzato nell'IT aziendale. Classifica ogni applicazione del portfolio in una delle quattro categorie: Tollerare, Investire, Migrare, Eliminare, utilizzando due dimensioni di punteggio: valore aziendale e adeguatezza tecnica. Il framework è logicamente valido, ampiamente applicabile ed è citato come metodologia raccomandata dal CIO Council del governo federale statunitense nell'Application Rationalization Playbook. Tuttavia, nella pratica fallisce più spesso di quanto abbia successo, per una ragione che i suoi sostenitori menzionano ma raramente approfondiscono: le classificazioni sono valide solo nella misura in cui sono supportate da prove concrete. Senza prove strutturali, conteggi reali delle dipendenze, misurazioni reali della complessità e dati reali sul valore aziendale derivati ​​da tracce di esecuzione anziché da interviste ai responsabili, le classificazioni TIME diventano una questione di politica aziendale. Le discussioni sulla classificazione iniziano già con le categorie Migrare ed Eliminare, dove è in gioco l'applicazione preferita di qualcuno, e non si risolvono mai.

Il modello: due assi, quattro disposizioni

Il modello TIME rappresenta ogni applicazione su una matrice 2×2. L'asse orizzontale indica l'adeguatezza tecnica, ovvero quanto bene l'attuale implementazione tecnica dell'applicazione supporti la sua funzione prevista: qualità dell'architettura, manutenibilità, capacità di integrazione, livello di sicurezza, affidabilità operativa. L'asse verticale indica il valore aziendale, ovvero quanto la funzione dell'applicazione sia importante per le operazioni aziendali, la generazione di ricavi, la conformità normativa o gli obiettivi strategici dell'organizzazione.

	Elevata compatibilità tecnica	Adatto a bassa tecnologia
Elevato valore commerciale	INVESTIREFinanziatela. L'applicazione è strategicamente importante e tecnicamente valida. Investite per mantenerne la leadership.	MIGRAREL'azienda ne ha bisogno, la tecnologia è inadeguata. Bisogna sostituire la piattaforma, non la funzione.
Basso valore commerciale	TOLLERAREPer ora lascia perdere. L'applicazione funziona correttamente, ma non vale la pena investire altro.	ELIMINAREMettilo da parte. Ha poco valore, è di bassa qualità e non c'è motivo di conservarlo.

La semplicità è intenzionale. TIME non è progettato per produrre una pianificazione degli investimenti dettagliata, bensì per fornire decisioni direzionali inequivocabili per ogni applicazione nel portafoglio. Un'applicazione che non può essere chiaramente classificata è un'applicazione che richiede ulteriori informazioni prima che sia possibile classificarla.

I quattro modelli operativi a quadranti

Ogni disposizione TIME non è solo un'etichetta, ma un modello operativo che determina come l'organizzazione gestirà l'applicazione in futuro.

Investire: Estrazione del Valore Massimo

Le applicazioni Invest sono i gioielli della corona del portfolio: alto valore aziendale, elevata adeguatezza tecnica. Giustificano gli investimenti più consistenti in nuove funzionalità, ottimizzazione delle prestazioni, espansione dell'integrazione e mantenimento dell'aggiornamento tecnico. Un'applicazione Invest che non è aggiornata dal punto di vista tecnico, con un runtime obsoleto, una postura di sicurezza superata e un debito di dipendenza crescente, rischia di finire in fase di migrazione prima ancora che il problema venga rilevato.

Impegni operativi per Invest:

• Capacità ingegneristiche dedicate allo sviluppo di funzionalità e alla manutenzione tecnica.
• Patch di sicurezza e aggiornamenti di conformità prioritari
• Copertura da parte del comitato di revisione architettonica per ogni modifica significativa.
• Monitoraggio proattivo con obiettivi SLA al livello Tier 1

Migrazione: sostituire la piattaforma, preservare la funzionalità

La migrazione delle applicazioni svolge una funzione aziendale di cui l'organizzazione ha effettivamente bisogno, ma su una piattaforma tecnica ormai inadeguata, troppo costosa da mantenere, troppo fragile da estendere e troppo isolata dal moderno panorama di integrazione. Il valore aziendale giustifica l'investimento nella migrazione; lo stato tecnico, tuttavia, rende il proseguimento degli investimenti nella piattaforma attuale poco redditizio.

La predisposizione alla migrazione risponde a una domanda specifica: vale la pena preservare la funzione? In caso affermativo, si procede alla migrazione. La scelta della piattaforma e le modalità di migrazione sono decisioni separate che la classificazione TIME non prende, limitandosi a stabilire che la piattaforma attuale non è la soluzione adatta.

Lo scenario di migrazione più comune negli ambienti legacy è il seguente: un programma batch COBOL che implementa logica aziendale critica, calcoli normativi complessi, regole di prezzo proprietarie e logica fiscale specifica per giurisdizione, su una piattaforma che rende costoso estenderla, testarla e integrarla. La logica è insostituibile; il problema è la piattaforma. La migrazione verso una piattaforma moderna preserva la logica fornendo al contempo le caratteristiche operative richieste dall'azienda.

Tollerare: Inazione deliberata con una data di scadenza

Il quadrante "tolleranza" è il più frainteso. Non significa "questa applicazione va bene così", bensì "la qualità tecnica di questa applicazione non giustifica l'investimento necessario per modificarla ora, e il suo valore aziendale non giustifica la sua eliminazione". Si tratta di una scelta consapevole di accettare lo status quo per un periodo definito, non di un rinvio indefinito.

La categoria "Tolleranza" indica una sospensione temporanea, non uno stato permanente. Ogni applicazione nel quadrante "Tolleranza" dovrebbe avere una data di revisione esplicita, in genere dai 12 ai 18 mesi, e condizioni definite che ne attiverebbero una riclassificazione anticipata: una vulnerabilità di sicurezza non risolvibile con una patch, la dismissione di una dipendenza che impone un cambio di piattaforma, un aumento del valore aziendale che renda l'applicazione meritevole di investimento, o un cambiamento di funzione aziendale che ne elimini lo scopo.

Le organizzazioni che considerano la fase di "Tolleranza" come permanente accumulano esattamente il debito tecnico che il modello TIME è stato progettato per prevenire. Un programma COBOL classificato come "Tolleranza" nel 2019 e che si trova ancora nel quadrante "Tolleranza" nel 2026 ha ricevuto sette anni aggiuntivi di manutenzione differita che prima o poi dovrà ricevere, sia in caso di emergenza quando qualcosa si rompe, sia in caso di migrazione forzata quando la piattaforma non sarà più supportata.

Eliminare: la decisione che tutti prendono ma nessuno esegue

Eliminare è la classificazione più semplice e la decisione meno attuata. L'applicazione ha scarso valore commerciale e scarsa adeguatezza tecnica, non ci sono motivi per mantenerla. Ritirarla.

Il fallimento dell'esecuzione è ben documentato: il programma "Elimina" viene proposto con entusiasmo, ma quasi mai attuato. Una revisione del portafoglio condotta nel 2024 presso un grande istituto finanziario ha individuato 87 candidati all'eliminazione. Diciotto mesi dopo, 71 di questi erano ancora attivi. Il divario tra la classificazione e la dismissione è il momento in cui i programmi di razionalizzazione perdono slancio.

Tre ostacoli specifici impediscono l'esecuzione di Eliminate:

Dipendenze nascoste. L'applicazione è stata classificata come "Da eliminare" in base al suo apparente stato di autonomia. Dopo la classificazione, l'analisi strutturale rivela che dodici altri programmi producono output che l'applicazione da eliminare elabora, oppure che tre sistemi esterni le inviano dati tramite un'interfaccia di file non documentata. L'applicazione non è autonoma; costituisce l'infrastruttura nascosta per altri sistemi. La classificazione deve essere rivista.

Ostacoli alla migrazione dei dati. L'applicazione contiene dati che non possono essere distrutti, registri normativi con periodi di conservazione obbligatori, dati dei clienti che devono essere trasferiti a un sistema successore, registri storici delle transazioni che i processi di audit interrogano annualmente. La migrazione dei dati deve precedere la dismissione ed è costosa.

Obblighi normativi. Alcune applicazioni non possono essere dismesse nemmeno quando il loro valore aziendale è pari a zero, perché i quadri normativi richiedono le funzionalità che offrono. Un'applicazione di reporting che produce una presentazione trimestrale per le autorità di controllo ha un valore normativo che non emerge da alcuna analisi del valore aziendale. Finché l'obbligo normativo non viene trasferito a un altro sistema, l'applicazione deve rimanere in esecuzione.

Il problema delle prove: perché TIME fallisce senza dati strutturali

La modalità di fallimento più significativa nelle implementazioni TIME è quella che la documentazione di Catio identifica con precisione: le discussioni sul posizionamento iniziano con le opzioni "Migra" ed "Elimina", dove è in gioco l'applicazione preferita di qualcuno. Senza prove oggettive, ogni classificazione si trasforma in una negoziazione. Il responsabile dell'applicazione sostiene "Investi". Il team IT sostiene "Migra". Il team finanziario vuole "Elimina". La riunione si conclude con "Tollera" perché è la posizione meno controversa.

Le prove strutturali risolvono queste negoziazioni sostituendo l'opinione con la misurazione.

Ai fini della valutazione dell'adeguatezza tecnica, le prove che contano sono:

Indicatore di conformità tecnica	Fonte	Sposta la classificazione verso
Complessità ciclomica per programma (media)	Analisi del codice statico	Basso = migliore vestibilità, Alto = minore vestibilità
Percentuale di codice morto	Analisi di raggiungibilità	Codice morto elevato = minore adattabilità
Fan-in (conteggio delle dipendenze in entrata)	Mappatura delle dipendenze	Un elevato fan-in aumenta Tollerare rispetto a Eliminare
Condivisione del libro di testo ampiezza	Analisi della dipendenza COPY	Condivisione elevata = accoppiamento più elevato = minore adattamento
Tempo trascorso dall'ultimo cambiamento significativo	Registro di gestione delle modifiche/Git	Un lungo periodo di inattività può indicare un codice morto o problemi di stabilità.
Conteggio delle vulnerabilità di sicurezza	Scansione SAST	Conteggio elevato = minore adattabilità

Ai fini della valutazione del valore aziendale, le prove che contano sono:

Indicatore del valore aziendale	Fonte	Sposta la classificazione verso
Volume delle transazioni per periodo	Registri di esecuzione JCL, record dello scheduler	Volume elevato = valore più elevato
spartiacque a valle	Mappatura delle dipendenze	Un elevato numero di ramificazioni (fan-out) equivale a un valore più elevato (molti ne dipendono).
Indicatore di funzione regolatoria	Classificazione dei dati, registro di conformità	Presente = valore minimo garantito indipendentemente dagli altri punteggi
prossimità dei ricavi	Analisi del flusso di dati verso i sistemi di fatturazione/ricavo	Adiacenza diretta = valore più alto
Conteggio utenti o conteggio chiamate API	Registri di accesso, traffico di rete	Conteggio elevato = valore più alto

L'intuizione fondamentale: per i sistemi COBOL legacy, la maggior parte di questi indicatori non è disponibile tramite le voci del CMDB, le interviste ai responsabili delle applicazioni o l'analisi del traffico di rete. Sono invece disponibili tramite l'analisi strutturale del codice sorgente, i log di esecuzione e la pianificazione dei job JCL che documenta cosa viene effettivamente eseguito in produzione e quando.

Valutazione dell'idoneità tecnica per COBOL e sistemi legacy

I criteri standard di valutazione dell'idoneità tecnica, la compatibilità delle API, la predisposizione al cloud nativo, il supporto alla containerizzazione e l'architettura a microservizi sono irrilevanti per i programmi batch COBOL. Un programma COBOL non può essere containerizzato; la sua valutazione in base ai criteri cloud-native produce un punteggio di idoneità tecnica pari a zero per ogni programma legacy, il che non fornisce all'organizzazione alcuna informazione utile.

Per i sistemi COBOL e mainframe, il punteggio di idoneità tecnica richiede criteri specifici per COBOL:

Punteggio di complessità (peso: 30%): complessità ciclomica media tra i paragrafi e le sezioni del programma. I programmi con un CC medio inferiore a 10 hanno una complessità gestibile; i programmi superiori a 20 hanno una complessità strutturale che rende la manutenzione costosa e rischiosa.

Punteggio di manutenibilità (peso: 25%): Composto da percentuale di codice morto, ampiezza di condivisione dei copybook e tasso di duplicazione. Un programma con il 40% di codice morto, 15 copybook condivisi e una significativa duplicazione del codice ha una bassa manutenibilità, indipendentemente dalla sua correttezza funzionale.

Punteggio di rischio di dipendenza (peso: 20%): Conteggio delle dipendenze in entrata ponderato in base alla criticità delle dipendenze in entrata. Un programma con 50 dipendenze in entrata da programmi di Livello 1 presenta un elevato rischio di dipendenza; le modifiche a tale programma richiedono il coordinamento di 50 programmi a valle.

Punteggio di attualità (peso: 15%): attualità del dialetto COBOL e della versione del compilatore, modernità della sintassi JCL e interfaccia del database (SQL incorporato vintage, VSAM vs DB2, solo batch vs batch+CICS). I programmi scritti in sintassi COBOL-85 con SQL incorporato DB2 sono più attuali dei programmi scritti in COBOL-74 con accesso ai file solo tramite VSAM.

Punteggio di postura di sicurezza (peso: 10%): presenza di credenziali hardcoded, accesso ai file non protetto, assenza di controllo dello STATO DEL FILE ed esposizione a SQL injection nella costruzione dinamica di SQL.

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

Questa formula di punteggio produce un punteggio di conformità tecnica da 0 a 100, derivato dall'analisi del codice strutturale piuttosto che da una valutazione qualitativa. Due applicazioni con funzioni identiche ma caratteristiche strutturali diverse produrranno punteggi di conformità tecnica differenti, e tali punteggi rifletteranno accuratamente i diversi investimenti necessari per la manutenzione e l'ampliamento di ciascuna.

Il problema della deriva tollerabile: la governance per il quadrante di contenimento

Tolleranza è il quadrante in cui si accumula debito nel tempo in ogni organizzazione che utilizza TIME senza una governance esplicita di Tolleranza. Il meccanismo è semplice: un'applicazione entra in Tolleranza perché non vale la pena modificarla, poi vi rimane indefinitamente perché la sua modifica non è mai la priorità più urgente.

Una disciplina di governance tollerante impedisce il rinvio indefinito:

Fattori scatenanti della riclassificazione basata sulle condizioni:

• È stata identificata una vulnerabilità di sicurezza che non può essere corretta entro 30 giorni → valutare se migrare o eliminare
• Il fornitore annuncia la fine del ciclo di vita di un componente della piattaforma da cui dipende l'applicazione → revisione per Migrate
• Il punteggio di valore aziendale supera la soglia (nuovo requisito normativo, modifica del modello di business) → revisione per Investire o Migrare
• Il pensionamento per dipendenza impone una modifica dell'interfaccia → revisione per Migrare o Eliminare
• L'analisi del codice morto rivela che l'applicazione è effettivamente inattiva → revisione per eliminare

Frequenza di revisione basata sul tempo:

• Le domande vengono inserite in Tolerate con una data di revisione di 12 mesi
• Alla revisione a 12 mesi, la domanda viene esplicitamente riclassificata o esplicitamente ri-tollerata con una nuova data di 12 mesi
• La ri-tolleranza richiede una motivazione scritta che documenti perché le condizioni non sono cambiate
• Un'applicazione che è stata ri-tollerata più di due volte senza essere riclassificata fa scattare un'escalation al comitato di revisione dell'architettura

Il registro Tolerate: un elenco aggiornato di tutte le applicazioni Tolerate con la relativa data di classificazione, la data di revisione, il responsabile e l'insieme di condizioni che attiverebbero una riclassificazione. Questo registro viene esaminato a ogni riunione del comitato di revisione dell'architettura, non solo durante la revisione annuale del portfolio.

Rendere Eliminate eseguibile: colmare il divario nella dismissione

Il divario tra "classificato come da eliminare" e "smantellato con successo" è il punto in cui i programmi di razionalizzazione si bloccano. Colmare questo divario richiede di trattare ogni decisione di eliminazione come un progetto con ambito, dipendenze e criteri di successo definiti, e non come una conclusione.

La lista di controllo per l'esecuzione di Eliminate:

• Verifica delle dipendenze completata: L'analisi statica conferma l'assenza di dipendenze di produzione in entrata (non solo zero dipendenze documentate, ma zero verificate a livello strutturale).
• Piano di smaltimento dei dati approvato: Sono stati identificati i requisiti normativi in ​​materia di conservazione dei dati; il piano di migrazione o archiviazione dei dati è stato approvato dall'ufficio legale e di conformità.
• Notifica a valle completata: Il proprietario di ogni sistema consumatore è stato informato e ha confermato l'assenza di dipendenza attiva
• Verifica degli obblighi normativi completata: Non è richiesto alcun adempimento attivo di obblighi normativi, audit o conformità in relazione all'applicazione.
• Responsabile della disattivazione assegnato: Persona designata responsabile dell'esecuzione dello smantellamento, non solo della decisione di classificazione.
• Piano di ripristino definito: Procedura per il ripristino del servizio qualora la disattivazione riveli una dipendenza non rilevata
• Data di disattivazione stabilita: Una data precisa sul calendario IT, non "quando avremo tempo".

Fase di analisi strutturale: nessuna decisione di eliminazione procede alla pianificazione della dismissione finché un'analisi strutturale non conferma l'assenza di dipendenze in entrata dai percorsi di esecuzione in produzione. La causa più comune di errore nell'esecuzione dell'eliminazione è la scoperta di una dipendenza dopo l'annuncio della dismissione, che impone un ripristino. L'analisi delle dipendenze strutturali prima dell'annuncio previene questo problema.

Il ciclo di rivalutazione TIME

Le classificazioni temporali non sono permanenti. Il valore aziendale cambia con l'evolversi della strategia dell'organizzazione. L'adeguatezza tecnica varia a seconda che l'applicazione venga mantenuta, estesa o invecchiata. Il modello è un'istantanea; il portfolio richiede un quadro dinamico.

Rivalutazione annuale completa: ogni applicazione nel portfolio viene valutata in base ai criteri attuali di valore aziendale e adeguatezza tecnica. Le classificazioni che non sono cambiate per tre anni consecutivi vengono esaminate in modo specifico, per verificare se l'applicazione è effettivamente stabile (documentando il motivo) oppure se la valutazione non rileva i cambiamenti in atto.

Rivalutazione innescata da eventi specifici: determinati eventi attivano una revisione immediata della riclassificazione.

• Fusione o acquisizione (nuova combinazione di portafoglio)
• Modifiche normative che incidono sugli obblighi di conformità
• Annuncio della fine del supporto per una piattaforma importante (database, sistema operativo, runtime).
• Cambiamento significativo del modello di business (nuova linea di prodotti, uscita dal mercato, ristrutturazione organizzativa)
• Incidente di sicurezza relativo all'applicazione

Disciplina nel registro delle modifiche: ogni riclassificazione viene registrata con: classificazione precedente, nuova classificazione, data, prove che hanno motivato la modifica e responsabile dell'approvazione. La cronologia delle classificazioni di ogni applicazione costituisce la traccia di controllo che dimostra che il portfolio viene gestito attivamente anziché essere semplicemente categorizzato e dimenticato.

Come SMART TS XL Fornisce le prove per la classificazione TIME

Le decisioni di classificazione del modello TIME sono valide solo nella misura in cui lo sono le prove a supporto. Per le applicazioni moderne con copertura CMDB, monitoraggio API e architetture documentate, tali prove sono accessibili. Per i portfolio COBOL legacy in cui il CMDB è incompleto, i responsabili sono andati in pensione e la struttura delle dipendenze non è documentata, le prove devono provenire dall'analisi strutturale del codice stesso.

SMART TS XL'S analisi statica del codice Produce gli input di idoneità tecnica richiesti per la valutazione COBOL: complessità ciclomica per programma, percentuale di codice morto, rilevamento di pattern di sicurezza (credenziali hardcoded, accesso a file non protetti) e attualità del dialetto COBOL. Queste metriche sono derivate dal codice sorgente, non da stime degli sviluppatori, e non dipendono dalla capacità di qualcuno di ricordare cosa fa l'applicazione.

La mappatura delle dipendenze dell'applicazione produce i conteggi delle dipendenze in entrata che impediscono decisioni di eliminazione premature e i conteggi delle dipendenze in uscita che supportano la valutazione del valore aziendale. Un'applicazione con 45 dipendenze in entrata da programmi di produzione non è un candidato sicuro per l'eliminazione, indipendentemente da come il suo proprietario ne valuti il ​​valore aziendale. Il conteggio delle dipendenze è il dato strutturale che prevale sull'argomentazione di classificazione.

L' analisi di modernizzazione dei sistemi legacy produce un inventario del codice obsoleto che modifica le classificazioni: i programmi che appaiono nel CMDB come applicazioni attive ma non hanno dipendenze di produzione in entrata sono candidati a codice obsoleto, riclassificati da "Tollerare" a "Eliminare" sulla base di evidenze strutturali, non sulla valutazione del responsabile aziendale di un programma di cui potrebbe non aver mai saputo l'esistenza.

La capacità di analisi dell'impatto rende realizzabile la checklist di esecuzione di Eliminate: l'analisi strutturale che conferma l'assenza di dipendenze di produzione in entrata prima dell'inizio di qualsiasi pianificazione di dismissione. Questo è il punto di controllo che previene il fallimento più comune nell'esecuzione di Eliminate, ovvero la dipendenza non rilevata che emerge dopo l'annuncio.

La funzionalità di ricerca aziendale rende il processo di classificazione TIME interrogabile durante l'intero ciclo di rivalutazione: è possibile trovare ogni applicazione classificata come "Tollerare" con una data di revisione entro i prossimi 30 giorni, ogni applicazione classificata come "Eliminare" senza una data di dismissione assegnata, ogni applicazione con un punteggio di idoneità tecnica inferiore a 30 che è ancora classificata come "Investire". Queste interrogazioni rappresentano lo strumento di governance che mantiene il modello TIME uno strumento di gestione attivo, anziché un semplice esercizio di classificazione una tantum.

Un quadro di riferimento è valido solo nella misura in cui lo sono le prove a supporto.

La struttura a due assi del modello TIME è corretta. Il valore aziendale e l'adeguatezza tecnica sono le dimensioni giuste per le decisioni relative al portfolio applicativo. Le quattro disposizioni sono le opzioni giuste. Il problema non è il framework, ma la base di dati che le organizzazioni vi applicano.

Le classificazioni basate su dati di interviste e stime CMDB generano dibattiti organizzativi. Le classificazioni basate su analisi strutturali, complessità misurata, conteggio verificato delle dipendenze e adeguatezza tecnica derivata dal codice, producono decisioni difendibili. Il responsabile dell'applicazione che sostiene che il suo programma COBOL meriti un investimento piuttosto che una migrazione ha maggiori difficoltà quando l'analisi strutturale mostra una complessità ciclomica media di 35, il 40% di codice morto e 12 vulnerabilità di sicurezza. Il team IT che sostiene che un programma possa essere eliminato ha maggiori difficoltà quando l'analisi delle dipendenze mostra 45 dipendenze di produzione in entrata.

Il modello TIME funziona quando le prove lo confermano. L'analisi strutturale del portfolio applicativo è il modo in cui le organizzazioni raccolgono le prove a supporto delle applicazioni legacy che necessitano maggiormente di decisioni di razionalizzazione e che, con ogni probabilità, dispongono della documentazione necessaria a semplificare tali decisioni.