Somos uma empresa de administração de benefícios pequena, muito especializada, com uma coleção de software extremamente útil e robusta, alguns escritos em COBOL, mas a maioria em BASIC. Dois consultores em período integral mantiveram e aprimoraram habilmente esse sistema ao longo de mais de 30 anos. Escusado será dizer que eles vão se aposentar em breve. (Uma delas está desesperada para se aposentar há vários anos, mas é leal a uma falha e, por isso, continua firme, apesar da insistência do marido em que o golfe deva ter prioridade.)

Iniciamos o processo de conversão para um sistema desenvolvido por uma das três únicas empresas do país que oferecem o tipo de software que usamos. Agora, acreditamos que, embora essa empresa seja teoricamente capaz de concluir o processo de conversão, ela não tem recursos para fazê-lo em tempo hábil e acreditamos que ela não poderá oferecer o tipo de serviço que precisamos executar nossos negócios. (Não há nada como ser capaz de definir suas próprias prioridades e ter autoridade para alocar seus recursos como achar melhor.)

O hardware não é um problema - somos capazes de emular com muita eficiência em servidores modernos. Se COBOL e BASIC fossem idiomas modernos, estaríamos dispostos a correr o risco de encontrar substitutos para nossos consultores atuais daqui para frente.

Parece que deveria haver um modelo de negócios para uma empresa de suporte de TI que se concentre em plataformas herdadas como essa e forneça o talento de programação e desenvolvimento de software para suportar um sistema como o nosso, removendo de nossas costas os riscos de encontrar o talento certo em programação e o trabalho de convencer os programadores mais jovens de que eles podem ter uma carreira produtiva e gratificante, em parte em uma linguagem antiga e não sexy como o BASIC.

Em resumo, como gerentes que não são de TI, como podemos gerenciar melhor essa transição?

Pode parecer que "deve haver um modelo de negócios para uma empresa de suporte de TI que se concentre em plataformas herdadas como esta", mas pessoalmente acho que isso é apenas um desejo de sua parte, pois "resolveria" os desafios que você enfrenta em um caiu rapidamente.

Ficar preso em ambientes antigos não é o caminho a seguir. E eu, pelo menos, não apostaria a vida de nenhuma empresa tentando ficar presa ao encontrar uma empresa que, por enquanto, estaria disposta a fazer o que você aparentemente não pode.

Portanto, não é uma resposta para a pergunta real que você pediu, mas conselhos sinceros sobre como você pode avançar enquanto mantém os riscos de uma migração no mínimo.

Leia "Como sobreviver a uma reescrita básica, sem perder a sanidade"

Não cometa o erro de um projeto de migração longo sem resultados reais por muito tempo. Leia "Como sobreviver a uma reescrita básica, sem perder a sanidade"

Não posso enfatizar o suficiente como os conselhos desse artigo me ajudaram a resolver / abordar problemas semelhantes depois de me queimar fazendo esses tipos de projetos da maneira "antiga".

Configurar testes automatizados

Se você ainda não o instalou (por que não?), Peça aos programadores atuais que criem um equipamento de teste automatizado para seus aplicativos.

O conjunto de testes automatizados deve cobrir todas as áreas funcionais dos seus aplicativos. Deverá documentar as especificações de trabalho atuais nas regras "quando_X_depois_Y" dos casos de teste individuais. Isso ajudará a impedir que as alterações em seu código atual quebrem a funcionalidade existente, além de oferecer suporte a qualquer migração para um novo ambiente.

Como você está lidando com o COBOL e o BASIC, o conjunto de testes provavelmente deve estar no nível dos testes de integração: trabalhando em um conjunto "fixo" de arquivos / bancos de dados de entrada e verificando os arquivos de saída / conteúdo alterado do banco de dados de programas específicos (COBOL) e / ou aplicações. Para as partes BASIC do seu software, isso pode significar adicionar parâmetros de linha de comando para fazê-los exercer certas funções sem a intervenção (G) da interface do usuário ou obter uma ferramenta de teste automatizada (G) da interface do usuário.

Isolar cálculos e outros algoritmos

Até o Cobol suporta a noção de subprogramas que podem ser chamados de um programa principal. Isole todos os cálculos de importação e outros algoritmos em programas ou módulos separados. O objetivo é criar uma biblioteca de programas / módulos / o que quer que o trabalho pesado resulte isolado de tudo o que reúne informações e cria resultados.

Adapte o equipamento de teste para testá-los tanto em seus aplicativos antigos quanto em isolamento. Isso garantirá que o trabalho que você está fazendo no código "antigo" para facilitar a migração para um ambiente mais novo introduza o menor número possível de erros.

Inicie um novo conjunto de aplicativos em um ambiente "atual"

Não converta seu código atual. Converter um idioma para outro significa impor as restrições do ambiente antigo ao novo. O resultado é muitas vezes inferior ao desejável (leia-se: o resultado será terrível e difícil de manter). Migrar. Reserve um tempo para configurar seus aplicativos no novo ambiente de uma maneira que seja considerada a melhor prática para esse ambiente.

Obtenha novos programadores, bem versados ​​no ambiente escolhido, para fazer isso. Torne uma prioridade desde o primeiro dia isolar todos os cálculos e algoritmos importantes em classes e / ou pacotes separados e ocultá-los atrás de interfaces. Use injeção de dependência (o tipo mais barato de injeção de dependência de bricolage fará) para informar ao seu novo aplicativo quais classes instanciar / usar para fazer os cálculos.

Essa é uma boa maneira de fazer as coisas de qualquer maneira e, no seu caso, permitirá que você migre essas partes importantes em uma base por caso. Ele também ocultará os meandros da chamada de programas básicos e / ou cobol das funções de chamada no novo ambiente.

Não vá além: configure os aplicativos e, talvez, configure a função de entrada / saída mais importante que usa um cálculo da sua "biblioteca" COBOL / BASIC.

Integre sua "biblioteca" COBOL / BASIC

Descubra como chamar sua "biblioteca" COBOL / BASIC a partir do seu novo ambiente. Isso pode envolver a configuração de arquivos de parâmetros ou tabelas de banco de dados, a execução de um programa COBOL / BASIC que envolve a biblioteca COBOL / BASIC que você configurou anteriormente. Se você tiver sorte, sua versão do BASIC poderá permitir a criação de DLLs que podem ser chamadas diretamente.

Implemente a classe em seu novo ambiente que chamará a "biblioteca" de COBOL / BASIC e testará o problema usando os mesmos testes que estão no chicote de teste do ambiente antigo, mas agora na forma de testes de unidade no novo ambiente .

Sim, isso significa "duplicar" os testes, mas é uma rede de segurança que você não quer prescindir. Apenas porque esses testes de unidade servirão posteriormente como testes para verificar a implementação de seus cálculos e algoritmos quando eles forem migrados para o seu novo ambiente.

Mais uma vez: não vá além de adicionar os testes de unidade para o (s) cálculo (s) usado (s) pelo mais importante da etapa anterior.

Conheça os novos aplicativos em iterações

Abra os novos aplicativos repetindo as duas etapas anteriores para todas as funções em seus aplicativos antigos. Continue adicionando os testes de unidade que verificam os cálculos no chicote de teste dos novos aplicativos. Use o conjunto de testes de integração para verificar se as funções migradas funcionam da mesma forma que seus aplicativos antigos.

Migrar a biblioteca principal em iterações

E, finalmente, migre os cálculos e algoritmos na sua "biblioteca" COBOL / BASIC, reimplementando-os em seu novo ambiente. Novamente, faça isso de forma iterativa, usando os testes (unitários) como uma maneira de manter sua sanidade.

Parece que este aplicativo é "essencial" para os seus negócios. Nos casos em que um sistema ou processo é o que é da sua empresa, é necessário ter sua própria solução personalizada.

Você aludiu a isso. Infelizmente, dado o longo tempo que você passou desde a atualização de suas tecnologias, essa será uma tarefa extremamente difícil.

Eu recomendaria uma das duas rotas.

1. Equipe um grupo de desenvolvedores / gerentes de projeto / QE / operações de TI e construa seu sistema de forma incremental, conforme observado na resposta bastante técnica acima. No entanto, isso será excepcionalmente caro.
2. Em vez de um fornecedor pronto para uso, procure um consultor qualificado de desenvolvedor personalizado. Este grupo tratará de todos os recursos para criar seu novo sistema, e você poderá trazê-lo para casa com uma equipe pequena do que a opção 1 para continuar. Esta opção possui um conjunto diferente de riscos, no entanto, a seleção de um bom provedor pode ser muito difícil para os não técnicos. Eles também podem ser um risco muito alto com excedentes de custos, etc. Para mitigar essa rota, use sua equipe existente para criar um conjunto muito detalhado de requisitos (da perspectiva do usuário) para o seu lance. Em seguida, solicite lances de preço fixo também.

Boa sorte, você tem cerca de 20 anos de legado a superar. Não será barato, fácil ou limpo.

Em vez de procurar uma empresa para manter seu software legado ou reescrever seu software legado, procure uma empresa para fornecer um serviço contínuo de sistema de administração de benefícios. Terceirize os problemas de decidir se deve ou não reescrever o software, qual cronograma definir, que idioma ou ferramentas usar.

Sim, os custos óbvios dessa abordagem podem exceder os custos óbvios da contratação de novos programadores, mas, por sua própria admissão, você não é gerente de TI e é fácil prever cenários nos quais você toma decisões que acabam custando à sua empresa mais do que o custos óbvios de terceirização.