Puede que la frase más peligrosa en la gestión de software sea «deberíamos reescribirlo entero». Se dice de sistemas que lo merecen: quince años de antigüedad, sin documentar, sostenidos por las dos personas que recuerdan por qué el módulo de facturación se comporta así. También se dice de sistemas que sostienen el negocio: pedidos, existencias, facturación y nóminas pasan por ellos cada día, y la empresa se para cuando ellos se paran. La promesa de la reescritura seduce porque es limpia. Un sistema nuevo, hecho bien esta vez, y un día se acciona el interruptor. El historial es menos limpio: las reescrituras de golpe de sistemas en funcionamiento fallan con la frecuencia suficiente, y con un coste suficiente, como para tratar la frase como una afirmación que exige pruebas y no como un plan.
Existe una alternativa con una tasa de finalización mucho mejor: la sustitución incremental - el patrón strangler fig, llamado así por la higuera estranguladora que crece alrededor de un árbol anfitrión hasta que el árbol ya no sostiene nada. El sistema nuevo crece alrededor del viejo, asume un módulo cada vez, y el viejo se retira cuando ya no se enruta nada hacia él. Es menos espectacular que una reescritura. De eso se trata.
Por qué fallan las grandes reescrituras
Los modos de fallo son tan previsibles que tienen nombre. El primero es el efecto del segundo sistema: el equipo que reconstruye arrastra a la reconstrucción todas las ambiciones que el sistema anterior reprimió. Un proyecto acotado como «lo que hace el sistema viejo, sobre una pila moderna» se convierte en silencio en «lo que hace el sistema viejo, más los informes que comercial siempre quiso, más una arquitectura de plugins, más multitenencia por si algún día hace falta». El alcance crece justo en el proyecto donde el alcance debía estar cerrado, porque el sistema viejo está ahí como recordatorio diario de todo lo que nunca hizo.
El segundo es la ventana de funcionalidades congeladas. Una reescritura solo sigue siendo una reescritura si el objetivo se queda quieto, así que el sistema viejo se congela mientras se construye el nuevo. Pero el negocio no se congela. Dieciocho meses son mucho tiempo para decirle a comercial que no habrá nada nuevo, y casi ninguna empresa mantiene esa línea - así que los cambios acaban entrando igualmente en el sistema viejo, la reescritura persigue un objetivo móvil y la distancia entre ambos se ensancha justo en el momento en que debía estar cerrándose.
El tercero son los datos que nadie entiende. Un sistema que lleva una década sosteniendo un negocio no está descrito por su documentación; está descrito por su comportamiento. El redondeo raro en el cálculo del descuento, el código de estado que existe para un cliente de 2016, el proceso nocturno que repara lo que rompe el turno de día - nada de eso vive en una especificación, porque el sistema viejo es la especificación. Una reescritura de golpe descubre esos requisitos en el peor momento posible: después del cambio, en producción, en forma de incidencias de soporte. Ese descubrimiento suele ser lo que mata el proyecto.
Qué aspecto tiene realmente la sustitución incremental
El patrón strangler tiene pocas piezas móviles. Primero, se coloca una fachada delante del sistema viejo: una capa de enrutado que recibe todas las peticiones y, el primer día, las pasa todas tal cual. No cambia nada salvo que ahora la puerta de entrada es suya. Ese es todo el primer hito, y vale más de lo que parece: a partir de aquí, dónde vive cada pieza de funcionalidad es una decisión de enrutado que usted controla, invisible para quien usa el sistema. La fachada puede ser una pasarela de API, un proxy inverso o un servicio ligero propio - la tecnología importa mucho menos que el hecho de tenerla.
Después la sustitución avanza módulo a módulo. Una pieza acotada del sistema - la tarificación, por ejemplo - se reconstruye como servicio nuevo sobre una pila deliberadamente aburrida, porque una modernización es el último sitio donde gastar el presupuesto de novedad. El módulo nuevo funciona en paralelo con el viejo: ambos reciben las mismas entradas, ambos producen salidas, y las salidas se comparan. La respuesta del módulo viejo es la que ven los clientes; la del módulo nuevo es una sombra, que se registra y se coteja.
El cambio se hace por módulo, y solo cuando los números coinciden: no en la fecha de la hoja de ruta, no cuando la demostración se ve bien, sino cuando el informe de diferencias ha estado limpio, o explicablemente no limpio, durante el tiempo suficiente para confiar en él. Entonces la fachada enruta la tarificación al módulo nuevo, el viejo sigue en marcha como respaldo y la atención pasa al siguiente módulo. Cada paso es pequeño, medido y reversible - que es exactamente lo que no es un cambio de golpe.
El sistema viejo no es el enemigo. Es la especificación, el oráculo de pruebas y el respaldo - hasta el día en que ya no se enruta nada hacia él.
Cómo elegir el primer módulo
El primer módulo carga con una parte desproporcionada del destino del proyecto, porque su trabajo real es demostrar la maquinaria - la fachada, la ejecución en paralelo, la conciliación, el cambio - sobre algo que no puede hundir a la empresa. Tres filtros hacen casi todo el trabajo. Bajo acoplamiento: elija algo que comparta el menor número de tablas y llamadas con el resto del sistema - generación de documentos, notificaciones, un flujo de informes - para no tener que deshacer todo el nudo el primer día. Mucho dolor: elija algo de lo que la gente se queje activamente, para que el primer cambio produzca un resultado que alguien de fuera del proyecto note. A menudo el mejor candidato es el flujo de trabajo que el equipo ya parchea con exportaciones y reintroducción manual de datos: la capa de hojas de cálculo alrededor de un sistema heredado es el mapa de dónde duele. Medible: elija algo cuya salida pueda compararse de forma mecánica - documentos generados, totales calculados, tiempos de respuesta - porque toda la disciplina del cambio depende de tener números que cuadrar.
Lo que el primer módulo no debe ser es impresionante. Pequeño, molesto y contable gana a grande y estratégico. Un primer módulo que tarda seis semanas y cambia sin incidentes compra más credibilidad que uno que tarda seis meses y quizá lo consiga. Los módulos estratégicos llegan después, cuando la maquinaria ya ha sobrevivido al contacto con producción.
El problema de los datos
El código es la mitad fácil de una modernización. La mitad difícil son los datos, y el principio rector es contundente: el sistema viejo sigue siendo la fuente de verdad hasta que el nuevo demuestre lo contrario, módulo a módulo. En la práctica eso significa que los datos fluyen en un solo sentido mientras un módulo está en sombra - sincronizados del viejo al nuevo mediante captura de cambios si la base de datos antigua lo permite, o mediante un proceso nocturno por lotes si es lo que da la plataforma. El módulo nuevo lee su copia sincronizada, calcula sus respuestas y no escribe nada de lo que dependa nadie.
Entre la sombra y el cambio está el periodo de conciliación, y es donde afloran los requisitos reales. Ambos sistemas procesan el trabajo del mismo día; un proceso de comparación coteja los resultados; cada discrepancia se investiga. La mayoría de las discrepancias son el sistema nuevo equivocándose de formas que ninguna especificación habría captado: el redondeo sin documentar, el cliente tratado como caso especial. Investigadas de una en una, en sombra, son lecciones baratas. Esos mismos descubrimientos después de un cambio de golpe son caídas del servicio.
Algunas discrepancias apuntan en sentido contrario: el sistema viejo estaba equivocado, y el negocio lleva años absorbiendo el error en silencio. Eso son decisiones, no errores - ¿se conserva el comportamiento antiguo por continuidad, o se corrige y se avisa a los afectados? Cualquiera de las dos respuestas puede ser la buena; lo que está mal es tomar la decisión por accidente, que es justo lo que ha hecho toda reescritura que nunca ejecutó los dos sistemas en paralelo. Solo en el cambio se transfiere la propiedad de los datos del módulo: el sistema nuevo pasa a escribir, y el proceso de conciliación sigue funcionando un tiempo más como alarma.
Cuándo la reescritura es la decisión correcta
La honestidad exige plantear el caso contrario, porque la sustitución incremental no es gratis: la fachada, la sincronización y la ejecución en paralelo cuestan un esfuerzo que una reescritura limpia se ahorraría. Ese sobrecoste es un seguro, y no merece la pena asegurar todas las casas. Si el sistema es lo bastante pequeño como para que una sustitución enfocada se entregue en 2-3 meses, la maquinaria de coordinación puede costar más que el riesgo que elimina. Si la plataforma está genuinamente muerta - un entorno de ejecución para el que no se puede contratar a nadie, hardware que no se puede reemplazar, un proveedor que ya no existe - puede que no quede nada estable a lo que estrangular. Y si el sistema tiene pocos usuarios que puedan tolerar un cambio brusco - una herramienta interna que usa un equipo con el que se puede hablar cara a cara - la ejecución en paralelo es una precaución que la situación no exige.
Aun así, conserve dos costumbres del manual incremental: migre los datos antes de la fecha límite y no durante ella, y ejecute el viejo y el nuevo en paralelo durante un periodo de validación si hay alguna forma de hacerlo. La decisión entre reescritura y strangler fija el tamaño del aparato de seguridad - no cambia si las salidas se verifican antes de que alguien dependa de ellas.
El lado político
Una modernización que dura un año es un proyecto político, sea cual sea la arquitectura. Dos sistemas funcionando en paralelo significan pagar por los dos, y en algún momento una persona razonable hará la pregunta que todo proyecto largo teme: ¿esto va a terminar alguna vez? La virtud más infravalorada del patrón strangler es que genera su propia respuesta. Como la sustitución es por módulo, el avance se cuenta: módulos cambiados, porcentaje del tráfico atendido por el sistema nuevo, incidentes por cambio. El proyecto tiene un marcador, no una estimación de porcentaje completado que lleva un año clavada en el ochenta.
La cadencia que mantiene la confianza es la demostración semanal de algo real: no diapositivas, sino el nuevo módulo de tarificación produciendo los presupuestos reales de esta semana junto a los del viejo, con las diferencias en pantalla. Los responsables ven encogerse las discrepancias semana tras semana, y eso hace más por la confianza que cualquier plan. Y los compromisos se mantienen pequeños a propósito: nunca prometa la fecha en que muere el sistema viejo - prometa el siguiente módulo, entréguelo, repita. Así es como llevamos los encargos de modernización de sistemas heredados, y es la diferencia entre una modernización en la que el negocio cree y otra que simplemente tolera.
Del sistema viejo se suele hablar como del problema. Tratado bien, es lo contrario: una especificación completa y en funcionamiento de lo que el negocio necesita, un oráculo de pruebas que califica cada respuesta del sustituto y un respaldo que hace reversible cada paso. La gran reescritura tira esos activos a la basura y después fracasa por falta de ellos. La sustitución incremental los gasta, deliberadamente, módulo a módulo - hasta el día en que alguien mira la tabla de enrutado, no encuentra nada apuntando al sistema viejo y lo apaga. Sin drama. De eso se trataba.