Somos una empresa de administración de beneficios pequeña, muy especializada, con una colección de software extremadamente útil y robusta, algunos escritos en COBOL pero la mayoría en BASIC. Dos consultores a tiempo completo han mantenido y mejorado este sistema durante más de 30 años. No hace falta decir que pronto se jubilarán. (Uno de ellos ha estado desesperado por retirarse durante varios años, pero es leal hasta el punto de fallar y, por lo tanto, aguanta a pesar de la insistencia de su esposo de que el golf debe tener prioridad).

Comenzamos por el camino de la conversión a un sistema desarrollado por una de las tres únicas empresas del país que ofrecen el tipo de software que utilizamos. Ahora creemos que, aunque esta empresa es teóricamente capaz de completar el proceso de conversión, no tienen los recursos para hacerlo a tiempo, y hemos llegado a creer que no podrán ofrecer el tipo de servicio que necesitamos para ejecutar Nuestro negocio. (No hay nada como ser capaz de establecer las propias prioridades y tener la autoridad para asignar los recursos de uno como lo considere conveniente).

El hardware no es un problema: podemos emular de manera muy efectiva en servidores modernos. Si COBOL y BASIC fueran idiomas modernos, estaríamos dispuestos a correr el riesgo de encontrar reemplazos para nuestros consultores actuales en el futuro.

Parece que debería haber un modelo de negocio para una empresa de soporte de TI que se concentre en plataformas heredadas como esta y proporcione el talento de programación y desarrollo de software para soportar un sistema como el nuestro, eliminando de nuestras espaldas los riesgos de encontrar el talento de programación adecuado y el trabajo de convencer a los programadores más jóvenes de que pueden tener una carrera productiva y gratificante, en parte en un lenguaje antiguo y poco sexy como BASIC.

En resumen, como gerentes que no son de TI, ¿cómo podemos gestionar mejor esta transición?

Puede parecer que "debería haber un modelo de negocio para una empresa de soporte de TI que se concentre en plataformas heredadas como esta", pero personalmente creo que es solo una ilusión de su parte ya que "resolvería" los desafíos que enfrenta en uno cayó de golpe.

Permanecer atrapado en entornos antiguos no es la forma de avanzar. Y por mi parte, no apostaría la vida de ninguna empresa a tratar de mantenerse estancado al encontrar alguna empresa que, por ahora, estaría dispuesta a hacer lo que aparentemente no puede hacer.

Por lo tanto, no es una respuesta a la pregunta real que solicitó, sino consejos sinceros sobre cómo podría avanzar mientras mantiene los riesgos de una migración al mínimo.

Lea "Cómo sobrevivir a una reescritura desde cero sin perder la cordura"

No cometa el error de un proyecto de migración largo sin resultados reales durante mucho tiempo. Lea "Cómo sobrevivir a una reescritura desde cero sin perder la cordura"

No puedo enfatizar lo suficiente cómo el consejo de ese artículo me ha ayudado a abordar / abordar problemas similares después de quemarme haciendo ese tipo de proyectos de la manera "antigua".

Configurar pruebas automatizadas

Si aún no lo ha implementado (¿por qué nunca?), Haga que sus programadores actuales creen un arnés de prueba automatizado para sus aplicaciones.

El conjunto de pruebas automatizadas debe cubrir todas las áreas funcionales de sus aplicaciones. Debería documentar las especificaciones de trabajo actuales en las reglas "when_X_then_Y" de los casos de prueba individuales. Esto ayudará tanto a evitar que los cambios en su código actual rompan la funcionalidad existente como a respaldar cualquier migración a un nuevo entorno.

Como se trata de COBOL y BASIC, el conjunto de pruebas probablemente debería estar al nivel de las pruebas de integración: trabajando con un conjunto "fijo" de archivos / bases de datos de entrada y comprobando los archivos de salida / contenido de bases de datos modificadas de programas específicos (COBOL) y / o aplicaciones. Para las partes BÁSICAS de su software, esto puede significar agregar parámetros de línea de comandos para que ejerzan ciertas funciones sin intervención de (G) UI, u obtener una herramienta de prueba automatizada basada en (G) UI.

Aislar cálculos y otros algoritmos.

Incluso Cobol admite la noción de subprogramas invocables desde un programa principal. Aísle todos los cálculos de importación y otros algoritmos en programas o módulos separados. El objetivo es crear una biblioteca de programas / módulos / lo que sea que haga el trabajo duro aislado de todo lo que reúne entradas y crea salidas.

Adapte el arnés de prueba para probarlos tanto a través de sus aplicaciones antiguas como de forma aislada. Esto asegurará que el trabajo que está haciendo en el código "antiguo" para facilitar la migración a un entorno más nuevo introducirá la menor cantidad posible de errores.

Inicie un nuevo conjunto de aplicaciones en un entorno "actual"

No conviertas tu código actual. Convertir un idioma a otro significa imponer las restricciones del antiguo entorno al nuevo. El resultado es a menudo menos que deseable (léase: el resultado será terrible y un dolor de mantenimiento). Emigrar. Tómese el tiempo para configurar sus aplicaciones en el nuevo entorno de una manera que se considere la mejor práctica para ese entorno.

Obtenga nuevos programadores, bien versados ​​en su entorno elegido, para hacerlo. Haga que sea una prioridad desde el primer día aislar todos los cálculos y algoritmos importantes en clases y / o paquetes separados y ocultarlos detrás de las interfaces. Use la inyección de dependencia (el tipo más barato de inyección de dependencia de bricolaje) para decirle a su nueva aplicación qué clases instanciar / usar para hacer los cálculos.

De todos modos, esta es una buena manera de hacer las cosas y, en su caso, le permitirá migrar esas partes importantes según cada caso. También ocultará las complejidades de llamar a programas básicos y / o cobol de las funciones de llamada en el nuevo entorno.

No vaya más allá de configurar las aplicaciones y quizás configurar la función de entrada / salida más importante que utiliza un cálculo de su "biblioteca" COBOL / BASIC.

Integre su "biblioteca" COBOL / BASIC

Descubra cómo llamar a su "biblioteca" COBOL / BASIC desde su nuevo entorno. Esto puede implicar configurar archivos de parámetros o tablas de bases de datos, ejecutar un programa COBOL / BASIC que envuelva la biblioteca COBOL / BASIC que configuró anteriormente. Si tiene suerte, su versión de BASIC puede permitir la creación de DLL que se pueden llamar directamente.

Implemente la clase en su nuevo entorno que llamará a la "biblioteca" COBOL / BASIC y pruebe a utilizarla con las mismas pruebas que están en el arnés de prueba del antiguo entorno, pero ahora en forma de pruebas unitarias en el nuevo entorno .

Sí, esto significa "duplicar" las pruebas, pero es una red de seguridad de la que no quiere prescindir. Aunque solo sea porque estas pruebas unitarias luego servirán como pruebas para verificar la implementación de sus cálculos y algoritmos cuando se migren a su nuevo entorno.

Pero nuevamente: no vaya más allá de agregar las pruebas unitarias para los cálculos utilizados por el más importante del paso anterior.

Desarrolle las nuevas aplicaciones en iteraciones

Desarrolle las nuevas aplicaciones repitiendo los dos pasos anteriores para todas las funciones en sus aplicaciones anteriores. Siga agregando esas pruebas unitarias que verifican los cálculos al arnés de prueba de sus nuevas aplicaciones. Utilice el conjunto de pruebas de integración para verificar que las funciones migradas funcionen igual que sus aplicaciones anteriores.

Migrar la biblioteca principal en iteraciones

Y finalmente migre los cálculos y algoritmos en su "biblioteca" COBOL / BASIC, re-implementándolos en su nuevo entorno. Nuevamente, haga esto de forma iterativa utilizando las pruebas (de unidad) como una forma de mantener la cordura.

Parece que esta aplicación es "fundamental" para su negocio. En los casos en que un sistema o proceso es lo que ES su negocio, es un caso para tener su propia solución personalizada.

Aludiste a esto. Desafortunadamente, dado el largo tiempo que ha pasado desde que actualizó sus tecnologías, esta será una tarea extremadamente difícil.

Yo recomendaría una de las dos rutas.

1. Personalice un grupo de desarrolladores de TI / gerentes de proyecto / QE / operaciones y desarrolle su sistema de forma incremental, como se señala en la respuesta técnica más arriba. Sin embargo, esto será excepcionalmente costoso.
2. En lugar de un proveedor comercial, busque un consultor de desarrollador personalizado calificado. Este grupo manejará todos los recursos para construir su nuevo sistema, luego puede incorporarlo con un pequeño personal que la opción 1 para continuar. Esta opción tiene un conjunto diferente de riesgos, sin embargo, seleccionar un buen proveedor puede ser muy difícil para los no técnicos. También pueden tener un riesgo muy alto con sobrecostos, etc. Para mitigar esta ruta, use su personal existente para elaborar un conjunto muy detallado de requisitos (desde la perspectiva del usuario) para su oferta. Luego solicite ofertas de precio fijo también.

Buena suerte, tienes que superar unos 20 años de legado. No será barato, fácil o limpio.

En lugar de buscar una empresa para mantener su software heredado o una empresa para reescribir su software heredado, busque una empresa que brinde un servicio continuo del sistema de administración de beneficios. Subcontrate los problemas de decidir si reescribe el software, qué programa establecer, qué idioma (s) o herramientas usar.

Sí, los costos obvios de este enfoque podrían exceder los costos obvios de contratar nuevos programadores, pero, por su propia admisión, usted no es un gerente de TI y es fácil prever escenarios en los que toma decisiones que finalmente le cuestan a su empresa más que costos obvios de la subcontratación.