En su momento, la Harvard Business Review rechazó su artículo original basándose en que no había demostrado su hipótesis. Sin embargo, esta observación se conoce como la Ley de Conway, y las experiencias colectivas de mis colegas y las mías han reforzado una y otra vez la verdad de esta afirmación. Pero no hace falta que te fíes de nuestra palabra.
En «Exploring the Duality between Product and Organizational Architectures», un estudio de la Harvard Business School llevó a cabo un análisis de diferentes bases de código para ver si podían probar la hipótesis original de Conway aplicada a los sistemas de software. En él, tomaron múltiples ejemplos de software creado para resolver el mismo propósito (por ejemplo, software de procesamiento de textos, de gestión financiera y de bases de datos), y compararon las bases de código creadas por equipos de código abierto poco acoplados, y las creadas por equipos muy acoplados. Su estudio descubrió que los equipos de producto, a menudo ubicados en el mismo lugar, creaban software que tendía más a bases de código monolíticas y fuertemente acopladas. Mientras que los proyectos de código abierto daban lugar a bases de código más modulares y descompuestas.
Desde hace unos años, las organizaciones han comprendido este vínculo entre la estructura organizativa y el software que crean, y han adoptado nuevas estructuras para lograr el resultado que desean. Netflix y Amazon, por ejemplo, se estructuran en torno a múltiples equipos pequeños, cada uno con la responsabilidad de una pequeña parte del sistema global. Estos equipos independientes pueden ser dueños de todo el ciclo de vida de los servicios que crean, lo que les permite un mayor grado de autonomía que el que tienen los equipos más grandes con bases de código más monolíticas. Estos servicios, con sus preocupaciones independientes, pueden cambiar y evolucionar por separado los unos de los otros, lo que se traduce en la capacidad de entregar los cambios a la producción más rápidamente. Si estas organizaciones hubieran adoptado equipos de mayor tamaño, los sistemas monolíticos más grandes que habrían surgido no les habrían dado la misma capacidad de experimentar, adaptarse y, en última instancia, mantener a sus clientes contentos.
Puede que veas tensiones en tus propias organizaciones cuando tu estructura y tu software no están alineados. Puede que haya visto, por ejemplo, los retos que supone que equipos distribuidos intenten trabajar en la misma base de código monolítico. En este caso, las vías de comunicación a las que se refiere Conway contrastan con el propio código, donde la base de código única requiere una comunicación de grano fino, pero un equipo distribuido sólo es capaz de una comunicación de grano grueso. Cuando surgen estas tensiones, la búsqueda de oportunidades para dividir los sistemas monolíticos en torno a los límites de la organización a menudo producirá ventajas significativas.
En anteriores Radares Tecnológicos hemos destacado la creciente popularidad de los Microservicios, que están siendo adoptados cada vez más por las organizaciones que buscan mejorar la autonomía de sus equipos y aumentar la velocidad del cambio. El artículo de Martin Fowler y James Lewis profundiza en el tema, destacando que estas arquitecturas permiten a las organizaciones mucha más flexibilidad a la hora de alinear la arquitectura de sus sistemas con la estructura de sus equipos para que la ley de Conway funcione. En la próxima edición del Tech Radar, hablaremos del reflejo de la creciente influencia de los microservicios, desde la tecnología de infraestructura como Packer o Docker hasta la herramienta de descubrimiento de servicios Consul, o los microcontenedores como el popular DropWizard o el bastante nuevo SpringBoot. También hablaremos de lo contrario: organizaciones que cambian la estructura de sus equipos para adaptarse a sus sistemas de TI.
Esperamos que surjan más técnicas y tecnología de apoyo para permitir las arquitecturas de microservicios, y estaremos al tanto de ellas en los próximos meses. Mientras tanto, si quieres saber más, suscríbete al último Tech Radar, consulta el artículo de Martin y James sobre microservicios, o mi libro de O’Reilly, Building Microservices.