Ford, Kua, Parsons + AWS Architecture Blog + ThoughtWorks
El problema que resuelve
La seguridad es el argumento más común para justificar el BAUP — "no podemos entregar nada hasta que la arquitectura de seguridad esté completa". El problema es que ese argumento trata la seguridad como un estado que se alcanza una vez y se mantiene solo. La realidad es exactamente la opuesta: la seguridad es una propiedad que se erosiona continuamente a medida que el sistema evoluciona, el entorno cambia, y aparecen nuevas amenazas. Una arquitectura de seguridad diseñada completamente al inicio no es más segura — es una fotografía que envejece.
Qué es
Security como Fitness Function es la aplicación del mecanismo central de Evolutionary Architecture al dominio de seguridad. En lugar de diseñar la seguridad como prerequisito de existencia del sistema, se define como un conjunto de criterios medibles y automatizables que el sistema debe satisfacer en cada iteración. Los arquitectos de seguridad pueden definir, por ejemplo, que el número de hallazgos críticos y altos debe ser cero — y los equipos son guiados a reducir ese número, resultando en mejor seguridad. No es seguridad prometida — es seguridad verificada continuamente. AWS
Cómo lo resuelve
Desplaza la pregunta de "¿está segura la arquitectura?" — que solo puede responderse al final — a "¿este cambio incrementa o reduce nuestra postura de seguridad?" — que puede responderse en cada iteración. Incluso si no se cumplen todas las fitness functions de seguridad desde el inicio, las aplicaciones que las cumplían en un punto pueden dejar de cumplirlas más tarde por diversas razones — y los requisitos de seguridad, así como su prioridad relativa, cambiarán con el tiempo. Diseñar para ese cambio es más seguro que diseñar para un momento estático. Alice, Eve and Bob
Aquí es donde Team Topologies ilumina el mecanismo sin ser condición: cuando existe un Platform Team bien definido, ese equipo absorbe naturalmente la responsabilidad de mantener y evolucionar las fitness functions de seguridad, liberando a los equipos de IA agéntica para enfocarse en outcomes. Pero el principio se sostiene independientemente — cualquier equipo que opere la plataforma puede asumir ese rol.
Tres principios centrales
1. Seguridad como propiedad continua, no como estado final — es esencial saber si un sistema cumple cualidades requeridas como performance, seguridad, mantenibilidad y tolerancia a fallos mientras el software cambia constantemente. Las fitness functions proveen ese mecanismo de verificación continua. Oreilly
2. Definir las fitness functions de seguridad temprano, no implementarlas todas temprano — las fitness functions deben ser identificadas tan temprano como sea posible, y categorizadas como clave, relevantes, o no relevantes — pero no necesariamente implementadas todas al mismo tiempo. Eso es exactamente lo que permite construir incrementalmente sin sacrificar la visión de seguridad completa. GitHub
3. La capa intermedia es la arquitectura de seguridad — este es el argumento más potente para el técnico: la Plataforma de Capacidades Digitales no es el sacrificio de seguridad frente a la urgencia del negocio. Es la decisión arquitectónica que evita que los sistemas de IA agéntica accedan directamente al core — reduciendo la superficie de ataque, centralizando los controles de acceso, y permitiendo que la seguridad evolucione en la plataforma sin afectar a los consumidores.