Puntos clave
- Se logró impulsar la transición con un desacoplamiento gradual sin reemplazar por completo el sistema existente.
- Un sistema de datos en tiempo real basado en CDC sustituyó el acceso directo al mainframe.
- En lugar de REST, se usó GraphQL para eliminar múltiples capas BFF y asegurar flexibilidad y mantenibilidad.
- Una estructura de equipos centrada en dominios (Team Topologies) dejó claras las responsabilidades y la propiedad de cada equipo.
- Con despliegues graduales y automatización, el sistema se migró sin riesgo y entregando valor de forma estable.
Caso de adopción: la mitad del sistema sobrevivió incluso durante una caída
Ocurrió una falla del mainframe, pero gracias a una arquitectura de streaming basada en la nube, la nueva UI siguió funcionando con normalidad.
Incluso cuando el sistema existente estaba caído, el nuevo sistema mantuvo la experiencia del cliente y demostró su resiliencia.
Estrategia principal: desacoplamiento en múltiples capas
- Diseño guiado por dominio (DDD): se reorganizó el modelo centrado en el mainframe para hacerlo más afín al negocio.
- Team Topologies: se pasó a una organización de equipos centrada en capacidades funcionales.
- Arquitectura basada en eventos: se redujo el acoplamiento entre sistemas mediante un enfoque asíncrono.
- Change Data Capture (CDC): se detectan cambios de datos en tiempo real para conectar el legado con el sistema nuevo.
Estructura anterior: Unified Web Portal 1.0
Se integraban diversos datos del mainframe mediante ETL para ofrecerlos en una base de datos SQL y en SaaS,
pero surgieron problemas como falta de tiempo real, deterioro en la calidad de los datos y llamadas directas al mainframe.
Problemas
- Retraso de datos causado por ETL
- Conexión síncrona con el mainframe poco elástica
- Creación de una enorme cantidad de APIs BFF
- Cuellos de botella y retrasos en los releases por la estructura organizacional
- En picos de tráfico, la sobrecarga del mainframe provocaba caídas del servicio completo
Definición de nuevos objetivos
Objetivos técnicos: separar el mainframe y la web, eliminar el BFF y garantizar autonomía a los equipos.
Objetivos de negocio: reducir consultas al call center, bajar costos de licencias y mejorar la satisfacción del cliente.
Resumen de la nueva arquitectura
- El mainframe sigue siendo el system of record
- CDC → Kafka → base de datos de dominio (CosmosDB)
- GraphQL + API REST → BFF → UI
- Todos los componentes están conectados mediante una estructura basada en eventos y un message broker
Paso 1: Change Data Capture
- Se construyó un system of reference con streaming de datos en tiempo real
- Mainframe → Kafka → transformación → base de datos de dominio → exposición vía API
- Se aseguró una estructura de datos flexible, no dependiente del esquema del mainframe
Paso 2: Domain-Driven Design + GraphQL
- Se definió el modelo de dominio con DDD (Entity, Command, Event)
- Cada dominio se estructuró como un nodo GraphQL y se creó un supergraph mediante schema stitching
- Se soportó una estructura de consultas optimizada para obtener solo los datos necesarios
Cambio en la estructura organizacional: Team Topologies
- Reorganización en stream-aligned teams centrados en capacidades funcionales
- Las áreas complejas (por ejemplo, la integración con el mainframe) fueron gestionadas por equipos dedicados
- Se operó un equipo de Enablement para el soporte técnico
Expansión basada en eventos: eventos de dominio internos + patrón Saga
- El patrón Outbox genera eventos cuando cambia el dominio
- Parallel Saga sincroniza el trabajo del mainframe con CDC
- Se construyeron workflows basados en máquinas de estado → capaces de responder a flujos complejos
Retos
- Fue necesario cambiar la percepción interna sobre la adopción de una estructura basada en eventos
- En una estructura asíncrona, asegurar la observabilidad era indispensable
- Los trabajos batch del mainframe → provocaban sobrecarga en el pipeline de CDC
- Complejidad en la gestión del schema de GraphQL y dudas sobre adoptar un enfoque federated
- Las preocupaciones transversales, como autenticación y logging, se gestionaron con paquetes separados y automatización
Estrategia de releases: release train + feature flags
- Cada equipo despliega de forma independiente y se integra en el repositorio de despliegue
- Se configuró un pipeline de despliegue por entorno con Kustomize
- Con feature flags se separaron los releases funcionales y de seguridad, manteniendo desarrollo trunk-based
Aplicación de arquitectura híbrida
- UWP 1.0 y UWP 2.0 coexistieron mientras se realizaba una transición gradual
- Con edge routing, las solicitudes de los usuarios se fueron cambiando de forma secuencial al nuevo sistema
Conclusión: construcción de una plataforma evolutiva
- Separación completa entre frontend y mainframe
- Mayor velocidad y estabilidad con una estructura centrada en equipos
- Mejora en la satisfacción del cliente y en los costos operativos
- Se aseguró una base flexible que incluso permite reemplazar el mainframe en el futuro
1 comentarios
La mejora gradual y la extracción progresiva de microservicios son muy importantes... Al ver textos como este, uno siente que el PM que lidera ese proyecto es realmente importante e impresionante. Gestionar tantísimas cosas da vértigo.