Modernice el sistema que nadie se atreve a tocar, una capacidad cada vez.
Décadas de reglas de negocio viven en COBOL, PL/I, Oracle Forms y las primeras versiones de Java y .NET. Recuperamos esas reglas, construimos una red de seguridad de pruebas y trasladamos capacidad a capacidad tras una fachada, con ejecuciones en paralelo y conciliación antes de apagar nada.
Para organizaciones en España que dependen de aplicaciones en mainframe, COBOL u otras tecnologías sin soporte, y no pueden permitirse interrumpir el servicio.
Directores de sistemas y arquitectos empresariales
Responsables de aplicaciones
Expertos funcionales
Equipos de operaciones
Flujo de trabajo ilustrativo
01Evaluar la cartera de aplicacionesPersona
02Recuperar las reglas de negocioAgente
03Construir la red de seguridadSistema
04Reconstruir una parte tras una fachadaSistema
05Ejecutar en paralelo y conciliarSistema
06Analizar las discrepanciasPersona
07Cambiar y retirarPersona
Se evalúa la cartera de aplicaciones y se acuerda el objetivo. Las reglas de negocio se recuperan del código con ayuda de la IA y las verifican personas. Unas pruebas de caracterización forman una red de seguridad. Cada capacidad se reconstruye tras una fachada y funciona en paralelo con el sistema antiguo; las discrepancias se analizan y se corrigen antes de que el responsable de negocio apruebe el cambio y se retire la parte antigua.
Antes y después
Qué cambia en su forma de trabajar
Hoy
Con el sistema
Hoy
Hoy: Cada cambio es un riesgo
Pequeños cambios normativos tardan meses porque nadie puede prever a qué más afectará un cambio.
Con el sistema
Con el sistema: Cambios respaldados por pruebas
Las pruebas de caracterización recogen lo que hace hoy el sistema, de modo que cada cambio muestra su efecto antes de publicarse.
Hoy
Hoy: El conocimiento se jubila
Las personas que entienden el código están cerca de la jubilación, y la documentación dejó de corresponderse con el sistema hace mucho tiempo.
Con el sistema
Con el sistema: Reglas documentadas y verificadas
Las reglas de negocio recuperadas del código se documentan en lenguaje claro y las confirman los expertos funcionales.
Hoy
Hoy: Los planes de cambio de golpe se estancan
Los programas de sustitución completa prometen una única fecha de corte que no deja de moverse mientras los costes crecen.
Con el sistema
Con el sistema: Valor entregado por partes
Las capacidades se trasladan de una en una tras una fachada. Cada parte entra en producción por sí sola y puede revertirse.
Hoy
Hoy: Datos atrapados en estructuras antiguas
Los nuevos servicios y los casos de uso de IA no pueden acceder a los datos sin extracciones frágiles y procesos nocturnos por lotes.
Con el sistema
Con el sistema: Datos disponibles mediante API
Los dominios migrados exponen sus datos mediante API documentadas, conciliadas con el sistema antiguo hasta que este se retira.
Flujo de trabajo
Cómo funciona el flujo de trabajo
Un enfoque de estrangulamiento progresivo (strangler fig): el sistema nuevo crece alrededor del antiguo, capacidad a capacidad. El ciclo entre la ejecución en paralelo y la reconstrucción es donde se concentra la mayor parte del trabajo real.
Flujo de trabajo ilustrativo
7 pasos · 3 controles humanos
Leyenda
Sistema
Agente
Persona
Control humano
Vía de excepción
Modernización de sistemas heredados: flujo de trabajo ilustrativo con ciclo de conciliación
Leer el diagrama como texto
La vía principal va de la evaluación de la cartera y la recuperación de las reglas de negocio, pasando por la construcción de una red de seguridad de pruebas de caracterización y la reconstrucción de una capacidad tras una fachada, hasta la ejecución en paralelo del sistema antiguo y el nuevo y, por último, el cambio y la retirada de la parte antigua.
Las personas aprueban la arquitectura objetivo, verifican cada regla recuperada y aprueban cada cambio: esos son los puntos de control humano.
Cuando la ejecución en paralelo muestra que los resultados difieren, la parte sale de la vía principal para que ingenieros y expertos funcionales analicen la diferencia, y vuelve al paso de reconstrucción hasta que el sistema antiguo y el nuevo concilian.
01
Paso 1: Evaluar la cartera de aplicacionesPersona
Inventario de aplicaciones, mapa de dependencias y flujos de datos, y una decisión para cada aplicación: retirar, mantener, realojar, cambiar de plataforma, reconstruir o sustituir. Se modelan los dominios para encontrar los puntos por los que se puede dividir.
Control humano
Su comité de arquitectura aprueba la arquitectura objetivo y el orden de las partes.
02
Paso 2: Recuperar las reglas de negocioAgente
La comprensión de código asistida por IA lee COBOL, PL/I, JCL, Oracle Forms y versiones antiguas de Java o .NET, y redacta documentación, grafos de llamadas y un catálogo de reglas de negocio.
Control humano
Ingenieros y expertos funcionales verifican cada regla extraída antes de utilizarla como especificación. Las reglas no verificadas se marcan como tales.
03
Paso 3: Construir la red de seguridadSistema
Las pruebas de caracterización se generan a partir de entradas y salidas de producción anonimizadas, de modo que el comportamiento actual, incluidas sus peculiaridades, queda recogido antes de cambiar nada.
04
Paso 4: Reconstruir una parte tras una fachadaSistema
Se coloca una fachada de enrutamiento o una capa de API delante del sistema antiguo. Una capacidad se reconstruye como un servicio nuevo, con sus datos migrados y sincronizados.
05
Paso 5: Ejecutar en paralelo y conciliarSistema
El sistema antiguo y el nuevo procesan las mismas transacciones. Los resultados y los datos se comparan automáticamente y cada diferencia se notifica por regla y por registro.
06
Paso 6: Analizar las discrepanciasPersona
Ingenieros y expertos funcionales deciden si cada diferencia es un defecto del servicio nuevo, un defecto del antiguo o un cambio intencionado, y devuelven la parte para su corrección.
Vía de excepción: Los resultados difieren· Vuelve al paso 4
07
Paso 7: Cambiar y retirarPersona
El tráfico de la capacidad pasa al servicio nuevo a través de la fachada. Tras un periodo estable, la ruta de código antigua y sus datos se retiran y se archivan.
Control humano
El responsable de negocio aprueba cada cambio a la vista de los resultados de la conciliación. La vuelta atrás a través de la fachada sigue disponible hasta la retirada.
Componentes
Qué construiríamos
01
Mapa de cartera y dependencias
Inventario, mapa de interfaces y flujos de datos, y un modelo de dominios que muestra por dónde se puede dividir el sistema.
Salesforce como nuevo front officePlataformaSalesforce
Plataforma de integración y pasarela de API
Cloud o centro de datos de destino
Controles
Controles integrados desde el diseño
Límites de acceso
El análisis del código se ejecuta en un entorno bajo su control, sin enviar código fuente a servicios que usted no haya aprobado. Los datos de producción utilizados para las pruebas se anonimizan antes de salir de la zona de producción.
Revisión humana
Ingenieros y expertos funcionales verifican las reglas recuperadas antes de que se conviertan en especificaciones. El responsable de negocio aprueba cada cambio a la vista de los resultados de la conciliación, con la vuelta atrás disponible.
Trazabilidad
Cada regla del catálogo remite al código del que procede y a la persona que la verificó. Los informes de conciliación se conservan como evidencia de cada cambio.
Protección de datos
La migración de datos sigue un mapeo documentado con recuentos de registros y sumas de verificación, y los datos personales se minimizan en los conjuntos de prueba. Las reglas de conservación acompañan a los datos.
Transparencia de la IA
Cuando la IA redacta documentación o código, el resultado se etiqueta, se revisa y se versiona como cualquier otro artefacto de ingeniería.
Indicadores
Qué mediríamos
Acordamos estas métricas con usted durante la evaluación y las seguimos para cada parte, no solo para el programa en su conjunto.
Qué mediríamos
Indicador
Por qué importa
Cómo lo mediríamos
01Plazo de entrega de los cambios
Por qué importaLa señal más clara de que el sistema es cada vez más fácil de cambiar.
Cómo lo mediríamosTiempo desde la aprobación de una solicitud de cambio hasta su puesta en producción, para las partes antiguas y las modernizadas.
02Estado de la conciliación
Por qué importaMuestra si el servicio nuevo se comporta realmente como el antiguo allí donde debe hacerlo.
Cómo lo mediríamosProporción de transacciones y registros que coinciden durante la ejecución en paralelo, con las diferencias abiertas por causa.
03Cobertura de reglas
Por qué importaLas reglas desconocidas son el principal riesgo de cualquier sustitución.
Cómo lo mediríamosProporción de reglas de negocio recuperadas que han verificado los expertos funcionales y que están cubiertas por pruebas.
04Huella heredada
Por qué importaLa modernización compensa cuando los componentes antiguos se apagan de verdad.
Cómo lo mediríamosCapacidades, rutas de código, procesos por lotes y licencias retirados, con seguimiento por parte.
No se fijan objetivos antes de disponer de una medición de referencia.
Despliegue
Cómo lo implantaríamos
Fase 01
Evaluación
Cartera, dependencias, dominios y riesgos. Elegimos una primera parte que sea importante para el negocio pero que pueda revertirse.
Criterios de salida
Arquitectura objetivo aprobada
Orden de las partes acordado
Acceso a pruebas y datos organizado
Fase 02
Primera parte
Recuperación de reglas, red de seguridad, fachada y una capacidad reconstruida, funcionando en paralelo con el sistema antiguo.
Criterios de salida
Conciliación dentro de la tolerancia acordada
El responsable de negocio aprueba el cambio
Vuelta atrás probada
Fase 03
Parte a parte
Las demás capacidades siguen el mismo camino, cada una con su propia ejecución en paralelo y su propia decisión de cambio.
Criterios de salida
Cada parte conciliada y cambiada
Conocimiento transferido a su equipo
Fase 04
Retirada
Las rutas de código antiguas, los procesos por lotes y los almacenes de datos se archivan y se apagan.
Sistemas de prestaciones, tributos y registros en los que la legislación está codificada en programas de hace décadas y los cambios no dejan de llegar.
Extensiones a medida del ERP y sistemas de planta, trasladados en paralelo a una migración a SAP S/4HANA.
Ejemplo ilustrativo
La gestión de personal de una administración autonómica
Situación
Una administración autonómica gestiona las nóminas y la vida administrativa de su personal con una aplicación en mainframe cuyo conocimiento está en manos de pocas personas, próximas a la jubilación.
Sistema
Nuevos módulos construidos alrededor del sistema existente, una capa de API que los conecta y una ejecución en paralelo de las nóminas hasta que los resultados coinciden, antes de retirar cada parte antigua.
Control humano
El servicio de personal valida cada nómina comparada y aprueba el paso a producción de cada módulo; nada se retira sin su conformidad.
Qué mediríamos
Diferencias entre las nóminas en paralelo, funciones retiradas del sistema antiguo e incidencias tras cada cambio.
España
Modernizar sin perder el hilo
Muchas administraciones y grandes empresas españolas siguen dependiendo de aplicaciones de gestión con décadas de antigüedad, mientras los proyectos financiados por el PRTR han añadido sistemas nuevos que hay que conectar con ellas. El Esquema Nacional de Seguridad exige mantener los sistemas actualizados y con soporte, el Esquema Nacional de Interoperabilidad pide que los datos sigan siendo intercambiables y NIS2 eleva la exigencia sobre la continuidad del servicio.
Modernizamos por fases, con el sistema antiguo y el nuevo en paralelo hasta que los resultados coinciden, y con cada paso documentado para su auditor.
Preguntas sobre la modernización de sistemas heredados
01¿Por qué no sustituir todo el sistema de una vez?
Porque un corte único concentra todo el riesgo en una sola fecha, y el negocio espera años para obtener algún beneficio. Avanzar capacidad a capacidad permite que cada parte se demuestre en una ejecución en paralelo, entre en producción por sí sola y pueda revertirse si es necesario.
02¿Puede la IA traducir nuestro COBOL a Java?
La traducción línea a línea suele producir un código tan difícil de cambiar como el original. Utilizamos la IA para leer y documentar el código antiguo y para redactar reglas y pruebas, y después diseñamos bien los nuevos servicios. Cada regla recuperada la verifican personas antes de utilizarla.
03Nuestros expertos se jubilan. ¿Cómo recogen lo que saben?
Mediante sesiones estructuradas en las que los expertos revisan las reglas recuperadas y las pruebas de caracterización. Su conocimiento queda en documentación y pruebas que permanecen en su equipo, no en nuestras cabezas.
04¿Se aplica también a SAP ECC?
Sí. Los mismos principios se aplican a la adaptación del código a medida y a una migración a SAP S/4HANA: evaluar qué se sigue utilizando, recuperar y probar lo que importa y avanzar por etapas controladas.
05¿Cuánto tiempo funcionan en paralelo el sistema antiguo y el nuevo?
Hasta que los resultados de la conciliación cumplen la tolerancia acordada con el responsable de negocio, y el tiempo suficiente para cubrir procesos periódicos como los cierres mensuales o anuales.