Modernizzare il sistema che nessuno osa toccare, una funzionalità alla volta.
Decenni di regole di business vivono in COBOL, PL/I, Oracle Forms e nelle prime versioni di Java e .NET. Recuperiamo quelle regole, costruiamo una rete di sicurezza fatta di test e migriamo funzionalità per funzionalità dietro una facciata, con esecuzioni in parallelo e riconciliazione prima di spegnere qualsiasi cosa.
Per enti e imprese che dipendono da applicazioni storiche, spesso nate prima del web, e non possono permettersi né un fermo né un salto nel buio.
04Ricostruire una porzione dietro una facciataSistema
05Esecuzione in parallelo e riconciliazioneSistema
06Analisi delle discrepanzePersona
07Passaggio e dismissionePersona
Si valuta il portafoglio applicativo e si concorda l’architettura di destinazione. Le regole di business vengono recuperate dal codice con l’aiuto dell’IA e verificate da persone. I test di caratterizzazione formano una rete di sicurezza. Ogni funzionalità viene ricostruita dietro una facciata ed eseguita in parallelo con il vecchio sistema; le discrepanze vengono analizzate e corrette prima che il responsabile di business approvi il passaggio e la vecchia parte venga dismessa.
Prima e dopo
Che cosa cambia nel modo di lavorare
Oggi
Con il sistema
Oggi
Oggi: Ogni modifica è un rischio
Piccoli adeguamenti normativi richiedono mesi, perché nessuno sa prevedere che cos’altro una modifica andrà a toccare.
Con il sistema
Con il sistema: Modifiche sostenute dai test
I test di caratterizzazione fotografano ciò che il sistema fa oggi, così ogni modifica mostra il suo effetto prima del rilascio.
Oggi
Oggi: Le competenze vanno in pensione
Le persone che conoscono il codice sono vicine alla pensione, e la documentazione ha smesso da tempo di corrispondere al sistema.
Con il sistema
Con il sistema: Regole scritte e verificate
Le regole di business recuperate dal codice vengono documentate in linguaggio chiaro e confermate dagli esperti di dominio.
Oggi
Oggi: I piani «big bang» si arenano
I programmi di sostituzione integrale promettono un’unica data di passaggio che continua a slittare mentre i costi crescono.
Con il sistema
Con il sistema: Valore rilasciato per porzioni
Le funzionalità migrano una alla volta dietro una facciata. Ogni porzione entra in esercizio da sola e può essere annullata.
Oggi
Oggi: Dati imprigionati in vecchie strutture
Nuovi servizi e casi d’uso di IA non riescono a raggiungere i dati senza estrazioni fragili ed elaborazioni batch notturne.
Con il sistema
Con il sistema: Dati disponibili tramite API
I domini migrati espongono i propri dati tramite API documentate, riconciliate con il vecchio sistema fino alla sua dismissione.
Flusso di lavoro
Come funziona il flusso di lavoro
Un approccio strangler fig: il nuovo sistema cresce attorno al vecchio, funzionalità dopo funzionalità. Il ciclo tra esecuzione in parallelo e ricostruzione è dove si concentra la maggior parte del lavoro reale.
Flusso di lavoro illustrativo
7 passi · 3 controlli umani
Legenda
Sistema
Agente
Persona
Controllo umano
Percorso di eccezione
Modernizzazione dei sistemi legacy: flusso illustrativo con ciclo di riconciliazione
Leggere il diagramma in forma testuale
Il percorso principale va dalla valutazione del portafoglio e dal recupero delle regole di business, attraverso la costruzione di una rete di sicurezza di test di caratterizzazione e la ricostruzione di una funzionalità dietro una facciata, fino all’esecuzione in parallelo di vecchio e nuovo e infine al passaggio e alla dismissione della vecchia parte.
Le persone approvano l’architettura di destinazione, verificano ogni regola recuperata e approvano ogni passaggio: sono questi i punti di controllo umano.
Quando l’esecuzione in parallelo mostra output diversi, la porzione lascia il percorso principale per l’analisi da parte di ingegneri ed esperti di dominio e torna alla fase di ricostruzione finché vecchio e nuovo non coincidono.
01
Passo 1: Valutare il portafoglioPersona
Inventario applicativo, mappatura delle dipendenze e dei flussi di dati, e una decisione per ogni applicazione: dismettere, mantenere, rehost, replatform, ricostruire o sostituire. I domini vengono mappati per individuare i punti in cui è possibile suddividere il sistema.
Controllo umano
Il Suo comitato di architettura approva l’architettura di destinazione e l’ordine delle porzioni.
02
Passo 2: Recuperare le regole di businessAgente
La comprensione del codice assistita dall’IA legge COBOL, PL/I, JCL, Oracle Forms e versioni meno recenti di Java o .NET, e produce bozze di documentazione, grafi delle chiamate e un catalogo delle regole di business.
Controllo umano
Ingegneri ed esperti di dominio verificano ogni regola estratta prima che venga usata come specifica. Le regole non verificate sono indicate come tali.
03
Passo 3: Costruire la rete di sicurezzaSistema
I test di caratterizzazione vengono generati da input e output di produzione anonimizzati, così il comportamento attuale, comprese le sue stranezze, viene fissato prima di qualsiasi modifica.
04
Passo 4: Ricostruire una porzione dietro una facciataSistema
Davanti al vecchio sistema viene posto uno strato di instradamento o di API che fa da facciata (façade). Una funzionalità viene ricostruita come nuovo servizio, con i dati migrati e mantenuti sincronizzati.
05
Passo 5: Esecuzione in parallelo e riconciliazioneSistema
Vecchio e nuovo elaborano le stesse transazioni. Output e dati vengono confrontati automaticamente e ogni differenza viene riportata per regola e per record.
06
Passo 6: Analisi delle discrepanzePersona
Ingegneri ed esperti di dominio stabiliscono se ogni differenza è un difetto del nuovo servizio, un difetto del vecchio o una modifica voluta, e rimandano la porzione in lavorazione.
Percorso di eccezione: Gli output differiscono· Torna al passo 4
07
Passo 7: Passaggio e dismissionePersona
Il traffico per la funzionalità passa al nuovo servizio attraverso la facciata. Dopo un periodo di stabilità il vecchio percorso di codice e i relativi dati vengono dismessi e archiviati.
Controllo umano
Il responsabile di business approva ogni passaggio sulla base degli esiti della riconciliazione. Il rollback tramite la facciata resta disponibile fino alla dismissione.
Componenti
Che cosa realizzeremmo
01
Mappa del portafoglio e delle dipendenze
Inventario, mappatura di interfacce e flussi di dati e un modello di dominio che mostra dove il sistema può essere suddiviso in porzioni.
Salesforce come nuovo front officePiattaformaSalesforce
Piattaforma di integrazione e API gateway
Cloud o data center di destinazione
Controlli
Controlli integrati nella progettazione
Limiti di accesso
L’analisi del codice avviene in un ambiente sotto il Suo controllo, senza inviare codice sorgente a servizi che Lei non ha approvato. I dati di produzione usati per i test vengono anonimizzati prima di uscire dalla zona di produzione.
Revisione umana
Le regole recuperate vengono verificate da ingegneri ed esperti di dominio prima di diventare specifiche. Ogni passaggio viene approvato dal responsabile di business sulla base degli esiti della riconciliazione, con il rollback sempre disponibile.
Tracciabilità
Ogni regola del catalogo è riconducibile al codice da cui proviene e alla persona che l’ha verificata. I report di riconciliazione vengono conservati come evidenza per ogni passaggio.
Protezione dei dati
La migrazione dei dati segue una mappatura documentata con conteggi dei record e checksum, e i dati personali vengono minimizzati nei set di test. Le regole di conservazione seguono i dati.
Trasparenza dell’IA
Quando l’IA produce bozze di documentazione o di codice, l’output viene etichettato, revisionato e versionato come qualsiasi altro artefatto di ingegneria.
Indicatori
Che cosa misureremmo
Concordiamo queste misure con Lei durante la valutazione e le monitoriamo per ogni porzione, non solo per il programma nel suo complesso.
Che cosa misureremmo
Indicatore
Perché è importante
Come lo misureremmo
01Lead time delle modifiche
Perché è importanteIl segnale più chiaro che il sistema sta diventando più facile da modificare.
Come lo misureremmoTempo dalla richiesta di modifica approvata alla produzione, per le parti vecchie e per quelle modernizzate.
02Stato della riconciliazione
Perché è importanteMostra se il nuovo servizio si comporta davvero come il vecchio dove deve farlo.
Come lo misureremmoQuota di transazioni e record che coincidono durante l’esecuzione in parallelo, con le differenze aperte per causa.
03Copertura delle regole
Perché è importanteLe regole sconosciute sono il rischio principale di qualsiasi sostituzione.
Come lo misureremmoQuota delle regole di business recuperate verificate dagli esperti di dominio e coperte da test.
04Impronta del legacy
Perché è importanteLa modernizzazione ripaga quando i vecchi componenti vengono effettivamente spenti.
Come lo misureremmoFunzionalità, percorsi di codice, job batch e licenze dismessi, monitorati per porzione.
Nessun obiettivo viene fissato prima di una misurazione di riferimento.
Rilascio
Come lo introdurremmo
Fase 01
Valutazione
Portafoglio, dipendenze, domini e rischi. Scegliamo una prima porzione che conti per il business ma che possa essere annullata.
Criteri di uscita
Architettura di destinazione approvata
Ordine delle porzioni concordato
Accesso a test e dati organizzato
Fase 02
Prima porzione
Recupero delle regole, rete di sicurezza, facciata e una funzionalità ricostruita, eseguita in parallelo con il vecchio sistema.
Criteri di uscita
Riconciliazione entro la tolleranza concordata
Il responsabile di business approva il passaggio
Rollback testato
Fase 03
Porzione dopo porzione
Le funzionalità successive seguono lo stesso percorso, ciascuna con la propria esecuzione in parallelo e la propria decisione di passaggio.
Criteri di uscita
Ogni porzione riconciliata e passata in esercizio
Conoscenze trasferite al Suo team
Fase 04
Dismissione
Vecchi percorsi di codice, job batch e archivi di dati vengono archiviati e spenti.
Estensioni ERP su misura e sistemi di stabilimento, migrati in parallelo a una migrazione a SAP S/4HANA.
Esempio illustrativo
Un sistema per i tributi locali scritto in COBOL
Situazione
Un consorzio di enti locali gestisce i tributi di molti comuni su un’applicazione COBOL che solo due persone sanno modificare, mentre i nuovi servizi online richiedono integrazioni che il sistema non supporta.
Sistema
Un livello di API davanti al sistema esistente, la migrazione per moduli verso un’applicazione moderna su cloud qualificato e test di equivalenza che confrontano ogni calcolo con il sistema precedente.
Controllo umano
L’ufficio tributi approva ogni modulo prima del passaggio in esercizio; le differenze di calcolo bloccano il rilascio finché non sono spiegate.
Cosa misureremmo
Quota di funzioni migrate, differenze di calcolo per ciclo di test, tempi di rilascio delle modifiche normative.
Italia
Dopo il PNRR, sistemi da far durare
I fondi del PNRR per la Missione 1 hanno finanziato in pochi anni migrazioni al cloud, nuovi servizi online e integrazioni con le piattaforme nazionali. Con la chiusura del piano nel 2026, molte amministrazioni e imprese si trovano sistemi nuovi accanto ad applicazioni storiche, da gestire, integrare e migliorare con risorse ordinarie.
Modernizziamo per gradi, nella cornice del Piano Triennale di AgID e della qualificazione cloud ACN per la PA e del D.Lgs. 138/2024 per la sicurezza: test di equivalenza, migrazione dei dati verificata e continuità del servizio come requisito di progetto.
01Perché non sostituire l’intero sistema in un colpo solo?
Perché un unico passaggio concentra tutto il rischio in una sola data, e il business attende anni prima di vedere un beneficio. Procedere funzionalità per funzionalità permette a ogni porzione di dimostrare il proprio valore in un’esecuzione in parallelo, di entrare in esercizio da sola e di essere annullata se necessario.
02L’IA può tradurre il nostro COBOL in Java?
Una traduzione riga per riga tende a produrre codice difficile da modificare quanto l’originale. Usiamo l’IA per leggere e documentare il vecchio codice e per redigere bozze di regole e test, poi progettiamo i nuovi servizi come si deve. Ogni regola recuperata viene verificata da persone prima di essere utilizzata.
03I nostri esperti stanno andando in pensione. Come raccogliete ciò che sanno?
Con sessioni strutturate in cui gli esperti esaminano le regole recuperate e i test di caratterizzazione. La loro conoscenza confluisce in documentazione e test che restano al Suo team, non nelle nostre teste.
04Vale anche per SAP ECC?
Sì. Gli stessi principi valgono per la bonifica del codice custom e per una migrazione a SAP S/4HANA: valutare che cosa si usa ancora, recuperare e testare ciò che conta e procedere per passi controllati.
05Per quanto tempo vecchio e nuovo funzionano in parallelo?
Finché gli esiti della riconciliazione rientrano nella tolleranza concordata con il responsabile di business, e abbastanza a lungo da coprire i processi periodici come le chiusure di fine mese o le elaborazioni annuali.