Modernizar un monolito sin apagar el negocio
Modernizar un sistema monolítico no obliga a elegir entre seguir acumulando limitaciones o reemplazarlo todo de una sola vez. Una evolución progresiva permite separar capacidades según las prioridades del negocio y sostener la operación mientras el software cambia.
Existen organizaciones que necesitan modificar con urgencia el sistema que sostiene sus ventas, producción o administración, algo que abordamos en este artículo. Los motivos varían desde incorporar una regla comercial, responder a una exigencia regulatoria, conectar una aplicación hasta acceder de otra manera a los datos. Y si bien al hacerlo el sistema puede seguir funcionando, algo está garantizado: cada intervención futura le llevará más tiempo y esfuerzo.
Entonces, llega el momento de modernizar el sistema.
Frente a esa situación suele instalarse un falso dilema: conservar el sistema tal como está o reemplazarlo completamente. Pero existe un tercer camino: modernizar por partes, donde la arquitectura actual y la nueva pueden convivir mientras se separan funcionalidades concretas y se verifica cada resultado antes de avanzar.
¿El mayor beneficio? No perder operatividad mientras se evoluciona.
La distancia entre reconocer la urgencia y poder actuar
En 2023 el IBM Institute for Business Value, el área de investigación empresarial de IBM, relevó a más de 400 ejecutivos de tecnología sobre sus desafíos. El 83 % consideró central modernizar aplicaciones y datos, pero solo el 27 % afirmó haber avanzado sobre una parte significativa de los sistemas necesarios.
Red Hat, una empresa especializada en software e infraestructura empresarial, consultó en 2023 a mil responsables de IT, desarrolladores backend y arquitectos y encontró que el 85 % de las aplicaciones sería modernizado mediante dos o tres pasos iterativos.
Pero reconocer el problema no alcanza cuando hay que mantener procesos críticos en funcionamiento y decidir qué parte debe cambiar primero. Aquí es donde avanzar por etapas permite abrazar y a la vez delimitar la complejidad.
Transformar sin reemplazar todo
Empecemos por conocer la principal forma de los sistemas a modernizar: el monolito, un diseño informático que reúne procesos, datos, reglas e integraciones que crecieron como una sola cosa con la organización. Su arquitectura se define, en parte, porque el modificar una de sus partes obliga a revisar muchas otras. O también porque el alcance del cambio resulta difícil de anticipar.
En sistemas monolíticos una sustitución completa concentra el riesgo. Puede exigir detener temporalmente la operación, volver a verificar circuitos ya probados y controlar al mismo tiempo la seguridad y confidencialidad de diferentes sectores.
En cambio, la evolución progresiva distribuye esas decisiones. El sistema existente continúa realizando las tareas que todavía resuelve correctamente, mientras nuevos componentes asumen responsabilidades específicas. Cada etapa puede probarse antes de avanzar.
El sistema debe dividirse según el negocio
Para avanzar por partes, primero hay que comprender qué responsabilidades contiene el monolito. Recursos Humanos, Finanzas, Producción o Ventas pueden considerarse dominios: áreas con procesos, datos, reglas y responsables capaces de validar su funcionamiento.
El Diseño Dirigido por el Dominio —DDD, por sus siglas en inglés— ayuda a reconocer esos límites. No se pregunta primero qué módulo conviene separar, sino qué capacidad cumple cada parte del sistema y quién puede confirmar que responde al negocio.
En este análisis la antigüedad puede ser una señal, pero no debería definir por sí sola el orden. También intervienen la criticidad, la frecuencia de los cambios, las dependencias y la posibilidad de entregar un resultado útil. IT puede advertir sobre la obsolescencia en alguno de los dominios, pero la prioridad debe construirse con las áreas que dependen del proceso.
El objetivo es evitar el apagón.
Fuente: Modernizing Legacy Code - While Not Bringing Down Prod - Joel Tosi - NDC Oslo 2025
Veamos por ejemplo a un área transversal a todo tipo de organizaciones: Recursos Humanos. Dentro de esta área pueden distinguirse la liquidación de sueldos, las vacaciones y las licencias. Aunque comparten información, tienen distintas frecuencias y prioridades: los sueldos se procesan todos los meses, mientras que los aguinaldos se liquidan dos veces al año y las vacaciones suelen concentrarse en determinados períodos. Esa diferencia permite modernizar una capacidad sin reemplazar todo el módulo.
La función elegida puede separarse y conectarse con el sistema existente mediante una API, que permite consultar datos o solicitar operaciones mientras las demás responsabilidades continúan dentro del monolito.
A medida que el nuevo componente asume esa función, ambas arquitecturas conviven. Si una interfaz necesita reunir varias operaciones relacionadas, un BFF —Backend for Frontend— puede organizarlas en un único punto de acceso.
El objetivo no es convertir cada proceso en un microservicio, sino separar las capacidades que necesitan evolucionar con mayor autonomía.
Progress OpenEdge como habilitador
Ahora bien, en organizaciones que operan sobre Progress OpenEdge, distintas capacidades pueden sostener esta convivencia.
Por un lado, la replicación mantiene bases de destino actualizadas y permite disponer de una alternativa ante determinadas fallas. Puede integrar una estrategia de continuidad y recuperación. La documentación de OpenEdge describe una base de origen y una base de destino que permanecen sincronizadas.
Por el otro, el particionamiento de tablas —table partitioning— divide una tabla en secciones independientes. Esto facilita la administración de grandes volúmenes de registros y permite trabajar con cada partición como una unidad diferenciada.
Finalmente, la arquitectura multi-tenant permite compartir una base y un esquema mientras determinados datos permanecen aislados por tenant. Como metáfora, un tenant sería un departamento y la base de datos completa, el edificio. También pueden existir espacios comunes para información compartida, sin duplicarla.
Es importante aclarar que un tenant no equivale a un dominio: el dominio representa una responsabilidad del negocio; el tenant define cómo se separan datos dentro de una infraestructura compartida.
En OpenEdge, los datos pueden aislarse lógica y físicamente por tenant o por grupos de tenants.
Las APIs REST permiten exponer datos y operaciones para nuevas aplicaciones o servicios. OpenEdge permite desarrollar servicios que utilizan transporte REST para conectar clientes con recursos y operaciones ABL.
OpenEdge también ofrece interfaces como JDBC y ODBC para que aplicaciones y herramientas externas accedan a la base de datos.
Estas capacidades no son una receta. Su utilidad depende de la arquitectura, los datos y la capacidad elegida para iniciar la modernización.
Cada etapa debe entregar un resultado verificable
Modernizar por partes requiere establecer qué significa completar cada etapa. El nuevo componente debe poder probarse, incorporarse a la operación, observarse y revertirse si no responde como se esperaba.
Los ciclos de integración y entrega continuas —CI/CD— ayudan a organizar compilaciones, pruebas y despliegues. OpenEdge está preparado para integrarse con distintas soluciones de automatización a lo largo de esas etapas.
La inteligencia artificial puede sugerir casos de prueba, pero requiere control humano. En Integra creemos que esta validación se vincula con un rol de desafío vital para la organización: una persona revisa y cuestiona lo producido antes de aceptarlo.
Por definición cada etapa de modernización genera valor cuando reduce un riesgo, acelera una modificación, simplifica una integración o vuelve accesible información que la organización ya poseía. El mejor resultado de cada una es que la organización reciba información que no sabía que tenía y pueda accionar en consecuencia.
La modernización puede revelar patrones, fortalezas, debilidades u oportunidades ocultas dentro de la operación. El valor, en este caso, es la certeza: contar con mejores elementos para decidir qué cambiar, qué conservar y dónde continuar la evolución.
Modernizar un monolito consiste en recuperar, capacidad por capacidad, la posibilidad de modificarlo sin perder la operación que todavía sostiene.
¿Qué parte de tu sistema debería evolucionar primero?
Un diagnóstico técnico permite identificar el dominio con mayor impacto, reconocer sus dependencias y definir una primera etapa de modernización que pueda convivir con la arquitectura actual sin comprometer la operación.
