Come conservare la conoscenza degli applicativi legacy?

Ogni azienda che opera su sistemi legacy convive con la consapevolezza che il sistema funziona, ma la conoscenza di come funziona è distribuita tra decine di migliaia di righe di codice scritte in decenni, in linguaggi come COBOL, PL/SQL o Java EE, da sviluppatori che in molti casi non lavorano più lì.

Le business rule, i flussi sono nel codice, così come le eccezioni, le logiche di calcolo, le casistiche specifiche del settore, ma il codice non è leggibile da un analista funzionale, non è consultabile da un nuovo sviluppatore, non è interrogabile da un CIO che deve prendere una decisione su un progetto di modernizzazione.

Questa situazione ha un nome preciso: debito di conoscenza ed è sistematicamente sottovalutato rispetto al debito tecnico, che almeno ha una rappresentazione misurabile in backlog e ticket.

In quasi ogni organizzazione con sistemi legacy critici esiste almeno una persona che “sa come funziona” quel sistema, ma quando questa va in pensione o lascia l’azienda, porta con sé una conoscenza che nessun sistema di ticketing o wiki aziendale è mai riuscito a catturare davvero.

Software legacy e perdita di conoscenza: quando il problema diventa visibile

Nella pratica quotidiana, la perdita di know-how su sistemi legacy si manifesta in tre scenari ricorrenti:

• Un bug critico si verifica sul sistema legacy: il tempo di diagnosi è sproporzionato rispetto alla correzione, perché nessuno del team attuale conosce la logica del modulo coinvolto.
• L’organizzazione vuole avviare un progetto di modernizzazione o integrazione: nella fase di analisi emerge che nessuno è in grado di documentare con precisione il comportamento del sistema esistente.
• Un nuovo sviluppatore deve prendere in carico il sistema legacy: la curva di apprendimento si misura in mesi, non in settimane.

In tutti e tre i casi, il costo reale è il tempo perso a fare reverse engineering manuale su codice non documentato, i rischi di regressione nelle modifiche, la dipendenza continua dagli unici esperti disponibili.

La risposta tradizionale a questi problemi è stata quasi sempre la stessa: avviare un progetto di modernizzazione. Sostituire il sistema legacy con qualcosa di nuovo, più manutenibile, più documentato. Un approccio comprensibile, ma che spesso porta con sé una conseguenza paradossale: per modernizzare un sistema che non si capisce, si finisce per riscriverlo senza capirlo davvero e il rischio di perdere comportamenti critici è molto alto.

Capire il legacy con una knowledge base consultabile in linguaggio naturale

Per capire prima di modernizzazione un applicativo, Omnia Group ha sviluppato OmnIA Bridge Discover che permette di decidere cosa fare con un sistema legacy con consapevolezza. Con Omnia Bridge Studio è possibile capire cosa fa, come lo fa, quali regole di business implementa, dove si concentra il debito tecnico.

OmnIA Bridge Discover è il piano di OmnIA Bridge dedicato alla creazione di knowledge base consultabili da sistemi legacy esistenti. Attraverso un processo di analisi semantica multi-agente, il sistema legge il codice sorgente legacy — COBOL, PL/SQL, Java EE, ecc — e costruisce una rappresentazione strutturata e interrogabile della conoscenza che contiene.

Gli output concreti al termine dell’analisi sono:

• Un grafo semantico navigabile del codebase: classi, metodi, dipendenze, business rule, tutto collegato e consultabile.
• Un catalogo delle business rule estratte automaticamente, con collegamento al codice sorgente che le implementa.
• Una documentazione tecnico-funzionale generata automaticamente: executive summary, data model, report del debito tecnico.
• Una knowledge base multi-tenant, isolata per progetto, con ricerca ibrida su testo, vettori e grafi.
• Un Domain Expert Agent: un’interfaccia conversazionale in linguaggio naturale per interrogare la knowledge base — senza dover sapere leggere una riga di COBOL.

La knowledge base è esportabile e resta in capo al cliente. Non dipende dalla presenza di Omnia Group: è un asset aziendale che può essere aggiornato, arricchito e consultato nel tempo.

Il punto tecnico più rilevante di OmnIA Bridge Discover è la distinzione tra analisi sintattica e analisi semantica. La maggior parte degli strumenti di analisi del codice opera a livello sintattico: conta le righe, mappa le dipendenze strutturali, identifica i pattern di codice. È utile, ma risponde alla domanda sbagliata: “come è scritto il codice?” invece di “cosa fa il codice?”. OmnIA Bridge Discover risponde alla seconda domanda: la pipeline di analisi costruisce un grafo semantico su Neo4j che rappresenta non solo la struttura del codice, ma le relazioni logiche tra i componenti quali business rule sono implementate in quale metodo, quale stored procedure governa quale flusso di processo, quali componenti sono più critici e accoppiati.

Uno degli output più utili per i responsabili IT è la quantificazione del debito tecnico. OmnIA Bridge Discover non fornisce una valutazione qualitativa, ma una misurazione quantitativa basata su algoritmi di analisi dei grafi: betweenness centrality, PageRank, community detection con algoritmo Leiden. Il risultato è un report visualizzabile in dashboard con treemap e heatmap, storicizzato nel tempo per monitorare l’evoluzione del debito.

Per un IT Manager o un CIO, questo significa poter rispondere a domande concrete: quali sono i componenti più a rischio? Dove si concentra la complessità? Decisioni che oggi richiedono settimane di analisi manuale diventano interrogazioni alla dashboard.