Deja de construir la fontanería del workflow

La mayoría de los equipos que construyen automatización operativa dedican la mayor parte de su esfuerzo de ingeniería a cosas que no son su lógica de negocio: reintentar pasos fallidos, programar cuándo se ejecuta el trabajo, rastrear en qué estado está un proceso de larga duración, asegurarse de que una acción no se dispara dos veces y recuperarse limpiamente cuando algo falla a mitad de camino. Nada de eso es la regla que decide qué hacer. Es la fontanería que hace que esa regla se ejecute de forma fiable, y construirla a mano es una de las formas más habituales en que los proyectos de automatización se disparan en presupuesto.

El impuesto de la fontanería

Imagina un equipo automatizando una regla operativa sencilla: cuando el pedido de un cliente lleva más de 48 horas sin enviarse, envía una alerta y abre un ticket de soporte. La regla en sí es una frase. Construirla de forma fiable exige un programador que compruebe la condición periódicamente, una forma de rastrear qué pedidos ya han disparado una alerta para que el mismo pedido no la dispare dos veces, una ruta de reintento para cuando la API de tickets esté caída brevemente, un mecanismo para recuperar la comprobación en curso si el proceso se reinicia a mitad de ejecución, y un registro lo bastante bueno como para responder “esto se disparó de verdad para el pedido 4471”. Son cinco problemas de ingeniería distintos sosteniendo una frase de lógica de negocio, y en cada uno de ellos puede esconderse un bug.

La mayoría de los equipos lo subestiman porque la fontanería no aparece como partida de gasto hasta que se rompe. Y se rompe en silencio, de tres formas concretas y caras.

Los tres modos de fallo que lo encarecen

Fallo parcial silencioso. Un workflow completa el paso uno y el dos, y luego el paso tres lanza un error que queda registrado pero no llega a la vista de ningún humano. El sistema cree que la tarea terminó, o no vuelve a comprobarlo nunca más. Nadie se entera hasta que un cliente se queja de algo que debería haber sido automático semanas antes.

Efectos secundarios duplicados. Un reintento se dispara porque una respuesta tardó, no porque el primer intento fallara realmente, y ahora el cobro, el email o el ticket se crean por duplicado. La idempotencia, asegurarse de que una operación tiene el mismo efecto se ejecute una vez o cinco, suena a detalle menor hasta que un pago o una notificación de cara al cliente se dispara dos veces y alguien tiene que dar explicaciones.

Estado perdido al reiniciar. Un proceso de larga duración se interrumpe por un despliegue, un fallo o un evento de escalado, y el registro en memoria de en qué punto de una secuencia de varios pasos estaba desaparece. El workflow o bien reinicia desde cero, repitiendo trabajo y arriesgándose a duplicar efectos secundarios, o bien se detiene en silencio, y nadie se entera hasta que un informe posterior no cuadra.

Cada uno de estos problemas tiene solución. Ninguno es trivial, y los tres se repiten en cada workflow que construye un equipo, lo que significa que el coste de resolverlos mal una vez se vuelve a pagar en cada nueva automatización.

Delega la fontanería en infraestructura

El argumento aquí no es “nunca escribas código de orquestación”. Es que los reintentos, la programación, el rastreo de estado y la idempotencia son problemas resueltos, con infraestructura madura detrás, y resolverlos de nuevo en cada proyecto es un mal uso del tiempo de ingeniería, que debería dedicarse a las reglas de negocio reales: qué cuenta como pedido estancado, cuál es el umbral de escalado correcto, qué significa “resuelto” para este negocio en concreto. Esa es la lógica que solo entiende tu equipo, y es la parte por la que vale la pena proteger el tiempo de ingeniería.

Un equipo que reserva su código a medida para “qué debería pasar” y se apoya en infraestructura para “asegurarse de que pasa de forma fiable” lanza más rápido y depura menos, porque los modos de fallo generales y difíciles de arriba los gestiona algo probado en batalla, no algo montado una vez bajo presión de plazos y nunca revisado.

Cuándo construirlo tú mismo

Esto no es un argumento general en contra de la orquestación a medida. Si tu proceso de verdad no necesita reintentos, porque cada paso es instantáneo e idempotente por naturaleza, la fontanería no es un coste real y construirla tú mismo está bien. Si tus requisitos de fiabilidad son inusualmente específicos, como garantías estrictas de orden entre pasos que una herramienta genérica no modela bien, una solución hecha a medida ajustada a ese requisito exacto puede rendir mejor que una genérica. Y un script pequeño y de propósito único que corre una vez al día con una persona revisando el resultado no necesita el mismo rigor que un proceso desatendido de cara al cliente; añadir infraestructura ahí es sobreingeniería, no diligencia.

La decisión pasa por volumen y consecuencia: cuanto más a menudo corre un workflow sin supervisión y cuanto más toca cosas que los clientes o el dinero pueden ver, más importa el impuesto de la fontanería, y más fuerte es el argumento para delegarlo en algo diseñado para gestionar fallos, no en algo montado para que funcione una demo.

La lógica de negocio es la única parte de un proyecto de automatización que un competidor no puede copiar con facilidad. Todo lo demás merece tratarse como una commodity, porque ya lo es.