ConwaysLaw

Prácticamente todos los profesionales que prefiero en Arquitectura de Software program sospechan profundamente de cualquier tipo de ley normal en el campo. Una buena arquitectura de software program es muy específica del contexto y analiza las compensaciones que se resuelven de manera diferente en una amplia gama de entornos. Pero si hay algo en lo que todos están de acuerdo es en la importancia y el poder de la Ley de Conway. Lo suficientemente importante como para afectar a todos los sistemas con los que me he cruzado, y lo suficientemente poderoso como para que estés condenado a vencer si intentas luchar contra él.

La ley probablemente se expresa mejor, por su autor, como:

Cualquier organización que diseñe un sistema (definido ampliamente) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

— Melvin Conway

La Ley de Conway es esencialmente la observación de que las arquitecturas de los sistemas de software program se ven notablemente similares a la organización del equipo de desarrollo que lo construyó. Originalmente me lo describieron diciendo que si un solo equipo escribe un compilador, será un compilador de un solo paso, pero si el equipo se divide en dos, entonces será un compilador de dos pasos. Aunque generalmente lo discutimos con respecto al software program, la observación se aplica ampliamente a los sistemas en normal.

Como me dijo mi colega Chris Ford: “Conway entendió que la comunicación humana permite y fomenta el acoplamiento de software program”. Si puedo hablar fácilmente con el autor de algún código, entonces es más fácil para mí desarrollar una comprensión rica de ese código. Esto facilita que mi código interactúe y, por lo tanto, se acople a ese código. No solo en términos de llamadas a funciones explícitas, sino también en los supuestos compartidos implícitos y la forma de pensar sobre el dominio del problema.

A menudo vemos cómo la falta de atención a la ley puede torcer las arquitecturas del sistema. Si una arquitectura está diseñada en desacuerdo con la estructura de la organización de desarrollo, entonces aparecen tensiones en la estructura del software program. Las interacciones de los módulos que fueron diseñadas para ser sencillas se vuelven complicadas, porque los equipos responsables de ellas no trabajan bien juntos. Las alternativas de diseño beneficiosas ni siquiera se consideran porque los grupos de desarrollo necesarios no se comunican entre sí.

Una docena o dos personas pueden tener comunicaciones profundas e informales, por lo que Conways Regulation indica que crearán un monolito. Eso está bien, por lo que la Ley de Conway no afecta nuestro pensamiento para equipos más pequeños. Es cuando los humanos necesitan organización que la Ley de Conway debería afectar la toma de decisiones.

El primer paso para lidiar con la Ley de Conway es saber no combatirla. Todavía recuerdo a un líder técnico inteligente, que acababa de convertirse en el arquitecto de un gran proyecto nuevo que constaba de seis equipos en diferentes ciudades de todo el mundo. “Tomé mi primera decisión arquitectónica”, me dijo. “Va a haber seis subsistemas principales. No tengo thought de qué van a ser, pero van a ser seis”.

Este ejemplo reconoció el gran impacto que tiene la ubicación en la comunicación humana. Poner equipos en pisos separados del mismo edificio es suficiente para reducir significativamente la comunicación. Poner equipos en ciudades y zonas horarias separadas dificulta aún más la conversación common. El arquitecto reconoció esto y se dio cuenta de que necesitaba tener esto en cuenta en su diseño técnico desde el principio. Los componentes desarrollados en diferentes zonas horarias necesitaban tener una interacción bien definida y limitada porque sus creadores no podrían hablar con facilidad.

Un desajuste común con la Ley de Conways es cuando un Orientado a la actividad
la organización del equipo trabaja en propósitos cruzados para el desarrollo de funciones. Los equipos organizados por capa de software program (por ejemplo, front-end, back-end y base de datos) conducen a una posición dominante. PresentationDomainDataLayering estructuras, lo cual es problemático porque cada característica necesita una estrecha colaboración entre las capas. Del mismo modo, dividir a las personas a lo largo de las líneas de actividad del ciclo de vida (análisis, diseño, codificación, prueba) significa muchas transferencias para pasar una característica de la thought a la producción.

Aceptar la Ley de Conway es superior a ignorarla, y en la última década hemos visto una tercera forma de responder a esta ley. Aquí alteramos deliberadamente la estructura organizativa del equipo de desarrollo para fomentar la arquitectura de software program deseada, un enfoque al que se hace referencia como el Maniobra inversa de Conway . Este enfoque se habla a menudo en el mundo de la microserviciosdonde los defensores aconsejan construir pequeños, de larga duración BusinessCapabilityCentric equipos que contienen todas las habilidades necesarias para entregar valor al cliente. Al organizar equipos autónomos de esta manera, empleamos la Ley de Conway para fomentar servicios igualmente autónomos que se pueden mejorar y desplegar de forma independiente unos de otros. De hecho, esta es la razón por la que describo los microservicios principalmente como una herramienta para estructurar una organización de desarrollo.

Si bien la maniobra inversa de Conway es una herramienta útil, no es todopoderosa. Si tiene un sistema existente con una arquitectura rígida que desea cambiar, cambiar la organización de desarrollo no va a ser una solución instantánea. En cambio, es más possible que resulte en una discrepancia entre los desarrolladores y el código, lo que agrega fricción para mejorar aún más. Con un sistema existente como este, el objetivo de la Ley de Conway es que debemos tener en cuenta su presencia al cambiar tanto la organización como la base de código. Y, como de costumbre, recomendaría dar pequeños pasos mientras se está atento a los comentarios.

El Diseño Dirigido por Dominio juega un papel con la Ley de Conway para ayudar a definir las estructuras de la organización, ya que una parte clave de DDD es identificar BoundedContexts. Una característica clave de un contexto acotado es que tiene su propio
Idioma ubicuo, definido y entendido por el grupo de personas que trabajan en ese contexto. Dichos contextos forman formas de agrupar a las personas en torno a un tema que luego puede alinearse con el flujo de valor.

La clave para recordar acerca de la Ley de Conways es que la descomposición modular de un sistema y la descomposición de la organización de desarrollo deben realizarse juntas. Esto no es solo al principio, la evolución de la arquitectura y la reorganización de la organización humana deben ir de la mano a lo largo de la vida de una empresa.

Agradecimientos

Invoice Codding, Birgitta Boeckeler, Camilla Crispim, Chris Ford, Gabriel Sadaka, Matteo Vaccari, Michael Chaffee y Unmesh Joshi revisaron los borradores de este artículo y sugirieron mejoras.