Cómo saber que tu sistema dejó de escalar

Un sistema no deja de escalar de un día para otro. Se degrada de a poco, y casi siempre la primera señal no viene del equipo técnico sino de la operación.

Las señales tempranas

Antes de que aparezca un problema de rendimiento medible, suelen aparecer síntomas de proceso. Vale la pena revisarlos porque son más baratos de corregir en esa etapa.

• Existe un archivo paralelo. Alguien mantiene una hoja de cálculo porque el sistema no refleja algo que el negocio necesita.
• Hay excepciones que se resuelven a mano. Casos que el sistema no contempla y que un usuario corrige por fuera.
• Nadie confía del todo en un reporte. Se contrasta contra otra fuente antes de usarlo.
• Un cambio pequeño toma semanas. La estimación deja de ser proporcional al tamaño del pedido.

Por qué ocurre

La causa más frecuente no es el volumen de datos ni el lenguaje elegido. Es que el modelo de datos original describía un negocio que ya cambió. El software sigue siendo correcto respecto de la empresa que existía cuando se construyó.

Cuando cada nueva funcionalidad requiere una excepción en el modelo, el problema no es la funcionalidad.

Qué hacer antes de reescribir

Reescribir desde cero es la opción más cara y la que más riesgo concentra. Antes de tomarla conviene agotar tres caminos.

• Aislar el módulo problemático y extraerlo como servicio, dejando el resto intacto.
• Corregir el modelo de datos en la zona afectada, con una migración controlada.
• Integrar en lugar de reemplazar, cuando lo que falta es comunicación entre sistemas y no funcionalidad.

La reescritura completa se justifica cuando el costo acumulado de estos parches supera al de construir de nuevo, y cuando existe claridad sobre el proceso que el nuevo sistema debe soportar. Sin esa claridad, la segunda versión repite los problemas de la primera.