Ogni organizzazione che utilizza sistemi legacy si trova ad affrontare la stessa fondamentale dilemma. I sistemi sono troppo preziosi per essere abbandonati, troppo costosi da mantenere nello stato attuale e troppo rischiosi da sostituire in un colpo solo. I mainframe COBOL elaborano il 95% delle transazioni bancomat a livello globale. L'80% dei budget IT del governo federale statunitense è destinato alla manutenzione di sistemi che avrebbero dovuto essere modernizzati anni fa. I sistemi legacy non stanno fallendo, stanno avendo successo, ed è proprio questo che li rende così difficili da cambiare.
Il costo dell'inazione si accumula. Il debito tecnico cresce ogni anno che la modernizzazione viene rimandata. Le vulnerabilità di sicurezza si accumulano nei codebase che non ricevono più patch. L'integrazione con i sistemi moderni diventa più difficile man mano che si allarga il divario tra l'architettura legacy e i modelli cloud-native. E il bacino di sviluppatori che conoscono i linguaggi legacy si riduce con il pensionamento di coloro che li hanno creati. Le organizzazioni che hanno successo nella modernizzazione non sono quelle che aspettano che la pressione diventi insopportabile. Sono quelle che pianificano metodicamente, scelgono l'approccio giusto per ogni sistema ed eseguono in modo incrementale, invece di puntare l'intero programma su un'unica grande transizione.
Conosci a fondo il tuo portafoglio successorio
SMART TS XL Identifica gli elementi che possono essere dismessi prima che l'ambito della modernizzazione sia definito.
Maggiori InformazioniChe cos'è la modernizzazione dei sistemi legacy?
La modernizzazione dei sistemi legacy è il processo di trasformazione di sistemi software obsoleti, spesso monolitici, che richiedono un'elevata manutenzione e sono difficili da integrare, in architetture moderne, agili e scalabili. Non si tratta necessariamente di una sostituzione. La modernizzazione comprende una vasta gamma di approcci, dal trasferimento del codice esistente su un'infrastruttura cloud con modifiche minime, passando per il refactoring incrementale, fino alla completa riprogettazione o sostituzione con alternative moderne.
La differenza rispetto alla semplice manutenzione: la manutenzione mantiene un sistema in funzione così com'è. La modernizzazione, invece, ne modifica le capacità fondamentali, l'architettura o l'ambiente operativo per estenderne la durata utile, ridurre i costi operativi, consentire l'integrazione con sistemi moderni o preparare l'organizzazione allo sviluppo di capacità future, inclusi i carichi di lavoro di intelligenza artificiale.
Perché i sistemi legacy non possono aspettare indefinitamente
Diversi fattori convergenti stanno facendo sì che il costo del differimento sia più elevato nel 2026 rispetto a tre anni fa:
Preparazione all'IA. I carichi di lavoro di IA generativa mettono a nudo ogni debolezza del patrimonio dati aziendale, dalle fonti frammentate alle semantiche incoerenti, fino agli accessi non regolamentati, nel giro di poche settimane dall'implementazione pilota. Le organizzazioni non possono eseguire flussi di lavoro di IA efficaci su sistemi legacy isolati e non documentati. La modernizzazione è il prerequisito per essere all'altezza dell'era dell'IA.
Scarsità di talenti. Trovare sviluppatori per COBOL, PL/I e Java (un linguaggio vecchio di quindici anni) sta diventando davvero difficile. L'età media degli sviluppatori COBOL è ormai intorno ai cinquantacinque anni. Ogni anno di ritardo nell'ammodernamento riduce la finestra temporale per il trasferimento di conoscenze, prima che il sapere istituzionale vada perduto con chi lo detiene.
Rischi per la sicurezza. I sistemi legacy che non ricevono più patch di sicurezza dai fornitori accumulano vulnerabilità CVE non risolte. Più a lungo un sistema opera in questo stato, maggiore sarà la superficie di vulnerabilità nota.
Complessità di integrazione. Le moderne architetture basate su API, i microservizi e le piattaforme cloud-native presuppongono modelli di connettività che i monoliti tradizionali non supportano nativamente. Ogni nuova soluzione di integrazione contribuisce ad aumentare il debito tecnico, rendendo più difficile la successiva modernizzazione.
Le 7 R: il quadro di riferimento fondamentale per le decisioni di modernizzazione
Il framework delle 7 R, derivato dalle originali 5 R di Gartner e ampliato attraverso la prassi di settore, offre alle organizzazioni un metodo strutturato per decidere come gestire ciascuna applicazione presente nel loro parco sistemi. Il principio fondamentale è che non esiste un unico approccio valido per tutti i sistemi. Un programma di modernizzazione a livello di portfolio applica strategie diverse a sistemi diversi in base alla loro complessità, criticità aziendale e valore strategico.
| Online | Cosa significa | Quando usarlo | Cronologia tipica | Livello di rischio |
|---|---|---|---|---|
| Andare in pensione | Dismissione: il sistema non è più necessario. | Sistemi ridondanti, inutilizzati o completamente superati | Immediato | Basso |
| conservare | Mantenere la situazione attuale con modifiche minime. | Il sistema funziona, ma i costi di modernizzazione superano i benefici. | In corso | Basso |
| Riospitare | Migrazione al cloud senza modifiche al codice. | Carichi di lavoro non critici, risultati rapidi, riduzione dei costi infrastrutturali | 1 – 3 mesi | Basso |
| Ripiattaforma | Passare a modifiche mirate della piattaforma (ad esempio, database gestito) | È necessario un accoppiamento moderato, prestazioni specifiche o ottimizzazione dei costi | 2 – 6 mesi | Medio |
| Refactoring | Ristrutturare il codice senza modificare il comportamento esterno. | Riduzione del debito tecnico, miglioramento della manutenibilità, copertura dei test | 3 – 12 mesi | Medio |
| Riarchitettare | Riprogettazione per architetture cloud-native, microservizi o nuove architetture | Significativi requisiti di scalabilità, cambiamento strategico della piattaforma | 12 – 24 mesi | Alto |
| sostituire | Abbandona i sistemi personalizzati, adotta il SaaS o un'alternativa moderna. | Funzionalità standard meglio supportate dai prodotti esistenti | 6 – 18 mesi | Media altezza |
La decisione più importante in qualsiasi programma di modernizzazione è applicare questo framework in modo rigoroso, piuttosto che adottare per impostazione predefinita un'unica strategia valida per tutto. Le organizzazioni che applicano un approccio "lift-and-shift" a ogni cosa finiscono per avere bollette del cloud superiori ai costi del loro data center, senza la flessibilità che li giustificherebbe. Le organizzazioni che applicano un approccio "rearchitect" a ogni cosa finiscono per avere programmi pluriennali che generano valore troppo lentamente per mantenere il supporto degli stakeholder.
Gli otto approcci alla modernizzazione in dettaglio
1. Rehosting (Lift-and-Shift)
Il rehosting consiste nel trasferire un'applicazione in un ambiente cloud o in una moderna infrastruttura senza apportare modifiche al codice sorgente. L'applicazione viene eseguita su una piattaforma diversa, ma il suo comportamento rimane identico. Rappresenta la via più rapida per il cloud, quella con il minor rischio e la minore trasformazione.
Ideale per: applicazioni non critiche in cui l'obiettivo principale è la riduzione dei costi dell'infrastruttura, il consolidamento dei data center o la preparazione per una futura modernizzazione. Il rehosting viene spesso utilizzato come prima fase: si sposta il sistema sull'infrastruttura cloud e poi si procede con il refactoring in modo incrementale.
Cosa non risolve: debito tecnico, problemi di manutenibilità, complessità di integrazione o limitazioni architetturali. Il sistema viene eseguito nel cloud ma rimane architettonicamente invariato. Un monolite che era costoso da mantenere in locale, lo è ancora anche dopo la migrazione.
2. Ripiattaforma
Il replatforming apporta modifiche mirate alla piattaforma o all'ambiente di runtime per sfruttare i servizi cloud, senza ristrutturare l'architettura dell'applicazione. La migrazione da un database autogestito a un servizio di database gestito nel cloud, o da un application server autogestito a una piattaforma di container gestita, sono tipici esempi di operazioni di replatforming.
Ideale per: applicazioni in cui specifici componenti hanno chiari equivalenti cloud-native che riducono i costi operativi e in cui il costo e il rischio di una riprogettazione completa non sono giustificati dai benefici aziendali.
3. Refactoring
Il refactoring consiste nella ristrutturazione del codice esistente per migliorarne la qualità interna senza modificarne il comportamento esterno. Permette di affrontare il debito tecnico, migliorare la testabilità, ridurre la complessità e rendere il codice più facile da comprendere ed estendere. Non si tratta di una migrazione di piattaforma: il sistema continua a funzionare nello stesso ambiente prima e dopo l'intervento.
Il refactoring è l'approccio più appropriato quando: la funzionalità principale del sistema è solida e ancora necessaria, ma la sua struttura interna rende le modifiche lente e rischiose. Un programma COBOL con decenni di logica condizionale accumulata che svolge correttamente una funzione aziendale critica ma richiede giorni di attenta analisi prima di qualsiasi modifica è un candidato ideale per il refactoring.
4. Riprogettazione
La riprogettazione dell'architettura consiste nel ridefinire la struttura fondamentale dell'applicazione, scomponendo un monolite in microservizi, passando da una comunicazione sincrona a una basata sugli eventi e implementando modelli CQRS o di event sourcing. È la strategia che richiede il massimo impegno e offre il massimo rendimento se eseguita correttamente, ma anche la più rischiosa se eseguita in modo inadeguato.
La principale modalità di fallimento da tenere d'occhio è l'"antipattern del monolite distribuito": team che implementano nuovi servizi ma non riescono a disaccoppiare il livello dati, creando la complessità operativa dei microservizi con il forte accoppiamento di un monolite. Il pattern funziona quando i confini dei dati sono definiti chiaramente prima che i servizi vengano estratti.
Ideale per: Sistemi in cui i requisiti di scalabilità, resilienza o flessibilità architetturale non possono essere soddisfatti all'interno della struttura esistente e in cui l'organizzazione possiede la maturità ingegneristica necessaria per gestire sistemi distribuiti.
5. Il motivo del fico strangolatore
Il modello del fico strangolatore è un approccio di modernizzazione in cui le funzionalità esistenti di un sistema legacy vengono gradualmente sostituite con nuove applicazioni e servizi, fino a quando il nuovo sistema non sostituisce completamente tutte le parti vecchie o chiave del sistema legacy.
Anziché sostituire un sistema obsoleto in un'unica soluzione, le nuove funzionalità vengono sviluppate parallelamente al vecchio sistema, soppiantandolo gradualmente man mano che i componenti moderni ne prendono il controllo. Un livello proxy o di facciata instrada le richieste, inizialmente inviando tutto al sistema obsoleto e, progressivamente, instradandone un numero maggiore ai nuovi componenti man mano che questi vengono validati. Il sistema obsoleto viene "soffocato" gradualmente fino a quando non può essere dismesso in sicurezza.
Il percorso più rischioso: la migrazione "big bang". Costruire un sistema di sostituzione completo in modo isolato e poi passare a una nuova configurazione in un colpo solo ha un tasso di fallimento documentato elevato su scala aziendale.
Perché Strangler Fig è ora la soluzione consigliata di default per i sistemi mission-critical: elimina la principale causa di fallimento della modernizzazione dei sistemi legacy, ovvero il passaggio brusco e immediato. Ogni nuovo componente viene validato in produzione prima di essere dismesso. Il rollback è sempre possibile perché il sistema legacy continua a funzionare. La continuità operativa è garantita in ogni fase.
Applicazione pratica: un istituto finanziario che sta sostituendo il proprio sistema bancario centrale estrae la funzione di consultazione dei conti come primo nuovo servizio. Il nuovo servizio gestisce il traffico di consultazione, mentre il sistema legacy si occupa di tutto il resto. Una volta che il servizio è stabile, viene estratta la funzione successiva, l'avvio delle transazioni. Questo processo continua fino alla dismissione del sistema centrale legacy, senza tempi di inattività e con validazione continua in ogni fase.
6. Incapsulamento (wrapping) delle API
L'incapsulamento delle API crea un livello API moderno attorno a un sistema legacy senza modificarne il codice interno. I client esterni interagiscono con l'API moderna; quest'ultima traduce le richieste nell'interfaccia nativa del sistema legacy e trasforma le risposte in formati moderni. Il sistema legacy diventa un dettaglio di implementazione interno nascosto dietro un'interfaccia pulita.
Ideale per: Sistemi che devono rimanere in funzione a tempo indeterminato (a causa di requisiti normativi, costi o complessità) ma che necessitano di partecipare a moderni modelli di integrazione. Il wrapping delle API è il metodo utilizzato da molte organizzazioni per rendere i programmi COBOL accessibili alle moderne applicazioni web e mobile senza dover modificare il codice COBOL.
Limitazione: i limiti, le prestazioni, la scalabilità e la manutenibilità del sistema sottostante non vengono affrontati. L'incapsulamento delle API migliora l'integrazione senza migliorare il sistema che incapsula.
7. Ricostruire da zero
La ricostruzione prevede l'abbandono dell'implementazione esistente e la creazione di una nuova soluzione da zero, mirata ad architetture, linguaggi e piattaforme moderne. È appropriata quando il sistema esistente è effettivamente irreparabile dal punto di vista economico e quando i requisiti aziendali sono sufficientemente chiari da consentire di specificare con sicurezza la soluzione sostitutiva.
Il rischio: ogni organizzazione che ha tentato una ricostruzione completa e radicale di un sistema critico ha scoperto che il sistema esistente conteneva una logica aziendale non documentata che il nuovo sistema non replicava. La migrazione IT della banca britannica TSB nel 2018 ha lasciato 1.9 milioni di clienti bloccati fuori dai propri conti per settimane. Il progetto Virtual Case File dell'FBI è stato abbandonato dopo 170 milioni di dollari di sviluppo. La sostituzione del sistema di gestione delle paghe del Queensland Health ha comportato che 35,000 dipendenti ospedalieri ricevessero pagamenti in eccesso o in difetto per mesi. In ogni caso, la complessità del sistema esistente, le sue regole aziendali incorporate, i suoi casi limite, il suo comportamento operativo in condizioni mai esplicitamente specificate, superavano le conoscenze del team di sostituzione prima dell'inizio del progetto.
8. Modernizzazione assistita dall'intelligenza artificiale
La modernizzazione assistita dall'IA utilizza modelli linguistici di grandi dimensioni e strumenti di IA specializzati per accelerare le fasi più laboriose della modernizzazione dei sistemi legacy: comprensione del codice, generazione della documentazione, traduzione del codice e generazione dei test.
Gli strumenti di traduzione da COBOL a Java utilizzano modelli linguistici di apprendimento (LLM) ottimizzati per entrambi i linguaggi per produrre traduzioni iniziali di programmi COBOL, che vengono poi revisionate e perfezionate da ingegneri umani. La traduzione elimina la maggior parte dello sforzo di conversione meccanica, ma non elimina la necessità che un essere umano comprenda cosa dovrebbe fare il codice tradotto.
La generazione automatizzata della documentazione analizza il codice legacy per produrre una documentazione strutturata che descrive le funzioni di ciascun programma, le regole aziendali implementate, i dati letti e scritti e le condizioni in cui si verificano i salti condizionali. Questa documentazione è il prerequisito fondamentale affinché gli ingegneri possano convalidare il codice tradotto e affinché l'organizzazione possa preservare le conoscenze quando gli esperti di COBOL andranno in pensione.
La generazione di test utilizza l'intelligenza artificiale per produrre unit test per programmi legacy basati sull'analisi del loro comportamento di input/output, creando la copertura di test che non è mai stata scritta durante lo sviluppo originale e che è necessaria prima che qualsiasi refactoring possa essere eseguito in sicurezza.
Il limite critico della modernizzazione assistita dall'IA: gli strumenti di IA accelerano la conversione del codice, ma non eliminano la necessità di comprendere la logica aziendale implementata dal codice stesso. Un programma tradotto correttamente è comunque un fallimento se la traduzione è corretta ma le regole aziendali sono state fraintese. Gli strumenti di IA riducono il costo del lavoro meccanico, non quello della comprensione.
Scegliere l'approccio giusto: un quadro decisionale
L'approccio di modernizzazione più adatto a qualsiasi sistema dipende da quattro fattori valutati congiuntamente: criticità aziendale, complessità tecnica, valore strategico, budget disponibile e tempistiche.
| Profilo di sistema | Approccio consigliato |
|---|---|
| Bassa criticità aziendale, bassa complessità | Ritirarsi o ripubblicare |
| Elevata criticità aziendale, bassa complessità, fattore determinante dei costi infrastrutturali | Ripubblicare o ripiattaformare |
| Elevata criticità, complessità moderata, debito tecnico il problema principale | Ristrutturare in modo incrementale |
| Elevata criticità, elevata complessità, importanza cruciale per la missione, requisito di assenza di tempi di inattività. | Modello del fico strangolatore |
| Sistema strettamente legato a una piattaforma obsoleta | Riprogettare la piattaforma o riprogettare l'architettura |
| Funzionalità standard disponibili come SaaS | sostituire |
| Oltre alla riparazione economica, requisiti ben compresi | Ricostruire (con estrema cautela) |
| Ampio portfolio di linguaggi COBOL o legacy | Traduzione assistita dall'intelligenza artificiale + validazione umana |
L'errore più comune: applicare lo stesso approccio a ogni sistema del portfolio perché è più semplice da spiegare agli stakeholder. Un programma di modernizzazione che rimappa tutto, indipendentemente dalle caratteristiche del sistema, produrrà risultati che vanno da adeguati (per alcuni sistemi) a costi inutili (per sistemi che avrebbero dovuto essere dismessi) fino a una pericolosa semplificazione eccessiva (per sistemi che necessitavano effettivamente di una riprogettazione).
Sfide nella modernizzazione dei sistemi legacy: cosa fa deragliare i programmi?
Comprendere perché i programmi di modernizzazione falliscono è importante quanto comprendere gli approcci disponibili. I fallimenti sono sempre gli stessi:
Logica aziendale non documentata. I sistemi legacy contengono regole aziendali che non esistono da nessuna parte se non nel comportamento del codice. Un programma COBOL modificato da dodici sviluppatori in trent'anni codifica decisioni che non sono mai state documentate e che nessun membro del team in vita comprende appieno. Qualsiasi approccio di modernizzazione che non estragga e documenti questa logica prima di modificare il sistema rischia di produrre un nuovo sistema che si comporta in modo diverso da quello vecchio, in modi che vengono scoperti solo quando si verificano conseguenze aziendali.
Tentativi di transizione "big-bang". Le organizzazioni che falliscono più clamorosamente nei progetti di modernizzazione sono quelle che tentano di sostituire un intero sistema in una sola volta, con un passaggio immediato in una data specifica. Tutti i fallimenti di modernizzazione più noti e documentati, come quelli di TSB Bank, FBI VCF e Queensland Health, seguono questo schema. La modernizzazione incrementale, con validazione continua a ogni passo, è l'approccio vincente.
Ampliamento incontrollato dell'ambito del progetto e scoperte durante l'esecuzione. Il team di modernizzazione scopre complessità non visibili in fase di pianificazione. Un sistema che sembrava un'applicazione circoscritta si rivela condividere dati con altri venti sistemi tramite interfacce di file non documentate. Una funzione che appariva semplice si rivela implementare una regola aziendale la cui definizione ha richiesto tre mesi di negoziazioni normative e che non è documentata da nessuna parte. La soluzione è l'analisi strutturale prima della pianificazione, non la pianificazione senza analisi strutturale.
Rischio di concentrazione delle conoscenze. Le persone che conoscono meglio il sistema preesistente sono spesso quelle più vicine alla pensione. Quando lasciano l'azienda prima che le loro conoscenze siano state trasferite e documentate, il team di modernizzazione si trova a operare con una comprensione incompleta del funzionamento del sistema.
Misurare le cose sbagliate. I team che misurano il successo della modernizzazione in base alla percentuale di migrazione del codice o al rispetto delle tempistiche, anziché in base ai risultati aziendali, alla riduzione dei costi, all'affidabilità del servizio e al tempo di implementazione delle funzionalità, ottimizzano per le attività anziché per i risultati.
La valutazione che deve precedere qualsiasi decisione di approccio
La cosa più importante che un'organizzazione possa fare prima di scegliere un approccio di modernizzazione è capire con cosa ha a che fare. Una valutazione che si limiti alla revisione della documentazione e alle interviste agli sviluppatori è inadeguata per due motivi: la documentazione è incompleta e obsoleta, e le conoscenze degli sviluppatori sono distribuite, incoerenti e concentrate in persone che spesso non sono disponibili o sono prossime alla pensione.
Una valutazione strutturale, che analizza il codice sorgente effettivo di ogni applicazione in esame e costruisce un modello di dipendenza a partire da ciò che il codice effettivamente fa, fornisce la base di prove per ogni decisione successiva:
Inventario dei programmi. Quanti programmi esistono effettivamente, inclusi quelli non presenti nella documentazione. Negli ambienti legacy di grandi dimensioni, il numero effettivo in genere supera quello documentato del 20-30%.
Mappatura delle dipendenze. Quali programmi chiamano quali altri, quali condividono dati tramite file o database, quali job JCL invocano quali programmi e in quale sequenza. La struttura delle dipendenze determina la sequenza di migrazione: i componenti ad alto consumo di risorse, da cui dipendono molti altri, vengono migrati per ultimi.
Identificazione del codice morto. I programmi che non vengono mai richiamati da alcun percorso di esecuzione in produzione possono essere completamente esclusi dall'ambito della modernizzazione. Nei tipici portafogli legacy, il codice morto rappresenta il 10-25% dell'inventario totale, una riduzione significativa dell'ambito ottenibile già in fase di valutazione.
Classificazione della complessità. Quali programmi presentano la maggiore complessità ciclomica, il maggior numero di dipendenze dal copybook, il maggior numero di chiamate e il maggior numero di interazioni con il database? Questi sono i programmi che richiederanno il maggior impegno e comporteranno il maggior rischio, e dovrebbero essere affrontati per ultimi, dopo che il team avrà acquisito esperienza su componenti meno complessi.
Estrazione della logica di business. Quali decisioni implementa ciascun programma, in base alle quali si dirama, quali calcoli esegue. Questa documentazione costituisce la specifica rispetto alla quale il sistema modernizzato deve essere validato.
Come SMART TS XL Supporta la modernizzazione dei sistemi legacy
La valutazione strutturale descritta sopra è precisamente ciò che SMART TS XL automatizza. Analizzando simultaneamente ogni programma COBOL, flusso di job JCL, copybook, modulo PL/I, programma RPG, schema SQL e componente associato, costruisce il modello di dipendenza completo che rende la pianificazione della modernizzazione basata su dati concreti anziché su ipotesi.
L' analisi di modernizzazione dei sistemi legacy produce un inventario completo dei programmi, inclusi quelli non presenti nella documentazione, con una valutazione preliminare della complessità per ogni componente. La mappatura delle dipendenze dell'applicazione crea il grafo delle dipendenze tra i diversi linguaggi che determina la sequenza di migrazione: quali componenti possono essere modernizzati nelle prime fasi perché non dipendono da nulla e quali devono attendere che i loro dipendenti siano pronti.
La funzionalità di analisi d'impatto rende ogni modifica proposta consapevole del rischio prima dell'esecuzione: quando il team propone di modernizzare un copybook COBOL incluso in 300 programmi, l'analisi d'impatto elenca ognuno di questi 300 programmi, definisce l'ambito dell'attività di validazione e individua le dipendenze a più alto rischio prima che la modifica venga apportata.
La funzionalità di analisi statica del codice identifica codice inutilizzato, programmi e paragrafi privi di riferimenti in entrata da qualsiasi percorso di esecuzione in produzione, consentendo di escluderli dall'ambito della modernizzazione prima dell'inizio di qualsiasi lavoro di conversione. Per le organizzazioni che migrano al cloud, non migrare il codice inutilizzato è una delle fonti più dirette di riduzione dei costi ottenibili durante la fase di valutazione.
La funzionalità di ricerca aziendale rende il modello strutturale interrogabile durante un programma di modernizzazione pluriennale: trova ogni programma che legge da un dataset specifico, ogni copybook che definisce un campo specifico, ogni job JCL che richiama un programma specifico, in pochi secondi, attraverso milioni di righe di codice in qualsiasi combinazione di linguaggi.
SMART TS XL'S visualizzazione del codice Produce i diagrammi di dipendenza e i diagrammi di flusso del programma che rendono comprensibile la struttura di sistema non documentata all'intero team di modernizzazione, compresi gli ingegneri che non hanno mai visto COBOL e hanno bisogno di capire cosa fanno effettivamente i programmi che stanno sostituendo.
Modernizzazione incrementale: il principio alla base di ogni programma di successo
La costante più evidente riscontrata nei programmi di modernizzazione, sia quelli di successo che quelli fallimentari, è il ruolo dell'approccio incrementale. La migliore prassi: la modernizzazione incrementale, utilizzando il modello "strangler" o roadmap componibili, riduce il rischio migrando i carichi di lavoro un dominio o una funzionalità alla volta.
L'approccio incrementale non è sinonimo di timidezza. È il riconoscimento che la comprensione di un sistema complesso preesistente si sviluppa nel corso del processo di modernizzazione e che un programma strutturato per integrare tale comprensione in ogni fase porterà a decisioni migliori rispetto a un programma che concentra tutte le decisioni in una fase di pianificazione che necessariamente precede la piena comprensione del sistema.
I programmi di modernizzazione che raggiungono il ROI previsto sono quelli che definiscono il successo a livello di singola fase, in cui ogni fase fornisce componenti validati e pronti per la produzione, anziché a livello di programma, dove il successo viene definito solo al momento del passaggio definitivo. Ogni fase rafforza la fiducia organizzativa, fa emergere le complessità di integrazione prima che diventino ostacoli e dimostra che l'approccio scelto funziona nel contesto specifico dei sistemi e dei vincoli dell'organizzazione.
