Módulo 2: La Ley de Conway

6. La maniobra inversa de Conway

Siguiente →

Descripción

Al terminar esta lección vas a tener en las manos la jugada maestra del oficio, la que convierte la Ley de Conway de una maldición que sufres en una herramienta que usas. Se llama la maniobra inversa de Conway (Inverse Conway Maneuver), y la idea es tan simple como poderosa: si el sistema copia la estructura de la organización, entonces para obtener la arquitectura que quieres, diseña la organización que la produciría. En vez de dibujar tres servicios independientes y rezar para que los equipos respeten las fronteras (que la lección 1 nos enseñó que se erosionan), formas tres equipos independientes, y los servicios independientes salen casi solos —porque la fuerza de Conway, que antes te desalineaba, ahora empuja en la dirección que quieres—. Es dejar de nadar contra la corriente y usarla como motor. Vas a aplicar la maniobra sobre el diagnóstico de la lección 5 —el checkout que concentra la mitad de la fricción por cruzar cuatro equipos— y a medir el resultado: reestructurar los equipos (crear un equipo dueño del flujo de checkout completo, volver la plataforma un servicio) baja la fricción total del sistema de 12 a 5, un 58% menos, sin tocar el código primero.

Esto importa porque invierte la secuencia con la que casi todos intentan cambiar una arquitectura —y explica por qué casi todos fallan—. El instinto es: primero rediseño el código (extraigo el servicio, separo los módulos), y después, tal vez, ajusto los equipos. Conway garantiza que esa secuencia se revierte: si reorganizas el código pero los equipos siguen compartiendo y coordinando como antes, el código vuelve poco a poco a reflejar la comunicación real, y en unos meses estás igual. La maniobra inversa da vuelta la secuencia: primero la organización, después —y casi sola— la arquitectura. Cambias quién posee qué y quién habla con quién, y el código empieza a fluir hacia la forma nueva porque ahora la estructura de comunicación lo respalda. No es que el código se reescriba mágicamente; es que cada refactor que hagas se sostiene, porque la organización dejó de empujar en contra. La maniobra es el reconocimiento de que el molde manda: cambia el molde y el concreto tomará su forma; reesculpe el concreto sin cambiar el molde y volverá a la forma vieja.

Conexión con el módulo: esta lección es la primera de las dos curas, y la que da nombre al giro central del módulo. La lección 5 entregó el diagnóstico preciso (checkout = 6 de 12 pares de fricción); esta lo cura y mide la cura. Reusa exactamente el mismo modelo —los mismos módulos, las mismas dependencias— y solo cambia la organización, para aislar que la mejora viene de reestructurar equipos, no de reescribir código. Es la aplicación práctica de todo lo anterior: la Ley de Conway (lección 2) dice que el sistema copia la organización, así que —maniobra inversa— cambiar la organización cambia el sistema; el costo de coordinación (lección 4) dice por qué reducir cruces vale la pena; la fricción por módulo (lección 5) dice dónde aplicar la maniobra. La lección 7 (team topologies) te dará el vocabulario para diseñar la organización objetivo con precisión; esta te da el principio y la medición del antes-y-después.

Para cambiar el cauce del río, no empujes el agua

Piénsalo así. Un río baja por una ladera y, al llegar al valle, hace una curva cerrada que inunda un sembradío cada temporada de lluvias. Quieres que el agua pase derecho, sin la curva. Tienes dos formas de intentarlo.

La primera, la ingenua: empujar el agua. Pones costales de arena, desvías el flujo a mano, cavas un canalito para guiar la corriente por donde quieres. Funciona... unos días. En cuanto llueve fuerte, el agua vuelve a su curva de siempre, tira los costales y reinunda el sembradío. Estás peleando contra el agua en cada temporada, para siempre, y siempre pierdes —porque el agua no sigue tus costales, sigue la forma del terreno—. El cauce (la curva) está determinado por la geografía, no por tus esfuerzos puntuales.

La segunda, la que funciona: cambiar el terreno. En vez de empujar el agua, excavas un cauce nuevo, recto, y bloqueas el viejo con un terraplén. Ahora el agua pasa derecho no porque la estés empujando, sino porque el terreno la lleva ahí naturalmente. No tienes que hacer nada cada temporada; el río fluye recto solo, porque cambiaste la forma que determina su curso. Un trabajo grande una vez, en vez de una pelea chica para siempre.

El código es el agua; la organización es el terreno. Rediseñar el código sin cambiar los equipos es empujar el agua con costales: el código vuelve a su forma vieja en cuanto dejas de empujar, porque sigue el terreno de la comunicación, no tus refactors. La maniobra inversa de Conway es cambiar el terreno: reorganizas los equipos (excavas el cauce nuevo) y el código fluye hacia la arquitectura que quieres, solo, porque ahora la estructura de comunicación lo lleva ahí. Es más trabajo de golpe —reorganizar equipos no es trivial— pero es un trabajo que se sostiene, en vez de una pelea que se repite cada temporada. Esta lección mide cuánto endereza el río cambiar el terreno.

Ejemplo trabajado: la maniobra inversa, medida

Vamos a tomar el diagnóstico de la lección 5 —la fricción total del sistema es 12, y el checkout aporta 6— y a aplicarle la maniobra inversa. La organización objetivo se diseña a propósito con dos movimientos:

  1. Un equipo stream-aligned dueño del flujo de checkout completo. En vez de que orders y payments se disputen el checkout (dos dueños, seis pares de fricción), creamos un equipo checkout que posee el flujo de compra de punta a punta —el checkout, el carrito, el procesamiento de pedido—. Un dueño único donde antes había dos.
  2. La plataforma como servicio. auth y notifications dejan de ser cosas que cualquiera edita y se vuelven servicios de plataforma con contratos estables: los demás módulos los consumen sin coordinar cada cambio. Depender de auth ya no mete a platform en la sala.

Y medimos la fricción total antes y después. Fíjate en el modelo: las dependencias que cruzan hacia un servicio de plataforma (as_a_service) ya no meten a ese equipo en la sala, porque se consumen por contrato, no por co-cambio.

# La maniobra inversa de Conway, simulada: cambiamos la ORGANIZACION
# para OBTENER la arquitectura que queremos, y medimos la friccion antes/despues.
from itertools import combinations

deps = {
    "search":             ["product_catalog"],
    "cart":               ["product_catalog"],
    "checkout":           ["cart", "payment_processing", "shipping_labels",
                           "notifications", "order_processing"],
    "order_processing":   ["shipping_labels", "auth"],
    "payment_processing": ["invoicing", "auth"],
    "invoicing":          ["notifications"],
    "shipping_labels":    ["delivery_tracking"],
}
modules = ["product_catalog", "search", "cart", "order_processing", "checkout",
           "payment_processing", "invoicing", "shipping_labels",
           "delivery_tracking", "auth", "notifications"]

def total_friction(owners, as_a_service):
    """Suma de C(k,2) sobre todos los modulos. Las dependencias hacia un
    servicio de plataforma (as_a_service) NO meten a ese equipo en la sala:
    se consumen por un contrato estable, no por co-cambio."""
    total = 0
    for m in modules:
        room = set(owners[m])
        for d in deps.get(m, []):
            if d not in as_a_service:
                room |= owners[d]
        total += len(list(combinations(room, 2)))
    return total

# ANTES: 5 squads por dominio, checkout co-poseido por orders y payments,
# y todo se co-cambia (monolito acoplado, sin servicios de plataforma).
before_owners = {
    "product_catalog": {"catalog"}, "search": {"catalog"},
    "cart": {"orders"}, "order_processing": {"orders"},
    "checkout": {"orders", "payments"},
    "payment_processing": {"payments"}, "invoicing": {"payments"},
    "shipping_labels": {"shipping"}, "delivery_tracking": {"shipping"},
    "auth": {"platform"}, "notifications": {"platform"},
}
before_service = set()   # nada es servicio: todo se co-cambia

# DESPUES: maniobra inversa. (1) un equipo stream-aligned 'checkout' que posee
# el flujo completo (cart + order_processing + checkout), un solo dueno;
# (2) auth y notifications se vuelven servicios de plataforma (contrato estable).
after_owners = {
    "product_catalog": {"catalog"}, "search": {"catalog"},
    "cart": {"checkout"}, "order_processing": {"checkout"},
    "checkout": {"checkout"},
    "payment_processing": {"payments"}, "invoicing": {"payments"},
    "shipping_labels": {"shipping"}, "delivery_tracking": {"shipping"},
    "auth": {"platform"}, "notifications": {"platform"},
}
after_service = {"auth", "notifications"}   # plataforma como servicio

fb = total_friction(before_owners, before_service)
fa = total_friction(after_owners, after_service)

def checkout_pairs(owners, as_a_service):
    room = set(owners["checkout"])
    for d in deps["checkout"]:
        if d not in as_a_service:
            room |= owners[d]
    return len(list(combinations(room, 2)))

print(f"{'escenario':<38}{'#duenos checkout':>18}{'friccion total':>16}")
print(f"{'ANTES  (5 squads, checkout compartido)':<38}"
      f"{len(before_owners['checkout']):>18}{fb:>16}")
print(f"{'DESPUES (maniobra inversa de Conway)':<38}"
      f"{len(after_owners['checkout']):>18}{fa:>16}")
print()
print(f"friccion de checkout : {checkout_pairs(before_owners, before_service)}"
      f" -> {checkout_pairs(after_owners, after_service)} pares")
print(f"friccion total       : {fb} -> {fa}"
      f"  (baja {(1-fa/fb)*100:.0f}%)")
print("No tocamos el codigo primero: movimos los EQUIPOS, y la friccion cayo.")

Qué esperar. Al correrlo:

escenario                               #duenos checkout  friccion total
ANTES  (5 squads, checkout compartido)                 2              12
DESPUES (maniobra inversa de Conway)                   1               5

friccion de checkout : 6 -> 3 pares
friccion total       : 12 -> 5  (baja 58%)
No tocamos el codigo primero: movimos los EQUIPOS, y la friccion cayo.

Detente en los números, porque son la tesis del módulo hecha resultado.

La fricción total cayó de 12 a 5 —un 58%— sin tocar el código. El mismo mapa de módulos, las mismas dependencias, byte por byte igual. Lo único que cambió fue la organización: un dueño único para el flujo de checkout, y la plataforma vuelta servicio. Y con ese solo cambio, más de la mitad de la fricción de coordinación del sistema desapareció. Esto es la maniobra inversa en acción: no rediseñamos el sistema, rediseñamos la organización, y el sistema —medido por su fricción— mejoró como si lo hubiéramos rediseñado. Cambiamos el terreno, y el río se enderezó.

El checkout bajó de 6 a 3 pares, y de 2 dueños a 1. El módulo que concentraba la mitad de la fricción se calmó a la mitad. Fíjate de dónde vino la mejora, porque tiene dos fuentes distintas: (1) darle un dueño único (#duenos: 2 → 1) elimina la fricción de la co-propiedad —ya no hay dos equipos disputándoselo—; (2) volver notifications un servicio de plataforma saca a platform de la sala del checkout —ya no hay que coordinar con platform para cada cambio del checkout—. Lo que queda (3 pares) es la coordinación genuina del checkout con payments (el cobro) y con shipping (el envío): esas son dependencias reales que no se pueden desear que desaparezcan —el checkout de verdad necesita cobrar y enviar—. La maniobra no lleva la fricción a cero (eso sería deshonesto); la lleva a su mínimo irreducible —la coordinación que el negocio realmente requiere—, quitando la fricción artificial de la mala organización.

Aquí está la lección hecha número: primero la organización, después la arquitectura. No tocamos el código —lo dice la última línea del output—, y aun así la fricción cayó 58%. ¿Por qué? Porque la fricción no vivía en el código, vivía en la organización que lo poseía. Cambiar el terreno de la comunicación (quién posee qué, qué se consume como servicio) cambió el costo de operar el sistema sin mover una línea. Y lo más importante para tu carrera: esta mejora se sostiene. Como ahora un solo equipo posee el checkout, el refactor que ese equipo haga para separar bien el cobro del pedido no se va a erosionar, porque no hay un segundo equipo empujando dependencias cruzadas en contra. El código va a fluir hacia la forma limpia porque la organización, por fin, lo respalda. Excavamos el cauce nuevo; ahora el agua corre sola.

Un matiz honesto, porque la maniobra tiene su letra chica. El modelo trata el "volver un servicio" como un interruptor —auth y notifications pasan de co-cambio a contrato estable de un día para otro—, y en la realidad eso es trabajo: definir el contrato, versionarlo, endurecerlo para que de verdad no haya que coordinar cada cambio. La maniobra inversa habilita ese trabajo (la organización nueva hace que valga la pena y que se sostenga), pero no lo hace gratis ni instantáneo. Igual, mover al equipo checkout a poseer tres módulos que antes estaban en dos squads implica reasignar personas, transferir conocimiento, y aguantar unos meses de transición. El 58% es el destino, no el primer día. Lo que el número prueba no es que la reorganización sea gratis, sino que es la palanca correcta: el mismo esfuerzo invertido en reorganizar la organización rinde una mejora que se sostiene, mientras que invertido solo en reescribir código rinde una mejora que se erosiona.

Profundización: cuándo la maniobra funciona, cuándo es cirugía innecesaria

La maniobra inversa es poderosa, y como toda herramienta poderosa, mal usada hace daño. Reorganizar equipos es una de las intervenciones más caras y disruptivas que existen —mueve personas, rompe relaciones, cuesta meses de productividad durante la transición—. Aplicarla cuando no hace falta es cirugía mayor para un raspón. Tres criterios para saber cuándo vale la pena.

Primero: la maniobra es para arquitecturas que quieres cambiar, no para las que ya funcionan. Si tu organización y tu arquitectura ya están alineadas —los módulos tienen dueños únicos, la fricción cross-team es baja—, reorganizar no compra nada y sí destruye el conocimiento y las relaciones que hacen productivos a los equipos. La maniobra se justifica cuando hay un desalineamiento medido y doloroso (como el 58% de fricción evitable de Mercado) y una arquitectura objetivo clara hacia la cual mover. Sin objetivo claro, reorganizar es solo agitar el organigrama y esperar suerte —el anti-patrón de las "reorganizaciones perpetuas" que dejan a todos mareados y a la arquitectura igual—.

Segundo: la maniobra diseña la organización a partir de la arquitectura deseada, no al revés. El orden correcto es: (1) decide qué arquitectura quieres (servicios independientes de catalog, checkout, payments, etc.); (2) diseña la organización que la produciría (un equipo por servicio, con las fronteras del sistema coincidiendo con las fronteras de los equipos); (3) reorganiza hacia esa organización; (4) deja que el código fluya hacia la arquitectura. El error es reorganizar primero "porque tocaba" y ver qué arquitectura sale —eso es dejar que el accidente organizacional dicte el sistema, exactamente lo que Mercado sufrió—. La maniobra inversa es deliberada: eliges la arquitectura, y de ahí derivas la organización.

Tercero: la maniobra no elimina la coordinación necesaria, solo la artificial. Vimos que la fricción del checkout bajó de 6 a 3, no a 0. Ese 3 es la coordinación real —el checkout necesita hablar con payments y shipping porque de verdad cobra y envía—. Un error común es esperar que la maniobra lleve toda la fricción a cero y frustrarse cuando no lo hace, o peor, forzar fronteras artificiales para eliminar coordinación que el negocio realmente requiere (partir el checkout de payments cuando cobrar es parte esencial del checkout). La maniobra bien hecha reconoce la coordinación irreducible y la deja fluir por el canal más barato posible (un contrato de servicio estable, no una cocina compartida), en vez de pretender abolirla. Hay dependencias que son la esencia del negocio; esas no se organizan para eliminar, se organizan para que cuesten lo mínimo.

La síntesis: la maniobra inversa es el reconocimiento maduro de que el arquitecto no dibuja sistemas, diseña las condiciones organizacionales para que el sistema correcto emerja. Es lo opuesto al arquitecto de torre de marfil que entrega un diagrama y se va (el anti-patrón del módulo 1). El arquitecto que entiende Conway sabe que su diagrama no vale nada si la organización no lo puede sostener, así que su verdadera intervención es sobre la organización —y esa intervención, bien medida y bien dirigida, mueve el sistema más que cualquier refactor—.

Errores comunes

Reorganizar el código antes que la organización (de secuencia invertida). Qué pasa: el equipo extrae un servicio del monolito, celebra la separación... y en seis meses el servicio está tan acoplado al monolito como antes, porque los mismos equipos siguen compartiéndolo. Por qué pasa: reescribir código se siente como progreso tangible; reorganizar equipos se siente político y fuera de alcance. Cómo detectarlo: si separas módulos en el código pero no cambias quién los posee ni quién coordina con quién, estás empujando el agua con costales. Cómo corregirlo: invierte la secuencia —primero la organización (excava el cauce), después el código fluye—; la maniobra inversa existe precisamente para esto.

Reorganizar sin una arquitectura objetivo (de reorganización a ciegas). Qué pasa: la empresa "reorganiza para mejorar" cada seis meses, moviendo equipos sin un mapa claro de qué arquitectura quiere, y la única constante es el mareo —la arquitectura sigue igual de enredada, solo que ahora con gente nueva confundida—. Por qué pasa: reorganizar se usa como señal de acción sin el trabajo de decidir hacia dónde. Cómo detectarlo: si no puedes dibujar la arquitectura objetivo que tu reorganización debería producir, estás agitando el organigrama sin rumbo. Cómo corregirlo: decide primero la arquitectura deseada, deriva de ella la organización, y solo entonces reorganiza —la maniobra es deliberada, no un ritual—.

Usar la maniobra donde no hace falta (de cirugía innecesaria). Qué pasa: un arquitecto lee sobre la maniobra inversa y reorganiza equipos que ya funcionaban bien y estaban alineados, destruyendo relaciones y conocimiento por una mejora que no existía. Por qué pasa: la herramienta es tan atractiva que se aplica sin medir si hay un problema que resuelva. Cómo detectarlo: si reorganizas sin poder mostrar un desalineamiento medido y doloroso (fricción cross-team alta), estás operando a un paciente sano. Cómo corregirlo: mide primero (lección 5); la maniobra se justifica solo cuando hay fricción evitable significativa y una arquitectura objetivo clara —si la fricción ya es baja, deja al equipo en paz—.

Ejercicios

Ejercicio 1 — Diseña la organización desde la arquitectura. Mercado decide que quiere que payments sea un servicio de verdad independiente —que el equipo de payments pueda cambiar y desplegar el cobro sin coordinar con nadie—. Según la maniobra inversa, ¿qué cambios organizacionales harían falta para producir esa arquitectura? Piensa en ownership y en qué dependencias tendrían que volverse servicios.

Ver solución

Para que payments sea un servicio de verdad independiente (cambiar y desplegar sin coordinar), la maniobra inversa exige diseñar la organización que lo produzca:

  1. Dueño único y completo del dominio de pago. El equipo payments debe poseer payment_processing e invoicing en su totalidad —lo que ya casi tiene—, sin que ningún otro equipo les meta mano. Ningún módulo de pago co-poseído.

  2. Sacar a payments del co-ownership del checkout. Hoy payments co-posee el checkout (por eso el checkout cruza cuatro equipos). Para que payments sea independiente, el checkout debe pertenecer a otro equipo (el equipo checkout de la maniobra), y ese equipo debe consumir payments como un servicio —llamar a una API de cobro estable—, no editar el módulo de pago. Así payments deja de compartir código con el flujo de checkout.

  3. Volver estables las dependencias de payments hacia otros equipos. payment_processing depende de auth (platform). Para que payments despliegue sin coordinar, esa dependencia debe ser hacia un servicio de plataforma con contrato estable (auth-as-a-service), no hacia algo que platform cambie y obligue a payments a adaptarse.

Con esos tres cambios, la comunicación que payments necesita para operar se vuelve interna (dentro de su propio equipo) o a través de contratos estables (que no requieren coordinar cada cambio). Y entonces —maniobra inversa— el código de payments naturalmente se separa en un servicio independiente, porque la organización ya lo trata como uno. Fíjate en el patrón: no dibujamos "payments es un microservicio" y esperamos; diseñamos la organización (dueño único, checkout como consumidor, plataforma como servicio) que produce ese microservicio.

Ejercicio 2 — El refactor que se erosiona. Un equipo, sin cambiar la organización, dedica un trimestre a separar limpiamente el módulo checkout en dos submódulos: uno de pedido (para orders) y uno de pago (para payments). Al terminar, el código está impecablemente separado. Predice, usando la Ley de Conway, qué va a pasar en los siguientes seis meses y por qué. ¿Qué debieron hacer distinto?

Ver solución

Qué va a pasar: el código impecablemente separado se va a re-acoplar en los siguientes meses. Como orders y payments siguen co-poseyendo el checkout (la organización no cambió), los dos equipos van a seguir teniendo que coordinar sobre esa área. Y cada vez que coordinan bajo presión —un bug urgente, una feature con deadline—, van a meter el atajo más rápido: una llamada directa del submódulo de pedido al de pago, un dato compartido "temporal", una dependencia cruzada "solo por ahora". En seis meses, los dos submódulos "limpios" van a estar tan entrelazados como el checkout original. Es empujar el agua con costales: el refactor se erosiona porque el terreno de la comunicación (dos equipos compartiendo) no cambió, y el código vuelve a fluir hacia la forma que ese terreno dicta.

Qué debieron hacer distinto: aplicar la maniobra inversa antes o junto con el refactor. En vez de separar el código y dejar dos dueños, debieron primero darle al checkout un dueño único —un equipo que posea el flujo completo—. Con un solo dueño, la separación del código se sostiene, porque no hay un segundo equipo empujando dependencias cruzadas en contra: el único equipo dueño puede mantener la frontera interna que le convenga, y nadie desde afuera la erosiona. La regla del módulo: reorganizar el código sin reorganizar los equipos se revierte; reorganizar los equipos hace que el código se reorganice —y se mantenga— solo. El trimestre de refactor no fue inútil, pero fue el segundo paso ejecutado como si fuera el primero.

Ejercicio 3 — ¿Maniobra o bisturí de más? Para cada situación, decide si la maniobra inversa está justificada o sería cirugía innecesaria, y por qué. (a) Un sistema donde el 55% de las dependencias cruzan equipos y hay tres módulos co-poseídos que causan retrasos constantes. (b) Un sistema donde cada equipo posee sus módulos, la fricción cross-team es baja, pero el CTO leyó sobre microservicios y quiere reorganizar "para modernizar". (c) Una startup de cinco personas en un equipo con un monolito que funciona bien.

Ver solución

  • (a) Justificada. Hay un desalineamiento medido y doloroso (55% cross-team, tres módulos co-poseídos, retrasos constantes) y una dirección clara de mejora (darles dueños únicos, alinear fronteras). Este es el caso de manual de la maniobra inversa: reorganizar hacia una arquitectura objetivo con una arquitectura actual claramente rota. Vale el costo de la reorganización porque la fricción evitable es alta.

  • (b) Cirugía innecesaria. El sistema ya está alineado —cada equipo posee sus módulos, fricción cross-team baja—. Reorganizar aquí no compra nada (no hay fricción evitable que reducir) y sí destruye las relaciones y el conocimiento que hacen productivos a los equipos. El motivo ("el CTO leyó sobre microservicios", "modernizar") no es un desalineamiento medido, es una moda. Operar a un paciente sano. La respuesta correcta: no reorganizar; si acaso, medir primero, y como la fricción es baja, dejar al equipo en paz.

  • (c) Cirugía innecesaria (y sobre-ingeniería). Cinco personas en un equipo con un monolito que funciona es la arquitectura conwayana correcta para ese tamaño (lección 3): un equipo, un monolito, cero fronteras que coordinar. Aplicar la maniobra inversa para partir en microservicios aquí crearía fronteras que la organización no necesita, puro costo sin beneficio. La maniobra se aplica cuando la organización ya creció lo suficiente para justificar fronteras; a los cinco, no. Dejar el monolito.

La lección: la maniobra inversa se justifica por un desalineamiento medido más una arquitectura objetivo clara, no por moda ni por reflejo. Solo (a) cumple las dos condiciones.

Resumen y siguiente paso

En esta lección aprendiste la jugada maestra del módulo: la maniobra inversa de Conway —para obtener la arquitectura que quieres, diseña la organización que la produciría—. Con el río y el cauce viste que empujar el agua (rediseñar el código) es una pelea que se repite y se pierde cada temporada, mientras que cambiar el terreno (reorganizar los equipos) endereza el río solo y para siempre. Y lo mediste ejecutando: aplicar la maniobra al checkout de Mercado —dueño único para el flujo de compra, plataforma como servicio— bajó la fricción total del sistema de 12 a 5 (–58%) y la del checkout de 6 a 3, sin tocar el código primero; lo que quedó es la coordinación irreducible (el checkout de verdad necesita cobrar y enviar), no la artificial de la mala organización. Entendiste que la secuencia correcta es organización primero, arquitectura después (y casi sola); que la maniobra se justifica solo con un desalineamiento medido y una arquitectura objetivo clara; y que su virtud es que la mejora se sostiene porque la organización deja de empujar en contra.

Antes de avanzar deberías poder: aplicar la maniobra inversa —derivar la organización que produciría una arquitectura deseada—; medir el antes-y-después de la fricción de una reorganización; explicar por qué reorganizar el código sin la organización se erosiona; y distinguir cuándo la maniobra está justificada de cuándo es cirugía innecesaria.

Lo que sigue es el vocabulario para diseñar la organización objetivo con precisión, en vez de a ojo. La maniobra inversa te dijo qué hacer (rediseñar la organización); las team topologies de la lección 7 te dicen cómo: los cuatro tipos de equipo —stream-aligned (dueño de un flujo de valor), platform (provee capacidades como servicio), enabling (ayuda a otros a mejorar) y complicated-subsystem (encapsula lo que requiere expertise profundo)— y los tres modos de interacción, con su costo de comunicación medido. Vas a ver que el "equipo checkout dueño del flujo completo" que diseñamos aquí tiene un nombre (stream-aligned) y que "la plataforma como servicio" es un patrón (platform + x-as-a-service). Es pasar de improvisar la organización a diseñarla con un catálogo de piezas probadas.

Recursos

  • Skelton & Pais — Team Topologies, sobre la Inverse Conway Maneuver — el libro que popularizó la maniobra (el término es anterior al libro y se atribuye a ThoughtWorks); explica en detalle cómo diseñar la organización a partir de la arquitectura deseada, el corazón de esta lección.
  • Martin Fowler — "Conway's Law" — la sección sobre la maniobra inversa ("if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins"), la frase que resume por qué primero se cambia la organización.
  • ThoughtWorks Technology Radar — "Inverse Conway Maneuver" — la ficha técnica que trata la maniobra como una técnica de ingeniería con sus advertencias (cuándo aplicarla y cuándo no), útil para el criterio de "maniobra o bisturí de más".
← Anterior5. Los módulos que cruzan fronteras de equipoSiguiente →7. Team topologies