Historia de la pregunta: En las iniciativas de modernización empresarial, los analistas de negocios se encuentran frecuentemente con el decadencia de conocimiento—un fenómeno donde la lógica empresarial crítica sobrevive solo en código legado ilegible. Esta pregunta surgió de migraciones de mainframe a la nube donde los arquitectos originales se retiraron hace décadas, dejando programas en COBOL que ejecutan perfectamente pero desafían la interpretación. El contexto histórico implica la transición de procesamiento por lotes monolítico a microservicios distribuidos, donde la gestión del estado implícito debe volverse explícita en los contratos de API.
El problema se centra en la opacidad epistémica: el sistema funciona, pero nadie sabe por qué. La base de código de COBOL contiene reglas de negocio tácitas—casos extremos, parches regulatorios y overrides manuales—que nunca fueron documentadas porque los desarrolladores originales las mantenían en la memoria. El personal de operaciones actual comprende las entradas y salidas, pero no la lógica de decisiones. Mientras tanto, la nueva arquitectura nativa en la nube requiere que estas reglas sean desacopladas, documentadas y expuestas a través de endpoints REST para consumo en tiempo real. La fecha límite regulatoria fija impide una excavación arqueológica de varios años, sin embargo, errores en la extracción de reglas podrían violar los mandatos de manejo de datos GDPR o la precisión de informes financieros.
La solución emplea un enfoque de ingeniería inversa triangulada. Primero, llevar a cabo talleres de Event Storming con el personal de operaciones para mapear comportamientos empresariales observables e identificar procesos de "caja negra". En segundo lugar, usar herramientas de análisis de código estático para generar gráficos de flujo de control de los programas COBOL, cruzando referencias de mutaciones de variables con resultados comerciales. En tercer lugar, implementar un modo en paralelo, donde los nuevos procesos de microservicios reflejan transacciones contra el sistema legado sin impacto en producción, señalando discrepancias para investigación. Esto crea un bucle de retroalimentación donde la arqueología del código valida los recuerdos de las partes interesadas, y el contexto de las partes interesadas explica las anomalías del código.
Una compañía de seguros regional necesitaba reemplazar un motor de calificación de pólizas COBOL de la década de 1980 por un conjunto de microservicios Python/FastAPI para permitir cotizaciones móviles en tiempo real. La lógica de cálculo original incluía ponderaciones de riesgo territorial complejas, factores de ajuste estacional y cláusulas de tratado de reaseguro que habían sido parcheadas a lo largo de más de cuarenta años. Los tres desarrolladores de COBOL restantes se habían retirado, y el personal de TI actual trataba al sistema como una "caja mágica" que producía primas correctas pero no podía explicar las derivaciones matemáticas para casos extremos específicos. La autoridad reguladora mandató la finalización de la migración dentro de ocho meses para evitar penalizaciones por infraestructura no soportada.
Se evaluaron varios enfoques para capturar los requisitos. La primera opción proponía una transcripción de código a especificaciones, donde los desarrolladores documentarían manualmente cada declaración IF y operación MOVE en la fuente de COBOL. Los pros incluían la completitud teórica y la preservación de la lógica exacta. Los contras eran severos: la base de código contenía más de dos millones de líneas de código espagueti con variables globales no documentadas, convirtiendo esto en un esfuerzo de varios años que perdería la fecha límite y probablemente introduciría errores de transcripción.
La segunda opción sugería derivación de requisitos de caja negra, observando entradas (atributos de pólizas) y salidas (montos de primas) para inferir reglas a través de regresión estadística. Los pros eran la velocidad y el enfoque en el valor comercial actual en lugar de la deuda técnica. Los contras incluían la incapacidad de detectar caminos de código inactivos para escenarios de reclamos raros y el riesgo de codificar errores como características.
La tercera opción, arqueología conductual con validación paralela, involucraba extraer datos de muestra de cinco años de registros de producción, construir árboles de decisiones a partir de transacciones reales y validar estos contra la fuente COBOL usando herramientas de comparación automatizadas.
El equipo seleccionó la tercera solución porque equilibraba velocidad con precisión mientras honraba el principio ágil de software funcionando sobre documentación integral. Al enfocarse en los caminos de código ejecutados en lugar de características muertas, redujeron el alcance en un 60% mientras garantizaban que las reglas comerciales activas se capturaran correctamente. Establecieron un lago de datos que contenía transacciones históricas anonimizadas y ejecutaron estas a través de trabajos JCL heredados y los nuevos servicios FastAPI, señalando automáticamente las discrepancias en el cálculo de primas superiores a 0.01%. Esto reveló tres condiciones críticas no documentadas: un override de deducible por huracán para las pólizas de Florida emitidas antes de 1992, un cálculo de comisión especial para agentes retirados y un error de redondeo en los informes fiscales trimestrales que había sido "corregido" mediante ajustes manuales en hojas de cálculo durante décadas. Los microservicios se rediseñaron para manejar explícitamente estos casos extremos como reglas comerciales configurables en lugar de constantes codificadas.
Cuando realizas ingeniería inversa en código legado, ¿cómo diferenciar entre una restricción crítica de negocio y una solución técnica que se puede eliminar de forma segura durante la migración?
Los candidatos a menudo asumen que toda la lógica existente sirve a un propósito comercial actual, cayendo en la falacia del costo hundido de la preservación de legado. El enfoque correcto implica análisis del contexto temporal: examinar las fechas de los cambios de código para correlacionar con cambios regulatorios conocidos, fusiones o limitaciones tecnológicas que ya no existen. Por ejemplo, una rutina de truncamiento de datos en COBOL podría existir únicamente porque el esquema original de DB2 usaba campos de ancho fijo, mientras que el moderno PostgreSQL admite cadenas de longitud variable—eliminando completamente la necesidad de la regla de truncamiento. Los analistas de negocios deben llevar a cabo sesiones de verificación de intenciones con las partes interesadas comerciales, presentando soluciones sospechosas como "Podemos simplificar esto eliminando X; ¿afecta esto tu cumplimiento?" en lugar de preguntar "¿Deberíamos mantener X?" Esto desplaza la carga de la prueba hacia la necesidad en lugar de la preservación.
¿Cómo evitas el anti-patrón de "culto al cargamento" donde el nuevo sistema replica flujos de trabajo de procesamiento por lotes ineficientes simplemente porque existen en el monolito COBOL?
Muchos candidatos se centran exclusivamente en la paridad funcional sin reestructuración de procesos. El fracaso ocurre cuando los analistas de negocios documentan el estado actual (por ejemplo, "El sistema ejecuta un lote nocturno a las 2 AM") como un requisito para el estado futuro, ignorando que las arquitecturas impulsadas por eventos utilizando Apache Kafka o RabbitMQ pueden habilitar el procesamiento en tiempo real. La solución requiere mapeo de capacidades: separando el "qué" (el cálculo de riesgo debe ocurrir) del "cómo" (por lotes frente a transmisión). Los analistas de negocios deben realizar un mapeo de flujo de valor para identificar tiempos de espera en el horario de lotes que servían la conveniencia operativa en lugar de las reglas comerciales. Al demostrar que los endpoints REST pueden proporcionar retroalimentación inmediata a los suscriptores—reduciendo el tiempo de cotización a vinculación de 24 horas a 30 segundos—justifican los cambios arquitectónicos que de otro modo serían rechazados como "demasiado diferentes del viejo sistema."
¿Cuál es tu metodología para cuantificar y comunicar el riesgo de "desconocidos desconocidos"—reglas tácitas que nunca se activaron durante tu período de observación de datos de muestra pero podrían surgir catastróficamente después de la migración?
Los candidatos presentan frecuentemente a las partes interesadas una falsa confianza basada en tasas de aprobación del 100% contra datos históricos. La respuesta sofisticada reconoce el sesgo de muestreo en los datos heredados y aboga por pruebas de estrés contra escenarios sintéticos. Esto implica generar datos de entrada difusos que ejerciten condiciones límite no vistas en registros de producción, y luego comparar los resultados del sistema COBOL y del nuevo sistema. Además, los analistas de negocios deben establecer un patrón de cortocircuito en la nueva arquitectura: si el microservicio encuentra una estructura de transacción que no puede procesar (indicando una posible regla perdida), debe degradarse de manera ordenada a llamar al envoltorio SOAP heredado (si está disponible) o marcarlo para revisión humana, en lugar de fallar silenciosamente o volver valores nulos. La estrategia de comunicación implica matrices de riesgo probabilísticas que muestran que, aunque se validan el 95% de las reglas, un 5% de incertidumbre residual requiere un período de hiper-cuidado de tres meses con comprobaciones manuales de reconciliación duplicadas.