El comité que todos evitan
En muchas organizaciones, revisar una arquitectura antes de producción significa presentar ante un comité que se reúne cada dos semanas, devuelve una lista de objeciones sin prioridad y vuelve a revisar todo en la siguiente ronda. Los equipos aprenden a esquivarlo, y el estándar deja de cumplirse.
El problema no es revisar. Es revisar sin una norma escrita y sin distinguir lo grave de lo menor.
Revisar contra una norma, no contra opiniones
Una homologación útil compara el diseño con un estándar escrito de la organización: qué zonas deben existir, qué servicios están permitidos, cómo se gestionan identidades, secretos, registros, copias de seguridad y costos. Si una regla no está escrita, no se puede exigir.
Un dictamen, no una lista de peros
El resultado de la revisión es un dictamen en el que cada desviación tiene:
- La regla que incumple, citada.
- Su severidad:
- Bloqueante: impide pasar a producción (por ejemplo, datos sensibles expuestos a internet).
- Mayor: debe corregirse en un plazo acordado (por ejemplo, sin copias de seguridad probadas).
- Menor: se corrige en la siguiente iteración (por ejemplo, etiquetado incompleto).
- Observación: sugerencia sin obligación.
- Una propuesta de corrección, no solo el problema.
Con esa clasificación, la decisión es simple: sin bloqueantes, se avanza; con bloqueantes, se corrige solo eso y se vuelve a revisar solo eso.
Cómo hacer que no frene
- Norma pública y estable, para que los equipos diseñen cumpliéndola desde el principio.
- Revisiones a demanda, no por calendario de comité.
- Automatizar lo comprobable: etiquetas, cifrado, exposición de red y otros puntos se validan solos con la infraestructura como código. La revisión humana se centra en lo que requiere criterio.
- Excepciones documentadas, con dueño y fecha de revisión, en lugar de prohibiciones que todos esquivan.
Cómo lo aplicamos: Arquitectura Cloud.