Módulo 2: La Ley de Conway

7. Team topologies

Descripción

Al terminar esta lección vas a tener el vocabulario para diseñar una organización a propósito, en vez de improvisarla. La maniobra inversa de la lección 6 te dijo qué hacer —rediseñar la organización para obtener la arquitectura que quieres—, pero lo hiciste a ojo: "un equipo dueño del flujo de checkout", "la plataforma como servicio". Skelton & Pais, en su libro Team Topologies, tomaron esas intuiciones y las convirtieron en un catálogo de piezas probadas. Hay cuatro tipos de equipo —y solo cuatro que valga la pena— y tres modos de interacción entre ellos. El equipo "checkout" que diseñaste tiene un nombre: stream-aligned (alineado a un flujo de valor). "La plataforma como servicio" es un patrón: un equipo platform que ofrece capacidades en modo x-as-a-service. Vas a aprender los cuatro tipos, los tres modos, y —lo que hace útil el vocabulario— el costo de comunicación de cada modo, medido: el mismo mapa de quién-necesita-a-quién puede costar una carga de coordinación de 15 o de 6, según el modo que elijas para cada relación.

Esto importa porque el vocabulario es lo que separa diseñar de improvisar. Sin él, cada arquitecto reinventa la organización desde cero, comete los mismos errores conocidos, y no puede comunicar su diseño ("necesitamos un equipo... que haga como de puente... que ayude a los otros pero no permanente"). Con él, dices "un equipo enabling temporal" y todos entienden. Pero el valor más profundo no es nombrar, es elegir el modo de interacción correcto —y ahí está el número de esta lección—. Dos equipos que se necesitan pueden relacionarse de tres formas con costos muy distintos: collaboration (co-diseñan juntos, alto ancho de banda, caro), x-as-a-service (uno consume lo que el otro provee, bajo ancho de banda, barato) o facilitating (uno ayuda al otro a mejorar, temporal). El error caro es tratar todo como collaboration —tener a todos los equipos co-diseñando con todos, ahogados en reuniones—. El arte, medido, es reservar el modo caro (collaboration) para donde de verdad hace falta y volver todo lo demás x-as-a-service. La misma organización, según los modos que elijas, fluye o se atasca.

Conexión con el módulo: esta lección es el cierre del arco de curas y la culminación del vocabulario. Todo el módulo construyó hacia aquí: la Ley de Conway (lección 2) dice que el sistema copia la organización; el costo de coordinación (lección 4) dice por qué los modos de comunicación importan tanto; la fricción por módulo (lección 5) diagnostica; la maniobra inversa (lección 6) reorganiza. Esta lección da el catálogo de piezas con el que se hace esa reorganización con precisión: los cuatro tipos de equipo son los bloques, los tres modos son cómo se conectan, y el costo de cada modo es el criterio para elegir. El equipo stream-aligned + platform que diseñaste en la lección 6 se vuelve, aquí, un patrón nombrado y medido. Es el puente hacia el proyecto (lección 8), donde vas a rediseñar la organización de una capacidad nueva de Mercado usando este catálogo, y hacia el módulo 3, donde vas a comunicar estos diseños a stakeholders.

Los cuatro roles de una obra de construcción

Piénsalo así. En una obra de construcción grande y bien organizada, no todos hacen de todo. Hay cuatro tipos de cuadrilla, cada una con un rol claro, y esa claridad es lo que hace que la obra fluya en vez de ser un caos.

Están las cuadrillas de construcción —las que de verdad levantan el edificio, piso por piso—. Cada una es dueña de una torre completa, de los cimientos al techo: hacen su torre de punta a punta y responden por ella. Son el corazón de la obra; todo lo demás existe para que ellas fluyan. Están los proveedores de servicios compartidos —la planta de concreto, el almacén de materiales, la grúa central—: no construyen ninguna torre, pero proveen a todas las cuadrillas lo que necesitan, de forma que cada cuadrilla pida concreto y lo reciba sin tener que montar su propia planta. Un servicio, consumido por todos, que les quita trabajo pesado de encima. Están los especialistas consultores —el ingeniero estructural experto que llega cuando una cuadrilla necesita resolver un cálculo complicado, les enseña cómo, y se va—: no se quedan permanentemente, ayudan a que la cuadrilla aprenda a hacerlo sola y luego pasan a otra. Y están las cuadrillas de subsistemas complicados —los que instalan el elevador o el sistema eléctrico de alta tensión, cosas que requieren una especialización tan profunda que no tiene sentido que cada cuadrilla de construcción la aprenda—: encapsulan una complejidad específica para que las demás no tengan que cargarla.

Cuatro roles: los que construyen el flujo (las torres), los que proveen un servicio (concreto, materiales), los que habilitan temporalmente (el consultor), y los que encapsulan lo complicado (el elevador). Una obra donde estos roles están claros fluye: cada cuadrilla sabe qué es suyo, a quién pedirle un servicio, y a quién llamar para lo complicado. Una obra donde todos hacen de todo y todos se consultan con todos es un caos de gente tropezándose. Las team topologies son exactamente estos cuatro roles, aplicados a equipos de software: stream-aligned (las cuadrillas de construcción), platform (los proveedores de servicios), enabling (los consultores) y complicated-subsystem (los del elevador). Esta lección los define y mide qué tan caro es cada forma de que se relacionen.

Los cuatro tipos de equipo y los tres modos de interacción

Antes del ejemplo ejecutado, el catálogo. Skelton & Pais argumentan que casi cualquier organización de software efectiva se arma con solo cuatro tipos de equipo:

Stream-aligned (alineado a un flujo de valor). Es el equipo por defecto, el que debería ser la mayoría. Posee un flujo de valor de punta a punta —un producto, una feature, un journey del usuario— y puede entregarlo sin depender de otros para lo esencial. El equipo checkout de la lección 6 es stream-aligned: dueño del flujo de compra completo. Los squads de Mercado (catalog, orders, etc.) deberían ser stream-aligned, y su dolor viene justo de que no lo son del todo (comparten el checkout).
Platform (plataforma). Provee capacidades como un servicio interno para que los equipos stream-aligned no tengan que construirlas cada uno. Autenticación, notificaciones, infraestructura, despliegue: cosas que todos necesitan y nadie debería reinventar. La clave: la plataforma ofrece esto como un servicio con un contrato estable, no metiéndose en el trabajo de cada equipo. El platform de Mercado (auth, notifications) es —o debería ser— un platform team.
Enabling (habilitador). Ayuda a los equipos stream-aligned a superar un obstáculo o adquirir una capacidad nueva —una práctica de testing, una tecnología, una técnica de arquitectura—, y lo hace temporalmente: llega, enseña, y se va cuando el equipo ya sabe hacerlo solo. Es el consultor de la obra. No posee ningún módulo; su producto es que otros equipos mejoren. Su interacción es, por diseño, pasajera.
Complicated-subsystem (subsistema complicado). Encapsula una parte del sistema que requiere expertise tan profundo que no tiene sentido que cada equipo stream-aligned la cargue: un motor de riesgo/fraude, un algoritmo de recomendación, un códec de video, un solver matemático. Existe para quitarle esa carga cognitiva a los demás. En Mercado, un motor de detección de fraude en payments sería un complicated-subsystem.

Y esos equipos se relacionan de solo tres modos de interacción, cada uno con un costo de comunicación distinto:

Collaboration (colaboración). Dos equipos trabajan juntos, codo a codo, sobre un problema compartido, durante un tiempo. Es alto ancho de banda —mucha comunicación, mucha sincronización— y por eso caro. Se usa para explorar territorio nuevo o resolver algo que ninguno de los dos puede resolver solo. Es valioso pero costoso; debe ser la excepción, no la regla.
X-as-a-service (algo-como-servicio). Un equipo consume lo que otro provee, a través de una interfaz estable, con mínima comunicación. El consumidor no necesita saber cómo funciona por dentro; solo usa el contrato. Es bajo ancho de banda —barato— y es como deberían relacionarse la mayoría de los equipos con la plataforma y con los subsistemas complicados.
Facilitating (facilitación). Un equipo (típicamente enabling) ayuda a otro a mejorar, temporalmente. Ancho de banda medio y —clave— pasajero: existe para terminar. Cuando el equipo ayudado ya aprendió, la interacción se disuelve.

El principio de diseño que amarra todo: minimiza los modos de alto ancho de banda. Collaboration es valioso pero caro; si toda tu organización colabora con todo, se ahoga en coordinación (el n(n-1)/2 de la lección 4, al máximo). El objetivo es reservar collaboration para las pocas fronteras donde de verdad hace falta co-diseñar, y volver todo lo demás x-as-a-service —contratos estables que no requieren coordinar cada cambio—. Vamos a medir exactamente cuánto ahorra eso.

Ejemplo trabajado: el costo de comunicación de cada modo

Vamos a poner un costo a cada modo y a medir dos formas de organizar las mismas relaciones. Le damos peso 3 a collaboration (caro, alto ancho de banda), 1 a x-as-a-service (barato) y 2 a facilitating (medio, temporal). Tenemos un mapa fijo de quién-necesita-a-quién en Mercado, y lo evaluamos bajo dos arreglos: uno donde todo es collaboration (el default cuando nadie diseñó las interacciones) y otro donde la plataforma y el subsistema complicado se consumen como servicio, y el equipo enabling solo facilita.

# Team topologies: cada modo de interaccion tiene un costo de comunicacion
# distinto. Lo medimos sobre los equipos de Mercado.

# Los 4 tipos de equipo (Skelton & Pais).
teams = {
    "checkout":      "stream-aligned",
    "catalog":       "stream-aligned",
    "fulfillment":   "stream-aligned",
    "platform":      "platform",
    "payments-risk": "complicated-subsystem",
    "enabling":      "enabling",
}

# Peso de comunicacion por modo de interaccion:
# collaboration = alto ancho de banda, caro, temporal (dos equipos co-disenan).
# x-as-a-service = bajo ancho de banda, estable (uno consume, el otro provee).
# facilitating  = medio, temporal (un equipo enabling ayuda a otro a mejorar).
WEIGHT = {"collaboration": 3, "x-as-a-service": 1, "facilitating": 2}

# Quien necesita a quien.
interactions = [
    ("checkout",    "platform"),
    ("catalog",     "platform"),
    ("fulfillment", "platform"),
    ("checkout",    "payments-risk"),
    ("enabling",    "checkout"),
]

def load(mode_of):
    total = 0
    print(f"{'interaccion':<30}{'modo':<18}{'peso':>5}")
    for a, b in interactions:
        mode = mode_of(a, b)
        w = WEIGHT[mode]
        total += w
        print(f"{a+' -> '+b:<30}{mode:<18}{w:>5}")
    print(f"{'CARGA TOTAL':<48}{total:>5}")
    return total

# Arreglo 1: todo por colaboracion (el default cuando nadie diseno los limites).
print("=== Arreglo A: todo es collaboration ===")
load_a = load(lambda a, b: "collaboration")

print()
# Arreglo 2: la plataforma y el subsistema complicado se consumen como servicio;
# el equipo enabling solo facilita (temporalmente).
print("=== Arreglo B: platform/complicated as-a-service, enabling facilita ===")
def mode_b(a, b):
    if b == "platform":
        return "x-as-a-service"
    if b == "payments-risk":
        return "x-as-a-service"
    if a == "enabling":
        return "facilitating"
    return "collaboration"
load_b = load(mode_b)

print()
print(f"Carga de comunicacion: {load_a} -> {load_b}  (baja {(1-load_b/load_a)*100:.0f}%)")
print("El mismo mapa de quien-necesita-a-quien; distinto MODO de interactuar.")

Qué esperar. Al correrlo:

=== Arreglo A: todo es collaboration ===
interaccion                   modo               peso
checkout -> platform          collaboration         3
catalog -> platform           collaboration         3
fulfillment -> platform       collaboration         3
checkout -> payments-risk     collaboration         3
enabling -> checkout          collaboration         3
CARGA TOTAL                                        15

=== Arreglo B: platform/complicated as-a-service, enabling facilita ===
interaccion                   modo               peso
checkout -> platform          x-as-a-service        1
catalog -> platform           x-as-a-service        1
fulfillment -> platform       x-as-a-service        1
checkout -> payments-risk     x-as-a-service        1
enabling -> checkout          facilitating          2
CARGA TOTAL                                         6

Carga de comunicacion: 15 -> 6  (baja 60%)
El mismo mapa de quien-necesita-a-quien; distinto MODO de interactuar.

Detente en los dos arreglos, porque son la misma organización con dos costos radicalmente distintos.

El mapa de necesidades es idéntico; solo cambia el modo. Fíjate: las cinco interacciones son las mismas en los dos arreglos —checkout necesita a platform, catalog necesita a platform, y así—. No agregamos ni quitamos ninguna relación. Lo único que cambió es cómo se relacionan: en A todo es collaboration (co-diseñar codo a codo), en B las relaciones con la plataforma y el subsistema complicado son x-as-a-service (consumir un servicio estable) y la del enabling es facilitating (ayuda temporal). Mismo quién-necesita-a-quién, distinto modo, y la carga de comunicación cae de 15 a 6 —un 60% menos—.

El default es el más caro. El arreglo A —todo collaboration— no es un hombre de paja; es lo que pasa por defecto cuando nadie diseña las interacciones. Si no defines cómo se relacionan los equipos, terminan colaborando en todo: reuniones de todos con todos, cada equipo metido en el trabajo de los demás, porque "necesitamos coordinar". Ese default cuesta 15. El arreglo B no eliminó ninguna necesidad; eligió el modo barato donde el modo barato bastaba —consumir la plataforma como servicio en vez de co-diseñarla, usar el motor de fraude como servicio en vez de meterse en sus tripas—. La lección: el ahorro no viene de que los equipos se necesiten menos, viene de que se relacionen de la forma más barata que su necesidad permite.

Collaboration se reserva, no se reparte. En el arreglo B no queda ninguna interacción en modo collaboration —todas se pudieron volver x-as-a-service o facilitating—. En una organización real sí quedarían algunas: las fronteras donde dos equipos de verdad tienen que co-diseñar algo nuevo (por ejemplo, si checkout y payments-risk estuvieran inventando juntos un flujo de pago que ninguno entiende aún). El punto no es eliminar collaboration —es valioso donde hace falta— sino reservarlo para esas pocas fronteras y no dejarlo como el modo por defecto de todo. Cada relación que puedes bajar de collaboration a x-as-a-service es peso 3 que se vuelve peso 1: el mayor apalancamiento de comunicación que tiene un arquitecto.

Aquí está la lección hecha número, y cierra el módulo: la estructura de equipos importa, pero el modo de interacción importa igual. Puedes tener los cuatro tipos de equipo perfectamente definidos y aun así ahogarte si todos colaboran con todos (arreglo A, carga 15). El diseño organizacional no termina en "quién es qué equipo"; incluye "cómo se relaciona cada par", y esa segunda decisión —el modo— es la que este ejemplo mide. Un platform team que insiste en co-diseñar con cada equipo que lo consume (collaboration) es un platform team que fracasó en su propósito: su razón de existir es ofrecer un servicio estable (x-as-a-service) para que los demás fluyan sin coordinarlo. El modo es donde el diseño se gana o se pierde.

Un matiz honesto sobre los pesos. Los números 3/1/2 son ordinales que reflejan el ancho de banda relativo de cada modo, no una medición de horas —collaboration cuesta más que x-as-a-service, y eso es lo robusto; que sea exactamente el triple es una estimación—. El valor del modelo no está en el "15" ni en el "6" exactos, sino en la comparación: el mismo mapa de necesidades cuesta 2.5 veces más si lo resuelves todo con collaboration que si eliges el modo barato donde cabe. Y esa proporción se sostiene sin importar los pesos exactos, porque collaboration siempre es más caro que consumir un servicio. El número te da la dirección y la magnitud del ahorro; no promete una cifra de horas.

Profundización: por qué solo cuatro tipos, y el "team API"

Podrías preguntarte: ¿por qué exactamente cuatro tipos de equipo? ¿No habría infinitas formas de organizar? El argumento de Skelton & Pais es que la mayoría de las organizaciones tienen demasiados tipos de equipo mal definidos —equipos "de proyecto", "de mantenimiento", "de integración", "de release", comités varios— y que casi todos esos o son innecesarios o encajan en uno de los cuatro fundamentales. Reducir el catálogo a cuatro no es una limitación arbitraria; es una disciplina de simplicidad: cada equipo debe poder decir en cuál de los cuatro tipos está, y si no puede, probablemente su propósito está confuso. Los cuatro tipos cubren las cuatro razones legítimas de que exista un equipo: entregar un flujo de valor (stream-aligned), proveer una capacidad común (platform), habilitar a otros (enabling), o encapsular complejidad profunda (complicated-subsystem). Un equipo que no es ninguno de esos cuatro es un equipo cuyo propósito hay que cuestionar.

El concepto que hace operable todo esto es el "team API" —la idea de que cada equipo expone una interfaz hacia los demás, igual que un módulo de software—. El team API de un equipo incluye: qué provee (el código, los servicios, las APIs que otros consumen), cómo se le pide algo (¿un ticket?, ¿un pull request?, ¿un canal de chat?), qué tan estable es lo que ofrece, y cómo se comunica su hoja de ruta. Un platform team con un buen team API es uno donde pedir una capacidad es tan simple como leer una documentación y llamar un endpoint —cero necesidad de coordinar con las personas del equipo—. Un equipo con mal team API es uno donde para usar lo suyo tienes que agendar una reunión, explicar tu caso, esperar—; es decir, un equipo que fuerza collaboration cuando debería ofrecer x-as-a-service. Diseñar el team API es diseñar el modo de interacción: un buen API estable habilita el modo barato (x-as-a-service); un API pobre o inestable fuerza el modo caro (collaboration). Por eso el trabajo de un platform team no es solo construir capacidades, sino empaquetarlas con un API tan bueno que nadie tenga que hablar con ellos para usarlas.

Esto conecta con el hilo entero del módulo. La Ley de Conway dice que las interfaces del software copian los canales de comunicación de los equipos. El team API es la versión deliberada de eso: en vez de dejar que las interfaces del software emerjan del accidente de quién-habla-con-quién, diseñas los canales de comunicación a propósito (los team APIs, los modos de interacción) para producir las interfaces de software que quieres. Es la maniobra inversa de Conway llevada a su forma más fina: no solo eliges quién posee qué (lección 6), sino cómo se comunica cada par de equipos (el modo) y qué expone cada uno (el team API). El resultado es una organización donde la comunicación cara está minimizada y localizada, y por Conway, un sistema con interfaces limpias y pocas dependencias caras. El vocabulario de las team topologies es, en el fondo, el manual para operar la fuerza de Conway con precisión de cirujano en vez de a ojo.

Errores comunes

Tratar todo como collaboration (de modo por defecto caro). Qué pasa: nadie define los modos de interacción, así que todos los equipos terminan co-diseñando con todos —reuniones interminables, cada equipo metido en el trabajo de los demás, la sensación de que "hay que coordinar todo"—. Por qué pasa: collaboration es el modo que emerge solo cuando no diseñas nada; sentarse a trabajar juntos parece lo natural y responsable. Cómo detectarlo: si tu calendario está lleno de reuniones inter-equipo y sientes que no puedes avanzar sin sincronizar con tres equipos, estás en el arreglo A (carga 15). Cómo corregirlo: pregunta por cada relación "¿de verdad tenemos que co-diseñar esto, o basta con que uno consuma un servicio del otro?"; vuelve x-as-a-service todo lo que puedas, y reserva collaboration para las pocas fronteras que de verdad lo exigen.

Un platform team que colabora en vez de servir (de plataforma fallida). Qué pasa: el equipo de plataforma, en vez de ofrecer capacidades como un servicio autoservicio, se involucra en el trabajo de cada equipo que lo consume —agenda reuniones, "ayuda a integrar", revisa cada uso—. En vez de quitar carga, la agrega, y se vuelve un cuello de botella por el que todo pasa. Por qué pasa: se confunde "dar buen soporte" con "meterse en todo", y falta un team API que permita el autoservicio. Cómo detectarlo: si para usar la plataforma tienes que hablar con el equipo de plataforma cada vez, no es una plataforma, es un cuello de botella. Cómo corregirlo: invierte en el team API —documentación, contratos estables, autoservicio— para que consumir la plataforma sea x-as-a-service (leer y llamar) y no collaboration (reunirse y coordinar).

Un equipo enabling que se vuelve permanente (de facilitación que no termina). Qué pasa: un equipo enabling llega a ayudar a otro a adoptar una práctica, pero en vez de enseñar y retirarse, se queda —hace el trabajo por el equipo en vez de habilitarlo a hacerlo solo—, y se convierte en una dependencia permanente. Por qué pasa: es más rápido hacerlo uno mismo que enseñar, y al equipo ayudado le conviene que el enabling siga cargando el trabajo. Cómo detectarlo: si un equipo enabling lleva un año "ayudando" al mismo equipo con lo mismo, dejó de habilitar y empezó a depender. Cómo corregirlo: el modo facilitating es temporal por diseño; pon una fecha de salida y mide el éxito por si el equipo ayudado quedó capaz de hacerlo solo, no por cuánto trabajo hizo el enabling.

Ejercicios

Ejercicio 1 — Clasifica los equipos. Para cada equipo, di de qué tipo de team topology es y por qué. (a) Un equipo que construye y opera el journey completo de "buscar y comprar un producto". (b) Un equipo que mantiene el sistema de CI/CD y los ambientes de despliegue que todos usan. (c) Un equipo de dos expertos en machine learning que mantiene el motor de recomendaciones. (d) Un grupo que durante tres meses ayuda a los squads a adoptar testing automatizado y luego se disuelve.

Ver solución

(a) Stream-aligned. Posee un flujo de valor de punta a punta (el journey de buscar y comprar) y lo entrega completo. Es el tipo por defecto y el que debería ser la mayoría. Su producto es directamente valor para el usuario.
(b) Platform. Provee una capacidad común (CI/CD, ambientes) como un servicio que todos los equipos consumen, para que ninguno tenga que montar su propio pipeline. Su éxito se mide por qué tan fácil es para los demás usar la plataforma sin coordinar.
(c) Complicated-subsystem. Encapsula una parte que requiere expertise profundo y escaso (machine learning) que no tiene sentido que cada equipo stream-aligned aprenda. Existe para quitarle esa carga cognitiva a los demás; los stream-aligned consumen el motor de recomendaciones sin entender sus tripas.
(d) Enabling. Ayuda a otros equipos a adquirir una capacidad nueva (testing automatizado) y lo hace temporalmente —se disuelve a los tres meses—. Su producto no es código sino que otros equipos mejoren; su modo es facilitating y su naturaleza es pasajera.

La disciplina: cada equipo encaja en uno de los cuatro. Si un equipo no encaja claramente en ninguno, su propósito está confuso y hay que cuestionarlo.

Ejercicio 2 — Elige el modo correcto. Para cada par de equipos que se necesitan, di qué modo de interacción (collaboration, x-as-a-service, facilitating) es el correcto y por qué. (a) Un stream-aligned que necesita autenticación, y el platform team que la provee. (b) Dos stream-aligned que están inventando juntos un flujo de pago nuevo que ninguno entiende todavía. (c) Un stream-aligned que quiere aprender a hacer chaos engineering, y un equipo enabling experto en eso.

Ver solución

(a) X-as-a-service. El platform team provee autenticación como un servicio estable; el stream-aligned la consume llamando una API, sin necesidad de co-diseñar ni coordinar con el platform team en cada uso. Es el modo barato y es exactamente para lo que existe una plataforma. Si esta relación fuera collaboration (reunirse cada vez para usar auth), la plataforma habría fracasado en su propósito.
(b) Collaboration. Aquí sí se justifica el modo caro: están inventando algo nuevo que ninguno entiende todavía, así que necesitan co-diseñar codo a codo, con alto ancho de banda, explorando juntos. Es exactamente la situación para la que collaboration es valioso —territorio desconocido que requiere las dos cabezas a la vez—. Eso sí: debe ser temporal; cuando el flujo de pago quede entendido y estable, la relación debería bajar a x-as-a-service (uno expone el pago como servicio y el otro lo consume).
(c) Facilitating. El equipo enabling ayuda temporalmente al stream-aligned a adquirir la capacidad de chaos engineering: le enseña, lo acompaña, y se retira cuando el equipo ya sabe hacerlo solo. No es collaboration (no co-diseñan un producto compartido) ni x-as-a-service (el enabling no provee un servicio permanente); es habilitación pasajera. La señal de éxito: que el stream-aligned quede capaz de hacer chaos engineering sin el enabling.

La regla: x-as-a-service por defecto (barato), collaboration solo para inventar algo nuevo juntos (caro, temporal), facilitating para transferir una capacidad (temporal).

Ejercicio 3 — Rediseña un arreglo caro. En una empresa, el platform team colabora (modo collaboration) con cada uno de los cuatro equipos stream-aligned que lo consumen, porque "así les da mejor soporte". Con los pesos del ejemplo (collaboration=3, x-as-a-service=1), calcula la carga de esas cuatro relaciones tal como están, y cuánto bajaría si el platform team ofreciera sus capacidades como servicio. ¿Qué tendría que construir para lograr el cambio?

Ver solución

Carga actual: cuatro relaciones stream-aligned → platform, todas en modo collaboration (peso 3): 4 × 3 = 12.

Carga si fueran x-as-a-service (peso 1): 4 × 1 = 4.

Ahorro: de 12 a 4, un 67% menos carga de comunicación, solo cambiando el modo de esas cuatro relaciones. Y el ahorro escala: cada nuevo equipo que consuma la plataforma agrega peso 3 en collaboration pero solo peso 1 en x-as-a-service, así que mientras más equipos, más grande la diferencia. Un platform team que colabora no escala; uno que sirve, sí.

Qué tendría que construir el platform team para lograr el cambio: un buen team API que habilite el autoservicio. En concreto: (1) documentación clara de qué capacidades ofrece y cómo usarlas; (2) contratos/APIs estables y versionados, para que los equipos consuman sin miedo a que cambie bajo sus pies; (3) un mecanismo de autoservicio (portal, CLI, endpoints) para pedir/usar capacidades sin agendar una reunión; (4) canales de soporte asíncronos para las dudas, en vez de involucrarse en cada integración. Con eso, usar la plataforma pasa de "reunirse y coordinar" (collaboration, caro) a "leer y llamar" (x-as-a-service, barato). La moraleja: la razón de existir de un platform team es ofrecer un servicio tan bueno que nadie tenga que hablar con ellos para usarlo —"dar mejor soporte" colaborando en todo es, paradójicamente, señal de que la plataforma no está haciendo su trabajo—.

Resumen y siguiente paso

En esta lección adquiriste el vocabulario para diseñar una organización a propósito. Con los cuatro roles de la obra de construcción viste los cuatro tipos de equipo de Skelton & Pais: stream-aligned (dueño de un flujo de valor, el tipo por defecto), platform (provee capacidades como servicio), enabling (habilita a otros, temporalmente) y complicated-subsystem (encapsula lo que requiere expertise profundo). Y los tres modos de interacción: collaboration (caro, para inventar juntos), x-as-a-service (barato, para consumir un servicio) y facilitating (temporal, para transferir una capacidad). Lo mediste ejecutando: el mismo mapa de quién-necesita-a-quién en Mercado cuesta una carga de comunicación de 15 si todo es collaboration (el default cuando nadie diseña) y de 6 si eliges el modo barato donde cabe —un 60% menos, sin cambiar ninguna necesidad, solo el modo—. Entendiste que el diseño organizacional no termina en "quién es qué equipo" sino en "cómo se relaciona cada par", que un platform team existe para ofrecer x-as-a-service (no para colaborar en todo), y que el team API es lo que habilita el modo barato.

Antes de avanzar deberías poder: clasificar equipos en los cuatro tipos y saber cuál debería ser la mayoría; elegir el modo de interacción correcto para un par de equipos según su necesidad; explicar por qué minimizar collaboration reduce la carga de comunicación; y reconocer los anti-patrones (todo collaboration, la plataforma que se mete en todo, el enabling que no termina).

Lo que sigue es juntar todo el módulo con tus manos. En la lección 8 —el proyecto— vas a rediseñar la organización de Mercado para una capacidad nueva que no vimos en las lecciones: el lanzamiento de reviews + recommendations, que un solo squad growth recibe entero. Vas a producir los tres artefactos del módulo: el mapa org↔arquitectura de la propuesta inicial, la medición ejecutada de su fricción y su carga por equipo, y la maniobra inversa que la arregla usando el catálogo de team topologies que acabas de aprender —separar el equipo stream-aligned de reviews del complicated-subsystem de machine learning—. Es la prueba de que aprendiste a diseñar la organización, no solo a diagnosticarla.

Recursos

Skelton & Pais — Team Topologies — la fuente de esta lección entera: los cuatro tipos de equipo, los tres modos de interacción, el concepto de team API y de carga cognitiva. Lectura obligatoria para cualquier arquitecto que diseñe organizaciones.
Team Topologies — conceptos clave (resumen gratuito) — el resumen oficial con los cuatro tipos y los tres modos explicados en una página, con diagramas; el mejor punto de entrada rápido.
Matthew Skelton — "How to find the right DevOps tools" y los patrones de topología en devopstopologies.com — el catálogo visual de topologías de equipo (y anti-patrones) que precedió al libro; útil para ver ejemplos concretos de arreglos buenos y malos.

← Anterior6. La maniobra inversa de Conway Siguiente →8. Proyecto: rediseña la organización de Mercado para una capacidad nueva