La relación entre la organización de equipos y la arquitectura

Esta relación se conoce como la ley de Conway, que fue hecha por Melvin Conway en el año 1967 y dice lo siguiente: “Las organizaciones que diseñan sistemas […] están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones."

Dentro de un equipo la comunicación es frecuente y fluida, hay reuniones periódicas de planning, dailies, retrospectivas y demos. Esto permite que el equipo tenga un alto alineamiento y una coordinación ágil, lo cual es fundamental para el desarrollo de un componente. Si de repente se decide partir este equipo en 2 equipos, se produce una separación en las comunicaciones. Las comunicaciones con otros equipos son mucho menos frecuentes, ya que una de las ideas de los equipos es aislarlos de externalidades para que puedan concentrarse en su scope. Esta reducción de la comunicación entre equipos, hace más compleja la tarea de mantener un único componente. En estos casos, existen dos posibilidades: 1) partir el componente en 2, uno por equipo, esto permite desacoplar a los equipos y trabajar de forma más autónoma. 2) mantener un único componente, lo cual implica fijar una serie de mecanismos y reuniones de coordinación entre equipos, con la sobrecarga que ello conlleva. Además los equipos son interdependientes, lo cual resta velocidad y autonomía e impacta en la productividad (al tener que trabajar tan coordinados, casi podríamos considerar que a efectos prácticos sigue habiendo un solo equipo).

Tradicionalmente muchas veces la reorganización de equipos se hace desde arriba, y no siempre por personas con un conocimiento profundo de la arquitectura de la aplicación. Repetidas veces me he encontrado que se reorganizaban los equipos en función de los clientes, si surgía un nuevo cliente se creaba un nuevo equipo, por ejemplo. Y en algunos casos se acababa haciendo un fork del código como solución para que el nuevo equipo tuviese independencia y pudiera moverse con agilidad. Con todo lo que esto conlleva: duplicar el código, con sus bugs y su deuda técnica, entre otras cosas.

De cara a hacer una reorganización más sensible a la arquitectura y que no impacte negativamente a la aplicación, existe lo que se conoce como la maniobra inversa de Conway. Esta consiste en organizar los equipos de modo que imiten la arquitectura de la aplicación que se desea conseguir. Para diseñar este tipo de reorganización es fundamental contar con la colaboración de los arquitectos de software, que ayudarán a diseñarla utilizando principios de arquitectura de software. Los equipos pueden verse como un sistema, con diferentes componentes con sus responsabilidades y cuya comunicación se realiza a través de interfaces bien definidas.

Si te interesa más este tema, te recomiendo el libro Team Topologies, de Matthew Skelton y Manuel Pais. Y si necesitas ayuda o consejo sobre cómo abordar una reorganización puedes contactarme aquí.