Gobernar la modernización de sistemas heredados: Supervisión para el patrón Strangler Fig

La muerte del reemplazo de golpe

Por qué las fases secuenciales no reflejan la realidad

El pensamiento tradicional de proyectos imagina la modernización como una secuencia: primero entender el sistema heredado, luego decidir qué construir, luego construirlo, luego migrar. Cada fase se completa antes de que comience la siguiente. Los puntos de control de gobernanza marcan las transiciones.

Este modelo mental tenía sentido cuando los sistemas se reemplazaban en migraciones de golpe — un fin de semana, todo cambia. Pero los reemplazos de golpe son cada vez más raros, y por buenas razones. Concentran el riesgo en un solo momento. Requieren entender todo el sistema heredado antes de reemplazar cualquier parte. Exigen que el nuevo sistema esté completo antes de que alguien lo use.

El patrón strangler fig funciona diferente. Identificas un área de funcionalidad, entiendes esa área, construyes su reemplazo, migras a sus usuarios, y desmantellas esa pieza del sistema heredado — mientras el resto sigue funcionando. Luego lo haces de nuevo con otra área.

Esto significa que en cualquier momento dado, diferentes áreas están en diferentes etapas. Todavía estás descubriendo algunas partes del sistema heredado mientras ya estás migrando usuarios de otras partes. La gobernanza que asume fases secuenciales no puede ver esto claramente.

Cuatro flujos de trabajo concurrentes

En lugar de fases, piensa en la modernización como cuatro tipos de trabajo ocurriendo concurrentemente, cada uno aplicándose a diferentes áreas del sistema en cualquier momento dado.

Trabajo de descubrimiento

Entender qué hace realmente el sistema heredado. Esto es

trabajo artesanal: investigación, hipótesis, verificación. Los sistemas heredados acumulan comportamiento durante décadas. La documentación describe intención, no realidad. Los desarrolladores que entendían las peculiaridades se han ido.

El descubrimiento ocurre a lo largo del proyecto, no solo al principio. Cuando empiezas a trabajar en una nueva área, descubres cosas sobre esa área. Cuando la migración revela comportamiento inesperado, estás haciendo descubrimiento. Cuando los usuarios reportan que el nuevo sistema maneja algo diferente, el descubrimiento explica por qué.

Preguntas de gobernanza para trabajo de descubrimiento:

• ¿Qué áreas estamos investigando actualmente?
• ¿Qué hemos aprendido que nos sorprendió?
• ¿Estamos hablando con las personas que realmente usan cada área?
• ¿El comportamiento descubierto se está documentando para áreas futuras?
• ¿Estamos encontrando cosas que afectan áreas que pensábamos que entendíamos?

Trabajo de decisión

Elegir qué debería hacer el reemplazo. No todo comportamiento heredado merece replicación. Algunos comportamientos son lógica de negocio esencial; otros son complejidad accidental de restricciones antiguas; otros son errores que los usuarios han sorteado por tanto tiempo que se han convertido en expectativas.

El trabajo de decisión ocurre para cada área mientras te preparas para construir su reemplazo. También puede ocurrir cuando la construcción revela que decisiones anteriores estaban equivocadas, o cuando la migración saca a la luz comportamientos que nadie anticipó.

Preguntas de gobernanza para trabajo de decisión:

• ¿Qué áreas tienen decisiones pendientes?
• ¿Quién está involucrado en estas decisiones? ¿Está representado el negocio?
• ¿Qué compromisos estamos haciendo, y son explícitos?
• ¿Estamos distinguiendo “cómo funciona” de “cómo debería funcionar”?
• ¿Se están documentando las decisiones para que áreas futuras puedan aprender de ellas?

Trabajo de construcción

Construir los componentes de reemplazo. Una vez que entiendes un área y has decidido qué debería hacer su reemplazo, la construcción a menudo sigue patrones de oficio — enfoques establecidos, frameworks estándar, arquitecturas familiares. La novedad estaba en el descubrimiento y la decisión; la construcción es ejecución.

Múltiples áreas pueden estar en construcción simultáneamente. Algunas pueden estar casi completas; otras apenas empezando. La gobernanza necesita rastrear cada una sin asumir que todas están en la misma etapa.

Preguntas de gobernanza para trabajo de construcción:

• ¿Qué áreas están en construcción?
• ¿Para cada una, puede el equipo estimar el trabajo restante con confianza?
• ¿Se están construyendo las áreas de manera que permita migración incremental?
• ¿Las pruebas de integración están validando comportamiento contra datos reales del sistema heredado?
• ¿La construcción está revelando vacíos en descubrimiento o decisiones anteriores?

Trabajo de migración

Mover usuarios y datos del área heredada a su reemplazo. Este es a menudo el trabajo más difícil — no técnicamente, sino operativamente. Ejecutar sistemas en paralelo, sincronizar datos, cambiar tráfico gradualmente, manejar casos límite donde lo viejo y lo nuevo se comportan diferente.

El trabajo de migración puede sacar a la luz problemas que te envían de vuelta al descubrimiento, decisión o construcción. Un área que pensabas que estaba completa resulta manejar un caso que no conocías. Los usuarios reportan comportamiento del que dependían que el reemplazo no proporciona. La integración entre la nueva área y los componentes heredados restantes no funciona como se esperaba.

Preguntas de gobernanza para trabajo de migración:

• ¿Qué áreas están en migración?
• ¿Qué porcentaje del tráfico/usuarios ha cambiado a cada nueva área?
• ¿Qué problemas han surgido, y cómo se están abordando?
• ¿Estamos en camino de desmantelar la pieza heredada?
• ¿Qué está bloqueando la migración completa para cada área?

Gobernar el portafolio de áreas

La gobernanza efectiva de modernización rastrea un portafolio de áreas, cada una en su propia etapa. Esto se parece menos a la supervisión tradicional de proyectos y más a la gestión de portafolios.

Una vista de gobernanza útil muestra:

Área	Descubrimiento	Decisiones	Construcción	Migración	Bloqueos
Facturación	Completo	Completo	Completo	60% migrado	Latencia en sincronización
Autenticación	Completo	En progreso	No iniciado	—	Esperando revisión de seguridad
Reportes	En progreso	—	—	—	Usuario clave de vacaciones
Inventario	No iniciado	—	—	—	Depende de Facturación

Esta vista revela varias cosas que el rastreo tradicional de proyectos no detecta:

Dependencias entre áreas. Algunas áreas no pueden empezar hasta que otras completen. Algunas comparten componentes. La gobernanza puede ver estas relaciones.

Dónde el trabajo está estancado. Un área que ha estado “en progreso” en decisiones por meses necesita atención. Un área que está al 40% de migración y no se ha movido en semanas tiene un problema.

Asignación de recursos. Si demasiadas áreas están en construcción y nada está migrando, los equipos pueden estar evitando el trabajo operativo difícil. Si todo está en descubrimiento y nada se está construyendo, la investigación puede haberse convertido en excusa para la inacción.

Progreso real. Las áreas migradas con piezas heredadas desmanteladas representan progreso real. Todo lo demás es trabajo en progreso.

Cuando los flujos de trabajo interactúan

La naturaleza concurrente de la modernización strangler fig significa que los descubrimientos en un flujo afectan el trabajo en otros.

El descubrimiento revela que una decisión estaba equivocada. Un área en construcción resulta necesitar capacidades que decidiste no incluir. ¿Revisas la decisión, extiendes el área, o aceptas una brecha?

La construcción expone descubrimiento incompleto. Construir el reemplazo saca a la luz comportamientos heredados que nadie conocía. ¿Pausas la construcción, documentas y decides rápido, o construyes lo que sabes y manejas el resto después?

La migración prueba que el reemplazo es inadecuado. Los usuarios en producción encuentran problemas que las pruebas no detectaron. ¿Vuelves atrás, arreglas hacia adelante, o ejecutas ambos sistemas más tiempo?

La gobernanza que trata cualquier movimiento hacia atrás como fracaso crea incentivos para ocultar problemas. La gobernanza que acepta la iteración mientras monitorea los estancamientos genuinos permite a los equipos responder a la realidad.

Señales a través de los flujos de trabajo

En lugar de rastrear porcentaje completado, la gobernanza efectiva monitorea señales que revelan la salud real.

Señales saludables

• Las áreas se mueven a través de las etapas a un ritmo razonable — no estancadas indefinidamente en ninguna etapa.
• Las sorpresas descubiertas llevan a decisiones explícitas, no a expansión silenciosa del alcance.
• La velocidad de construcción es aproximadamente consistente una vez que las áreas llegan a esa etapa.
• Los porcentajes de migración aumentan con el tiempo; las áreas eventualmente llegan al 100% y las piezas heredadas se apagan.
• Los problemas salen a la luz temprano y se abordan; no se acumulan silenciosamente.

Señales de advertencia

• Múltiples áreas estancadas en descubrimiento sin que se tomen decisiones.
• Decisiones siendo tomadas sin participación del negocio.
• Construcción ocurriendo pero ningún área llegando a migración.
• Migración estancada en porcentajes parciales — la ejecución en paralelo volviéndose permanente.
• Equipos reportando estado verde mientras nada realmente va a producción.
• Trabajo de descubrimiento expandiéndose a áreas aún no programadas, sugiriendo evasión de áreas más difíciles.

La pregunta del presupuesto

“¿Cuánto costará esto?” es difícil de responder para la modernización strangler fig porque no estás construyendo una sola cosa — estás reemplazando un sistema pieza por pieza.

Enfoques que funcionan:

• Presupuesto por área. Estima y financia cada área por separado. Las áreas tempranas informan las estimaciones para áreas similares posteriores. La variación se promedia a través del portafolio.

• Tasa de consumo en el tiempo. En lugar de preguntar “cuánto en total,” pregunta “cuánto por mes” y “por cuánto tiempo.” Rastrea si la tasa de consumo está produciendo progreso de migración proporcional.

• Priorización basada en valor. No todas las áreas son igualmente valiosas. Prioriza áreas que alivien más dolor, reduzcan más riesgo, o habiliten más oportunidad. Detente cuando las piezas heredadas restantes no valgan la pena reemplazar.

Enfoques que fracasan:

• Exigir costo total por adelantado. No sabes cuántas áreas existen hasta que empiezas. No sabes qué tan difícil es cada área hasta que trabajas en ella. Las estimaciones totales hechas temprano estarán equivocadas.

• Tratar todas las áreas como equivalentes. Algunas áreas son simples; otras están profundamente entrelazadas. La gobernanza que asume esfuerzo uniforme malinterpreta el trabajo.

• Esperar hasta que todo esté “terminado.” Con strangler fig, puedes parar cuando las áreas restantes no valen el esfuerzo. La gobernanza debería preguntar “¿vale la pena esta área?” no solo “¿está terminada?”

Los marcos de gestión no ofrecen nada para el trabajo real

Las organizaciones a menudo recurren a marcos de gestión familiares cuando gobiernan la modernización. Esto es comprensible — los ejecutivos quieren estructuras que reconocen. Pero aquí hay una verdad incómoda: los marcos de gestión no tienen nada que ofrecer para el trabajo real de desarrollo de software. No ayudan a los desarrolladores a entender código heredado, tomar decisiones arquitectónicas, escribir mejores pruebas o migrar usuarios de forma segura.

SAFe, LeSS, PMI, PRINCE2 y marcos similares se ocupan de la coordinación organizacional, asignación de recursos, estructuras de reporte y comunicación con stakeholders. Estas son preocupaciones legítimas — pero están completamente separadas del desarrollo de software. Ningún marco de gestión te enseña cómo refactorizar una base de código heredada, diseñar una fachada strangler, validar equivalencia de comportamiento o manejar migración de datos. Ninguna ceremonia de planificación produce mejor código. Ningún acta de proyecto mejora tu cobertura de pruebas.

Esto importa para la modernización de sistemas heredados porque la dificultad real está enteramente en el trabajo técnico: entender qué hace realmente el sistema heredado, decidir qué comportamiento preservar, construir reemplazos que funcionen correctamente y migrar sin interrumpir a los usuarios. Los marcos de gestión guardan silencio sobre todo esto.

Lo que los marcos de gestión abordan:

• Cómo reportar progreso a los stakeholders
• Cómo coordinar múltiples equipos
• Cómo asignar presupuestos entre iniciativas
• Cómo estructurar comités de gobernanza
• Cómo escalar decisiones

Lo que los marcos de gestión no abordan — y no pueden:

• Cómo investigar comportamiento heredado no documentado
• Cómo diseñar reemplazos que puedan ejecutarse junto a sistemas heredados
• Cómo probar que lo viejo y lo nuevo producen resultados equivalentes
• Cómo migrar usuarios incrementalmente sin pérdida de datos
• Cómo manejar los casos límite que solo salen a la luz en producción

Enfoques que realmente ayudan al trabajo:

La visualización estilo Kanban funciona para rastrear áreas a través de etapas — pero esto es una técnica de visualización, no un marco de gestión. Los equipos se benefician de ver elementos de trabajo moverse a través de columnas con límites WIP. El tablero no te dice cómo hacer el trabajo; te ayuda a ver dónde el trabajo está estancado.

Cynefin (Dave Snowden) ayuda a la gobernanza a entender por qué diferentes flujos de trabajo necesitan diferentes enfoques — el trabajo de descubrimiento vive en el dominio complejo; el trabajo de construcción es complicado. Pero nuevamente, esto es una herramienta de sensemaking para elegir enfoques, no una prescripción para ejecutarlos.

El pensamiento de Opciones Reales trata cada área como una opción — invertir en descubrimiento compra la opción de construir. Esto ayuda con decisiones de priorización, no con la construcción real.

El patrón es claro: los enfoques útiles te ayudan a ver, decidir o priorizar. Ninguno de ellos te ayuda a hacer realmente el trabajo técnico. Eso requiere habilidad de ingeniería, conocimiento del dominio y experiencia práctica — nada de lo cual viene de marcos de gestión.

El peligro:

Cuando las organizaciones invierten fuertemente en la adopción de marcos de gestión, a menudo creen que han abordado el desafío de modernización. No lo han hecho. Han abordado el desafío de coordinación y reporte — que es real, pero mucho más pequeño que el desafío técnico. Un proyecto perfectamente gobernado con capacidad técnica inadecuada seguirá fracasando. Un proyecto sin gobernanza con excelente ejecución técnica podría tener éxito a pesar del caos.

La paciencia para el progreso incremental

La modernización strangler fig produce valor incremental — cada área migrada es una pieza del sistema heredado que ya no necesita mantenimiento, una pieza de deuda técnica retirada, un grupo de usuarios en un mejor sistema. Pero no produce hitos dramáticos.

Los ejecutivos acostumbrados a grandes lanzamientos de proyectos pueden encontrar esto insatisfactorio. No hay momento de cortar la cinta — solo el apagamiento gradual de las luces del sistema heredado. La gobernanza que demanda hitos visibles puede crear presión para agrupar trabajo artificialmente, perdiendo la reducción de riesgo que la migración incremental proporciona.

Las organizaciones que modernizan exitosamente son aquellas donde la gobernanza valora el progreso sostenible sobre los hitos teatrales. Celebran cada pieza heredada desmantelada. Confían en que el sistema está mejorando incluso cuando no hay un solo momento al que apuntar. Entienden que el desarrollo de software incluye trabajo significativo de diseño — y que el trabajo de diseño aplicado área por área, con aprendizaje entre áreas, produce mejores resultados que intentar diseñar todo por adelantado.

El sistema heredado tomó años en construirse y décadas en evolucionar. La higuera estranguladora también tomará tiempo — pero producirá valor en el camino, no solo al final.