Modernización Legacy en banca tier-1

Contexto

Una entidad financiera tier-1 europea ejecuta sus procesos de cómputo financiero crítico (riesgo, tesorería, valoración) sobre un core Oracle con lógica en PL/SQL, un grid IBM Spectrum Symphony y sistemas de mercado como Murex y Algorithmics. Es una operación 24/7: no existe una ventana en la que el sistema pueda detenerse.

El core había crecido durante años en forma de monolitos PL/SQL difíciles de evolucionar, con despliegues manuales y procesos cuyo tiempo de ejecución ya no cabía en las ventanas de negocio. El objetivo fue reducir esos tiempos y modernizar la forma de entregar software sin tocar la disponibilidad.

El reto

Tres restricciones marcaron el proyecto:

• Procesos de cómputo financiero crítico con tiempos insostenibles, que bloqueaban operaciones del negocio.
• Monolitos Oracle con PL/SQL crítico acoplado, sin posibilidad de cambiar una pieza sin arriesgar el conjunto.
• Operación 24/7 e integraciones con Murex y Algorithmics que debían mantenerse intactas durante toda la transición.

Enfoque por fases

La modernización se ejecutó como una sucesión de fases controladas, cada una con validación y capacidad de reversión.

1. 01

   Diagnóstico del código y del grid

   Identificación del PL/SQL que concentraba el tiempo de cómputo y de la utilización real de los recursos del grid.

2. 02

   Refactorización y desacoplamiento

   Reescritura del PL/SQL crítico y separación progresiva de los monolitos Oracle en componentes desplegables de forma independiente.

3. 03

   Pipeline DevOps y GitOps

   Automatización de los despliegues: cada cambio versionado, probado y promovido de forma reproducible.

4. 04

   Migración por fases sin downtime

   Puesta en producción componente a componente, manteniendo las integraciones con Murex y Algorithmics y la operación 24/7.

Arquitectura y estrategia

El principio fue el mismo que aplicamos en el resto de proyectos de banca tier-1: extender y desacoplar en vez de reemplazar. El grid Symphony y el core Oracle siguen en su sitio; lo que cambia es cómo se reparte el trabajo (utilización del grid) y cómo se entrega el software (pipeline automatizado en lugar de despliegues manuales).

Resultados medibles

Resultados validados en producción:

Cifras agregadas y anonimizadas por acuerdo de confidencialidad. Fuente: proyectos de Vermont Solutions.

Lecciones aplicables

• En un core 24/7 la migración por fases con capacidad de reversión no es opcional: es la única forma de avanzar sin exponer el negocio.
• Automatizar la entrega (DevOps + GitOps) reduce errores y hace que cada despliegue sea predecible y auditable.
• Medir la utilización real del grid antes de ampliarlo evita inversiones innecesarias: el margen estaba en el reparto, no en el hardware.

Marco regulatorio

El cómputo de riesgo en banca tier-1 es materia supervisada; la modernización se diseñó para reforzar la evidencia de control.

• Basilea III/IV: cálculos de capital y riesgo dentro de las ventanas exigidas.
• DORA (Art. 28): trazabilidad de cambios, resiliencia operativa y gestión de terceros tecnológicos.
• BCBS 239: agregación de datos de riesgo con procesos documentados y reproducibles.

Preguntas frecuentes

Contenido relacionado

• Servicio: modernización de sistemas legacy →
• Servicio: HPC y Grid Computing →
• Producto: add-on para IBM Spectrum Symphony →
• Caso: extensión dinámica del GRID a la nube en banca →