Presos del organigrama: cómo la estructura de los equipos condiciona el desarrollo de software

¿Cuántas veces hemos escuchado decir: “Eso lo decidió el área de negocio; nosotros estamos aquí solo para implementarlo”? O la gente de negocio y producto diciendo “Pero esos son detalles de la implementación y los ingenieros los esclarecerán“.

Estas expresiones reflejan la gran desconexión y la poca colaboración entre las áreas de la organización—lo que llamamos silos organizacionales. El problema de fondo es la falta de agilidad y de foco en lo que realmente importa: acelerar la entrega de valor a los clientes.

Las novedades tecnológicas de los últimos años para la producción y despliegue de software (la nube, los contenedores, serverless, etc.) han servido para mejorar el trabajo de los equipos y agilizar la entrega de valor a los clientes. Pero en muchos casos, las organizaciones no terminan de cosechar los beneficios porque las estructuras organizativas se han quedado obsoletas y se han convertido en obstáculos que se interponen en la dinámica de los equipos.

En este artículo veremos cómo la estructura de los equipos y la comunicación entre ellos impactan sobre el diseño y la arquitectura de los sistemas de software—y por extensión, en la calidad, el mantenimiento y la agilidad para evolucionar los sistemas.

¿Qué es la Ley de Conway?

La Ley de Conway fue formulada por Melvin Conway hace más de 50 años y ganó fama cuando fue citada por Fred Brooks en su libro “The Mythical Man Month”. La ley señala que “Las organizaciones dedicadas al diseño de sistemas […] están destinadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones”.

Esta teoría revela que el diseño organizacional y el diseño de software son, en la práctica, dos caras de la misma moneda y están íntimamente relacionadas—aunque comúnmente sean cuestiones que se abordan por separado.

La Ley de Conway postula que los sistemas reflejan fielmente los canales internos de comunicación de los equipos y de la organización.

En el pasado, cuando los equipos se agrupaban en silos por área de tecnología, las aplicaciones tenían arquitecturas que reflejaban esa poca interacción e integración de los equipos (interfaz de usuario, middleware, base de datos, etc.).

Estas arquitecturas, más bien monolíticas, también aumentaban la dificultad para hacer las pruebas, los despliegues y evolucionar las aplicaciones.

Conway no señala qué tipo de arquitectura necesitamos. Pero con su observación explica los problemas de “disonancia” que aparecen si la arquitectura que pretendemos construir no es compatible con la estructura de los equipos ni con sus canales internos de comunicación.

James O. Coplien y Neil Harrison también lo señalan en su libro “Organizational Patterns of Agile Software Development”:

“Si las partes de una organización (por ejemplo, equipos, departamentos o subdivisiones) no reflejan exactamente las partes esenciales del producto, o si las relaciones entre las organizaciones internas no reflejan las relaciones entre las partes del producto, entonces el proyecto tendrá problemas… Hay que asegurar que la organización es compatible con la arquitectura del producto.”

En definitiva, los canales de comunicación e interacción entre los equipos se terminarán imponiendo y dictando la arquitectura del sistema. Concretamente, terminarán influyendo en el grado de acoplamiento y cohesión de las piezas de la arquitectura.

Agile, Lean y DevOps nos demuestran que los equipos pequeños y autónomos, alineados con las necesidades del negocio, son capaces de producir software en ciclos cortos e iterativos que se adaptan rápidamente a los cambios.

Pero ese marco de trabajo también debe apoyarse en una buena arquitectura para agilizar el desarrollo, las pruebas, los despliegues, el mantenimiento y evolución del sistema. Para ello, necesitamos que la arquitectura tenga en cuenta estos dos requerimientos no funcionales:

• Bajo nivel acoplamiento entre los diferentes módulos y componentes.
• Alto nivel de cohesión, que cada componente del sistema tenga un conjunto de responsabilidades (API) bien definidas y sus elementos internos estén muy relacionados e integrados entre si. La cohesión es el pegamento de los elementos internos

¿Qué hace falta para que la arquitectura sea más desacoplada y podamos acelerar los despliegues? ¿Qué podemos hacer para que las APIs estén mejor diseñadas, con más cohesión?

La respuesta es aplicar La Ley de Conway a la inversa.

Recorriendo el camino inverso de manera intencional

La Maniobra Inversa de Conway (Inverse Conway Manoeuvre, en inglés) propone influir intencionalmente en la configuración de los equipos para obtener una determinada arquitectura en el sistema.

Es decir, partiendo de las características de la arquitectura de software que queremos construir—desacoplada, más modular—podemos ajustar y evolucionar explícitamente las estructuras de comunicación de los equipos de la organización, de tal forman que eso se refleje también en el diseño técnico del sistema.

En otras palabras, si queremos que nuestra organización descubra y adopte ciertos diseños y arquitecturas—aquellos que se adaptan mejor a cómo queremos entregar valor al cliente—entonces podemos remodelar la organización para ayudar a que eso suceda. Por supuesto, no hay garantías de que la organización adopte los diseños que queremos, pero al moldear las vías de comunicación, es más probable que ocurra—según Conway.

No deberíamos abordar la arquitectura del software como un concepto aislado y sin tener en cuenta la estructura de los equipos. El motivo por el cual las arquitecturas de microservicios han tenido tanto éxito es que encajan a la perfección con equipos multidisciplinares y autónomos, capaces de asumir el desarrollo de módulos independientes, de principio a fin, con un diseño desacoplado del resto del sistema. Esto es más productivo que tener a varios equipos interactuando para desarrollar un sistema monolítico.

Conclusión

Conway observó que las estructuras de comunicación de las organizaciones influyen directamente en el diseño de los sistemas. La Ley de Conway señala las implicaciones estratégicas del diseño organizacional—la estructura e interacción de los equipos—sobre la arquitectura de los sistemas de software.

Revisar y remodelar la organización puede ayudar a mejorar la entrega de valor a los clientes a través de soluciones más modulares, fáciles de desplegar y de evolucionar y construidas por equipos más motivados.

En un próximo artículo abordaremos el diseño organizacional desde otro ángulo: la gestión de las dependencias entre los equipos.