qadRO Technologies
qadRO/Arquitectura/Las cuatro compuertas

Cuatro fases, y en cada una usted decide si seguimos

Así modernizamos una plataforma crítica. Automatizamos el trabajo mecánico de evaluar, transformar y migrar; el criterio de arquitectura sigue siendo nuestro y lo que se acelera es la ejecución. Entre fase y fase hay una compuerta, y ninguna se cruza sin la aprobación de su equipo.

El método

Qué se hace, qué se entrega y qué se aprueba

Una compuerta no es una junta de avance: es un punto donde el trabajo se detiene hasta que hay una decisión explícita. Por eso cada una tiene un entregable concreto asociado — algo que se puede leer y rebatir, no una presentación.

01

Evaluar

Inventario de aplicaciones, dependencias y esfuerzo real de migración, medido sobre el código y la operación actuales — no sobre la documentación, que casi siempre está desactualizada.

Usted recibeMapa de capacidades, duplicidades, esfuerzo por aplicación y caso de negocio
CompuertaAlcance y caso de negocio aprobados

Es la fase donde más seguido aparece la sorpresa incómoda: aplicaciones que nadie recordaba, integraciones que solo existen en producción, y áreas que resultan estar sosteniendo procesos que en el organigrama pertenecen a otras. Por eso se mide sobre el sistema vivo.

Se apoya en descubrimiento del dominio — event storming
02

Planear

Definimos la arquitectura objetivo y agrupamos su cartera en olas según dependencias, riesgo y prioridad de negocio. Aquí se acuerda el diseño, antes de que cambiarlo cueste caro.

Usted recibeArquitectura objetivo, plan por olas y caso de negocio a 24 meses
CompuertaArquitectura y olas aprobadas

La agrupación en olas no es un cronograma: es una decisión de arquitectura. Cada ola debería entregar algo que el negocio pueda usar por sí solo — un flujo de valor completo, no media capa técnica.

Conecta con O-AA axioma 5, alineación por flujo de valor, y axioma 11, particionar en vez de apilar capas
03

Transformar

Refactorización asistida, contenedores, infraestructura como código y migración de datos, ola por ola. Cada regla de negocio queda trazada a su código de origen, y el sistema anterior sigue operando hasta que el nuevo demuestra que puede sustituirlo.

Usted recibeCódigo transformado y ambiente productivo reproducible
CompuertaEnsayo de corte

La trazabilidad de cada regla a su código de origen es lo que hace auditable la migración: cuando alguien pregunte por qué el sistema nuevo calcula algo de cierta manera, la respuesta es una línea del sistema viejo, no una interpretación.

Corresponde al cap. 22 del estándar, infraestructura definida por software
04

Validar

Pruebas de equivalencia funcional y de carga antes de retirar el sistema anterior. Si algo no equivale, no se apaga nada.

Usted recibeEvidencia de equivalencia funcional y de carga
CompuertaAceptación del negocio

Es la compuerta que más protege al cliente y la que más disciplina exige del proveedor, porque es la única que puede detener un apagado ya calendarizado. Que la decisión sea del negocio y no de tecnología no es un detalle de gobierno: es lo que hace que la fecha no le gane a la evidencia.

Conecta con el registro de decisiones — gobierno ágil
El alcance

Qué se transforma

DeA
Mainframe y COBOLServicios cloud-native
Monolitos .NET y JavaAPIs y microservicios
Servidores en sitioInfraestructura como código
Despliegues manualesCI/CD con compuertas de calidad

Los dos últimos renglones no son un extra del proyecto: son el capítulo 22 del estándar O-AA —infraestructura como código, DevOps y confiabilidad del sitio— y son la diferencia entre entregar un sistema nuevo y entregar la capacidad de seguirlo cambiando.

Cómo avanza

Su cartera entra por lotes y sale certificada

Cada pieza es una aplicación de su plataforma heredada, y cambia de forma en cada estación: se mide, se agrupa en su ola, se transforma y se despliega, y sale certificada.

El reparto del trabajo es explícito, y conviene que lo sea: el agente ejecuta la evaluación; el diseño y la transformación son de agente y arquitecto; la aceptación es de personas. Nada avanza hasta que su equipo sella la compuerta.

Esa última frase es la que hace la diferencia entre automatizar y delegar. Se automatiza el trabajo mecánico —inventariar, trazar dependencias, transformar código repetitivo— y se conserva humano el criterio: qué arquitectura se persigue, qué riesgo se acepta y cuándo se apaga un sistema.

Lo que sigue

Las compuertas terminan. La arquitectura no.

Un programa de modernización tiene final: el día que se apaga el último sistema anterior. Pero un sistema no nace heredado — se vuelve heredado el día que su arquitectura deja de cambiar. Si al cerrar el programa se disuelve el equipo y se archiva el diseño, el reloj vuelve a correr.

Por eso la modernización y la arquitectura ágil son dos cosas distintas, no una dentro de la otra. La primera lo saca del hoyo una vez; la segunda es la capacidad de no volver a caer. Salir de un sistema heredado es una de las nueve puertas de entrada al estándar, no el estándar entero.

El método está publicado para que se pueda revisar antes de firmar, no después. Si algo de aquí no le cuadra para su caso, esa es exactamente la conversación que hay que tener primero.