Sigue habiendo COBOL en producción en Colombia, y no en un rincón: liquidando nóminas, calculando intereses, generando los archivos que se envían a una entidad de control cada mes.
La reacción habitual es tratarlo como un problema de tecnología obsoleta. Casi nunca lo es.
Por qué sigue ahí
Un programa en COBOL que lleva veinte años corriendo ha sobrevivido a veinte años de casos raros. Cada condición extraña que hay en ese código es una situación real que alguien reportó: un cliente que factura distinto, una excepción tributaria de un año concreto, un cambio normativo que hubo que aplicar en tres días.
Ese conocimiento no está en ningún manual, porque el manual no existe. No está en la cabeza de nadie, porque quien lo escribió se jubiló. Está en el código, y solo ahí.
Por eso el sistema sigue en pie: no porque nadie se haya atrevido a cambiarlo, sino porque funciona mejor de lo que su reputación sugiere.
Cuál es el problema real
El problema no es el lenguaje. Es la combinación de tres cosas:
- Nadie quiere tocarlo. El equipo actual no lo conoce, y cada cambio se hace con miedo. Eso convierte una modificación de dos horas en un proyecto de dos semanas.
- Corre sobre algo que envejece. El lenguaje no caduca; el sistema operativo, el hardware y el contrato de soporte sí.
- Depende de una persona. Casi siempre hay alguien que lo entiende. Si esa persona se va, el sistema pasa de estable a intocable.
Las opciones, en orden de sensatez
Dejarlo donde está y rodearlo
Si el programa hace bien lo suyo, se le puede poner una interfaz moderna delante y dejarlo intacto por detrás. Se expone lo que calcula a través de una capa nueva y el resto del sistema conversa con esa capa, no con el COBOL.
Es lo más barato y lo que menos riesgo tiene. No resuelve la dependencia de la plataforma, pero compra años.
Trasladarlo sin reescribirlo
Sacarlo del mainframe y ponerlo a correr sobre servidores actuales, con un compilador moderno. El código sigue siendo el mismo; cambia lo de debajo. Resuelve el problema del soporte de plataforma sin tocar la lógica que nadie sabe explicar.
Reescribirlo
La opción que primero se propone y la que más veces sale mal. Reescribir significa volver a aprender, fallando en producción, todo lo que ese código ya sabe. Es la conversación que tratamos en modernizar o rehacer desde cero.
A veces es la respuesta correcta. Pero es la última, no la primera.
Lo que hay que hacer ya, cueste lo que cueste decidir
Independientemente de la ruta, hay dos cosas que no admiten espera:
- Asegurarse de tener el código fuente. Suena obvio. No lo es: es sorprendentemente frecuente que lo que corre en producción no coincida con lo que hay guardado.
- Sacar el conocimiento de una sola cabeza. Aunque sea grabando a esa persona explicando el sistema durante unas horas. Es la inversión más barata que existe contra el riesgo más caro.
Si su empresa está en esta situación, un diagnóstico le dice qué opción encaja antes de comprometer presupuesto.