Team Topologies

De dónde sale

Matthew Skelton y Manuel Pais publicaron Team Topologies en 2019, después de años ayudando a empresas a adoptar DevOps. Vieron que muchas fallaban por lo mismo: cambiaban herramientas y procesos, pero no cómo estaban repartidas las personas, y el reparto acababa decidiendo la arquitectura y la velocidad.

El libro parte de una idea sencilla: el equipo es la unidad de entrega, no la persona. Un equipo estable, de cinco a nueve personas, que es dueño de una parte del software de principio a fin. Todo lo demás (tipos de equipo, formas de relacionarse, cuánto puede llevar cada uno) se construye encima de esa idea.

La ley de Conway y la maniobra inversa

En 1968, Melvin Conway escribió que las organizaciones que diseñan sistemas acaban produciendo diseños que copian su estructura de comunicación. Si tres equipos construyen un compilador, sale un compilador de tres fases. No es una ley de la naturaleza, sino una observación que se cumple con terquedad: lo que es fácil de coordinar dentro de un equipo acaba junto, y lo que cruza equipos acaba separado por una interfaz.

Team Topologies le da la vuelta: si el organigrama va a decidir la arquitectura, que la decida a propósito. Es la maniobra inversa de Conway: primero se piensa qué arquitectura se quiere (qué partes deben poder cambiar sin coordinarse) y después se forman los equipos con esa forma.

Para encontrar dónde cortar, el libro propone buscar planos de fractura: líneas por las que el software se puede partir con poco acoplamiento. Las más habituales:

• Un área de negocio (un subdominio, en términos de DDD). Es el plano preferido.
• Un requisito regulatorio: lo que tiene que auditarse aparte.
• Un ritmo de cambio distinto: lo que cambia cada día, separado de lo que cambia una vez al año.
• Un perfil de riesgo, una tecnología muy distinta, la ubicación de las personas o un tipo de usuario.

Cortar por capas técnicas (un equipo de pantallas, otro de servicios, otro de base de datos) es el corte que la ley de Conway castiga más: casi cualquier cambio de negocio cruza las tres capas y, por tanto, los tres equipos.

Lo que cabe en la cabeza de un equipo

El segundo pilar es la carga cognitiva: todo lo que un equipo tiene que tener en la cabeza para hacer bien su trabajo. Viene de la psicología del aprendizaje (John Sweller), que distingue tres tipos:

La consecuencia práctica es que el tamaño de lo que lleva un equipo lo marca su carga, no su número de personas. Añadir gente a un equipo saturado no ayuda: cada persona nueva tiene que aprender todo lo que el equipo lleva, y las reuniones crecen. Lo que ayuda es reducir lo que el equipo tiene que saber: partir su dominio o quitarle la carga ajena.

En la serie De cero a neobanco se simplifica en dos tipos: carga del dominio (la intrínseca y la pertinente juntas) y carga ajena al dominio. Para decidir qué quitar a un equipo, la distinción que importa es esa.

Cuatro tipos de equipo

Team Topologies propone que casi cualquier organización se puede describir con solo cuatro tipos de equipo:

• Stream-aligned: alineado con un flujo de cambio del negocio (un producto, un tipo de cliente, un recorrido) y dueño de él de principio a fin. Es el tipo principal: la mayoría de los equipos deberían serlo, y los otros tres existen para que estos vayan más rápido.
• Platform: ofrece a los stream-aligned lo que necesitan para trabajar (entornos, despliegue, observabilidad) como un servicio interno de autoservicio. Su objetivo es bajar la carga ajena de los demás.
• Enabling: especialistas que ayudan temporalmente a otros equipos a aprender algo (seguridad, una práctica nueva, una norma) y se retiran cuando lo han aprendido. No hacen el trabajo por ellos.
• Complicated-subsystem: lleva una parte que exige un conocimiento tan especializado (matemáticas, un motor de vídeo, un algoritmo) que no tiene sentido repartirlo entre los stream-aligned. Debe ser raro.

Lo que no aparece en la lista también es una decisión: no hay equipos de «backend», de «QA» o de «arquitectura» como tipos permanentes. Si existen, el libro propone preguntarse a cuál de los cuatro tipos deberían parecerse.

Tres formas de relacionarse

Igual de importante que los tipos es cómo se hablan los equipos. El libro limita las relaciones a tres modos de interacción, cada uno con su coste y su momento:

La recomendación es que cada pareja de equipos tenga un modo claro en cada momento, y que sea explícito. La mayoría de los problemas entre equipos vienen de modos implícitos o equivocados: dos equipos «colaborando» indefinidamente en algo que ya podría ser un servicio, o un equipo que pide como servicio algo que aún no existe.

Para que el modo X-as-a-service funcione, el libro propone que cada equipo publique su API de equipo: no solo su API técnica, sino también cómo se le pide algo, qué documentación ofrece, cómo se comunica y qué se puede esperar de él.

La topología se mueve

Una topología no es un organigrama que se dibuja una vez. Las relaciones cambian a medida que el software madura: dos equipos colaboran para descubrir algo, y cuando está descubierto pasan a una relación de servicio. Un equipo enabling termina su trabajo y pasa a acompañar a otro. Un complicated-subsystem deja de serlo cuando su conocimiento se vuelve común.

Por eso el libro habla de sentir la organización: revisar cada cierto tiempo si los modos siguen encajando, si algún equipo está saturado o si aparecen señales como esperas largas, traspasos frecuentes o reuniones que no deberían hacer falta. Esta idea encaja con los mapas de Wardley: lo que está en génesis pide colaboración; lo que llega a producto, servicio.

Errores frecuentes

• Renombrar los equipos sin cambiar nada. Llamar «plataforma» al departamento de sistemas no lo convierte en un servicio de autoservicio.
• Colaborar con todos para siempre. La colaboración es para descubrir; mantenida, se convierte en coordinación permanente.
• Un enabling que hace el trabajo. Si el equipo especialista prepara la auditoría en lugar de enseñar a hacerla, el otro equipo no aprende y el especialista se convierte en cuello de botella.
• Demasiados complicated-subsystem. Todo parece especializado visto desde dentro; si hay muchos, probablemente son equipos de componente con otro nombre.
• Medir el tamaño por personas. Lo que limita a un equipo es su carga cognitiva; contratar no la baja.
• Una plataforma obligatoria que no resuelve nada. La plataforma tiene que ganarse a sus usuarios como un producto.

Dónde se ve en New Capital Bank

El acto 2 de De cero a neobanco cuenta el marco sobre el banco, y el acto 3 sigue con la plataforma:

• Un equipo ya no basta: la ley de Conway y la maniobra inversa, cortar por capas o por flujo de negocio.
• El equipo que lo hacía todo: la carga cognitiva, y por qué contratar no la baja.
• Cuatro tipos de equipo y tres formas de colaborar: los tipos, los modos y cómo cambia una relación.
• La plataforma como producto: el equipo platform tratado como producto.

Fuentes. Matthew Skelton y Manuel Pais, Team Topologies (IT Revolution, 2019) y teamtopologies.com. Melvin Conway, «How Do Committees Invent?», Datamation, 1968. La notación de los diagramas sigue la del libro, simplificada.