Módulo 8: Proyecto capstone — sé el arquitecto de Mercado ante un cambio

2. Enmarca el rol y el encargo

Descripción

Este es el paso 1 del entregable, y es el que casi todos se saltan: antes de derivar un atributo, dibujar una caja o estructurar un equipo, el arquitecto tiene que enmarcar dos cosas —qué es su rol en este cambio y qué es el encargo—. Suena obvio, pero es el paso donde se decide si el cambio va a tener un arquitecto que habilita o un cuello de botella que ahoga. La frase del liderazgo —"abrir Mercado a vendedores externos por API y crecer 10x"— no es una instrucción que el arquitecto ejecuta con sus manos: es un encargo que desata una ola de decisiones, y el trabajo del arquitecto no es tomarlas todas, sino separar las pocas que son suyas (las que cruzan equipos, moldean la estructura, definen contratos) de las muchas que delega (las locales, que la squad dueña toma mejor porque está más cerca del problema). Al terminar esta lección vas a tener el primer artefacto del dossier: el mapa de ownership del cambio, con el costo de coordinación medido de hacerlo bien contra hacerlo mal.

Esto importa porque el mayor riesgo de un cambio grande no es técnico, es estructural en el rol del arquitecto: la tentación de "revisar todo para que la calidad no se caiga" convierte al arquitecto en el paso obligado de cada decisión, y con eso mata el cambio de dos formas a la vez —lo frena (todo espera su visto bueno) y lo empeora (las squads, que sabían más, dejan de decidir)—. El módulo 1 te enseñó esto en abstracto con Álex, el arquitecto de Mercado atrapado en las cuatro imágenes falsas. Aquí lo aplicas al cambio concreto: un cambio que toca las cinco squads y agrega actores nuevos genera decenas de decisiones por semana, y ninguna persona puede ser el embudo de todas sin volverse el cuello de botella que el propio módulo 1 juró evitar. Enmarcar bien el rol es lo que hace posible todo lo demás: solo un arquitecto que no está ahogado en 46 decisiones semanales tiene el tiempo y la cabeza para derivar atributos, estructurar equipos y liderar el rollout.

Conexión con el módulo: esta lección hace el paso 1 del hilo que viste en la lección 1, y aporta la pieza de M1 al capstone. Es deliberadamente lo primero, porque enmarca el rol con el que harás todo lo demás: si aquí decides ser el embudo, no llegarás vivo al paso 3. La salida de esta lección —el mapa de qué posee el arquitecto y qué delega— alimenta directamente a la lección 4 (la maniobra inversa de Conway): las decisiones locales que aquí delegas son las que allá se vuelven responsabilidad de equipos con fronteras claras. Y prepara la lección 6 (el rollout sin autoridad): el arquitecto que aquí se define como jardinero es el que allá podrá liderar sin ser la puerta. Aquí no derivas atributos todavía (eso es la lección 3); aquí decides quién decide qué en el cambio.

El director de obra que no pone los ladrillos

Piensa en la construcción de un edificio grande. Hay un director de obra, y hay muchos oficios: albañiles, electricistas, plomeros, carpinteros, cada uno experto en lo suyo. El encargo del cliente es una frase: "quiero un edificio de oficinas de diez pisos, listo en dieciocho meses". De esa frase salen miles de decisiones: qué grosor de cable en cada piso, cómo se enruta la tubería del baño del tercer nivel, qué tipo de bisagra en las puertas, dónde va cada toma de corriente. Un director de obra novato, ansioso por que "todo salga perfecto", intenta aprobar cada una de esas decisiones: ningún electricista conecta un cable sin su visto bueno, ningún plomero suelda una junta sin que él la revise. ¿Qué pasa? La obra se detiene. Los oficios pasan el día esperando al director, que corre de un piso a otro sin dar abasto, y como no es electricista ni plomero, sus aprobaciones ni siquiera mejoran las decisiones —solo las retrasan—.

El director de obra que sabe su oficio hace lo contrario. Reconoce que de esas miles de decisiones, solo unas pocas son suyas: dónde van los muros de carga (porque afectan a todo el edificio), cómo se conectan los sistemas entre pisos (porque cruzan oficios), qué normas de seguridad son innegociables (porque son de alto riesgo). Esas las posee él, porque tienen una vista del conjunto que ningún oficio tiene. Todas las demás —el grosor del cable, la ruta de la tubería, la bisagra— las delega al oficio experto, dándole una regla clara ("todo cable cumple esta norma", "toda tubería aguanta esta presión") en vez de revisar cada junta. Así la obra fluye: los oficios deciden lo suyo con autonomía dentro de las reglas, y el director se concentra en las pocas decisiones estructurales donde su vista del conjunto es insustituible.

El arquitecto ante "abrir Mercado a vendedores externos" es ese director de obra. El encargo desata decenas de decisiones por semana, y la trampa es querer aprobarlas todas "para que la calidad no se caiga". El oficio es separar las muros de carga —los contratos entre servicios, los límites de la Seller API, los atributos de calidad, la seguridad de los datos de terceros— que el arquitecto posee, de las bisagras —cómo cada squad implementa lo suyo por dentro— que delega con guardrails. Esta lección es dibujar ese mapa y medir, con números, cuánto cuesta confundirse de rol.

Ejemplo trabajado: el mapa de ownership del cambio, medido

Vamos a enmarcar el encargo en tres pasos ejecutados. Primero, traducir el cambio al conjunto de decisiones que genera por semana, separando las cross-team (de nivel arquitecto: contratos, límites de servicio, atributos) de las locales (de la squad dueña). Segundo, medir el costo de coordinación de dos formas de ejercer el rol: el arquitecto-embudo que posee las 46, contra el arquitecto-jardinero que posee solo las 8 cross-team y delega las 38 con guardrails. Y tercero, mostrar por qué centralizar no escala —por qué el arquitecto no puede ser el canal único por el que todo pasa—.

# Capstone paso 1: entender el ROL y el ENCARGO antes de diseniar nada.
# El cambio "abrir a vendedores externos + crecer 10x" desata una ola de decisiones.
# La pregunta del arquitecto NO es "que decido yo": es "cuales son MIAS (load-bearing,
# cross-team) y cuales delego a la squad duena con guardrails" -- para no volverme el
# cuello de botella por el que todo el cambio tiene que pasar.

# Decisiones que el cambio genera en una semana tipica, por squad: (total, cross_team).
# Las cross-team son de nivel arquitecto (contratos, limites de servicio, atributos);
# el resto son locales, de la squad que las vive.
change_decisions = {
    "catalog":  (14, 2),   # el 10x de listings golpea al catalogo mas que a nadie
    "checkout": (9, 1),
    "payments": (8, 2),    # pagos y payouts a vendedores externos
    "shipping": (7, 1),
    "platform": (8, 2),    # api gateway, auth de terceros, rate limiting
}
ARCHITECT_CAPACITY = 12   # decisiones que una persona alcanza a atender por semana
WEEKS = 10                # el horizonte del rollout

total = sum(t for t, _ in change_decisions.values())
cross = sum(c for _, c in change_decisions.values())
local = total - cross

print("=== Paso 1: mapa de ownership del cambio ===")
print(f"{'squad':<10}{'total':>7}{'cross->architect':>18}{'local->squad':>14}")
print("-" * 49)
for squad, (t, c) in change_decisions.items():
    print(f"{squad:<10}{t:>7}{c:>18}{t - c:>14}")
print("-" * 49)
print(f"{'TOTAL':<10}{total:>7}{cross:>18}{local:>14}")


# Costo de coordinacion: arquitecto-embudo (posee las 46) vs arquitecto-jardinero
# (posee solo las 8 cross-team, delega 38 con guardrails). Misma capacidad en ambos.
def simulate(arrivals, capacity, weeks):
    backlog = total_wait = 0
    for _ in range(weeks):
        backlog += arrivals
        backlog -= min(backlog, capacity)
        total_wait += backlog
    return backlog, total_wait


bl_bottleneck, wait_bottleneck = simulate(total, ARCHITECT_CAPACITY, WEEKS)
bl_garden, wait_garden = simulate(cross, ARCHITECT_CAPACITY, WEEKS)

print()
print(f"=== Paso 2: costo de coordinacion en {WEEKS} semanas ===")
print(f"{'rol del arquitecto':<30}{'backlog':>10}{'espera(dec-sem)':>17}")
print("-" * 57)
print(f"{'EMBUDO   (posee las 46)':<30}{bl_bottleneck:>10}{wait_bottleneck:>17}")
print(f"{'JARDINERO(posee 8 cross-team)':<30}{bl_garden:>10}{wait_garden:>17}")
print()
print(f"Delegar lo local ahorra {wait_bottleneck - wait_garden} decision-semanas y elimina el backlog.")


# Por que centralizar no escala: si TODO pasa por el arquitecto, el es un cuello con
# muchos canales. Y el cambio hace CRECER la organizacion (una squad nueva para el
# surface de vendedores). Los canales de coordinacion entre squads crecen n(n-1)/2.
def paths(n):
    return n * (n - 1) // 2


print("=== Paso 3: por que el arquitecto no puede ser el canal unico ===")
for squads in (5, 6):
    print(f"  {squads} squads  ->  {paths(squads)} canales de coordinacion entre squads")
print(f"  Un mega-equipo de 12 personas ->  {paths(12)} canales internos")
print(f"  Dos equipos de 6 personas     ->  {paths(6)} + {paths(6)} = {paths(6)*2} canales internos")
print("El arquitecto que aprueba todo se vuelve el hub por el que pasan TODOS los canales:")
print("no escala. El rol es poseer las 8 decisiones load-bearing y estructurar equipos")
print("(modulo 2) para que las 38 locales fluyan sin el. Ese es el encargo, bien enmarcado.")

Qué esperar. Al correrlo:

=== Paso 1: mapa de ownership del cambio ===
squad       total  cross->architect  local->squad
-------------------------------------------------
catalog        14                 2            12
checkout        9                 1             8
payments        8                 2             6
shipping        7                 1             6
platform        8                 2             6
-------------------------------------------------
TOTAL          46                 8            38

=== Paso 2: costo de coordinacion en 10 semanas ===
rol del arquitecto               backlog  espera(dec-sem)
---------------------------------------------------------
EMBUDO   (posee las 46)              340             1870
JARDINERO(posee 8 cross-team)          0                0

Delegar lo local ahorra 1870 decision-semanas y elimina el backlog.
=== Paso 3: por que el arquitecto no puede ser el canal unico ===
  5 squads  ->  10 canales de coordinacion entre squads
  6 squads  ->  15 canales de coordinacion entre squads
  Un mega-equipo de 12 personas ->  66 canales internos
  Dos equipos de 6 personas     ->  15 + 15 = 30 canales internos
El arquitecto que aprueba todo se vuelve el hub por el que pasan TODOS los canales:
no escala. El rol es poseer las 8 decisiones load-bearing y estructurar equipos
(modulo 2) para que las 38 locales fluyan sin el. Ese es el encargo, bien enmarcado.

Lee el paso 1 primero, porque es el diagnóstico de raíz. El cambio genera 46 decisiones por semana, y de ellas solo 8 cruzan equipos —los contratos de la Seller API, los límites entre el surface de vendedores y el catálogo, la política de rate limiting, la auth de terceros, el manejo de payouts—. Las otras 38 son locales: cómo el catálogo indexa internamente para aguantar 10x más listings, qué caché usa el checkout, cómo payments estructura sus tablas de payout. Ese reparto ya te dice cuál es tu rol: las 8, no las 46. Fíjate que el catálogo aporta 12 decisiones locales —es el squad que más golpea el 10x de listings— y solo 2 cross-team; el arquitecto no tiene por qué meterse en las 12, esas las decide catalog mejor que nadie porque las vive. El mapa separa, sin más análisis, los muros de carga de las bisagras.

Ahora el paso 2, donde el diagnóstico se vuelve número y duele. Con el rol embudo —el arquitecto posee las 46, capacidad de 12 por semana— en 10 semanas se acumula un backlog de 340 decisiones atascadas y 1870 decision-semanas de espera: las cinco squads pasan una parte enorme del rollout esperando el visto bueno de un arquitecto que no da abasto por más que trabaje. Con el rol jardinero —solo las 8 cross-team suben, las 38 locales las deciden las squads con guardrails— el backlog es 0 y la espera es 0. La misma capacidad (12) en los dos casos; lo único que cambia es cuánto trabajo se hace pasar por el arquitecto. Delegar lo local ahorra 1870 decision-semanas y elimina el atasco. No es que el jardinero trabaje más; es que dejó de ser el paso obligado de 38 decisiones que no eran suyas. Este es exactamente el resultado del módulo 1 (el bottleneck es estructural, no un defecto de esfuerzo), ahora medido sobre este cambio.

Y el paso 3 explica por qué la trampa del embudo empeora justo cuando el cambio crece. Los canales de coordinación entre squads crecen como n(n-1)/2: con 5 squads son 10, y como el cambio agrega un equipo nuevo para el surface de vendedores (lo verás en la lección 4), con 6 squads son 15. Si el arquitecto insiste en ser el canal único, se vuelve el hub por el que pasan todos esos canales —y ese hub no escala: crece con cada squad y cada decisión—. La última línea nombra la salida: el rol es poseer las 8 decisiones load-bearing y estructurar los equipos (que es el paso 3, la maniobra inversa de Conway) para que las 38 locales fluyan sin él. Fíjate en el dato de los equipos: un mega-equipo de 12 personas tiene 66 canales internos; dos equipos de 6 tienen 30 en total —menos de la mitad—. Esa es la semilla de por qué el cambio necesita un equipo nuevo y chico, no inflar uno existente. El encargo, bien enmarcado, es "poseo 8, delego 38, y para que las 38 fluyan sin mí, estructuro la organización" —y eso es el puente a la lección 4—.

Profundización: qué hace que una decisión sea del arquitecto

El mapa depende de una clasificación —cross-team vs local— que conviene volver precisa, porque es el juicio central de esta lección. ¿Qué hace que una decisión del cambio sea de nivel arquitecto y no de la squad? Tres pruebas, las mismas que el módulo 5 usó para los architecturally-significant requirements, aplicadas aquí a las decisiones.

Primera: ¿cruza fronteras de equipo? Una decisión es del arquitecto si su resultado obliga a coordinar a más de un equipo o define cómo se hablan entre sí. El contrato de la Seller API es de nivel arquitecto porque todos los que la consuman dependen de él; el formato interno de la tabla de listings del catálogo no lo es, porque solo catalog lo toca. La regla: si cambiar la decisión rompe a otro equipo, es load-bearing; si solo afecta a quien la toma, es local. En el cambio de Mercado, las 8 cross-team son precisamente las que definen las fronteras del surface nuevo con el resto del sistema.

Segunda: ¿moldea la estructura y es cara de revertir? Una decisión es del arquitecto si define una costura que después será cara de mover. "La Seller API se expone detrás de un gateway con contrato versionado" moldea toda la arquitectura del surface y es carísima de cambiar una vez que hay terceros integrados; "el catálogo usa este índice invertido" es reversible dentro de catalog sin que nadie afuera se entere. El arquitecto pone su energía donde el error es caro y permanente, no donde es barato y local. Esta prueba es la que evita el otro extremo: no toda decisión "importante" es del arquitecto —muchas son importantes para la squad pero triviales para la estructura—.

Tercera: ¿es de alto riesgo transversal? Una decisión es del arquitecto si un error se propaga más allá del equipo que lo comete —seguridad de los datos de terceros, un atributo de calidad que todos deben cumplir, un límite que si se rompe cae todo el sistema—. La auth de vendedores externos es de nivel arquitecto porque un fallo ahí compromete a toda la plataforma; el color del botón de "publicar producto" del panel de vendedor no lo es, por más visible que sea. El riesgo transversal, no la visibilidad, es lo que sube una decisión al arquitecto.

Con estas tres pruebas, la clasificación deja de ser a ojo. Y aquí está el punto fino: la mayoría de las decisiones de un cambio, incluso uno grande, son locales. En Mercado, 38 de 46. Eso no es una casualidad del ejemplo; es la realidad de casi cualquier cambio, y es liberador —significa que el arquitecto no tiene que (ni puede) tocar la mayor parte del trabajo—. El error del embudo es no creer esto: sentir que "todo es importante, así que todo es mío". La disciplina del jardinero es aplicar las tres pruebas con honestidad y descubrir que la mayoría de las decisiones pasan las tres con un "no" —son bisagras, no muros de carga— y por lo tanto no son suyas.

Un matiz honesto sobre el modelo. Los números (46 decisiones, 8 cross-team, capacidad 12) son un juicio ilustrativo, no una medición de Mercado, y el modelo de colas es una simplificación —trata todas las decisiones como iguales en costo, cuando unas toman minutos y otras días—. Lo que el modelo captura no es una predicción exacta de semanas, sino la estructura del problema: hacer pasar mucho más trabajo del que cabe por una sola persona produce un backlog que crece sin techo, y el remedio no es que la persona corra más rápido (la capacidad es la misma en los dos escenarios) sino hacer pasar menos delegando lo que no es suyo. Esa forma —el atasco del embudo contra el flujo del jardinero— es robusta aunque los números exactos sean discutibles.

Errores comunes

Clasificar demasiadas decisiones como "del arquitecto" por miedo a la calidad (de embudo). Qué pasa: el arquitecto, ante un cambio grande y riesgoso, marca casi todas las decisiones como cross-team "porque este cambio es delicado", y termina con un mapa donde posee 30 de 46. El resultado es el backlog de 340 y las 1870 decision-semanas de espera. Por qué pasa: un cambio importante se siente como si todo en él fuera importante, y delegar da miedo. Cómo detectarlo: si tu columna de "cross-team" tiene más de un puñado de decisiones por squad, no clasificaste, te asustaste. Cómo corregirlo: corre las tres pruebas (¿cruza fronteras?, ¿moldea y es cara de revertir?, ¿riesgo transversal?) con honestidad; la mayoría de las decisiones de cualquier cambio son locales, y tratarlas como propias es el error que ahoga el cambio, no el que lo protege.

Delegar sin guardrails y llamarlo "empoderar" (de abandono). Qué pasa: el arquitecto, entendiendo que debe delegar, suelta las 38 decisiones locales sin dar ninguna regla —"ustedes deciden, confío en ustedes"— y las squads toman decisiones incompatibles entre sí (cada una expone su API de forma distinta, cada una loguea a su manera), y el sistema se fragmenta. Por qué pasa: se confunde delegar (dar autonomía dentro de una frontera) con abandonar (soltar sin frontera). Cómo detectarlo: si delegaste una decisión pero no puedes nombrar el guardrail que la encauza, abandonaste. Cómo corregirlo: cada delegación local viene con un guardrail que fija el qué (el resultado que le importa al conjunto) y deja el cómo a la squad —"toda comunicación entre servicios es por contrato versionado", no "hagan buenas APIs"—; el jardinero no revisa cada decisión, pone los carriles dentro de los cuales la squad decide sola.

Empezar por la arquitectura sin enmarcar el rol (de saltarse el paso 1). Qué pasa: el arquitecto, emocionado con el cambio, salta directo a diseñar el surface de vendedores sin haber decidido qué decisiones son suyas, y sin darse cuenta se mete a decidir cosas locales (cómo indexa el catálogo, qué caché usa el checkout) que no le tocan, reintroduciendo el embudo por la puerta de atrás. Por qué pasa: diseñar es más atractivo que enmarcar el rol, que se siente burocrático. Cómo detectarlo: si estás tomando decisiones que solo afectan a una squad por dentro, te saliste de tu rol. Cómo corregirlo: haz el paso 1 antes que nada —el mapa de ownership—; te dice exactamente en qué 8 decisiones meterte y en cuáles 38 no, y te protege de reintroducir el embudo mientras diseñas.

Ejercicios

Ejercicio 1 — Clasifica cinco decisiones del cambio. Para cada una de estas decisiones que el cambio de Mercado desata, di si es cross-team (del arquitecto) o local (de la squad), aplicando las tres pruebas: (a) el esquema del contrato JSON que la Seller API expone a los terceros; (b) qué librería de HTTP usa internamente el servicio de catálogo para llamar a la base de datos; (c) la política de cuántas peticiones por minuto puede hacer un vendedor externo (rate limiting); (d) el nombre de las columnas de la tabla interna de payouts de payments; (e) el nivel de disponibilidad (SLO) que debe cumplir la Seller API.

Ver solución

(a) El contrato JSON de la Seller API → cross-team (del arquitecto). Cruza fronteras (todos los terceros y varios servicios internos dependen de él), moldea la estructura y es carísimo de cambiar una vez que hay integradores externos, y un error es de alto riesgo transversal. Pasa las tres pruebas: es un muro de carga.
(b) La librería de HTTP interna del catálogo → local (de la squad). No cruza fronteras (nadie fuera de catalog la ve), no moldea la estructura del sistema (es reversible dentro de catalog), y un error solo afecta a catalog. Falla las tres pruebas: es una bisagra. La decide catalog.
(c) El rate limiting de vendedores externos → cross-team. Cruza fronteras (protege a todo el sistema del abuso de un tercero), es de alto riesgo transversal (sin él, un vendedor podría tumbar la plataforma), y es una política que moldea cómo se expone el surface. Del arquitecto.
(d) El nombre de las columnas de la tabla de payouts → local. Es interno de payments, reversible sin que nadie afuera se entere, y un error se contiene en payments. Bisagra. La decide payments —siempre que el contrato de payouts (cross-team) esté bien definido; el nombre de la columna interna no lo es—.
(e) El SLO de la Seller API → cross-team. Es un atributo de calidad que otros equipos y los terceros dan por hecho, cruza fronteras (define qué pueden esperar los que dependen de la API) y es de alto riesgo transversal. Del arquitecto, y de hecho conecta con el paso 2 (derivar atributos): el SLO sale de los atributos priorizados.

El patrón: las decisiones sobre contratos, políticas transversales y atributos de calidad son del arquitecto; las decisiones sobre el interior de un servicio (librerías, esquemas internos, técnicas de implementación) son de la squad. Cuatro de estas cinco resultaron fáciles una vez aplicadas las tres pruebas; la (d) es la trampa —suena "de datos, importante"— pero el nombre interno de una columna no cruza fronteras ni moldea nada afuera.

Ejercicio 2 — El embudo que crece con el cambio. El paso 3 mostró que con 6 squads hay 15 canales de coordinación entre equipos. Supón que el cambio resulta tan grande que Mercado suma dos equipos nuevos (llega a 7 squads), y que el arquitecto sigue insistiendo en aprobar cada decisión cross-team él solo. Sin correr el código, calcula los canales entre squads con 7 equipos y argumenta por qué el problema del embudo no es lineal sino que empeora con el crecimiento.

Ver solución

Canales con 7 squads: 7 × 6 / 2 = 21 canales de coordinación entre equipos. Comparado con los 15 de 6 squads y los 10 de 5 squads, la progresión es 10 → 15 → 21: cada squad que se suma agrega más canales que el anterior (5, luego 6), porque el nuevo equipo tiene que coordinar con todos los que ya estaban.

Por qué el embudo no es lineal. Si el arquitecto es el canal único —el hub por el que pasa toda la coordinación—, su carga no crece con el número de squads sino con el número de canales, que crece como n(n-1)/2, es decir, cuadráticamente. Pasar de 5 a 7 squads (40% más equipos) casi duplica los canales (de 10 a 21). Un arquitecto que apenas daba abasto con 5 squads queda completamente enterrado con 7, no porque haya un 40% más de trabajo, sino porque hay más del doble de coordinación que atraviesa su escritorio. El embudo se degrada más rápido de lo que crece la organización.

La conclusión para el rol. Esto es exactamente por qué el encargo bien enmarcado no dice "el arquitecto aprueba todas las decisiones cross-team", sino "el arquitecto estructura los equipos para que la coordinación que de verdad necesita pasar por él sea mínima". La respuesta al crecimiento no es un arquitecto que corra más rápido (imposible contra una curva cuadrática), sino una organización diseñada —la maniobra inversa de Conway del paso 3— donde cada equipo posee su surface y coordina por contratos estables, de modo que el arquitecto no está en la mayoría de los canales. El paso 1 (enmarcar el rol) y el paso 3 (estructurar) son las dos caras de la misma defensa contra el embudo: uno decide qué no es tuyo, el otro hace que lo que no es tuyo fluya sin ti.

Ejercicio 3 — Reencuadra al arquitecto que quiere aprobar todo. El arquitecto de Mercado te dice: "este cambio expone a terceros y mueve dinero real; es demasiado riesgoso para delegar. Voy a revisar personalmente cada decisión técnica de las cinco squads durante el rollout, para que nada se rompa". Con lo que mediste en esta lección, respóndele: por qué su plan conseguiría lo contrario de lo que busca, y qué le propondrías en su lugar.

Ver solución

Por qué su plan consigue lo contrario. El arquitecto quiere que "nada se rompa", pero revisar las 46 decisiones semanales con una capacidad de 12 produce un backlog de 340 decisiones atascadas y 1870 decision-semanas de espera en 10 semanas. El efecto es doble y ambos van en contra de su meta: (1) el rollout se frena —las squads pasan el tiempo esperando su aprobación en vez de construir—, y un cambio que no avanza es un cambio en riesgo, no protegido; (2) la calidad baja, no sube, porque las squads —que conocen su dominio mejor que él— dejan de decidir lo local, y el arquitecto revisa 38 decisiones que no entiende tan bien como quien las vive, agregando retraso sin agregar criterio. Querer proteger el cambio revisándolo todo es la forma más segura de asfixiarlo. El riesgo real no disminuye; solo se disfraza de "todo pasó por mí".

Qué proponerle en su lugar. No "delega y confía a ciegas" (eso sería abandono), sino el rol del jardinero con guardrails, apoyado en el número:

Que posea las 8 decisiones que de verdad son suyas —justo las que hacen riesgoso el cambio: el contrato de la Seller API, la auth de terceros, el rate limiting, la seguridad de los datos, los payouts, los atributos de calidad—. Ahí su vista transversal es insustituible y su revisión sí agrega criterio. Ocho decisiones caben holgadas en su capacidad de 12.
Que delegue las 38 locales con guardrails, no con revisión: "toda comunicación entre servicios es por contrato versionado", "todo servicio cumple este SLO", "los logs van en este formato con trace-id", "ningún dato financiero se guarda sin cifrar". Los guardrails garantizan lo que le preocupa (que no se rompa el conjunto) sin que él tenga que aprobar cada PR. El riesgo se controla con carriles claros, no con un embudo.
Reencuadrarle su propia meta: "Tu preocupación por que nada se rompa es correcta —es exactamente lo que un buen arquitecto debe tener—. Pero revisar las 46 no la cumple: la frena. La cumples mejor poseyendo las 8 donde el riesgo real vive, y poniendo guardrails que protegen las otras 38 sin que tengas que tocarlas. Así te queda cabeza para lo que de verdad importa —derivar bien los atributos, estructurar los equipos, liderar la adopción— en vez de estar ahogado aprobando cómo indexa el catálogo."

Es el mismo movimiento del proyecto del módulo 1 (reencuadrar a Álex): el enemigo es la estructura del rol, no la persona; su intención (proteger la calidad) es buena y se cumple mejor de otra forma. El número —1870 decision-semanas de espera— es lo que despersonaliza el argumento y lo vuelve incontestable.

Resumen y siguiente paso

En esta lección hiciste el paso 1 del entregable: enmarcar el rol y el encargo. Con el director de obra que no pone los ladrillos —que posee los muros de carga y delega las bisagras— entendiste que el trabajo del arquitecto ante un cambio no es tomar todas las decisiones, sino separar las pocas que son suyas de las muchas que delega. Lo mediste ejecutando: el cambio "abrir a vendedores externos + crecer 10x" desata 46 decisiones semanales, de las cuales solo 8 cruzan equipos (del arquitecto) y 38 son locales (de las squads); el rol embudo produce 340 decisiones atascadas y 1870 decision-semanas de espera, mientras el rol jardinero las lleva a cero con la misma capacidad; y los canales de coordinación crecen n(n-1)/2, así que el arquitecto-canal-único no escala. Aprendiste las tres pruebas que clasifican una decisión como del arquitecto (¿cruza fronteras?, ¿moldea y es cara de revertir?, ¿riesgo transversal?), y por qué la mayoría de las decisiones de cualquier cambio son locales.

Antes de avanzar deberías poder: traducir un cambio de negocio al conjunto de decisiones que desata; separar las cross-team de las locales con las tres pruebas; explicar por qué el rol embudo frena y empeora el cambio que quiere proteger; y proponer guardrails que delegan lo local sin abandonarlo.

Lo que sigue es el paso 2, y es el que le da contenido a esas 8 decisiones que acabas de reservar para el arquitecto. Ya sabes cuántas decisiones son tuyas; la lección 3 te enseña de dónde salen las más importantes de ellas —los atributos de calidad—. Vas a tomar la meta del cambio y derivar, ejecutado, los atributos de calidad que implica, priorizados por su respaldo de negocio: vas a ver salir scalability arriba (porque "crecer 10x" y "abrir a vendedores" la empujan), y el conflicto scalability-vs-cost como el trade-off que gobierna todo el cambio. Ese ranking es el insumo del que cuelga la estructura que diseñarás en la lección 4: no puedes decidir qué equipos crear sin saber primero qué atributo tiene que producir el sistema.

Recursos

Martin Fowler — "Who Needs an Architect?" — el contraste entre el arquitecto que decide todo y el que habilita, que este mapa de ownership formaliza para un cambio concreto. La lectura que resume por qué el rol jardinero le gana al embudo.
Mark Richards & Neal Ford — Fundamentals of Software Architecture — su tratamiento del rol del arquitecto y de cómo trabaja con los equipos en vez de por encima de ellos es el respaldo directo del paso 1: qué decide el arquitecto y qué delega.
Matthew Skelton & Manuel Pais — Team Topologies — el marco de la carga cognitiva de un equipo y de por qué los equipos chicos con fronteras claras superan a los grandes; sostiene el paso 3 (los canales n(n-1)/2) que aquí solo asomaste y que la lección 4 desarrolla.
Gregor Hohpe — The Software Architect Elevator — sobre el arquitecto que multiplica en vez de ser el cuello de botella; el marco de por qué enmarcar bien el rol es lo que hace posible todo lo demás del capstone.

← Anterior1. Presentación del capstone: el oficio como un solo movimiento Siguiente →3. Deriva los atributos de calidad desde la meta