El drift de configuración aparece cuando DEV, QA y PROD ya no son equivalentes en lo que debería ser controlado: parámetros externalizados, credentials, endpoints, certificados, roles, variables de despliegue, scheduler, feature toggles o reglas de reintento. El riesgo no es teórico. El mismo paquete puede probar bien en QA y fallar en producción porque una dependencia quedó alineada solo de forma manual.
Reducir drift no significa burocratizar cada ajuste. Significa saber qué configuración puede variar por ambiente, quién puede cambiarla, cómo se evidencia y qué comparación mínima se hace antes de promover una versión.
1) Separar diseño de configuración operativa
Un buen punto de partida es distinguir entre lo que pertenece al diseño del iFlow y lo que pertenece a la operación del ambiente. El diseño debe viajar controlado; la configuración debe estar externalizada, documentada y restringida.
- Diseño: pasos del flujo, mapeos, validaciones, rutas, transformaciones y manejo de errores.
- Configuración: URLs, aliases, credenciales, colas, timers, umbrales, flags y parámetros por ambiente.
- Decisión operativa: quién aprueba una excepción temporal y cuándo debe retirarse.
Cuando esa frontera no existe, la corrección urgente termina mezclando código, configuración y criterio operativo en el mismo movimiento.
2) Definir una matriz de configuración esperada
La matriz no tiene que ser pesada, pero sí debe permitir comparar ambientes sin depender de memoria. Una versión útil incluye:
| Elemento | Pregunta de control | Evidencia |
|---|---|---|
| Endpoint | ¿El host corresponde al ambiente correcto? | URL esperada, owner y fecha de revisión |
| Credential alias | ¿El alias existe y su uso está aprobado? | Nombre del alias, responsable y ventana de rotación |
| Parámetros | ¿El valor varía por ambiente o debería ser idéntico? | Valor esperado o regla de variación |
| Scheduler | ¿La frecuencia de QA representa el comportamiento productivo? | Frecuencia, zona horaria y restricciones |
3) Controlar cambios manuales sin negar la operación real
En paisajes reales siempre habrá ajustes manuales: una credencial que rota, un endpoint que cambia, una prueba de conectividad o una pausa temporal del scheduler. El problema no es que existan. El problema es que no dejen rastro.
4) Comparar antes de promover, no después del incidente
Antes de mover una versión hacia QA o PROD conviene revisar una lista corta:
- Parámetros externalizados: valores esperados y diferencias justificadas.
- Credenciales y certificados: aliases existentes, vigencia y owner.
- Endpoints: host, path, autenticación, allowlist y dependencia funcional.
- Scheduler y reintentos: frecuencia, ventanas de carga y riesgo de duplicados.
- Observabilidad: logs, Correlation ID, alertas y criterio de escalamiento.
Esta revisión no reemplaza SAP Transport Management, SAP Cloud ALM ni el monitoreo runtime. Funciona como una capa de disciplina operativa para que esos controles no convivan con configuración invisible.
5) Tratar excepciones como inventario vivo
Una excepción aceptada puede ser razonable: un endpoint temporal durante cutover, un scheduler reducido para pruebas o un certificado con rotación pendiente. Lo importante es que tenga vencimiento y responsable. Si una excepción no tiene fecha de revisión, se vuelve configuración permanente por accidente.
6) Señales de drift que conviene investigar
- El mismo iFlow requiere pasos manuales diferentes para desplegarse en cada ambiente.
- QA usa endpoints, payloads o credenciales que no representan producción.
- Los aliases existen con nombres parecidos, pero sin convención ni owner claro.
- Los fallos se resuelven cambiando parámetros directamente en el tenant sin evidencia posterior.
- La comparación de ambientes depende de una persona específica.
En una evaluación de gobierno de SAP CPI, el drift suele aparecer como deuda silenciosa: no siempre rompe hoy, pero reduce la confiabilidad de cada promoción futura. Por eso el Picasso CPI Governance Assessment revisa configuración, ownership, evidencias y operabilidad sin plantear que la documentación sustituye los controles nativos de SAP.