Aziende manifatturiere e software legacy
Molte aziende manifatturiere utilizzano macchinari di produzione interfacciati con un software. Spesso questi software sono applicativi verticali fortemente specializzati per un tipo di realtà produttiva o sviluppati per controllare particolari strumentazioni.
In alcuni casi, le versioni di questi software sono molto datate, e costringono le aziende che ne fanno utilizzo a supportare un’infrastruttura legacy dedicata a quello specifico programma. Le ragioni di una situazione simile sono differenti, e si possono ricercare nell’andamento di un particolare settore, oppure nell’estrema specificità del programma, caratteristica che ha reso i costi di un upgrade fuori budget.
In non pochi casi, un upgrade non è mai stato fatto perché l’azienda produttrice del macchinario o del software è uscita dal mercato, casistica che ha costretto il cliente a prendersi in carico la manutenzione dell’applicativo.
Ci sono molti casi di aziende in questa situazione, specie nel settore tessile, dove esistono telai o plotter pilotati da verticali realizzati in Visual Fox Pro o versioni datate di Visual Basic, che risiedono su macchine virtuali con versioni di Windows XP o precedenti, le uniche dove quei framework possono essere eseguiti.
I problemi di un’infrastruttura legacy
Gestire un’infrastruttura obsoleta è un impegno oneroso per diversi motivi. Oltre a gestire un server con una versione di Windows out of support, spesso è necessario mantenere un’infrastruttura di rete dedicata per il collegamento all’impianto produttivo, e proteggere questa Subnet con un apposito firewall, settato in maniera “aggressiva” per sopperire alla mancanza di aggiornamenti di sicurezza del sistema operativo troppo datato.
Occorre poi formare almeno una risorsa interna sulla manutenzione dell’infrastruttura legacy. Tutte queste problematiche portano le aziende a valutare la fattibilità di una migrazione della soluzione verticale su una piattaforma moderna, magari offrendo la possibilità di usufruirne anche in mobilità.
Criticità della migrazione
La criticità principale di trasformare un verticale legacy in un’applicazione mobile solitamente è costituita dalla disponibilità o meno del codice sorgente del software. Il codice sorgente potrebbe non essere in possesso del cliente perché magari il fornitore del verticale non esiste più e non ha avuto la possibilità di rilasciare i sorgenti ai propri clienti.
Le aziende che si trovano in una situazione del genere sono però invitate ad eseguire un controllo più approfondito sul server su cui risiede l’applicazione: qualche volta, infatti, questo genere di verticali viene installato con il sorgente a cuore aperto sullo stesso server proprio per favorire eventuali interventi di manutenzione a caldo ed in tempo breve.
Nel caso, invece, che si abbia a disposizione il codice sorgente, la maggiore criticità potrebbe essere costituita dalla mancanza di documentazione e dalla difficoltà del processo di reverse engineering, o dal fatto che il sorgente sia scritto con un framework datato o poco conosciuto.
Migrazione del sorgente legacy
Se si ha a disposizione il sorgente dell’applicazione, una prima ricerca da fare riguarda l’esistenza di tool di conversione automatica del codice. Per molti framework anche datati esiste infatti la possibilità di realizzare una prima migrazione massiva del codice utilizzando uno di questi strumenti.
Per esempio, un caso molto diffuso è quello di dover migrare del codice da Visual Fox Pro: uno dei convertitori di codice automatico più usati è il Visual Fox Pro Code Converter di .com Solutions, disponibile direttamente sullo Store di Microsoft.
Un altro software che potrebbe essere stato impiegato per sviluppare il vostro verticale legacy, e che ora non è più in commercio, è il Borland C++. Per questo framework sono disponibili tool come RCConvertor oppure OWLNext. Ovviamente, il risultato di questo primo step non sarà una versione già completamente funzionante del software nell’ambiente di destinazione, ma sarà una versione aggiornata al nuovo framework della logica di business del verticale.
Questi tool spesso riescono a mappare correttamente la maggior parte degli oggetti e degli eventi dal vecchio al nuovo ambiente, ma possono inserire bug logici o tecnici nel codice, che deve essere ricontrollato minuziosamente. Eventuali logiche che l’automatismo non sia riuscito a convertire correttamente dovranno essere poi gestite manualmente dal team di sviluppo.
Nel caso che per il framework sorgente non esista sul mercato un tool di conversione automatica, si può controllare l’esistenza di un’eventuale interoperabilità con l’ambiente di destinazione. In questo caso sarebbe possibile effettuare un embedding (incorporamento) nel nuovo sistema direttamente di oggetti importati dal framework precedente.
Migrazione senza sorgenti
Nel caso non si disponga dei sorgenti del vecchio software, è necessario effettuare un’analisi della logica di business del verticale, tenendo in particolare conto le specificità relative a un eventuale collegamento con un impianto di produzione.
In questo caso occorrerà valutare anche la fattibilità della replica dell’interfaccia tra il programma e il macchinario, magari costituita da un hardware datato come una porta seriale. Molti framework moderni supportano librerie per la gestione della comunicazione con interfacce hardware datate.
Uno dei sistemi più diffusi è la COM Interoperability, che permette di impiegare in applicazioni .NET controlli ActiveX o oggetti COM, replicando in questo modo la logica dell’interfaccia nel nuovo software.
Nel caso si debba gestire questa comunicazione da un dispositivo mobile, sarà possibile interfacciare al macchinario di produzione un server su cui installare un web service che renda fruibili all’app mobile i dati raccolti dalla seriale.
Anche quando non si disponga dei sorgenti, è possibile ridurre il tempo di conversione del software utilizzando plugin che replicano alcune logiche specifiche (per esempio quelle legate al tracciamento dei vettori di un plotter) del verticale.
In questo modo sarà possibile costruire la nuova applicazione attorno a dei moduli già definiti e realizzare solo i flussi di dati aggiuntivi tra questi blocchi di logica.
Un aiuto importante per ridurre i tempi di conversione può arrivare dai key user del verticale che, grazie alla loro esperienza di utilizzo, sapranno indicare quali sono le funzionalità chiave da replicare e quali invece le logiche secondarie che è possibile tralasciare nella nuova versione.
