Team Topologies y diseño sociotécnico

Diseñar equipos es trabajo de arquitectura

El Capítulo 3 mostró que la ley de Conway no es una curiosidad sino una fuerza: el sistema que construye un grupo de equipos tiende a copiar la forma en que esos equipos se comunican. Si eso es cierto, decidir cómo se forman los equipos, de qué se hace cargo cada uno y cómo interactúan es una decisión arquitectónica, con consecuencias tan duraderas como elegir una base de datos o un estilo de integración. La disciplina de diseñar a la vez la estructura del software y la estructura de los equipos se llama arquitectura sociotécnica.

El marco práctico más influyente para hacerlo es Team Topologies, de Matthew Skelton y Manuel Pais (IT Revolution, 2019; segunda edición 2025). Parte de un objetivo sencillo, el flujo rápido: una corriente constante y sostenible de cambios pequeños desde la idea hasta producción, con poca espera entre equipos. Después ofrece un vocabulario reducido para diseñar organizaciones que lo logren: cuatro tipos de equipo, tres modos de interacción, un límite llamado carga cognitiva del equipo y una técnica para encontrar las junturas por las que pueden dividirse el software y los equipos.

Varias premisas recorren el enfoque. La unidad de entrega es el equipo, no el individuo: el trabajo se asigna a equipos, la propiedad pertenece a los equipos y los equipos son estables, de modo que acumulan conocimiento de su dominio y de su código en lugar de formarse para un proyecto y dispersarse después. Los equipos son pequeños, normalmente de cinco a nueve personas, porque la confianza y la comprensión compartida disminuyen rápidamente por encima de ese tamaño (los autores se basan en la investigación de Robin Dunbar sobre el tamaño de los grupos). Y los límites de los equipos deben diseñarse para el flujo del cambio, no para la comodidad de las líneas jerárquicas ni según la historia de quién construyó qué.

Para los arquitectos, esto cambia el trabajo. Un límite de servicio propuesto solo es bueno si algún equipo puede hacerse cargo de él por completo; un equipo propuesto solo es viable si el código del que se hace cargo le permite trabajar sin pedir permiso a otros tres equipos. El arquitecto que dibuja cajas sin preguntar quién se hará cargo de cada una está diseñando la mitad del sistema.

Los cuatro tipos fundamentales de equipo

Team Topologies sostiene que casi todos los equipos de una organización de software deberían ser de uno de cuatro tipos. El sentido de tener tan pocos tipos es la claridad: cada tipo tiene un propósito distinto, una forma distinta de medir el éxito y una relación distinta con los demás equipos, de modo que conocer el tipo de un equipo indica a todos qué esperar de él.

Un equipo alineado al flujo (stream-aligned) está alineado con un flujo de cambio: un producto, un recorrido del cliente, un grupo de usuarios o una capacidad de negocio. Se hace cargo de su parte de extremo a extremo, desde el descubrimiento y la construcción hasta su operación en producción, y debería poder entregar la mayoría de los cambios sin esperar a nadie. Los equipos alineados al flujo son el tipo predeterminado y deberían ser la gran mayoría; los otros tres tipos existen para reducir su carga.

Un equipo de plataforma proporciona servicios internos (pipelines de despliegue, un entorno de ejecución, observabilidad, infraestructura de datos) como un producto que los equipos alineados al flujo consumen mediante autoservicio. Una buena plataforma se juzga por la velocidad de sus usuarios, no por su propia lista de funcionalidades. Un equipo facilitador está formado por especialistas que ayudan a otros equipos a adquirir una capacidad de la que carecen, como la automatización de pruebas, las prácticas de observabilidad o un framework nuevo, y después pasan a otra cosa; su éxito se mide porque el otro equipo deja de necesitarlo. Un equipo de subsistema complicado se hace cargo de una parte que requiere conocimientos poco comunes, como un motor de precios basado en modelos actuariales, un solucionador de optimización de rutas o un códec de video, para que los equipos alineados al flujo puedan usarla sin tener que dominarla. El libro insiste en que este tipo debe usarse con moderación y solo donde la especialidad sea real.

Tres modos de interacción

Los tipos de equipo dicen qué son los equipos; los modos de interacción dicen cómo trabajan juntos. Skelton y Pais sostienen que la interacción ambigua e improvisada entre equipos es una fuente importante de retrasos, porque cada conversación no planificada es una dependencia. Por eso recomiendan que cada par de equipos que deban interactuar elija deliberadamente uno de tres modos, durante un periodo determinado.

En la colaboración, dos equipos trabajan estrechamente en un objetivo compartido, con responsabilidades difusas, por ejemplo, mientras descubren cómo debe dividirse una capacidad nueva. Produce un aprendizaje rápido, pero cuesta a ambos equipos capacidad y carga cognitiva, así que debe tener un plazo acotado. En X como servicio (X-as-a-Service), un equipo proporciona algo (una API, una capacidad de plataforma, una biblioteca) que otro consume con poca o ninguna colaboración; escala bien, pero solo funciona una vez que el límite se entiende bien y la interfaz es buena. En la facilitación, un equipo, normalmente un equipo facilitador, ayuda a otro a aprender o a eliminar un obstáculo.

Los modos están pensados para cambiar. Una secuencia habitual es descubrir y luego asentar: un equipo de plataforma colabora con un equipo alineado al flujo durante unas semanas para diseñar una capacidad nueva, después la convierte en una oferta de autoservicio y pasa a X como servicio. Los modos también funcionan como mecanismo de detección. Si un equipo que debería consumir un servicio como servicio sigue necesitando reuniones, probablemente la interfaz o el límite están mal; si dos equipos llevan un año colaborando, quizá en realidad sean un solo equipo, o la división entre ellos esté en el lugar equivocado.

La carga cognitiva como restricción de diseño

La idea de carga cognitiva procede de la psicología de la educación. La teoría de la carga cognitiva de John Sweller, publicada por primera vez en 1988, partía de la observación de que la memoria de trabajo humana solo puede retener y procesar unos pocos elementos nuevos a la vez, por lo que la enseñanza debe diseñarse para no sobrecargarla. La teoría distingue la carga intrínseca (la dificultad inherente del material), la carga extrínseca (la dificultad causada por la forma en que se presenta la tarea) y, en trabajos posteriores, la carga pertinente (el esfuerzo que construye una comprensión duradera). Los investigadores aún debaten si la carga pertinente es una categoría aparte, y Team Topologies usa las tres como heurística práctica, no como medición.

La Sección 3.7 presentó la versión de esta idea aplicada a los equipos: el total que un equipo debe tener en la cabeza para construir, operar y cambiar aquello de lo que se hace cargo. Lo que importa aquí es cómo usarla como restricción de diseño. Cuando una arquitectura asigna a un equipo más de lo que puede comprender, los efectos son previsibles: entregas más lentas, correcciones superficiales, guardias frágiles, conocimiento concentrado en una o dos personas y, con el tiempo, salidas de la empresa. Son los mismos síntomas que a menudo se atribuyen a malos ingenieros o a mal código.

El libro ofrece reglas prácticas para dimensionar las responsabilidades de un equipo según la complejidad del dominio: asigna cada dominio a un solo equipo; un equipo suele poder llevar dos o tres dominios sencillos; un equipo que se hace cargo de un dominio complejo no debería hacerse cargo de nada más; y ningún equipo debería tener dos dominios complicados. También se puede preguntar directamente a los equipos, por ejemplo con una encuesta breve sobre lo bien que entienden sus sistemas, la seguridad que sienten cuando están de guardia y cuánto tiempo dedican a las herramientas en lugar de al dominio. Las colas de tickets crecientes, los largos tiempos de incorporación y los traspasos frecuentes a la única persona que entiende un componente son señales indirectas útiles.

Las respuestas arquitectónicas reflejan los tres tipos de carga. Reduce la carga extrínseca con plataformas, automatización, caminos pavimentados y buena documentación. Acota la carga intrínseca trazando los límites de servicios y módulos de modo que la parte del dominio de cada equipo sea coherente y de un tamaño manejable, y situando las especialidades profundas detrás de interfaces de subsistema complicado. Protege la carga pertinente dejando tiempo para aprender, que es donde ayudan los equipos facilitadores.

Las API de equipo y la plataforma viable más delgada

Si los equipos interactúan mediante modos deliberados, cada equipo necesita una cara clara hacia el resto de la organización. Team Topologies la llama API del equipo: todo lo que el equipo ofrece y espera. Incluye la API técnica (endpoints, eventos, bibliotecas y sus reglas de versionado y obsolescencia), pero también la interfaz humana: la documentación y las guías de incorporación, la hoja de ruta y las prioridades actuales del equipo, sus prácticas de trabajo, los canales donde se le puede contactar, cómo solicitarle trabajo y qué tiempos de respuesta esperar.

Poner por escrito una API del equipo es un ejercicio barato y revelador. Obliga a un equipo a decir de qué se hace cargo, lo que suele dejar al descubierto servicios sin propietario y datos en disputa, y ofrece a otros equipos una forma de interactuar sin una reunión. Muchas organizaciones la mantienen como una página breve en el repositorio del equipo, revisada cada trimestre junto con la documentación de arquitectura.

La plataforma merece especial cuidado, porque es donde las buenas intenciones fallan con más frecuencia. Una plataforma construida como un gran proyecto interno, con una larga hoja de ruta y adopción obligatoria, puede fácilmente añadir carga cognitiva en lugar de reducirla. Skelton y Pais recomiendan la plataforma viable más delgada (thinnest viable platform): el conjunto más pequeño de servicios, documentación y estándares que realmente acelera a sus usuarios. Para una organización pequeña puede ser una página bien mantenida que enumere qué servicios del proveedor de nube deben usar los equipos y cómo; para una grande puede ser una plataforma interna para desarrolladores. La ingeniería de plataformas se trata en profundidad en el Capítulo 10; lo esencial aquí es que una plataforma es un producto cuyos clientes son otros equipos, y debe diseñarse y medirse como tal.

Planos de fractura: por dónde dividir el software y los equipos

Cuando una parte del sistema ha crecido demasiado para un solo equipo, hay que dividirla, y la división debe funcionar tanto para el código como para los equipos. Team Topologies llama planos de fractura a las junturas naturales por las que puede dividirse el software. El libro enumera varios, y el primero suele ser el mejor: un contexto delimitado del diseño guiado por el dominio, porque un límite que sigue el lenguaje y las reglas del negocio tiende a mantener juntos los cambios relacionados.

Los demás son útiles cuando coinciden con una diferencia real en cómo deben tratarse las partes del sistema. Dividir solo por un límite tecnológico (por ejemplo, un equipo móvil y un equipo de backend) suele ser la opción más débil, porque entonces la mayoría de los cambios lo cruzan, que es la estructura de equipos por capas sobre la que advierte la ley de Conway.

La ley de Conway, la maniobra inversa y sus límites

Team Topologies es, en la práctica, un conjunto de herramientas para la maniobra inversa de Conway que describió la Sección 3.7: decide la arquitectura que quieres y después da forma a los equipos y a los modos de interacción para que la ley de Conway empuje el sistema hacia ella. Sus aportaciones son prácticas. Los tipos de equipo dicen qué clase de equipo debe hacerse cargo de cada parte; los modos de interacción dicen qué límites entre equipos deben ser finos (X como servicio) y cuáles son temporalmente gruesos (colaboración); la carga cognitiva dice cuánto puede tener a su cargo cada equipo; los planos de fractura dicen por dónde cortar.

Los límites señalados en la Sección 3.7 siguen vigentes y conviene repetirlos en este contexto. Reorganizar los equipos no reestructura una base de código fuertemente acoplada: durante meses después de una reorganización, los equipos nuevos lucharán contra la arquitectura antigua, y por eso los cambios en los equipos y los cambios en la arquitectura deben planificarse como un único programa. Los límites que se consolidan en equipos demasiado pronto encarecen los errores, por lo que muchas organizaciones mantienen los límites inciertos dentro de un solo equipo o de un solo monolito modular hasta tener pruebas. Y las reorganizaciones frecuentes destruyen el conocimiento acumulado por los equipos estables, del que depende el enfoque.

Los profesionales tampoco se ponen de acuerdo sobre lo literalmente que hay que aplicar el marco. Sus defensores valoran el vocabulario compartido, que convierte quejas vagas (siempre estamos esperando al equipo de datos) en preguntas que se pueden diseñar (¿qué modo de interacción queremos con el equipo de datos y qué lo convertiría en X como servicio?). Sus críticos advierten de que los cuatro tipos a menudo se aplican como etiquetas a una organización que no cambia, de que los equipos reales a veces mezclan tipos (un equipo de plataforma que también se hace cargo de un subsistema complicado) y de que el marco dice poco sobre financiación, estructura de gestión o incentivos. Ambas observaciones son justas: los tipos son una ayuda para el diseño, no un organigrama, y los propios autores los presentan como punto de partida para un ajuste continuo.