Siamo una piccola, molto specializzata, società di gestione dei benefici con una raccolta di software estremamente utile e robusta, alcuni scritti in COBOL ma la maggior parte in BASIC. Due consulenti a tempo pieno hanno abilmente mantenuto e migliorato questo sistema per oltre 30 anni. Inutile dire che presto andranno in pensione. (Uno di loro ha cercato disperatamente di ritirarsi per diversi anni, ma è fedele a un errore e quindi resiste nonostante l'insistenza del marito che il golf dovrebbe avere la priorità.)

Abbiamo iniziato il percorso di conversione in un sistema sviluppato da una delle sole tre aziende nel paese che offrono il tipo di software che utilizziamo. Riteniamo ora che, sebbene questa azienda sia teoricamente in grado di completare il processo di conversione, non ha le risorse per farlo in modo tempestivo e siamo arrivati ​​a credere che non saranno in grado di offrire il tipo di servizio di cui abbiamo bisogno per eseguire i nostri affari. (Non c'è niente come essere in grado di stabilire le proprie priorità e avere l'autorità di allocare le proprie risorse come meglio crede).

L'hardware non è un problema: siamo in grado di emulare in modo molto efficace su server moderni. Se COBOL e BASIC fossero lingue moderne, saremmo disposti a correre il rischio di poter trovare sostituzioni per i nostri attuali consulenti in futuro.

Sembra che ci dovrebbe essere un modello di business per un'azienda di supporto IT che si concentra su piattaforme legacy come questa e fornisce i talenti di programmazione e sviluppo software per supportare un sistema come il nostro, eliminando dalle nostre spalle i rischi di trovare il giusto talento di programmazione e il compito di convincere i programmatori più giovani a poter avere una carriera produttiva e gratificante, in parte in un linguaggio vecchio e non sexy come BASIC.

In breve, come manager non IT, come possiamo gestire al meglio questa transizione?

Può sembrare che "ci dovrebbe essere un modello di business per un'azienda di supporto IT che si concentra su piattaforme legacy come questa", ma personalmente penso che sia solo un pio desiderio da parte tua in quanto "risolverebbe" le sfide che devi affrontare in una colpo solo.

Rimanere bloccati nei vecchi ambienti non è il modo di andare avanti. E io per primo non scommetterei la vita di nessuna compagnia nel cercare di rimanere bloccato trovando una ditta che, per ora, sarebbe disposta a fare ciò che apparentemente non puoi.

Quindi non una risposta all'attuale domanda che hai chiesto, ma un consiglio sincero su come potresti andare avanti mantenendo al minimo i rischi di una migrazione.

Leggi "Come sopravvivere a una riscrittura radicale senza perdere la sanità mentale"

Non commettere l'errore di un lungo progetto di migrazione senza risultati reali per lungo tempo. Leggi "Come sopravvivere a una riscrittura radicale senza perdere la sanità mentale"

Non posso sottolineare abbastanza come il consiglio di quell'articolo mi abbia aiutato ad affrontare / affrontare problemi simili dopo avermi bruciato facendo quel tipo di progetti alla "vecchia maniera".

Imposta test automatici

Se non lo hai già installato (perché mai no?), Chiedi ai tuoi attuali programmatori di creare un cablaggio di test automatizzato per le tue applicazioni.

La suite di test automatizzati dovrebbe coprire tutte le aree funzionali delle applicazioni. Dovrebbe documentare le attuali specifiche di lavoro nelle regole "when_X_then_Y" dei singoli casi di test. Questo aiuterà sia a mantenere le modifiche nel codice corrente da interrompere le funzionalità esistenti sia a supportare qualsiasi migrazione verso un nuovo ambiente.

Dato che hai a che fare con COBOL e BASIC, la suite di test dovrebbe probabilmente essere al livello dei test di integrazione: lavorare su un set "fisso" di file / database di input e controllare i file di output / modificare il contenuto del database di programmi specifici (COBOL) e / o applicazioni. Per le parti BASIC del software ciò può significare l'aggiunta di parametri della riga di comando per farli esercitare determinate funzioni senza l'intervento dell'interfaccia utente (G) o ottenere uno strumento di test automatizzato basato sull'interfaccia utente (G).

Isolare i calcoli e altri algoritmi

Anche Cobol supporta l'idea di sottoprogrammi richiamabili da un programma principale. Isolare tutti i calcoli di importazione e altri algoritmi in programmi o moduli separati. L'obiettivo è quello di creare una libreria di programmi / moduli / qualunque cosa faccia il lavoro grugnito isolata da tutto ciò che raccoglie input e crea output.

Adatta il cablaggio di prova per testarli sia attraverso le tue vecchie applicazioni che in isolamento. Ciò garantirà che il lavoro svolto sul "vecchio" codice per facilitare la migrazione verso un ambiente più recente introdurrà il minor numero di errori possibile.

Avvia un nuovo set di applicazioni in un ambiente "attuale"

Non convertire il tuo codice attuale. Convertire una lingua in un'altra significa imporre i vincoli del vecchio ambiente al nuovo. Il risultato è spesso meno desiderabile (leggi: il risultato sarà terribile e doloroso da mantenere). Migrare. Prenditi il ​​tempo necessario per configurare le tue applicazioni nel nuovo ambiente in un modo che è considerato la migliore pratica per quell'ambiente.

Ottieni nuovi programmatori, esperti nel tuo ambiente prescelto, per farlo. Rendi prioritario fin dal primo giorno isolare tutti i calcoli e gli algoritmi importanti in classi e / o pacchetti separati e nasconderli dietro le interfacce. Usa l'iniezione di dipendenza (farà il tipo più economico di iniezione di dipendenza fai-da-te) per dire alla tua nuova applicazione quali classi istanziare / usare per fare i calcoli.

Questo è comunque un buon modo di fare le cose e nel tuo caso ti permetterà di migrare quelle parti importanti in base al caso. Nasconderà anche la complessità di chiamare i programmi di base e / o cobol dalle funzioni di chiamata nel nuovo ambiente.

Non andare oltre la configurazione delle applicazioni e forse l'impostazione della singola funzione di input / output più importante che utilizza un calcolo dalla tua "libreria" COBOL / BASIC.

Integra la tua "libreria" COBOL / BASIC

Scopri come chiamare la tua "libreria" COBOL / BASIC dal tuo nuovo ambiente. Ciò può comportare l'impostazione di file di parametri o tabelle di database, l'esecuzione di un programma COBOL / BASIC che avvolge la libreria COBOL / BASIC impostata in precedenza. Se sei fortunato, la tua versione di BASIC potrebbe consentire la creazione di DLL che possono essere chiamate direttamente.

Implementa la classe nel tuo nuovo ambiente che chiamerà la "libreria" COBOL / BASIC e testerà il diavolo usando gli stessi test che si trovano nel cablaggio di test del vecchio ambiente, ma ora sotto forma di test unitari nel nuovo ambiente .

Sì, questo significa "duplicare" i test, ma è una rete di sicurezza di cui non vuoi fare a meno. Se non altro perché questi test unitari serviranno in seguito come test per verificare l'implementazione dei calcoli e degli algoritmi quando vengono migrati nel nuovo ambiente.

Ma ancora: non andare oltre l'aggiunta dei test unitari per i calcoli utilizzati dal singolo più importante del passaggio precedente.

Rafforzare le nuove applicazioni nelle iterazioni

Completa le nuove applicazioni ripetendo i due passaggi precedenti per tutte le funzioni delle tue vecchie applicazioni. Continuare ad aggiungere quei test unitari che controllano i calcoli sul cablaggio di test delle nuove applicazioni. Utilizzare la suite di test di integrazione per verificare che le funzioni migrate funzionino come le vecchie applicazioni.

Migrare la libreria principale nelle iterazioni

E infine migra i calcoli e gli algoritmi nella tua "libreria" COBOL / BASIC, implementandoli nuovamente nel tuo nuovo ambiente. Ancora una volta, fai questo in modo iterativo usando i test (unit) come un modo per mantenere la sanità mentale.

Sembra che questa applicazione sia "core" per la tua attività. Nei casi in cui un sistema o un processo è ciò che è la tua azienda, è il caso per avere la tua soluzione personalizzata.

Hai alluso a questo. Purtroppo, considerato il lungo tempo trascorso dall'aggiornamento delle tecnologie, questa sarà un'impresa estremamente difficile.

Consiglierei uno dei due percorsi.

1. Organizzare un gruppo IT di sviluppatori / project manager / QE / operazioni e costruire il sistema in modo incrementale, come indicato nella risposta piuttosto tecnica sopra. Questo sarà tuttavia eccezionalmente costoso.
2. Piuttosto che un fornitore standard, cercare un consulente sviluppatore personalizzato qualificato. Questo gruppo gestirà tutte le risorse per costruire il tuo nuovo sistema, quindi puoi portarlo a casa con un piccolo staff rispetto all'opzione 1 per continuare. Questa opzione presenta una serie diversa di rischi, tuttavia la scelta di un buon fornitore può essere molto difficile per i non tecnici. Possono anche comportare un rischio molto elevato con sovraccarichi di costi, ecc. Per mitigare questo percorso, utilizza il tuo personale esistente per elaborare una serie molto dettagliata di requisiti (dal punto di vista dell'utente) per la tua offerta. Quindi chiedere anche offerte a prezzo fisso.

Buona fortuna, hai circa 20 anni di eredità da superare. Non sarà economico, facile o pulito.

Piuttosto che cercare un'azienda che mantenga il proprio software legacy o che una ditta riscriva il proprio software legacy, cercare un'azienda che fornisca un servizio di gestione continua dei vantaggi. Esternalizzare i problemi di decidere se riscrivere o meno il software, quale programma impostare, quale lingua (e) o strumenti da usare.

Sì, i costi ovvi di questo approccio potrebbero superare i costi ovvi dell'assunzione di nuovi programmatori ma, per tua stessa ammissione, sei un manager non IT ed è facile prevedere scenari in cui prendere decisioni che alla fine costano alla tua azienda più del costi evidenti di esternalizzazione.