La trazabilidad permite explicar cómo una decisión de seguridad responde a una necesidad del negocio. Evita que el catálogo de productos se convierta en la arquitectura.
Preguntar por el resultado, antes que por el control
Cuando reviso una propuesta, necesito que el negocio pueda reconocer su necesidad en el diseño. Si el objetivo es incorporar una compañía, hay que aclarar qué servicios deben seguir funcionando, qué información se compartirá y qué actividades requieren integración inmediata. “Integrar todo” no sirve como requisito operativo.
También preguntaría quién valida el resultado. Seguridad puede diseñar una capacidad de protección, pero el responsable del proceso debe explicar qué necesita para trabajar. Esa conversación permite separar lo imprescindible de lo deseable y registrar los compromisos. Si no conocemos el plazo o el impacto de una interrupción, debemos tratarlo como una pregunta pendiente que condiciona la arquitectura, en lugar de completarlo con una suposición silenciosa.
Partir del contexto
Describir los servicios, las partes interesadas y los resultados esperados. Convertir expresiones generales como «acceso seguro» en atributos que puedan discutirse y evaluarse.
Convertir atributos en condiciones comprobables
Continuidad, trazabilidad y facilidad de incorporación son términos útiles, pero necesitan significado dentro del servicio. Para continuidad, debemos acordar qué actividad se recupera y en qué condiciones. Para trazabilidad, qué acciones se atribuyen a una identidad y cómo se consulta esa evidencia. Para incorporación, qué pasos necesita un nuevo equipo y cuánto trabajo requiere.
No asignaría un número únicamente porque resulte fácil de medir. Primero definiría qué decisión ayudará a tomar. Un porcentaje de disponibilidad puede describir un componente y dejar fuera una dependencia que impide trabajar. Una métrica de incorporación puede medir altas de cuentas sin comprobar que sus permisos son adecuados. El atributo debe conservar su relación con el resultado que quería el negocio.
De la necesidad a la evidencia
- Necesidad de negocioQué actividad queremos habilitar.
- Atributos y requisitosQué significa que el servicio cumpla su propósito.
- Capacidad y decisiónQué solución elegimos y por qué.
- Control y operaciónCómo se aplica y quién lo mantiene.
- EvidenciaCómo comprobamos el resultado.
La evidencia y los cambios de negocio permiten revisar las decisiones anteriores.
Construir una cadena comprensible
Vincular necesidad, atributo, riesgo, capacidad, decisión y evidencia. Una misma capacidad puede atender varios objetivos; un objetivo puede requerir varias capacidades.
Explicar una decisión de principio a fin
Imaginemos que elegimos federar identidades durante una adquisición. Necesito explicar qué actividad permite, qué riesgos modifica y qué condiciones exige. La federación puede simplificar el acceso, pero debemos conocer quién mantiene la identidad, cómo se retira y qué ocurre si falla el proveedor de autenticación.
Documentaría alternativas, dependencias y motivos de elección. Esa información permite revisar la decisión cuando cambia el contexto. Si una opción se descartó por falta de soporte técnico, conviene conservar ese motivo: puede dejar de ser válido en el futuro. También hay que distinguir una capacidad requerida de un producto concreto. Cambiar de herramienta no debería obligarnos a redescubrir la finalidad del control ni a perder los criterios con los que lo evaluamos.
Ejemplo: incorporar una adquisición
Si el negocio necesita integrar una nueva compañía sin interrumpir servicios, la arquitectura debe expresar qué significa ese resultado. Podrían acordarse atributos como continuidad, trazabilidad y facilidad de incorporación. A partir de ellos se identifican capacidades de federación, segregación y recuperación. La herramienta elegida llega después de entender esas capacidades y sus dependencias.
Cómo lo llevaría a una revisión de arquitectura
Prepararía una revisión con unas pocas decisiones relevantes, en lugar de empezar mostrando todo el catálogo de controles. Para cada una llevaría la necesidad, los atributos acordados, las alternativas consideradas y la evidencia que esperamos obtener. El negocio debe poder confirmar la finalidad; los equipos técnicos, las dependencias; y operación, las responsabilidades.
Si aparecen diferencias, las registraría como cuestiones que cambian el diseño. Por ejemplo, una solución puede ofrecer disponibilidad suficiente en sus componentes y requerir una intervención manual que el equipo no puede cubrir fuera de horario. Ese requisito operativo tiene que entrar en la decisión. No podemos dar por válida la capacidad únicamente con una cifra del fabricante.
También preguntaría qué cambio obligaría a revisar la elección. Una nueva población, otra ubicación de datos o una ampliación de acciones pueden alterar los requisitos. Tener esos desencadenantes identificados permite mantener el diseño con menos esfuerzo que rehacerlo cada vez.
Al cerrar la revisión, dejaría decisiones y preguntas pendientes con responsables. La aprobación del diseño debe distinguir lo validado de lo que todavía depende de pruebas. Después, la implantación necesita devolver evidencia a ese registro: qué capacidades se han configurado realmente, qué diferencias han aparecido y qué compromisos siguen abiertos. Esa continuidad es lo que convierte la trazabilidad en una herramienta de trabajo.
Mantener la arquitectura viva
Registrar el responsable de cada decisión, sus supuestos y las condiciones que obligan a revisarla. Los cambios de negocio deben poder rastrearse hasta las capacidades afectadas.
Usar la trazabilidad en los cambios
La utilidad se ve cuando llega una nueva petición. Si cambia el alcance de un servicio, podemos recorrer las relaciones y localizar los requisitos afectados. Una nueva población de usuarios puede modificar el modelo de identidad, las necesidades de soporte y las condiciones de acceso a datos.
No todo cambio obliga a rehacer la arquitectura completa. Necesitamos determinar qué supuestos siguen siendo válidos y qué decisiones requieren nueva evidencia. Mantendría un registro breve con el motivo del cambio, los responsables consultados y el resultado de la revisión. Ese registro debe ayudar a quien opera el servicio, no quedarse únicamente en el repositorio del arquitecto. La documentación pierde valor cuando describe una solución que ya no corresponde al funcionamiento real.
El límite de la trazabilidad
Una matriz muy extensa puede aparentar rigor sin ayudar a decidir. Es preferible mantener relaciones que un responsable pueda explicar y validar. Cuando una decisión depende de un supuesto —por ejemplo, que un proveedor conservará una función crítica— ese supuesto debe quedar junto a la decisión, con un desencadenante de revisión.
Dar al modelo operativo el mismo peso
Una capacidad debe tener responsables capaces de mantenerla. ¿Quién revisa permisos? ¿Quién cambia la política? ¿Quién investiga un comportamiento inesperado? ¿Quién decide que una excepción ya no está justificada? Estas actividades necesitan aparecer en el modelo operativo y en su RACI.
Para comprobar la trazabilidad, elegiría algunas decisiones importantes y pediría que se explicaran en ambos sentidos: desde la necesidad hasta el control y desde el control hasta su finalidad. También comprobaría qué evidencia existe y cuándo se revisó. Si solo podemos señalar una casilla en una matriz, nos falta explicación. Mi objetivo es que el diseño ayude a decidir, a operar y a adaptar el servicio cuando cambian las necesidades, manteniendo visibles las limitaciones y los compromisos.
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.