IXATU Operations: modernizar un sistema legacy empezando por la realidad
Modernizar un sistema legacy suele dibujarse como un viaje entre dos arquitecturas: se define un destino limpio, se diseña una migración y se conduce todo lo anterior hacia allí. El dibujo resulta tranquilizador porque ordena el futuro. También puede ocultar la pregunta más difícil: ¿entendemos de verdad el sistema que queremos sustituir?
IXATU Operations nace de cambiar el orden de esa pregunta. En vez de comenzar por el sistema destino perfecto y obligar después al legacy a encajar en él, parte de la realidad existente, la encapsula, construye producto útil sobre datos reales, obtiene feedback y utiliza ese conocimiento para reemplazar progresivamente el sistema anterior.
La evolución conceptual puede resumirse así:
Platform
target → migration → product → feedback
Operations
reality → product → feedback → knowledge → progressive replacementNo es una renuncia a la arquitectura. Es una forma de hacer que la arquitectura aprenda antes de consolidarse.
El punto de partida no es una lista de tecnologías
La realidad de partida se apoya principalmente en una aplicación de Microsoft Access y en su persistencia histórica en Azure SQL:
Microsoft Access
↓
Azure SQL históricoSería fácil describir el trabajo como «cambiar Access y Azure SQL por React, una API y PostgreSQL». Pero el valor y el riesgo del sistema no están sólo en sus tecnologías. Están también en reglas que nunca llegaron a escribirse, nombres que perdieron su contexto, estados contradictorios, datos históricos acumulados y decisiones operativas que viven en la experiencia de quienes usan el sistema.
Una columna aparentemente sencilla puede mezclar varias épocas del negocio. Un valor anómalo puede ser un error, una excepción aceptada o la huella de una regla que nadie recuerda hasta que deja de cumplirse. Sustituir la tecnología sin descubrir esa semántica sólo cambia el lugar donde reside la incertidumbre.
Por eso el primer objetivo de Operations no es copiar todas las tablas a otro motor. Es construir una frontera segura desde la que observar el sistema real y convertir sus comportamientos en conocimiento explícito.
De IXATU Energy Platform a IXATU Operations
IXATU Energy Platform seguía un enfoque target-first. Primero se describía una plataforma moderna y coherente; después se preparaba la migración necesaria para alimentarla; finalmente, el producto podía empezar a recibir uso y feedback.
Ese enfoque no fue un fracaso. Dejó decisiones y aprendizaje reutilizables: FastAPI como contrato de entrada, React con Vite para la interfaz, PostgreSQL como destino relacional, Liquibase para la evolución de esquemas, Docker para entornos reproducibles y CI/CD para convertir validaciones en un gate repetible. También consolidó arquitectura hexagonal, vertical slices, tests y modelado de dominios como formas de contener el cambio.
Operations conserva ese capital técnico, pero invierte el orden de descubrimiento. Su enfoque reality-first empieza conectando una capacidad acotada al origen real, protege el dominio moderno mediante una frontera explícita y entrega una pequeña utilidad que usuarios reales puedan evaluar. El feedback no llega al final para confirmar el diseño: participa en la construcción del modelo.
La diferencia no consiste en elegir entre una plataforma ideal y un producto improvisado. Consiste en decidir cuándo consideramos que sabemos lo suficiente para fijar una abstracción. Platform formuló un destino valioso. Operations utiliza la realidad para comprobar, corregir y completar ese destino.
La Anti-Corruption Layer contiene la deuda semántica
Acceder al legacy directamente desde cada endpoint o componente trasladaría sus peculiaridades a todo el producto. La alternativa es una Anti-Corruption Layer que concentra la traducción:
Azure SQL legacy
↓
Adapter
↓
Anti-Corruption Layer
↓
modelo moderno
↓
API / UIEl adapter conoce el protocolo de acceso y ejecuta consultas acotadas. La Anti-Corruption Layer interpreta las filas: traduce nombres heredados, normaliza representaciones cuando existe evidencia para hacerlo y conserva la procedencia de las anomalías cuando todavía no la hay. El dominio, la API y la UI trabajan con un vocabulario moderno sin fingir que el origen ya es limpio.
Esta frontera es importante también para los tests. Las rarezas conocidas pueden reproducirse como casos concretos del adapter y del mapping, mientras el dominio se prueba contra contratos comprensibles. Cuando aparece una nueva excepción no hay que contaminar cada capa; hay que decidir cómo se representa en el límite.
Es la misma idea desarrollada en Modernizar una base de datos legacy sin reescribirla, aplicada aquí a un producto concreto y a un proceso continuo de discovery.
El producto también es una herramienta de discovery
Una de las primeras capacidades útiles es un Attention Board de vencimientos. Su misión no es prometer que todos los registros del origen son consistentes. Es mostrar qué requiere atención y permitir que una persona reconozca la regla real detrás de cada caso.
Supongamos que el origen contiene:
Estado = Activo
F_vencimiento = fecha pasadaUn sistema construido desde un modelo ideal podría rechazar el registro porque viola una invariante. Un proceso de limpieza podría corregirlo automáticamente y borrar la evidencia. Operations puede convertirlo en una señal explícita:
Activo con vencimiento pasado — revisarLa inconsistencia deja de ser un bloqueo invisible y se convierte en una conversación verificable con quien conoce la operación. Quizá el estado deba cambiar. Quizá la fecha represente otra cosa. Quizá exista una prórroga no modelada. La interfaz permite distinguir esas posibilidades antes de convertir una suposición en una regla permanente.
Así, el producto no sólo consume conocimiento del dominio: ayuda a producirlo. Cada excepción bien presentada puede terminar como una regla documentada, un caso de test, una mejora del modelo o una decisión de migración.
Aprender con datos reales sin conceder capacidad de escritura
Reality-first no significa operar sin barreras. La primera fase puede trabajar con una identidad de base de datos que tenga capacidad de lectura y deniegue escritura. Esa separación reduce el impacto posible de un defecto en la API, de una consulta equivocada o de una automatización mal dirigida.
La protección debe existir en la infraestructura y no sólo como convención de código. La API puede exponer exclusivamente consultas; el adapter puede limitar su superficie; el despliegue puede recibir el mínimo privilegio necesario. Los logs y fixtures deben evitar datos personales o detalles sensibles, y la documentación pública no necesita connection strings, credenciales, nombres internos ni identificadores operativos.
Read-only no resuelve todos los riesgos: una lectura ineficiente puede degradar el origen y una respuesta puede exponer más datos de los necesarios. Sí establece una frontera inicial clara: podemos aprender de la realidad sin adquirir todavía autoridad para modificarla.
Vertical slices que terminan en feedback humano
El trabajo avanza por capacidades pequeñas que atraviesan todo el sistema:
datos reales
↓
adapter
↓
dominio
↓
API
↓
UI
↓
feedback humanoCada slice debe responder una pregunta operativa concreta. El Attention Board, por ejemplo, obliga a comprobar la consulta real, la interpretación de vencimientos, el contrato de la API, la presentación de estados y la utilidad de la señal para una persona. Completar sólo la capa de acceso a datos o sólo una pantalla con mocks no produciría ese aprendizaje.
Este recorrido amplía la idea de vertical slices de extremo a extremo: aquí el final del slice no es únicamente un smoke técnico, sino feedback humano capaz de corregir el modelo.
Los agentes de IA pueden acelerar implementación, búsqueda de inconsistencias y generación de casos de prueba, pero no sustituyen ese gate. Un Director–Implementer Loop ayuda a mantener separadas propuesta, validación y aceptación cuando parte del trabajo se delega a agentes. La semántica del negocio sigue necesitando evidencia y autoridad humana.
PostgreSQL cambia de momento, no de destino
PostgreSQL no se abandona. Cambia su función dentro de la secuencia.
En el enfoque target-first era:
prerrequisito del productoEn Operations pasa a ser:
destino progresivo de dominios suficientemente entendidosEsto permite que una capacidad genere valor antes de completar una migración global. Cuando un dominio ya tiene vocabulario estable, reglas contrastadas, casos de prueba y criterios de reconciliación, puede empezar a residir en PostgreSQL. Otros dominios pueden seguir leyéndose desde Azure SQL a través de la misma frontera mientras maduran.
La convivencia entre PostgreSQL y Azure SQL aporta técnicas para esa transición: batch, sincronización controlada, reconciliación, outbox o CDC según el caso. Elegir una técnica sofisticada no elimina la incertidumbre semántica; sólo resulta responsable cuando sabemos qué significa equivalencia para el dominio que estamos moviendo.
Sustituir Access sin un big bang
La retirada de Access puede avanzar capacidad a capacidad. Primero, Operations replica una consulta valiosa en modo lectura. Después, usuarios comparan ambos resultados y las diferencias se clasifican. Las reglas descubiertas entran en el dominio y en los tests. Cuando una capacidad moderna demuestra que puede operar con seguridad, deja de depender de la interfaz anterior. Sólo entonces se aborda la siguiente.
El proceso no exige que toda la aplicación legacy se mantenga intacta hasta un gran día de corte ni que toda ella se reescriba antes de entregar valor. Permite reducir su superficie gradualmente:
- observar una capacidad real;
- encapsular sus dependencias legacy;
- publicar una alternativa útil en modo lectura;
- reconciliar resultados y recoger feedback;
- estabilizar reglas y ownership;
- migrar persistencia y, cuando corresponda, habilitar mutaciones acotadas;
- retirar la parte reemplazada de Access.
Los rehearsals antes de mutar sistemas siguen siendo esenciales para delta migration, reconciliación y cutover. No compiten con reality-first. Responden a otra pregunta: cómo ensayar un cambio ya definido. Operations añade la condición previa: antes de sofisticar el ensayo debemos entender suficientemente qué comportamiento estamos intentando preservar o reemplazar.
De la realidad al sistema que merece permanecer
IXATU Operations no reduce la ambición técnica. Conserva los componentes, patrones y disciplina aprendidos con Platform, pero los pone al servicio de una secuencia distinta: realidad, producto, feedback, conocimiento y sustitución progresiva.
El resultado deseado sigue siendo un sistema moderno, coherente y operable. La diferencia es que cada parte de ese sistema debe ganarse su forma mediante datos reales, casos observables y decisiones contrastadas. PostgreSQL continúa siendo destino. La arquitectura continúa importando. Los tests, los contenedores y CI/CD continúan protegiendo el cambio. Lo que desaparece es la obligación de acertar toda la semántica antes de permitirnos aprender.
No estamos renunciando al sistema ideal. Estamos dejando de intentar adivinarlo antes de haber entendido suficientemente el sistema real.