Gobernanza de la arquitectura en organizaciones ágiles

Para qué sirve la gobernanza de la arquitectura

La gobernanza de la arquitectura es el conjunto de prácticas con las que una organización se asegura de que sus decisiones técnicas significativas se toman bien, son coherentes con sus objetivos y se siguen de verdad. Responde a cuatro preguntas: quién puede tomar qué decisiones, cómo deben tomarlas, qué dirección deben seguir y cómo sabe nadie si el resultado se ajusta a lo previsto.

Los propósitos son prácticos. La gobernanza alinea la tecnología con la estrategia, para que cincuenta equipos no elijan cincuenta formas de almacenar los datos de los clientes. Gestiona el riesgo y el cumplimiento normativo: la protección de datos, la seguridad, la accesibilidad y la regulación sectorial necesitan pruebas de que se siguen las reglas. Limita la diversidad innecesaria, porque cada base de datos, lenguaje o producto de mensajería adicional necesita conocimientos, parches y soporte de guardia. Protege cualidades que ningún equipo posee por sí solo, como la latencia de extremo a extremo, la seguridad y el costo. Y difunde el aprendizaje, para que una lección que pagó un equipo no la vuelva a pagar el siguiente.

Las organizaciones ágiles sienten aquí una tensión. El principio del Manifiesto Ágil según el cual las mejores arquitecturas surgen de equipos autoorganizados (Sección 1.8) empuja hacia la autonomía; la escala, la regulación y la infraestructura compartida empujan hacia la alineación. Las descripciones de Henrik Kniberg de la cultura de ingeniería de Spotify popularizaron la expresión autonomía alineada (aligned autonomy) para el objetivo: equipos libres de decidir el cómo, dentro de un entendimiento compartido del qué y el porqué. La gobernanza es la maquinaria que lo hace posible. Mal hecha, se convierte en el lento proceso de aprobación de la Sección 11.2; bien hecha, los equipos apenas la notan, porque lo correcto es también lo fácil.

Principios, estándares, guardrails y compuertas

La gobernanza usa cuatro tipos de instrumento, que difieren en cuánto restringen y en cuándo actúan. Los principios expresan una dirección duradera y dejan margen al criterio. Los estándares son elecciones concretas y obligatorias (todos los servicios exponen trazas de OpenTelemetry; todas las API públicas se describen en OpenAPI). Los guardrails (salvaguardas) mantienen a los equipos dentro de límites seguros mientras trabajan, normalmente de forma automática y continua. Las compuertas (gates) detienen el trabajo hasta que alguien lo aprueba.

El consenso actual, aunque no universal, es preferir los guardrails a las compuertas siempre que una regla pueda formularse de manera objetiva, reservar las compuertas para las pocas decisiones en las que de verdad hace falta un criterio humano con rendición de cuentas, y celebrar esas compuertas pronto y con un tiempo limitado. Un camino pavimentado (paved road) (término de Netflix; Spotify lo llama camino dorado, golden path) complementa a ambos: cuando la forma admitida de construir un servicio ya incluye imágenes aprobadas, logging, análisis de seguridad y despliegue, la mayoría de los equipos cumplen sin que se les diga, y el esfuerzo de gobernanza puede concentrarse en las desviaciones deliberadas. La Sección 10.7 trata las plataformas que ofrecen esos caminos.

Redactar principios de arquitectura

TOGAF, el marco de arquitectura empresarial de The Open Group (el TOGAF Standard, 10th Edition, 2022), ofrece una plantilla muy utilizada para los principios, con cuatro partes. El nombre es breve y fácil de recordar. El enunciado expresa la regla en una o dos frases inequívocas. La justificación explica el beneficio para el negocio, en términos que un patrocinador no técnico podría aceptar. Las implicaciones dicen qué exige el principio en la práctica: qué hay que hacer, cuánto cuesta y qué descarta. TOGAF también enumera criterios para un buen conjunto de principios: comprensible, robusto (lo bastante preciso para decidir casos difíciles), completo, coherente y estable.

Dos pruebas detectan la mayoría de los principios débiles. Primero, ¿podría una organización sensata elegir lo contrario? "Los sistemas deben ser seguros" no la supera; nadie elegiría la inseguridad. "Preferir comprar a construir para las capacidades genéricas" la supera, porque algunas organizaciones prefieren, con razón, construir. Segundo, ¿cambia el principio una decisión real? Si nadie puede nombrar una elección que resolvería, es un eslogan. Andrew Harmel-Law pide un conjunto que no sea ni demasiado pequeño para cubrir las necesidades clave ni demasiado grande para que los equipos lo recuerden, que proceda de los propios equipos y esté vinculado a la estrategia de negocio, en lugar de máximas o prácticas generales de programación. Los principios más escasos y precisos se recuerdan y se usan; las listas largas, no.

Toma de decisiones descentralizada: el proceso de consejo

Si las decisiones ya no se canalizan a través de una junta, ¿quién las toma? El artículo de Andrew Harmel-Law Scaling the Practice of Architecture, Conversationally (martinfowler.com, diciembre de 2021) propuso una respuesta tomada de las organizaciones autogestionadas: el proceso de consejo (advice process). Su única regla es que cualquiera puede tomar una decisión arquitectónica, siempre que antes de decidir pida consejo a todas las personas a las que afectará de forma significativa y a personas con conocimientos relevantes. Quien toma la decisión debe escuchar y registrar el consejo, pero no está obligado a seguirlo; el objetivo es una aportación amplia, no el consenso. La responsabilidad sigue siendo de la persona o el equipo que decide, y eso es lo que hace funcionar la regla: quien sabe que carga con las consecuencias pide consejo en serio.

Harmel-Law describe cuatro elementos de apoyo. Los registros de decisiones (ADR, Sección 4.5) son la herramienta para pensar y registrar, e incluyen el consejo recibido, de quién y cuándo. Un foro asesor de arquitectura, normalmente semanal, de alrededor de una hora y abierto a cualquiera, da visibilidad a los nuevos spikes, a las decisiones propuestas y a las que se revisan; y, lo que es fundamental, ofrece consejo, pero no decide. Los principios arquitectónicos que proceden de los equipos dan una dirección compartida. Y un radar tecnológico interno muestra el panorama tecnológico actual de la organización y su postura.

El proceso de consejo tiene modos de fallo que conviene conocer. Quienes deciden pueden consultar solo a las personas que probablemente estarán de acuerdo; ayuda una lista publicada de a quién hay que consultar para cada tipo de decisión (a seguridad para cualquier cosa que toque datos personales, al equipo de plataforma para la nueva infraestructura). El consejo puede pedirse demasiado tarde, cuando el código ya está escrito; ayuda hacer del ADR propuesto el comienzo del trabajo, no el final. Y a algunas personas les resulta incómodo al principio que el foro no decida. En entornos regulados, el proceso puede convivir con un pequeño número de compuertas formales, aplicadas solo donde la ley o el apetito de riesgo de la organización lo exijan.

Radares tecnológicos

Thoughtworks publica su Technology Radar dos veces al año desde 2010. Cada edición sitúa un centenar de blips (técnicas, herramientas, plataformas, y lenguajes y frameworks: los cuatro cuadrantes) en anillos que expresan una recomendación. Adopt significa probado y recomendado; Trial, que merece la pena aplicarlo en un proyecto que pueda asumir el riesgo; Assess, que merece la pena explorarlo para entender su efecto; y el anillo exterior, llamado Hold durante la mayor parte de la historia del radar y Caution en sus ediciones más recientes, significa avanzar con cuidado. Cada blip tiene una breve justificación por escrito, que es la parte más valiosa.

Muchas organizaciones crean su propio radar, para sí mismas y no para el sector. Thoughtworks ofrece una herramienta de código abierto, Build Your Own Radar, que genera un radar a partir de una hoja de cálculo o un archivo CSV con las columnas name, ring, quadrant, isNew y description. El valor está menos en la imagen que en el proceso: los equipos proponen blips, un grupo pequeño con representantes de muchos equipos los debate, los anillos se asignan con una razón por escrito y el radar se actualiza cada trimestre o cada semestre. Un anillo Hold es una herramienta de gobernanza suave pero eficaz: dice "ningún uso nuevo" sin prohibir lo que ya existe. Un radar se diferencia de una lista de tecnologías aprobadas en que es explícitamente provisional y razonado, y en que recoge lo que la organización ha aprendido, incluidos sus errores.

name,ring,quadrant,isNew,description
Debezium for outbox relay,Trial,Tools,TRUE,"Change data capture from the order database's write-ahead log to Kafka, replacing polling relays. Trial in ordering only; see ADR-0031. Owner: ordering team. Review: Q3."
Polling outbox relay,Hold,Techniques,FALSE,"Adds load and latency at peak; no new uses. Existing relays move when Debezium leaves Trial."

# ADR-0031: Use Debezium change data capture for the ordering outbox relay

Status: Accepted (2026-05-14)   Decision-taker: Priya N., ordering team
Context: The polling relay queries the outbox table every 500 ms. At 100 orders/s
it adds measurable database load and up to 1 s of event delay to dispatch.
Options: (1) tune polling; (2) Debezium CDC on the write-ahead log; (3) managed CDC
from the cloud provider.
Decision: Option 2, for the ordering service only, as a Trial on the radar.
Advice received:
- Platform team (2026-05-06): supports; will run Kafka Connect, needs runbook.
- Data team (2026-05-07): concern about replication slot growth if Connect stops;
  asks for an alert on slot lag. Accepted.
- Security (2026-05-08): CDC user must have replication rights only. Accepted.
- Advisory forum (2026-05-09): suggested option 3; rejected for portability (P3).
Consequences: lower load and delay; a new component to operate; slot-lag alert
and a fitness function on event delay (p99 under 2 s) added.
Review: after one quarter, or before any second service adopts it.

El papel actual de la arquitectura empresarial

La arquitectura empresarial (Sección 1.2) ha tenido una reputación incómoda en las organizaciones ágiles: equipos centrales que producían marcos, estándares y procesos de aprobación que los equipos de entrega vivían como obstáculos. El papel ha ido cambiando. En las organizaciones donde funciona bien, los arquitectos empresariales curan los principios y el radar en lugar de dictarlos, mantienen el mapa de capacidades de negocio y sistemas que ningún equipo puede ver por sí solo, toman o facilitan las decisiones de puerta de un solo sentido que de verdad afectan a toda la organización (identidad, datos centrales, estrategia de nube, grandes proveedores), dirigen el foro asesor y dan forma a la plataforma y al camino pavimentado junto con los equipos de plataforma.

La imagen de Gregor Hohpe del arquitecto que viaja en ascensor entre la sala de juntas y la sala de máquinas (Sección 11.7) describe la habilidad que esto requiere: traducir la estrategia en dirección técnica y las restricciones técnicas al lenguaje del negocio. Los profesionales siguen sin ponerse de acuerdo sobre cuánta autoridad central es sana. Algunos sostienen que una función central fuerte es imprescindible en empresas reguladas, con muchas fusiones o muy integradas; otros sostienen que la mayor parte de su valor puede ofrecerse mediante plataformas, principios y consejo. La respuesta depende del tamaño de la organización, de su regulación y de qué parte de su panorama de sistemas es realmente compartida.

Cumplimiento mediante la automatización

Sea cual sea el modelo organizativo, el cumplimiento más barato es el automatizado. Las funciones de aptitud (Sección 11.3) comprueban las características de la arquitectura. La política como código hace lo mismo con las reglas de la organización: las reglas se escriben en un lenguaje legible por máquinas, se guardan en el control de versiones, se revisan y se prueban como el código, y se evalúan automáticamente contra definiciones de infraestructura, manifiestos de despliegue o solicitudes a la API. Open Policy Agent, un proyecto graduado de la Cloud Native Computing Foundation, es un motor de uso general muy utilizado con su propio lenguaje de políticas, Rego; Conftest aplica políticas Rego a archivos de configuración en un pipeline, y los controladores de admisión como OPA Gatekeeper o Kyverno hacen cumplir políticas dentro de los clústeres de Kubernetes.

El cumplimiento automatizado tiene otra ventaja que las organizaciones reguladas valoran mucho: las pruebas. Un registro del pipeline que muestra que cada lanzamiento pasó las mismas comprobaciones es una prueba mucho más sólida para un auditor que un formulario firmado, y se produce sin costo adicional.

package main

import rego.v1

# Guardrail: images must come from the organisation's scanned registry
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not startswith(c.image, "registry.fooddelivery.example/")
    msg := sprintf("%s: image %s is not from the approved registry", [input.metadata.name, c.image])
}

# Guardrail: every container declares a memory limit
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not c.resources.limits.memory
    msg := sprintf("%s: container %s has no memory limit", [input.metadata.name, c.name])
}

Equilibrar autonomía y alineación

La pregunta práctica es qué decisiones se gobiernan y cómo. Una regla útil se deriva de la Sección 1.6: cuanto más reversible y local es una decisión, más cerca del equipo debe tomarse; cuanto más irreversible y de mayor alcance, más consejo y, en ocasiones, aprobación necesita. La tabla presenta un reparto típico; cada organización ajusta el suyo.

La propia gobernanza debe medirse. Son señales útiles cuánto tardan las decisiones significativas desde la propuesta hasta la aceptación, cuántas excepciones a los estándares se solicitan y se conceden, qué proporción de servicios está en el camino pavimentado, cuántas tecnologías en Hold se siguen extendiendo y si los incidentes se remontan a decisiones que se saltaron el consejo. Si las decisiones son lentas, la gobernanza es demasiado pesada; si los incidentes siguen remontándose a decisiones no consultadas, es demasiado ligera.