Mantener viva la arquitectura de referencia

Una arquitectura de referencia se mantiene viva con tres cosas muy poco vistosas. Cada decisión tiene un dueño con nombre, que responde por ella y puede cambiarla. Cada decisión tiene una fecha de revisión, y se revisa de verdad aunque nada haya cambiado. Y hay una lista de eventos que obligan a revisar sin esperar al calendario: una fusión, un servicio de nube nuevo, un hallazgo que se repite.

El formato importa poco: una tabla de decisiones con fecha, dueño y estado basta. Lo que importa es que alguien abra la tabla en la fecha prevista.

Una decisión sin dueño es la primera señal de una referencia que se muere: cuando un proyecto la contradice, nadie sabe a quién preguntar si es una excepción o un error, y cuando el contexto cambia, nadie la revisa. Se arregla asignando un dueño con nombre, no un área.

Pide las decisiones del registro cuyo dueño figura como sin dueño.

Cada decisión lleva una fecha en la que debe revisarse. Una revisión vencida no es un trámite pendiente: es una decisión que sigue gobernando sistemas nuevos sin que nadie haya comprobado si todavía es cierta. El retraso se mide en días entre la fecha de revisión y la de corte del registro.

El corte de este registro es el 2027-08-10. Revisa las fechas de revisión, descarta las que todavía no han llegado y calcula cuántos días lleva atrasada la más vieja.

Una desviación de la referencia no es mala por sí misma: a veces un sistema tiene una razón de peso para no cumplir una decisión. Lo que sí es un problema es la desviación que nadie autorizó. Una excepción tiene un número, un responsable y una fecha de vencimiento; sin ellos, es un incumplimiento que se está normalizando.

Compara los sistemas medidos contra las decisiones y localiza el que se aparta de una decisión sin ninguna excepción registrada.

Una revisión de calendario protege contra el olvido, pero hay cambios que invalidan una decisión de un día para otro: un servicio de nube nuevo, una fusión, un hallazgo que se repite. Para eso existe la lista de disparadores: eventos que obligan a revisar las decisiones afectadas antes de que el cambio entre en marcha, sin esperar a la próxima fecha.

Abre la tabla de disparadores y mira qué revisión se asocia a cada evento.