Muchos programas comienzan con un mandato único: migrar a la nube, refactorizar el monolito, reemplazar el mainframe o adoptar una nueva plataforma. El mandato crea impulso, pero también puede ocultar que distintas partes merecen respuestas distintas.
Empieza por la disposición, no por el destino
Para cada dominio funcional, pregunta si debe conservarse, corregirse, encapsularse, rehospedarse, cambiarse de plataforma, refactorizarse, rediseñarse, reconstruirse, reemplazarse o retirarse. La respuesta debe reflejar valor, frecuencia de cambio, riesgo operativo, salud técnica, dependencias, productos disponibles y capacidad organizacional.
Usa las mismas dimensiones de decisión
- Diferenciación: ¿la capacidad crea ventaja o es una función estándar?
- Presión de cambio: ¿con qué frecuencia cambia el comportamiento y cuánto cuesta hoy?
- Concentración de riesgo: ¿qué costaría una falla, un resultado incorrecto o la falta de especialistas?
- Acoplamiento: ¿qué tan entrelazado está el dominio con datos, jobs, interfaces y otras capacidades?
- Ajuste de reemplazo: ¿un producto satisface las reglas reales sin recrear el legado dentro de su configuración?
La hoja de ruta es un argumento de dependencias
Debe explicar por qué una oleada precede a otra. El trabajo temprano puede aislar interfaces, mejorar observabilidad, extraer datos compartidos o estabilizar pruebas. Esos habilitadores reducen la incertidumbre de todas las oleadas posteriores.
Prefiere compromisos reversibles al inicio
Las primeras fases deben aumentar conocimiento y opciones. Un inventario de reglas, un mapa de dependencias, un modelo de dominios y una base de validación generan valor para múltiples arquitecturas y retrasan las decisiones irreversibles hasta tener mejor evidencia.