Cuando un proceso digital cambia, la discusión suele formularse de forma demasiado simple: «¿lo hacemos rápido mediante un parámetro o hay que desarrollarlo?». Esa pregunta oculta una decisión de diseño más importante. Cada cambio incorpora una regla de negocio, una expectativa operativa y un coste futuro de mantenimiento. Resolver todo con código ralentiza la adaptación; resolver todo con opciones de configuración puede volver el producto impredecible, difícil de auditar y frágil.
La decisión correcta no depende solo del esfuerzo inicial. Depende de la estabilidad de la regla, quién debe modificarla, el riesgo de hacerlo y si el cambio introduce una capacidad nueva. El objetivo es que el proceso evolucione sin convertir cada excepción en una bifurcación permanente ni esconder decisiones críticas en pantallas de administración ambiguas.
Las tres alternativas y el límite de cada una
Una misma petición puede expresarse como una regla fija, una configuración o un desarrollo a medida. Son mecanismos distintos y deben tener responsabilidades claras.
Regla estable implementada en código
Una regla en código es adecuada cuando representa un comportamiento estructural del producto: validaciones obligatorias, restricciones de seguridad, cálculos con poca variabilidad o decisiones que deben ser iguales para todos los casos de un mismo contexto. También es una buena elección si modificarla exige comprender dependencias técnicas o si un error tendría consecuencias graves.
- Ventaja: comportamiento explícito, versionado junto al software y cubierto por pruebas automatizadas.
- Riesgo: un ajuste operativo menor requiere despliegue y puede crear dependencia del equipo técnico.
- Señal de diagnóstico: la regla se mantiene prácticamente igual durante meses y existen pocas razones legítimas para que cada unidad la altere.
Configuración administrable
La configuración sirve para variaciones previstas del proceso. Por ejemplo, umbrales de aprobación, destinatarios de avisos, calendarios operativos, categorías habilitadas o secuencias de pasos dentro de un marco ya diseñado. No es una forma de evitar el diseño: es una capacidad de producto que necesita modelo de datos, permisos, validaciones y una interfaz entendible.
- Ventaja: negocio u operaciones pueden responder a cambios autorizados sin esperar un ciclo de desarrollo.
- Riesgo: demasiados parámetros generan combinaciones imposibles de entender o de probar.
- Señal de diagnóstico: el cambio es recurrente, previsible y está dentro de límites que el sistema puede validar.
Desarrollo de una capacidad nueva
El desarrollo a medida es necesario cuando la petición cambia el modelo del proceso: incorpora participantes, estados, decisiones, datos, integraciones o excepciones que no existían. Intentar encajarlo como un parámetro suele producir lógica condicional dispersa y una interfaz de configuración que nadie puede gobernar.
- Ventaja: permite diseñar una solución coherente, observable y sostenible.
- Riesgo: tratar una necesidad puntual como una plataforma genérica y sobredimensionar el alcance.
- Señal de diagnóstico: para soportar el cambio hay que añadir campos, permisos, reglas de enrutamiento o estados nuevos.
Las seis preguntas para clasificar un cambio
Antes de estimar tareas, producto, negocio y tecnología deberían responder las siguientes preguntas por escrito. La respuesta reduce decisiones basadas solo en urgencia o en el coste aparente de la primera implementación.
- ¿Con qué frecuencia cambia? Si puede variar varias veces al año por decisiones operativas legítimas, la configuración merece evaluación. Si es excepcional y no se repetirá, quizá convenga una regla explícita o una solución temporal con fecha de retirada.
- ¿La variación estaba prevista en el diseño? Configurar no debe significar aceptar cualquier comportamiento. Debe existir un conjunto delimitado de opciones y reglas de compatibilidad.
- ¿Quién es el propietario de la decisión? Si operaciones debe cambiarla, necesita una experiencia segura y permisos adecuados. Si requiere interpretación técnica, debe mantenerse en código.
- ¿Qué impacto tiene un error? Cuanto mayor sea el impacto financiero, legal, de seguridad o de continuidad operativa, mayor debe ser el control: validación, revisión, pruebas y trazabilidad.
- ¿Afecta al modelo de dominio? Si aparece una entidad, un estado, un rol o una relación nuevos, no se trata solo de configurar; probablemente hay una capacidad que diseñar.
- ¿Cómo se comprobará y revertirá? Si no se puede previsualizar el efecto, registrar el cambio y volver atrás, la configuración no está lista para ser administrable.
Una configuración saludable restringe decisiones dentro de un diseño; no transfiere al usuario la responsabilidad de diseñar el sistema.
Cuándo usar código, configuración o desarrollo
Una regla estable en código es preferible cuando un pedido no admite variaciones por unidad, cuando protege una condición esencial o cuando su validez depende de una lógica compleja. Por ejemplo, impedir que una solicitud pase a aprobación sin los datos mínimos requeridos. Convertir esa condición en una casilla editable puede degradar la calidad del proceso.
La configuración es apropiada para decisiones operativas que cambian dentro de un rango conocido. Un flujo de aprobación puede permitir definir el importe a partir del cual se requiere una segunda revisión, siempre que el sistema valide el valor, identifique a los responsables y evite dejar el flujo sin aprobador. En ese caso, el producto no entrega libertad absoluta: entrega variabilidad controlada.
El desarrollo a medida debe iniciarse cuando el cambio altera la naturaleza del flujo. Si una organización necesita aprobaciones paralelas, delegación temporal, reglas según atributos de varias entidades y una escalada por vencimiento, probablemente ha superado un parámetro de umbral. Conviene diseñar una capacidad de enrutamiento y decisión, aunque se implemente de forma incremental.
Riesgos que revelan una mala decisión
La parametrización excesiva es el riesgo más habitual. Suele reconocerse porque la pantalla contiene nombres técnicos, opciones que se contradicen, dependencias implícitas y valores que nadie se atreve a tocar. El equipo termina necesitando a un desarrollador para interpretar una configuración que, en teoría, gestionaba negocio.
El problema contrario son las excepciones invisibles en código. Surgen cuando cada cliente, área o caso especial añade una condición aislada. Con el tiempo, dos reglas producen resultados distintos para situaciones que parecen equivalentes, y nadie puede explicar cuál prevalece. Una señal clara es que las incidencias se resuelven preguntando «qué condición entra primero» en lugar de consultar una política comprensible.
También hay riesgo de lógica duplicada. Un umbral definido en una interfaz administrativa, repetido en un servicio de integración y reinterpretado en un informe genera divergencias. Para evitarlo, cada decisión debe tener una fuente de verdad, un propietario y un lugar conocido donde se evalúa.
Cómo diseñar una configuración segura y gobernable
Una configuración administrable debe tratarse como parte del producto, no como una tabla editable. Defina primero qué variaciones son válidas y cuáles no. Después incorpore controles proporcionales al impacto.
- Permisos por rol: separe quién puede consultar, proponer, aprobar y publicar cambios.
- Validaciones de negocio: impida combinaciones inválidas antes de guardar, no cuando el proceso ya ha fallado.
- Historial auditable: registre qué cambió, quién lo hizo, cuándo y cuál era el valor anterior.
- Ámbito explícito: indique con claridad si la regla aplica a toda la organización, a una unidad, a un tipo de solicitud o a un periodo.
- Pruebas de escenario: permita comprobar casos representativos antes de activar una modificación de alto impacto.
- Reversión: ofrezca una forma controlada de recuperar una versión anterior sin editar manualmente múltiples valores.
Las recomendaciones de OWASP sobre autorización y validación de entradas son especialmente pertinentes cuando usuarios no técnicos administran reglas que afectan a permisos, importes o rutas de decisión. La interfaz debe explicar el efecto de cada cambio sin revelar detalles técnicos innecesarios.
Ejemplo: la evolución de un flujo de aprobación
Imagine un flujo en el que toda solicitud superior a un importe definido requiere la aprobación de una persona responsable. La obligatoriedad de informar un importe y la prohibición de aprobar una solicitud propia son reglas estables: deben mantenerse en código y estar cubiertas por pruebas.
El importe umbral y la persona responsable pueden ser configurables si cambian por unidad operativa y el sistema valida que siempre exista un responsable activo. El historial debe mostrar qué umbral estaba vigente cuando se inició cada solicitud, para que una modificación posterior no reescriba el contexto de una decisión ya tomada.
Si después se solicita que dos áreas aprueben en paralelo, que la responsabilidad dependa de categoría y región, y que exista delegación durante ausencias, el equipo debe detenerse. Ya no es razonable sumar casillas a la configuración existente. Es el momento de definir una capacidad de reglas de enrutamiento, con prioridades, conflictos, estados y observabilidad propios.
La decisión sostenible no consiste en elegir siempre la alternativa más rápida. Consiste en escoger el mecanismo que preserve la claridad del proceso hoy y permita evolucionarlo mañana. Use código para invariantes, configuración para variaciones previstas y desarrollo para cambios de modelo.