Header Ads Widget

Ticker

6/recent/ticker-posts

Ley de Conway: ¿Qué significa para su estrategia de API?



En octubre, asistí a la Cumbre de la Plataforma Nórdica de APIs 2019 en Estocolmo, Suecia. Entre una gran cantidad de temas interesantes, una idea que siguió surgiendo fue la de la Ley de Conway, como en la charla de Zdenek Nemec sobre la elección de un estilo API . La teoría sencilla dice que construimos sistemas de acuerdo con nuestras estructuras de comunicación interna. Pero, ¿cómo se aplica eso al diseño de API? ¿Es algo bueno (alerta de spoiler: probablemente no!), Y ¿qué podemos hacer al respecto? Responderé esas preguntas y más en este artículo: lo primero es lo primero, ¡saquemos algunas definiciones del camino!

¿Qué es la ley de Conway?

La Ley de Conway es un fenómeno mediante el cual las organizaciones construyen sistemas que reflejan fielmente sus estructuras internas. Fue formulado originalmente por el programador Melvin Conway hace más de 50 años, quien lo expresó de esta manera:
“las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones”.

El principio parece ser cierto en una variedad de campos, técnicos y de otro tipo, pero se aplica más comúnmente al mundo del desarrollo de software. Y dentro del ámbito del software, hay un movimiento en particular cuyos practicantes parecen haberse enamorado de la Ley de Conway: las API.

Lea también:  Arquitectura de la plataforma de personas

Ley de Conway y API

La idea es simple: la Ley de Conway establece que tendemos a construir sistemas que reflejan nuestras estructuras de comunicación interna, por lo que cualquier API que construyamos también reflejará nuestras estructuras de comunicación interna. Esto no solo determinará con cuántas API diferentes terminaremos, sino también el alcance y la naturaleza de cada API individual.

Veamos un ejemplo. Suponga que su organización se ocupa tanto de té como de café, y usted está buscando crear algunas API de inventario de cara al cliente como parte de su estrategia de transformación digital. Si la estructura de su organización está muy dividida entre "gente del té" y "gente del café", tal vez incluso con equipos de tecnología separados, es probable que termine con dos API (una para cada producto) codificadas de manera muy diferente.

Si su organización, en cambio, utiliza una estructura de sucursal única, con los mismos equipos de producto, marketing y tecnología para cada bebida, es mucho más probable que termine con una sola API que lo haga todo, y de manera homogénea.

¿Es mala la ley de Conway?

Muchos de nosotros hablamos de la Ley de Conway como si fuera algo malo. Eso es porque a menudo lo es, especialmente para la empresa promedio. Según el antropólogo Robin Dunbar, nosotros, como seres humanos, luchamos por mantener más de 150 (esto ha sido llamado el número de Dunbar relaciones estables a la vez. Con empresas establecidas que cuentan con más de 150 empleados, a veces solo en el personal de tecnología, la comunicación entre equipos está realmente fragmentada. Como resultado, sus API están débilmente acopladas y a menudo son inconsistentes.

No es necesario que explique por qué la inconsistencia es algo malo, solo mire hacia atrás en el ejemplo anterior. En la organización fragmentada del té y el café, tener dos API de inventario incoherentes obligaría a los clientes (la mayoría de los cuales compra ambos productos de todos modos) a escribir el doble de código. No es que los clientes puedan simplemente reutilizar el mismo código para cada API, ya que se comportan de manera diferente.

Bueno, ¿y si puede lograr que el diseño de API sea coherente en toda su organización? Desafortunadamente, todavía terminas con un montón de API poco acopladas. Lo sé, lo sé, eso suena como algo bueno. Después de todo, estamos tratando activamente de alejarnos de las aplicaciones monolíticas gigantescas, en lugar de reemplazarlas con microservicios elegantes e independientes .

El problema es que las API deben acoplarse libremente por elección, no por necesidad. Hay un momento y un lugar para el acoplamiento flojo. Especialmente en el backend, el acoplamiento flexible puede ayudar a mejorar la seguridad y la flexibilidad y, lo que es más importante, acelerar los ciclos de desarrollo.

Sin embargo, en la interfaz, sus API deben diseñarse en función de los casos de uso de los consumidores, lo que generalmente implica agrupar partes separadas de su infraestructura. Microservicios incluso los defensores como James Lewis y Martin Fowler aceptan que los servicios deben organizarse en torno a la capacidad del negocio , ofreciendo un “ amplio pila implementación de software para que el área de negocios” (el énfasis es mío).

Cómo combatir la ley de Conway

De vez en cuando, la Ley de Conway funcionará a su favor. Pero, ¿qué debe hacer si las estructuras de comunicación interna de su organización no son las ideales o reflejan mal cómo los clientes interactúan con su negocio, como se describe anteriormente? Resulta que hay al menos algunas opciones.

La maniobra inversa de Conway

Uno de los enfoques más radicales para abordar la ley de Conway es la llamada maniobra de Conway inversa . En lugar de intentar luchar contra la Ley de Conway, ¡esta técnica realmente la usa! Simplemente comience con la visión de qué API necesitará para brindar un mejor servicio a sus clientes y, trabajando desde afuera hacia adentro, estructurar su organización en torno a esos productos.

De hecho, esto es exactamente lo que hacen empresas tecnológicas como Netflix y Amazon . Al estructurarse en torno a equipos pequeños y autónomos (consulte los equipos Two-Pizza de Amazon ), pueden adoptar más de cerca una arquitectura de microservicios modular para cualquier sistema y producto.

Por supuesto, impulsar grandes cambios organizacionales en un entorno empresarial es más fácil de decir que de hacer. Sin embargo, si al menos puede estructurar partes de su organización (especialmente los equipos de tecnología) en torno a sus API ideales, sin duda se beneficiará de la Ley de Conway.

Comunicacion mejorada

Si vuelve a consultar la declaración original de Conway, verá que él cree que los sistemas terminan reflejando las estructuras de comunicación de las organizaciones, y no necesariamente sus estructuras organizativas (aunque estas dos suelen ser una y la misma). Por lo tanto, es posible que pueda eludir los efectos de la Ley de Conway simplemente mejorando la comunicación en su organización.

Volvamos al ejemplo una vez más. Incluso si tiene equipos de tecnología separados para el café y el té, aún puede alentarlos (¡u obligarlos!) A comunicarse sobre la creación de sus API. Si puede mantener esta comunicación, es probable que termine con dos API que se comportan exactamente igual, ¡si no una API que lo hace todo! Y todo eso sin mucho esfuerzo ...

Estándares

Suponga que su organización es gigantesca, y me refiero a gigantesca , y simplemente no es factible que todos los equipos de productos se comuniquen entre sí de manera constante. Bueno, otra forma de administrar la Ley de Conway es implementar estándares para las API en toda la organización. Esto es algo que las organizaciones más grandes ya están haciendo y los beneficios son claros. Aunque esto puede no ayudar a garantizar que las API estén acopladas de una manera significativa para el consumidor, definitivamente eliminará las inconsistencias en el comportamiento de las API.

Pensamientos finales

La Ley de Conway es un principio simple con grandes repercusiones: los sistemas (o API) que diseñamos tienden a reflejar nuestras estructuras de comunicación interna. En la práctica, esto significa que las grandes empresas con estructuras fragmentadas y poco acopladas terminarán construyendo API de naturaleza similar. Hay algunas formas de sortear la ley de Conway, siendo la más radical la maniobra inversa de Conway. Las alternativas más accesibles incluyen la promoción de la comunicación entre sucursales y la implementación de estándares para el diseño de API.

Publicar un comentario

0 Comentarios