El documento congelado
Muchas normas se escriben una vez, se aprueban en una reunión y no se vuelven a tocar. Dos años después describen tecnologías que ya no se usan y prohíben cosas que todo el mundo hace. Los equipos aprenden que la norma no refleja la realidad, y dejan de mirarla.
El extremo contrario también falla: normas que alguien modifica cuando le parece, sin avisar, y que amanecen distintas un lunes cualquiera.
Un ciclo con estados
Cada regla de la norma pasa por estados conocidos:
- Propuesta. Cualquiera puede proponer una regla nueva o un cambio, con su motivo: un incidente, un cambio tecnológico, una exigencia legal.
- En revisión. El responsable del dominio la valora y la ajusta con los equipos afectados.
- Vigente, con transición. Se aprueba con una fecha de entrada en vigor y un periodo para adaptarse. Lo nuevo se exige desde el primer día; lo existente tiene un plazo.
- Revisión periódica. Cada cierto tiempo (por ejemplo, una vez al año) se confirma que sigue teniendo sentido.
- Retirada o sustituida. Una regla que ya no aporta se retira; una que cambia se sustituye por una nueva versión que cita a la anterior.
Versionar como el software
- Cada versión de la norma tiene número y fecha, y una lista de cambios legible.
- Los cambios se anuncian antes de entrar en vigor, no después.
- Se puede saber qué versión aplicaba en cualquier momento pasado, lo que importa en una auditoría.
- Las reglas automatizadas siguen a la norma: cuando una regla cambia, su comprobación automática cambia en la misma versión.
La fuente de las propuestas
Las mejores propuestas no vienen de un comité, sino de la operación: un incidente que reveló un vacío (como en cada fallo deja una regla), una excepción que se repite tanto que debería ser la regla, una regla que nadie cumple porque no tiene sentido.
Esa última fuente merece su propio artículo, porque las excepciones bien gestionadas son el mejor termómetro de una norma.
Cómo lo aplicamos: Gobierno Multicloud.