8. Proyecto: rediseña la organización de Mercado para una capacidad nueva

Descripción

Esta es tu graduación del módulo. Durante siete lecciones aprendiste a leer una organización y predecir la arquitectura que produce, a medir el espejo org↔código, a calcular el costo de coordinación, a diagnosticar el módulo que cruza fronteras, a aplicar la maniobra inversa de Conway, y a diseñar con el catálogo de team topologies. Todo eso lo viste aplicado a una situación: el monolito de Mercado y su checkout compartido. Ahora te toca a ti, de cero, sobre una situación distinta —una capacidad nueva que no analizamos en las lecciones—. La razón de cambiar el caso es la de siempre y es dura: si te dejara re-arreglar el checkout de las lecciones, no sabría si aprendiste el método o memorizaste la respuesta. Con un caso nuevo, la única forma de resolverlo es aplicar el método —y esa es, exactamente, la prueba de que el módulo funcionó—.

Tu entregable son tres artefactos para la capacidad nueva: (1) el mapa org↔arquitectura de la propuesta inicial —quién posee qué y qué depende de qué—; (2) la medición ejecutada de su fricción y de la carga por equipo, con Python; y (3) la maniobra inversa que la arregla —el rediseño organizacional usando team topologies, con la fricción medida antes y después—. Ninguna parte requiere construir el sistema: es puro trabajo de diseño organizacional —mapear, medir, rediseñar—, que es justo lo que separa a un arquitecto que entiende Conway de uno que dibuja cajitas. Constrúyelo tú primero; leer la solución de referencia sin haberlo intentado es como leer el marcador de un partido que no jugaste.

Conexión con el módulo: este proyecto cierra el arco. Las lecciones 2 a 5 te dieron el diagnóstico (la ley, el monolito, el costo, la fricción); las lecciones 6 y 7 te dieron la cura (la maniobra inversa, las team topologies). Aquí produces los tres artefactos con tus manos, de principio a fin, sobre un caso nuevo. Y con esta lección se cierra el módulo: al final está el resumen de las ocho lecciones y el puente hacia el módulo 3, donde vas a aprender a comunicar estos diseños —el C4 model y el ADR como herramientas para que la organización entienda y adopte la reestructuración que aquí sabes diseñar—.

El caso del proyecto: Mercado lanza reviews y recommendations

La situación nueva —tuya para resolver— es esta:

Mercado quiere lanzar dos capacidades a la vez: reviews (que los clientes dejen reseñas y calificaciones de los productos, con moderación de contenido) y recommendations (recomendar productos a cada cliente con un modelo de machine learning). El liderazgo, con prisa por lanzar, decide crear un solo squad nuevo, growth, y darle toda la capacidad: los cinco módulos nuevos. Tu trabajo como arquitecto es evaluar esa decisión con el método del módulo y proponer una organización mejor si hace falta.

Los módulos nuevos y de qué dependen (te lo da el equipo, para que no tengas que inventarlo):

• reviews_api — recibe y guarda las reseñas. Depende de moderation (para filtrar contenido), de product_catalog (para asociar la reseña al producto, es de catalog), de auth (para saber quién reseña, es de platform) y de notifications (para avisar, es de platform).
• moderation — filtra reseñas ofensivas con un modelo. Depende de ml_training (usa el modelo entrenado).
• rating_aggregate — calcula el rating promedio de cada producto. Depende de reviews_api.
• recommendations — recomienda productos. Depende de rating_aggregate, de ml_training y de product_catalog (de catalog).
• ml_training — entrena los modelos de machine learning que usan moderation y recommendations.

Fíjate en la mezcla: reviews (reseñas, moderación, ratings) es una capacidad de cara al usuario, cercana al producto; recommendations + ml_training es una capacidad de machine learning, que requiere expertise profundo y distinto. El liderazgo metió las dos en un solo squad. Tu método del módulo debería tener algo que decir sobre eso. No re-enseñes cómo funciona un modelo de ML ni una API de reseñas —eso es de otras guías—; tu trabajo es diseñar la organización que produzca la mejor arquitectura para esta capacidad.

Lo que tienes que entregar

Sigue los pasos en orden; cada uno se apoya en el anterior.

Parte 1 — El mapa org↔arquitectura de la propuesta inicial

Dibuja (en texto o ASCII) el mapa de la propuesta del liderazgo: el squad growth poseyendo los cinco módulos nuevos, catalog poseyendo product_catalog, platform poseyendo auth y notifications, y las dependencias entre todos. Identifica a ojo qué te preocupa de esa organización —antes de medir—.

Parte 2 — La medición ejecutada

Escribe y corre el Python que mide, para la propuesta inicial, dos cosas: la fricción total (los pares de equipos que deben coordinarse por módulo, C(k,2), como en las lecciones 5 y 6) y la carga por equipo (cuántos módulos posee el equipo más cargado). Entrega los números reales, corridos, no citados de memoria. Reusa las fórmulas del módulo.

Parte 3 — La maniobra inversa

Rediseña la organización usando el catálogo de team topologies (lección 7). Decide qué equipos debería haber, de qué tipo es cada uno, y quién posee qué. Vuelve a medir la fricción y la carga con la nueva organización, y compara. Cierra explicando qué problema resolviste y qué coordinación es irreducible.

La rúbrica

Así se evalúa el proyecto. No es por extensión ni por elegancia: es por si el diseño organizacional está bien hecho y bien defendido con evidencia.

Criterio	No cumple	Cumple	Sobresale
Mapa org↔arquitectura	Solo dibuja módulos, sin ownership	Ownership + dependencias claros	Además señala a ojo los riesgos antes de medir
Medición ejecutada	Números citados de memoria o inventados	Fricción y carga corridas en Python	Además declara supuestos (qué es servicio, qué co-cambia)
Maniobra inversa	"Hagamos microservicios" sin equipos	Rediseño con tipos de team topology y ownership	Además mide el antes/después y nombra la coordinación irreducible
Criterio	Reorganiza sin justificar	Justifica con el desalineamiento medido	Además dice cuándo NO valdría la pena reorganizar

El criterio que más pesa, y el que separa a un arquitecto de un dibujante de cajitas, es la medición ejecutada: si entregas todo lo demás pero los números salieron de tu cabeza y no de correr el código, no mediste —afirmaste con cifras inventadas, que es peor, porque finge rigor—.

La solución de referencia

Intenta el proyecto entero antes de seguir. Lo que viene es una solución correcta, no la única.

Parte 1 — El mapa de la propuesta inicial

La propuesta del liderazgo, en un mapa:

                    growth (un solo squad, dueno de TODO lo nuevo)
     +----------------------------------------------------------------+
     |  reviews_api   moderation   rating_aggregate                   |
     |  recommendations   ml_training                                 |
     +----------------------------------------------------------------+
              |            |                 |            |
              v            v                 v            v
        product_catalog  auth/notifications (platform)  ...

    dependencias:
      reviews_api      -> moderation, product_catalog, auth, notifications
      moderation       -> ml_training
      rating_aggregate -> reviews_api
      recommendations  -> rating_aggregate, ml_training, product_catalog

Lo que preocupa a ojo, antes de medir: el squad growth posee cinco módulos que abarcan dos capacidades muy distintas: reviews (de cara al usuario: reviews_api, moderation, rating_aggregate) y machine learning (recommendations, ml_training). Esto huele a dos problemas del módulo: (1) un equipo con demasiada carga cognitiva —cinco módulos de dos dominios distintos es mucho para un solo squad (lección 4)—; y (2) la ausencia de una frontera entre dos subsistemas que deberían estar separados —el ML es un complicated-subsystem (lección 7) que no debería estar mezclado con la capacidad de reviews de cara al usuario—. La prisa del liderazgo por "un solo equipo para lanzar rápido" está a punto de crear el mismo problema que Mercado ya tiene con el monolito: un pedazo grande sin fronteras internas, que después dolerá partir.

Parte 2 — La medición ejecutada

# Proyecto: Conway sobre una capacidad NUEVA de Mercado (reviews + recommendations).
# Medimos la friccion antes, aplicamos la maniobra inversa, y volvemos a medir.
from itertools import combinations

# Modulos de la nueva capacidad + los existentes que consume.
modules = ["reviews_api", "moderation", "rating_aggregate",
           "recommendations", "ml_training",
           "product_catalog", "auth", "notifications"]

deps = {
    "reviews_api":     ["moderation", "product_catalog", "auth", "notifications"],
    "moderation":      ["ml_training"],
    "rating_aggregate":["reviews_api"],
    "recommendations": ["rating_aggregate", "ml_training", "product_catalog"],
}

def total_friction(owners, service):
    total = 0
    for m in modules:
        room = set(owners[m])
        for d in deps.get(m, []):
            if d not in service:
                room |= owners[d]
        total += len(list(combinations(room, 2)))
    return total

def max_modules_per_team(owners):
    counts = {}
    for m in modules:
        for t in owners[m]:
            counts[t] = counts.get(t, 0) + 1
    return max(counts.values()), counts

# ANTES: un solo squad 'growth' recibe TODA la capacidad nueva (5 modulos),
# mezclando dos subsistemas distintos (reviews de cara al usuario + ML).
before_owners = {
    "reviews_api": {"growth"}, "moderation": {"growth"},
    "rating_aggregate": {"growth"}, "recommendations": {"growth"},
    "ml_training": {"growth"},
    "product_catalog": {"catalog"}, "auth": {"platform"},
    "notifications": {"platform"},
}
before_service = set()

# DESPUES: maniobra inversa. Un equipo stream-aligned 'reviews' (reviews_api,
# moderation, rating_aggregate) y un complicated-subsystem 'ml-reco'
# (recommendations, ml_training). catalog/auth/notifications como servicio.
after_owners = {
    "reviews_api": {"reviews"}, "moderation": {"reviews"},
    "rating_aggregate": {"reviews"}, "recommendations": {"ml-reco"},
    "ml_training": {"ml-reco"},
    "product_catalog": {"catalog"}, "auth": {"platform"},
    "notifications": {"platform"},
}
after_service = {"product_catalog", "auth", "notifications"}

fb = total_friction(before_owners, before_service)
fa = total_friction(after_owners, after_service)
mb, cb = max_modules_per_team(before_owners)
ma, ca = max_modules_per_team(after_owners)

print(f"{'escenario':<34}{'friccion':>10}{'max modulos/equipo':>20}")
print(f"{'ANTES  (1 squad growth)':<34}{fb:>10}{mb:>20}")
print(f"{'DESPUES (maniobra inversa)':<34}{fa:>10}{ma:>20}")
print()
print(f"friccion (coord_pairs) : {fb} -> {fa}")
print(f"carga del equipo mas cargado: {mb} modulos -> {ma} modulos")
print(f"ownership antes : {cb}")
print(f"ownership despues: {ca}")

Qué esperar. Al correrlo:

escenario                           friccion  max modulos/equipo
ANTES  (1 squad growth)                    4                   5
DESPUES (maniobra inversa)                 2                   3

friccion (coord_pairs) : 4 -> 2
carga del equipo mas cargado: 5 modulos -> 3 modulos
ownership antes : {'growth': 5, 'catalog': 1, 'platform': 2}
ownership despues: {'reviews': 3, 'ml-reco': 2, 'catalog': 1, 'platform': 2}

Lee los números como aprendiste, y fíjate en algo sutil que este caso enseña y el del checkout no: la fricción de coordinación no era el peor problema aquí; la carga cognitiva sí.

En la propuesta inicial, la fricción es 4 —relativamente baja—, porque como un solo squad (growth) posee todo lo nuevo, casi todas las dependencias son internas a growth (no cruzan equipos). Un ingeniero apurado podría mirar ese 4 y decir "no hay problema de coordinación, dejémoslo en un squad". Sería el error. El número que grita es el otro: growth posee 5 módulos, mezclando dos capacidades muy distintas (reviews de cara al usuario y ML). Ese squad va a estar sobrecargado —demasiada carga cognitiva, dos dominios que requieren mentalidades y expertise distintos en la misma cabeza— y, peor, como no hay frontera interna entre reviews y ML, los dos subsistemas se van a entrelazar en el código (Conway: un equipo sin fronteras internas produce un módulo sin fronteras internas). Es el monolito de la lección 3 naciendo otra vez, en chiquito.

Tras la maniobra inversa, los dos números mejoran: la fricción baja de 4 a 2 y la carga del equipo más cargado baja de 5 módulos a 3. Pero el cambio importante es cualitativo, y se ve en el ownership: pasamos de {growth: 5} —un squad ahogado— a {reviews: 3, ml-reco: 2} —dos equipos cohesivos, cada uno con un dominio—. Ahora hay una frontera de verdad entre la capacidad de reviews y la de ML, y por Conway, esa frontera organizacional va a producir una frontera limpia en el código: reviews y recommendations van a ser dos subsistemas separados, no una bola mezclada.

El detalle honesto: la fricción no bajó a 0, bajó a 2. Ese 2 es la coordinación irreducible entre reviews y ml-reco: moderation (de reviews) depende de ml_training (de ml-reco), y recommendations (de ml-reco) depende de rating_aggregate (de reviews). O sea, los dos equipos de verdad se necesitan mutuamente —reviews usa el modelo de moderación entrenado por ml-reco, y ml-reco usa los ratings calculados por reviews—. Esa es coordinación real del negocio, no artificial: no se organiza para eliminar, se organiza para que cueste lo mínimo (un contrato estable entre los dos equipos). La maniobra quitó la fricción y la carga artificiales (un squad haciendo de todo) y dejó la coordinación genuina (dos dominios que se alimentan). Y de paso, product_catalog, auth y notifications se consumen como servicios de plataforma (por eso salieron del co-cambio), no como cosas que reviews tenga que coordinar en cada cambio.

Parte 3 — La maniobra inversa, con team topologies

El rediseño, nombrado con el catálogo de la lección 7:

• Equipo reviews — stream-aligned. Posee el flujo de reseñas de punta a punta: reviews_api, moderation, rating_aggregate. Es una capacidad de cara al usuario con un journey claro (dejar una reseña, verla moderada, ver el rating). Consume la plataforma (auth, notifications) y el catálogo (product_catalog) como servicios (x-as-a-service), y consume el modelo de moderación de ml-reco por un contrato estable.

• Equipo ml-reco — complicated-subsystem. Posee recommendations y ml_training: el machine learning, que requiere expertise profundo y escaso (científicos de datos, ingenieros de ML) que no tiene sentido mezclar con el equipo de reviews. Encapsula esa complejidad para que reviews (y otros) consuman recomendaciones y modelos sin entender sus tripas. Consume rating_aggregate de reviews como insumo para entrenar/recomendar.

• catalog y platform — sin cambios, consumidos as-a-service. product_catalog (catalog), auth y notifications (platform) siguen donde estaban; la clave es que las capacidades nuevas los consumen como servicios estables, no metiéndoles mano. Por eso no aparecen en la sala de coordinación de los módulos nuevos.

• Interacción entre reviews y ml-reco: x-as-a-service en ambos sentidos (con quizás un toque inicial de collaboration temporal al arrancar, mientras definen los contratos). reviews consume el modelo de moderación de ml-reco; ml-reco consume los ratings de reviews. Cada uno expone lo suyo por un contrato estable, así la coordinación irreducible (peso mínimo) fluye por el canal más barato.

Qué problema resolví: el error de la propuesta inicial no era la fricción de coordinación (era baja, 4) sino la carga cognitiva y la falta de frontera —un solo squad con cinco módulos de dos dominios distintos, condenado a producir un subsistema mezclado y a ahogarse—. La maniobra inversa separó los dos dominios en dos equipos alineados a sus capacidades (uno stream-aligned de reviews, uno complicated-subsystem de ML), bajó la carga del equipo más cargado de 5 a 3 módulos, y creó la frontera organizacional que —por Conway— producirá una frontera limpia en el código.

Qué coordinación es irreducible: la fricción de 2 que queda es real: reviews y ml-reco se alimentan mutuamente (moderación usa el modelo de ML; recomendaciones usan los ratings). Eso no se elimina reorganizando; se hace fluir barato por contratos estables. Intentar llevarla a 0 —por ejemplo, duplicando el entrenamiento de modelos dentro de reviews para no depender de ml-reco— sería peor: crearía duplicación y perdería el expertise concentrado. La organización correcta reconoce la dependencia genuina y la deja pasar por el canal más barato, no la abole.

Cuándo NO valdría la pena: si Mercado fuera un piloto de reviews con un solo módulo y sin ML todavía (digamos, solo reviews_api y rating_aggregate, sin moderación ni recomendaciones), meterlo todo en un squad growth sería lo correcto —dos módulos de un dominio, carga baja, cero necesidad de fronteras—. La maniobra inversa se justifica aquí porque son cinco módulos de dos dominios distintos con expertise distinto; con dos módulos de un dominio, partir sería sobre-ingeniería. La regla del módulo: reorganizar se justifica por un desalineamiento (o una sobrecarga) medido, no por reflejo.

Ejercicios

Estos ejercicios transfieren el método a otras decisiones de Mercado, para que confirmes que aprendiste a diseñar organizaciones y no a repetir una.

Ejercicio 1 — El equipo enabling que falta. El equipo reviews, recién formado, no sabe hacer testing de moderación de contenido (probar que el filtro no deja pasar contenido ofensivo ni bloquea contenido legítimo). Mercado tiene un equipo experto en testing de sistemas de ML. ¿Qué tipo de team topology es ese equipo experto, qué modo de interacción debería usar con reviews, y por qué debe tener fecha de caducidad?

Ver solución

El equipo experto en testing de ML es un enabling team: su propósito es ayudar a otros equipos a adquirir una capacidad nueva (testing de moderación), no poseer un módulo propio. Su producto es que el equipo reviews quede capaz de hacer ese testing solo.

El modo de interacción correcto es facilitating: el equipo enabling acompaña a reviews —les enseña las técnicas, revisa con ellos los primeros tests, comparte herramientas—, pero no hace el trabajo por ellos. La meta es transferir la capacidad.

Por qué debe tener fecha de caducidad: porque el modo facilitating es temporal por diseño. Si el equipo enabling se quedara permanentemente haciendo el testing de moderación de reviews, dejaría de habilitar y se volvería una dependencia —reviews nunca aprendería, y el enabling sería un cuello de botella para todos los equipos que necesiten lo mismo—. El éxito del enabling se mide por si reviews quedó autónomo, no por cuánto trabajo hizo. Poner una fecha de salida (por ejemplo, "seis semanas") fuerza a que la interacción sea transferencia de capacidad y no sustitución permanente. Es el anti-patrón "el enabling que se vuelve permanente" de la lección 7.

Ejercicio 2 — La dependencia que contamina. Supón que el liderazgo insiste en dejar recommendations y ml_training dentro del squad reviews (no crear el equipo ml-reco), "para no tener otro equipo". Con el método, argumenta con al menos dos números por qué es mala idea, y qué síntoma concreto verías en seis meses.

Ver solución

Número 1 — la carga cognitiva: dejar todo en reviews mantiene un equipo con 5 módulos de dos dominios distintos (reviews de cara al usuario + ML), en vez de dos equipos de 3 y 2 módulos cada uno. La carga del equipo más cargado se queda en 5 en vez de bajar a 3. Un equipo que tiene que sostener en la cabeza tanto la lógica de reseñas como el entrenamiento de modelos de ML está sobrecargado —son dos expertises distintas—, y la sobrecarga se traduce en lentitud y errores.

Número 2 — la ausencia de frontera (Conway): con un solo equipo dueño de reviews y ML, no hay ninguna frontera organizacional entre los dos dominios, así que —por la Ley de Conway— el código no tendrá frontera entre ellos. La fricción medida sería baja (todo interno al equipo), pero eso es engañoso: la baja fricción de coordinación esconde un alto acoplamiento interno que nadie ve hasta que duele.

Síntoma en seis meses: el código de reviews y el de recomendaciones/ML estarán entrelazados sin frontera —el módulo de moderación llamando directo a las tripas del entrenamiento, la lógica de recomendaciones mezclada con la de ratings, datos compartidos sin contrato—. Cuando eventualmente quieran separar el ML (para escalarlo aparte, para contratar un equipo dedicado, para reusar los modelos en otra parte), se encontrarán con que no pueden sin un refactor doloroso, porque nunca hubo una frontera. Es exactamente el monolito de la lección 3 naciendo de nuevo: un pedazo grande sin costuras internas, perfecto para el squad único que lo escribió y un tormento para partir después. La lección: crear la frontera ahora (cuando es barato, dos equipos desde el inicio) es mucho más barato que crearla después (cuando el código ya se mezcló).

Ejercicio 3 — Otra capacidad, mismo método. Mercado quiere agregar international (vender en otros países: manejo de monedas, impuestos por país, traducciones). Se propone —otra vez— un solo squad intl dueño de todo. Sin correr código, aplica el método: ¿qué preguntarías para decidir si un solo squad basta o si hay que partir? Da el criterio, no una respuesta fija.

Ver solución

El método no da una respuesta fija —da un criterio que se evalúa con las preguntas correctas—. Lo que preguntaría para decidir:

1. ¿Cuántos módulos y de cuántos dominios distintos? Si international es un dominio cohesivo (monedas, impuestos, traducciones son todas "adaptación por país", que se piensan juntas), un solo squad stream-aligned podría bastar. Si esconde dos dominios de expertise muy distinto —digamos, un motor de cálculo de impuestos que requiere expertise fiscal profundo, separado del resto—, ese motor podría ser un complicated-subsystem aparte.

2. ¿Cuál es la carga cognitiva? ¿Cuántos módulos poseería el squad intl? Si son dos o tres de un dominio, la carga es manejable (no partir). Si son seis de dominios mezclados, se sobrecarga (partir).

3. ¿Qué dependencias cruzan hacia otros equipos, y son co-cambio o servicio? ¿international necesita meterle mano al checkout, a payments, al catálogo (co-cambio, caro), o los consume como servicios estables (barato)? Si obliga a co-cambiar módulos de otros equipos, aparece fricción cross-team que hay que diseñar (quizás contratos estables, quizás mover fronteras).

4. ¿Hay una frontera natural que, si no la creo ahora, será cara de crear después? El criterio de Conway: si dentro de international hay dos subsistemas que van a querer separarse eventualmente, es más barato darles equipos separados desde el inicio que dejarlos mezclarse y partirlos después.

El criterio, en una frase: un solo squad basta si la capacidad es un dominio cohesivo con carga cognitiva manejable y pocas dependencias cross-team caras; hay que partir si esconde dominios de expertise distinto, sobrecarga a un equipo, o carece de una frontera que será cara de crear más tarde. La respuesta depende de los números y del contexto —lo que aprendiste es a preguntar y medir, no a aplicar "siempre parte" ni "nunca partas"—. Eso es tratar el organigrama como una decisión de arquitectura, que es la tesis del módulo.

Resumen del módulo y hacia dónde sigues

Con este proyecto cierras el módulo 2, el corazón social de la guía. Empezaste con la tesis —shipeas tu organigrama: la estructura del sistema copia la estructura de comunicación de la organización— y el puente de las dos cuadrillas que muestra que la juntura frágil cae donde se divide la organización (lección 1). Convertiste la ley de frase en herramienta, midiendo el espejo org↔código de Mercado —61.5% de dependencias cross-equipo, el grafo de comunicación que la arquitectura exige— (lección 2). Descubriste el origen del monolito doloroso: es tu primer organigrama, fosilizado —perfecto para el equipo único de 2019, roto para los cinco squads de 2024, sin que el código cambiara una línea— (lección 3). Entendiste el motor económico: la coordinación crece cuadráticamente (n(n-1)/2), así que un equipo grande se ahoga y partir en chicos baja la coordinación 5x con la misma gente (lección 4). Diagnosticaste la fricción concentrada: el checkout, co-poseído por dos equipos y tocando cuatro, aporta la mitad de la fricción del sistema (lección 5). Aplicaste la cura maestra: la maniobra inversa de Conway —cambiar la organización para obtener la arquitectura—, que bajó la fricción de 12 a 5 sin tocar el código (lección 6). Y adquiriste el vocabulario para diseñar organizaciones a propósito: los cuatro tipos de equipo y los tres modos de interacción de las team topologies, con el modo barato (x-as-a-service) bajando la carga de 15 a 6 (lección 7). Aquí, en el proyecto, lo hiciste todo tú sobre un caso nuevo: mapeaste, mediste la fricción y la carga, y rediseñaste con la maniobra inversa y las team topologies.

La capacidad que te llevas: ante cualquier sistema, puedes leer su organización y predecir su arquitectura, medir el desalineamiento entre las dos, diagnosticar dónde se concentra la fricción, y rediseñar la organización —con la maniobra inversa y el catálogo de team topologies— para obtener la arquitectura que el negocio necesita. Dejaste de tratar el organigrama como un dato fijo contra el que se pelea, y empezaste a tratarlo como la primera decisión de arquitectura.

Hacia dónde sigues, dentro de esta guía:

• Módulo 3 — Comunicar la arquitectura. Ya sabes diseñar la reestructuración org↔arquitectura; el módulo 3 te enseña a comunicarla para que la entiendan y la adopten: el C4 model (Context/Container/Component/Code — el diagrama correcto para cada audiencia) y el ADR como la herramienta que hace viajar en el tiempo el por qué de una decisión. El mapa org↔arquitectura y la maniobra inversa que diseñaste aquí no sirven de nada si no puedes explicárselos al VP que aprueba la reorganización y al equipo que la vive —y eso es un oficio en sí mismo—.

Y hacia el resto del ecosistema: cada vez que este módulo habló de "servicios independientes", "monolito", "microservicios" o "contratos estables" sin re-enseñarlos, se apoyaba en las guías que sí los enseñan —architectural-styles-and-boundaries, api-design-and-integration, architecture-decisions-and-tradeoffs—. Ahora tienes lo que ninguna de ellas cubre: la dinámica org↔arquitectura, la fuerza social que decide si esos patrones técnicos se pueden sostener. La Ley de Conway es el recordatorio de que la arquitectura no la hacen los diagramas: la hacen las personas, organizadas de cierta forma, comunicándose de cierta forma —y el mayor apalancamiento del arquitecto está justo ahí—.

Recursos

• Skelton & Pais — Team Topologies — el cierre natural del módulo: el libro entero es el manual para diseñar organizaciones que produzcan buenas arquitecturas, exactamente lo que hiciste en este proyecto. Los cuatro tipos de equipo, los tres modos y la maniobra inversa, todo en un solo lugar.
• Melvin Conway — "How Do Committees Invent?" (1968) — vuelve al origen para cerrar el círculo: Conway ya anticipaba en 1968 casi todo lo que mediste, incluida la idea de que reorganizar es la palanca para cambiar el sistema. Corto y fundacional.
• Martin Fowler — "Conway's Law" — el mejor resumen de todo el módulo en dos páginas, con la maniobra inversa y la frase que lo condensa: cuando la arquitectura del sistema y la de la organización chocan, gana la de la organización.