Diez factores de riesgo que vuelven peligrosos los sistemas empresariales antiguos, los dolores de cabeza diarios que causan, un mapa de calor sencillo de probabilidad e impacto y el patrón strangler fig para reemplazar un sistema heredado una función a la vez.
Author
Anichur Rahaman
El software heredado casi nunca se cae de golpe; se va desgastando poco a poco. Un reporte tarda un poco más cada mes. Agregar un nuevo método de pago "va a llevar unas semanas". El único desarrollador que entiende el módulo de inventario se va de vacaciones y todo el equipo se queda esperando a que regrese.
Los dueños de negocio suelen notar estos síntomas mucho antes de que alguien les ponga nombre. Cuando reviso un sistema antiguo como arquitecto, mi trabajo es convertir esa incomodidad difusa en una lista concreta de riesgos, calificar cada uno y proponer una salida que no detenga la operación. Este artículo comparte ese método.
Encontrarás diez factores de riesgo que vale la pena revisar, los dolores de cabeza que cada uno provoca en el día a día, un mapa de calor sencillo para calificarlos y un enfoque de modernización —el patrón strangler fig— que reemplaza el sistema viejo pieza por pieza en lugar de apostarlo todo a reescribirlo desde cero.
Ser heredado no tiene que ver con la edad. Un sistema de cinco años puede ser moderno si tiene pruebas, documentación y corre sobre software con soporte. Uno de dos años puede ser heredado si nadie se atreve a tocarlo. Una definición práctica:
Un sistema heredado es cualquier sistema del que depende el negocio, pero que no se puede modificar de forma segura, rápida o a un costo razonable.
Con esta definición, la pregunta no es "¿cuántos años tiene?", sino "¿qué tan riesgoso es cambiarlo y qué tan riesgoso es dejarlo como está?". Las dos opciones tienen un precio.
Cuando la versión del lenguaje o del framework llega al fin de su soporte, dejan de salir parches de seguridad. Cada mes que pasa se agranda la brecha entre las vulnerabilidades conocidas y tus defensas. Además, actualizar se vuelve cada vez más difícil, porque las librerías avanzan y dejan de ser compatibles con tu versión.
El dolor de cabeza diario: "No podemos integrar esa pasarela de pago; su librería pide una versión más nueva de PHP".
Solo un desarrollador o un proveedor externo sabe cómo funciona el sistema. No hay nada documentado, y cuando esa persona se va, el conocimiento se va con ella. Suele ser el riesgo de mayor impacto, y el último en el que reparan los dueños.
El dolor de cabeza diario: versiones, correcciones y hasta un simple ajuste de datos esperan a que esa persona tenga tiempo.
Sin pruebas, cada cambio es una apuesta, así que el equipo cambia lo menos posible. Los problemas se parchan por fuera en lugar de resolverse de raíz, y modificar el código se vuelve más difícil cada año.
El dolor de cabeza diario: "Corregimos el redondeo de las facturas y ahora el reporte de descuentos sale mal".
Cientos de tablas que todas las partes de la aplicación leen y escriben, a veces también scripts externos. Cambiar una columna puede romper una pantalla de la que nadie se acuerda.
El dolor de cabeza diario: modificar un campo sencillo se convierte en una semana entera rastreando efectos secundarios.
Contraseñas guardadas con métodos obsoletos, llaves de API escritas dentro del código, paneles de administración sin doble factor, páginas de error que exponen datos de la base de datos y ningún límite de intentos al iniciar sesión. Por separado, cada punto parece menor; juntos, son una puerta abierta.
El dolor de cabeza diario: cuando un cliente grande manda su cuestionario de seguridad, nadie quiere contestarlo.
Los datos del cliente están en la tienda, en el CRM y en una hoja de cálculo; las existencias, en el sistema y en la libreta del encargado del almacén. Cuando las cifras no coinciden, la gente deja de creer en todas.
El dolor de cabeza diario: las juntas se van en discutir cuál reporte es el correcto.
Archivos CSV que viajan cada noche por FTP, scripts que extraen datos del sitio de un proveedor, integraciones que se detienen sin avisar cuando caduca una contraseña. Funcionan hasta que dejan de hacerlo, y nadie se da cuenta durante días.
El dolor de cabeza diario: "Los estatus de la paquetería no se actualizan desde el martes".
Consultas que traen un registro por cada vuelta de un ciclo, cero caché y reportes que recorren tablas completas. Con mil pedidos todo va bien; con un millón, es un suplicio.
El dolor de cabeza diario: los reportes de fin de mes tardan toda la noche y la tienda se pone lenta mientras corren.
No queda registro de quién cambió un precio, un sueldo o una existencia. No hay forma de exportar o eliminar los datos personales de un cliente cuando lo solicita. El consentimiento no se guarda. En muchos países, las leyes de protección de datos convierten todo esto en obligaciones legales, no en funciones opcionales.
El dolor de cabeza diario: responder una sola pregunta del auditor toma una semana.
Un sistema cerrado en el que el proveedor controla la exportación de tus datos, sube los precios al renovar o descontinúa el producto. A veces el propio contrato es el mayor riesgo.
El dolor de cabeza diario: "Queremos cambiarnos de sistema, pero no logramos sacar nuestros datos en un formato que sirva".
No necesitas un consultor para empezar. Reúne a quienes usan el sistema y a quienes le dan mantenimiento, y califiquen cada riesgo del 1 al 5 en dos ejes:
Multiplica ambas cifras. Lo que sume 15 o más se atiende este trimestre; lo que quede entre 8 y 14 entra en la hoja de ruta; lo que esté por debajo de 8 basta con vigilarlo. El mapa de calor de arriba no es más que esta tabla dibujada, y es la diapositiva más efectiva que conozco para que un consejo directivo apruebe presupuesto de modernización.
| Riesgo | Probabilidad (1–5) | Impacto (1–5) | Puntaje | Acción |
|---|---|---|---|---|
| Lenguaje o framework sin soporte | 5 | 5 | 25 | Este trimestre |
| Dependencia de una sola persona | 4 | 5 | 20 | Este trimestre |
| Deuda de seguridad | 4 | 5 | 20 | Este trimestre |
| Sin pruebas automatizadas | 4 | 4 | 16 | Este trimestre |
| Integraciones frágiles | 3 | 3 | 9 | Hoja de ruta |
| Dependencia del proveedor | 2 | 4 | 8 | Hoja de ruta |
Estos puntajes son solo un ejemplo, no una referencia. En tu propia sesión saldrán otros, y la conversación vale tanto como el resultado.
Una vez que los riesgos están a la vista, la respuesta más tentadora es: "Hagámoslo de nuevo, pero bien hecho". Sin embargo, las reescrituras completas fracasan muchas más veces de las que salen bien, y por razones que se pueden anticipar:
El higo estrangulador es una planta que crece alrededor de un árbol hasta que puede sostenerse sola. En software ocurre lo mismo: el sistema nuevo crece alrededor del viejo y va asumiendo sus funciones una por una, hasta que el núcleo antiguo se puede apagar.
Pon una capa de enrutamiento delante del sistema viejo, como un API gateway o un proxy ligero. Al principio envía el 100 % del tráfico al sistema antiguo. Al mismo tiempo:
Elige una pieza importante y con límites claros: catálogo e inventario, o pedidos. Construye el módulo nuevo o adopta uno ya probado, y dirige esa función hacia él.
Cuando se haya movido la última pieza, archiva el histórico en un almacenamiento de solo lectura, apaga las pantallas viejas que queden y elimina el código antiguo. Conserva los datos y deshazte del riesgo.
No todas las partes de un sistema heredado merecen el mismo trato. Tres preguntas definen el camino de cada una:
Hay lecciones que no vienen en los libros, sino de la experiencia:
StoreConsole está formado por módulos independientes —catálogo, inventario, pedidos, envíos, contabilidad, recursos humanos, nómina, CRM y más— que se comunican entre sí únicamente mediante eventos. Por eso es una opción natural para el camino de "reemplazar": colocas un módulo detrás de la fachada, lo alimentas desde el outbox del sistema viejo y pasas al siguiente cuando el primero ya está estable. Cada módulo incluye bitácora de actividad, permisos por rol y doble factor de autenticación, lo que reduce varios de los riesgos anteriores desde el primer día. El breve recorrido de abajo muestra los roles, el doble factor y la bitácora de auditoría.
Anichur Rahaman es arquitecto de software y fundador de StoreConsole. Diseña sistemas de comercio y ERP para empresas en crecimiento, con especial atención a la arquitectura orientada a eventos, la exactitud de los datos y los sistemas que corren en los servidores de la propia empresa.
About the Author
Anichur Rahaman
Continue Reading
