O-AA es el estándar de The Open Group para arquitectura en organizaciones ágiles. Esta página explica qué es, qué huecos deja al descubierto en una empresa que ya trabaja con métodos ágiles, y por dónde conviene empezar a cerrarlos.
«El objetivo de este documento es cubrir tanto la Transformación Digital de la empresa como su Transformación Ágil.»
O-AA §1.1 — ObjetivoEsa sola frase ubica el estándar. No describe cómo se corre un sprint ni cómo se estima un backlog: describe cómo se transforma una empresa en dos frentes al mismo tiempo —el digital y el organizacional— sin que la arquitectura se quede atrás en el intento.
No compite con Scrum ni con SAFe: se pone encima. Ellos organizan cómo se entrega cada iteración. O-AA se ocupa de que la suma de esas iteraciones siga teniendo una arquitectura defendible dos años después.
«Este documento no trata de alinear la capa de Sistemas de Información con la capa de Negocio. Las decisiones de negocio impactan todas las preocupaciones, incluidas las de software y hardware.»
O-AA §10.1 — Building Blocks LogicAhí rechaza de frente el encuadre clásico de «alinear TI con el negocio», que supone dos mundos que hay que acercar. Para O-AA es un solo sistema.
El ejemplo que usa el propio estándar es el mandato de Bezos de que todos los equipos de Amazon expusieran sus datos por interfaces de servicio: una decisión de arquitectura de software que fue, al mismo tiempo, una decisión de negocio que reconfiguró la organización y la estrategia de la empresa.
El estándar se organiza en una matriz —lo que la empresa hace frente a lo que la empresa es— más cinco bloques que la cruzan entera. Este es el índice real de su segunda parte.
| Preocupación | Lo que la empresa hace | Lo que la empresa es |
|---|---|---|
| Experiencia | Diseño de experienciacap. 13 Journey mappingcap. 15 | Arquitectura de productocap. 14 |
| Sistema de trabajo | Mapeo de flujos de valorcap. 16 | Arquitectura de operacionescap. 17 |
| Sistema técnico | Event stormingcap. 19 | Domain-Driven Designcap. 20 |
Vale la pena detenerse aquí, porque es lo que casi nadie espera: la migración de una plataforma toca dos casillas de seis. Estrategia, organización, experiencia y flujos de valor no aparecen en un proyecto de migración, y son la mayor parte del estándar. Hay además una quinta preocupación —la Organización— que se conecta con las demás por la maniobra inversa de Conway.
O-AA rechaza la emergencia pura: algo de diseño previo evita desperdicio y acelera decisiones. Pero se corre del gran diseño por adelantado a la arquitectura continua. Lo intencional debe ocuparse de la esencia del sistema, no del catálogo de funciones, y se trata como lo que es: un conjunto de supuestos que hay que verificar.
No es un entregable que se firma. La deuda de diseño se acumula, los requerimientos no funcionales cambian, hay decisiones que envejecen mal y hay pivotes de negocio. El estándar dedica un capítulo entero a reestructurarla de forma permanente y a los entornos —técnico y no técnico— que lo hacen posible.
Las capas tienden al monolito aunque se desplieguen por separado. Y del lado del negocio, las áreas funcionales —finanzas, operaciones, comercial— también son capas. El estándar pide partir en tres niveles con tres criterios distintos: el negocio por mercado, el modelo operativo por capacidad y el software por dominio.
Un equipo ágil de verdad no entrega un proyecto sino un producto. El paso de estructuras temporales a permanentes es lo que sostiene todo lo demás: sin equipo estable no hay refactorización continua ni quién responda por las decisiones. Es axioma, no preferencia.
La maniobra inversa de Conway: en vez de aceptar que el sistema termine pareciéndose al organigrama, se moldea la organización para que sus líneas de comunicación sigan las fronteras de la arquitectura intencional. Con una advertencia del estándar: ninguna de las dos es estática, y el éxito depende de que coevolucionen.
El capítulo 9 los define como «lineamientos o restricciones que se recomienda seguir a los arquitectos ágiles». Van del enfoque en la experiencia del cliente y el pensamiento de afuera hacia adentro hasta la plataforma de datos modular y la seguridad por diseño. Son criterio, no lista de cumplimiento.
Estos seis son los que más se repiten, y ninguno es una opinión suelta: cada uno corresponde a algo que el estándar señala de forma explícita. Debajo de cada uno va la pregunta con la que usted mismo puede verificar si le aplica.
Es el hueco más común y el menos visible. El estándar lo describe así: al adoptar formas ágiles de trabajo, lo primero que se nota es que bajan los proyectos que llegan al comité. Los grandes se parten en piezas que ya no se administran como un todo, y esas piezas no alcanzan el tamaño mínimo para ser revisadas.
Dejan de ser proyectos y pasan a ser productos entregados por equipos ágiles. El resultado: se mueven por debajo del radar del gobierno clásico. Nadie decidió dejar de gobernar — el umbral se quedó donde estaba y el trabajo se hizo más chico.
El estándar es directo: los miembros del gobierno clásico no están lo bastante cerca del campo y suelen decidir sobre información de segunda mano que puede no reflejar la realidad actual. Y entre las causas de fondo que enlista para los fracasos grandes están las incómodas: decisiones contaminadas por luchas de territorio, y miembros que influyen sin ser responsables del resultado.
La alternativa que plantea no es quitar el gobierno, sino mover el derecho de decidir hacia los equipos más cercanos a la información, y convertir las normas en guardrails: barreras que expresan la intención de una política, en lugar de listas de tareas a cumplir.
Se diseñó al inicio del programa, se aprobó y se guardó. A partir de ahí cada decisión urgente la fue erosionando sin registro. Tres años después el sistema nuevo volvió a ser intocable, y nadie puede decir en qué momento pasó.
El estándar nombra el fenómeno —la deuda de diseño acumulada— y le pone remedio: refactorización arquitectónica continua. La arquitectura se reestructura de forma permanente, o deja de ser arquitectura y se convierte en documentación.
El sistema se dividió en presentación, negocio y datos; la empresa se dividió en finanzas, operaciones y comercial. Ambas divisiones son lo mismo: capas. Y las capas crean silos, que es justo lo que reduce la agilidad y la capacidad de escalar.
Se nota en la factura. En un sistema por capas, un cambio de negocio toca las cinco capas y coordina a cinco equipos. En uno partido por dominios, toca un dominio y un equipo.
Los pilotos de inteligencia artificial funcionan y ninguno llega a producción. En nuestra experiencia la causa rara vez es el modelo: es que los datos viven centralizados en una plataforma que nadie posee y por cuya calidad nadie responde.
El estándar llega al mismo lugar por otro camino. Muestra cómo, al unificar todo en una base compartida, una misma palabra deja de significar lo mismo — su ejemplo es «parte», que en almacén es un número con existencias en bodegas y en control de calidad es un objeto físico al que se le aplican pruebas. El modelo unificado termina hablando un idioma propio, y ahí empiezan los errores.
Lo que propone es una arquitectura de datos modular: lo que Zhamak Dehghani llamó data mesh. En vez de llevar los datos de los dominios a un lago central, cada dominio aloja y sirve sus propios datos de forma fácil de consumir, con contextos delimitados tanto del lado que origina el dato como del que lo consume.
Dos huecos que en la práctica son uno solo. El estándar los pone entre sus cambios de mentalidad: de priorizar funcionalidades del producto a priorizar resultados de negocio, medidos con indicadores. Las funciones tienen que resolver un objetivo, no llenar un backlog.
Y de proyecto a producto: cuando el proyecto cierra, el equipo se disuelve y el conocimiento se va con él. El siguiente equipo hereda un sistema que nadie sabe por qué está construido así.
O-AA no exige una secuencia ni un programa de adopción. Se entra por el problema que ya se tiene, y ese problema define qué parte del estándar aplica primero. Éstas son las puertas más frecuentes.
| Si su situación es… | Se entra por |
|---|---|
| «Entregamos por proyectos y cada uno deja huérfano lo anterior» | Cap. 12 · axioma 15 Organización ágil |
| «Vamos a abrir operación en otro país» | §5.6 Arquitectura intencional |
| «Vamos a cambiar de modelo de negocio» | §5.6 y cap. 11 Estrategia ágil |
| «Mis comités de arquitectura son un cuello de botella» | Cap. 8 Gobierno ágil |
| «Tengo los datos en un lago monolítico y la IA no despega» | Cap. 18 · axioma 9 Datos e IA |
| «Mis equipos no embonan con mi arquitectura» | Cap. 12 · axioma 12 Conway inverso |
| «Quiero lanzar un producto digital nuevo» | Caps. 13, 14 y 15 Experiencia y producto |
| «Mis procesos son lentos y no sé en qué paso» | Caps. 16 y 17 Flujos de valor y operación |
| «Tengo un core heredado del que necesito salir» | Caps. 6, 20 y 22 Refactorización y dominio |
Fíjese en el último renglón. Salir de un sistema heredado es una de las nueve puertas, no el estándar entero. Es la más conocida porque es la más dolorosa, pero una empresa que nunca tuvo un mainframe puede tener abiertos los ocho huecos anteriores.
Y hay una que conviene señalar. Para ilustrar cuándo sí vale la pena detenerse a diseñar por adelantado, el estándar desarrolla un ejemplo —una plataforma de coche compartido, que él mismo declara ficticio— y una de las dos situaciones que plantea es la expansión internacional acelerada. Las preguntas que enlista son las mismas que enfrenta cualquiera que abra operación en otro país: qué actividades se centralizan y cuáles no, cuál es el alcance de la operación local, si se clona la plataforma en cada país o se construye multi-tenant desde el principio. Son decisiones caras de revertir y casi siempre se toman con prisa.
Sea cual sea la puerta de entrada, la ejecución se parece. No es una secuencia con final: es un ciclo que sigue girando mientras el sistema esté vivo, y cada vuelta deja algo concreto que usted puede pedir y revisar.
El estándar respalda que sea ciclo y no línea: uno de sus siete cambios de mentalidad es justamente «de secuencial a concurrente». Las fases de un programa terminan; la arquitectura no.
Antes de dibujar cajas, sentamos en la misma sala a quien opera el negocio y a quien escribe el código, y recorremos los eventos reales del proceso: qué pasó, en qué orden, quién lo disparó. Sirve para algo muy concreto: descubrir que «cliente» significa tres cosas distintas en tres áreas, antes y no después de haberlo programado.
Dividimos en contextos delimitados por significado de negocio, no en capas técnicas, y definimos los contratos entre ellos. Donde el sector ya publicó un modelo de referencia lo tomamos de ahí en vez de inventarlo; donde no lo hay, se construye con lo que salió del descubrimiento.
La deuda de arquitectura —la parte de la deuda técnica que no se paga refactorizando una clase— se mide y se atiende en cada ola, no cuando ya duele. Se lleva un inventario vivo de las decisiones que envejecieron mal, priorizadas contra el costo de seguir arrastrándolas.
La decisión la toma quien tiene el contexto, y queda registrada con fecha, motivo y alternativas descartadas. Lo que escala a revisión es solo lo que cruza contextos o compromete al negocio. Un comité que aprueba todo no gobierna: hace cola.
Si algo de esta página describe su situación, la conversación útil no empieza por una propuesta. Empieza por revisar juntos cuál de los huecos tiene abierto y cuánto le está costando.