IT is part of the business

Durante la etapa de diseño de un sistema, da igual el campo al que nos refiramos, se tienen en cuenta muchos factores, que pueden depender de la naturaleza intrínseca del sistema. Entre esos factores podemos nombrar:

• Requisitos del usuario: Es fundamental comprender las necesidades y expectativas de los usuarios finales del sistema. Esto implica identificar y documentar claramente los requisitos funcionales (qué debe hacer el sistema) y los requisitos no funcionales (aspectos de rendimiento, seguridad, usabilidad, etc.). Los requisitos del usuario proporcionan una base sólida para el diseño del sistema, qué función debe cumplir y cómo debe hacerlo.
• Escalabilidad y capacidad de crecimiento: Es importante considerar la capacidad del sistema para adaptarse y crecer en el futuro. Esto incluye evaluar su capacidad de escalar para manejar mayores volúmenes de datos, usuarios o transacciones a medida que la demanda aumenta. El diseño debe ser flexible y modular para permitir futuras expansiones y actualizaciones sin requerir cambios drásticos en la estructura o la funcionalidad.
• Rendimiento y eficiencia: Muy unido al punto anterior; el diseño del sistema debe ser eficiente en términos de tiempo de respuesta, utilización de recursos y capacidad de procesamiento. Esto implica optimizar algoritmos, minimizar la carga del sistema, seleccionar tecnologías adecuadas y realizar pruebas de rendimiento para identificar y abordar posibles cuellos de botella.
• Arquitectura del sistema: Se debe definir una arquitectura adecuada para el sistema. Esto implica tomar decisiones sobre la estructura general del sistema, la interacción entre los componentes, la distribución de tareas y la comunicación entre los módulos. Una arquitectura bien pensada garantiza la eficiencia, la escalabilidad, la fiabilidad y la capacidad de mantenimiento del sistema.
• Usabilidad y experiencia del usuario: El diseño del sistema debe centrarse en proporcionar una experiencia de usuario intuitiva y fácil de usar. Se deben tener en cuenta los principios de diseño de interfaz de usuario, la accesibilidad, la navegación eficiente y la presentación clara de la información. Realizar pruebas de usabilidad y recopilar comentarios de los usuarios durante el proceso de diseño ayuda a mejorar la experiencia general del usuario.
• Seguridad y protección de datos: En muchos sistemas, la seguridad de los datos y la protección contra amenazas externas son aspectos críticos. Es importante identificar posibles vulnerabilidades y diseñar medidas de seguridad adecuadas, como autenticación, autorización, cifrado de datos y protección contra ataques cibernéticos. El diseño del sistema debe considerar políticas y prácticas de seguridad sólidas para proteger la integridad y la confidencialidad de la información.
• Mantenibilidad y extensibilidad: El diseño del sistema debe facilitar su mantenimiento a lo largo del tiempo. Esto implica utilizar prácticas de desarrollo de software sólidas, seguir estándares y convenciones, documentar el código y proporcionar una estructura modular y bien organizada. Además, se debe considerar la capacidad de extender y mejorar el sistema en el futuro sin afectar negativamente su estabilidad.

Y estos son sólo algunos de entre muchos otros aspectos a tener en cuenta.

El análisis de estos factores y la correcta selección de la solución para cada uno de ellos determinará el éxito o fracaso del sistema.

A la hora de implementar la solución o al evolucionarla, podemos encontrarnos dependencias y efectos colaterales no deseados, que quizá estaban detectados como riesgo y que se han traducido en realidad. Ya se sabe, como dice la ley de Murphy «si algo puede salir mal, saldrá mal». En otras palabras, sugiere que si hay una posibilidad de que algo salga mal en una situación determinada, es muy probable que eso ocurra. Pero quizá estamos haciendo que esta probabilidad sea mayor al no haber dado suficiente importancia a ciertos temas. A lo mejor la culpa no es de Murphy.

La lista anterior no es exhaustiva, hay varios factores que no se han nombrado y uno de ellos es la comunicación existente en el entorno, y suele ser clave para el éxito de la implementación y evolución de los sistemas.

El sistema diseñado convive y se comunicará con otros sistemas, y puede haber efectos indeseados si no se tiene en cuenta este aspecto como vimos hace un tiempo cuando hablamos de Systems Thinking; pero también hay comunicaciones internas entre equipos y personas que hay que tener en cuenta.

Introduciendo a Conway

En 1968, Melvin Conway establece que «las organizaciones que diseñan sistemas … están inevitablemente limitadas por la estructura de comunicación de sus propios equipos» y es lo que se conoce como La Ley de Conway. En otras palabras, la arquitectura de un sistema refleja la estructura de la organización que lo construye. Y si el lector se pregunta si esta ley sigue vigente tras más de cinco décadas, le animo a analizar cómo funcionan los sistemas de su empresa para darse cuenta que está tan vigente como el primer día.

Esta ley tiene profundas implicaciones en el diseño y desarrollo de sistemas, especialmente los tecnológicos, incluyendo la arquitectura de software y de datos. Es importante reseñar que se habla de la estructura de comunicación, no de la estructura organizativa y no siempre es lo mismo. El hecho de que dos departamentos de una misma empresa estén localizados en el mismo espacio, hará que se comuniquen entre ellos, aunque no tengan relación en el organigrama ni en los flujos de la cadena de valor, y esto a su vez impactará en los diseños de los sistemas.

Cuando los equipos de desarrollo de software están organizados de manera funcional, es decir, con especialistas separados en diferentes áreas, lo más seguro es que el sistema resultante esté fragmentado en módulos que reflejen la comunicación entre esos equipos. Por ejemplo, si un equipo de desarrollo se encarga de la lógica de negocio, otro del diseño de la interfaz de usuario y otro de la capa de persistencia de datos, es probable que la arquitectura del sistema separe claramente estos aspectos. Pero en este caso, también es probable que la arquitectura de datos esté fragmentada en diferentes silos de información. Cada equipo puede tener su propia base de datos o repositorio de contenido sin tener en cuenta al resto de actores implicados, lo que puede dificultar la interoperabilidad y la compartición de información entre los diferentes componentes del sistema. Esto puede llevar a problemas de redundancia de datos, falta de integridad y dificultades para obtener una vista completa y precisa de la información.

Por otro lado, si los equipos están organizados de manera más integrada y colaborativa, es más probable que el sistema resultante tenga una arquitectura más cohesionada y flexible. Los equipos multifuncionales, donde los miembros de diferentes disciplinas trabajan juntos, tienden a generar sistemas con una mejor integración entre los diferentes componentes. Esto se debe a que la comunicación fluida entre los equipos fomenta la comprensión compartida de la arquitectura general y promueve la colaboración para diseñar una estructura coherente. Esta multifuncionalidad que vemos por ejemplo en los equipos scrum.

La comunicación fluida entre los miembros del equipo permitirá la identificación de patrones y componentes reutilizables, lo que dará como resultado una arquitectura más coherente y modular. Por ejemplo, se pueden establecer patrones de diseño que promuevan la separación de preocupaciones y faciliten la escalabilidad y mantenibilidad del sistema.

Como ejemplo de la Ley de Conway podríamos tomar el desarrollo de una aplicación web. Si un equipo de desarrollo se divide en subequipos especializados en el front-end y en el back-end, lo más probable es que la arquitectura de la aplicación refleje esta división. La capa de presentación estará más enfocada en la interfaz de usuario y la experiencia del usuario, mientras que la capa de servidor se enfocará en el procesamiento de datos y la lógica empresarial sin tenerse en cuenta entre ellos. Esto puede resultar en una falta de cohesión y dificultades para realizar cambios o mejoras en el sistema debido a las dependencias existentes. En contraste, si el equipo trabaja de manera más colaborativa, con miembros que tienen conocimientos tanto en front-end como en back-end, es más probable que la arquitectura de la aplicación sea más modular, escalable y fácil de mantener.

Además, cuando los equipos de desarrollo trabajan de manera colaborativa y los datos se consideran como un recurso compartido (los datos, no la base de datos), es más probable que la arquitectura de datos sea coherente. Los equipos pueden, por ejemplo, adoptar un enfoque orientado a servicios, donde los diferentes componentes del sistema interactúan a través de interfaces bien definidas y comparten mecanismos adecuados para la sincronización y la consistencia de datos.

En un sistema de microservicios, cada servicio se encarga de una parte específica de la funcionalidad y tiene su propia base de datos. Esto refleja la estructura organizativa en la que equipos independientes son responsables de servicios individuales. Si bien esto puede ofrecer ventajas en términos de escalabilidad y autonomía de los equipos, también introduce desafíos en la gestión de la coherencia de datos y la integridad de la información.

Para superar estos desafíos, es necesario establecer prácticas de diseño de datos coherentes y utilizar mecanismos de sincronización y comunicación adecuados entre los servicios. Esto implica establecer contratos claros y definir interfaces de comunicación que permitan a los servicios intercambiar datos de manera confiable y consistente. Además, se pueden implementar técnicas como la replicación de datos y la implementación de patrones de consistencia para garantizar que la información se mantenga actualizada y coherente en todo el sistema.

Es importante tener en cuenta que la Ley de Conway no implica que la estructura de comunicación de la organización sea inmutable. De hecho, es beneficioso adaptar la estructura organizativa (incluso geográficamente) para facilitar la creación de una arquitectura del sistema más efectiva. Esto implica que los equipos de desarrollo y las estructuras organizativas deben estar en constante evolución y ajuste para alinear sus objetivos con los requerimientos del sistema. Esto por supuesto afecta también al diseño de los datos que debe ir de la mano de la arquitectura del sistema y puede ser necesario realizar ajustes en la arquitectura de datos para reflejar la nueva estructura organizativa y permitir una colaboración efectiva.

La Ley de Conway también tiene implicaciones en la comunicación y colaboración entre equipos distribuidos geográficamente. En estos casos, es fundamental establecer canales de comunicación efectivos y promover una cultura de colaboración remota. Si los equipos no están alineados y no se comunican de manera eficiente, es probable que la arquitectura del sistema se vea afectada negativamente. En cambio, cuando se establecen prácticas ágiles y se utilizan herramientas de colaboración adecuadas, los equipos distribuidos pueden superar los desafíos y lograr una arquitectura coherente y de alta calidad.

Bailando con Conway

Ya hemos visto como la ley de Conway establece que la arquitectura de un sistema refleja la estructura de comunicación de los equipos que lo construyen; pero ¿Cómo lidiar con ella? Deshacer completamente esta ley puede resultar difícil, ya que implica cambiar la estructura organizativa y las dinámicas de comunicación existentes en una organización, lo que impacta a la cultura de empresa. Sin embargo, es posible realizar ciertas maniobras o acciones que pueden mitigar los efectos negativos de la ley o permitir una adaptación más efectiva a las necesidades del sistema. Algunas estrategias que se pueden utilizar podrían ser:

• Reorganización de equipos: Es un punto clave la organización, la función y la estructura de los equipos. La idea es agrupar a los miembros del equipo según la arquitectura deseada del sistema, en lugar de basarse en funciones individuales y establecer los canales de comunicación precisos entre ellos. De esta manera, se fomenta la colaboración entre los miembros de diferentes disciplinas y se promueve una arquitectura más coherente. Por ejemplo, en lugar de tener equipos separados para el front-end y el back-end, se pueden formar equipos multidisciplinarios que incluyan desarrolladores, diseñadores y especialistas en bases de datos. Si queremos que dos módulos estén completamente desacoplados, lo mejor es desacoplar los equipos que trabajan en él, incluso física/geográficamente si es posible. Si queremos que dos módulos no compartan la misma base de datos, lo mejor es no compartir la misma persona con conocimientos de bases de datos entre los dos módulos.

• Comunicación y colaboración fluida: Promover una comunicación y colaboración fluida entre los miembros del equipo es esencial para deshacer la Ley de Conway. Esto implica establecer canales de comunicación efectivos, realizar reuniones regulares y fomentar una cultura de colaboración. La idea es que los equipos trabajen juntos de manera integrada, compartiendo conocimientos y tomando decisiones conjuntas sobre la arquitectura del sistema. Esto permitirá una comprensión compartida y una mayor coherencia en el diseño y desarrollo del sistema.
• Enfoque en la arquitectura: Es fundamental tener una visión clara de la arquitectura deseada del sistema desde el principio y comunicarla a todos los miembros del equipo. Esto incluye definir principios arquitectónicos, establecer patrones de diseño y documentar las decisiones clave. Al enfocarse en la arquitectura y establecer una dirección clara, se pueden mitigar los efectos negativos de la Ley de Conway y garantizar que la estructura del sistema refleje las necesidades del negocio y los requisitos técnicos.
• Prácticas ágiles y DevOps: La adopción de prácticas ágiles y DevOps puede ayudar a deshacer la Ley de Conway al fomentar la colaboración, la comunicación continua y la entrega rápida y frecuente de software. Estas metodologías promueven la formación de equipos multidisciplinarios, la automatización de procesos y la mejora continua. Al trabajar en ciclos cortos y permitir la retroalimentación constante, se pueden realizar ajustes en la arquitectura y en la estructura organizativa de manera más rápida y eficiente.
• Uso de servicios: Adoptar una arquitectura basada en servicios independientes puede ayudar a mitigar los efectos de la Ley de Conway al permitir una mayor modularidad y reutilización de componentes. Mediante la definición clara de interfaces y la separación de responsabilidades en servicios independientes, se puede reducir la dependencia de la estructura organizativa en la arquitectura del sistema. Esto permite que diferentes equipos trabajen en forma paralela y autónoma (y a veces hay que forzar que sea autónoma e independiente de verdad), colaborando a través de interfaces bien definidas. Con este enfoque, se facilita la integración de los diferentes componentes del sistema y se reduce la dependencia de la estructura organizativa en la arquitectura de software.

Es importante tener en cuenta que deshacer completamente la Ley de Conway puede ser un desafío, especialmente en organizaciones grandes y establecidas. Sin embargo, al implementar estas estrategias, es posible mitigar los efectos negativos y permitir una adaptación más efectiva de la arquitectura del sistema a las necesidades del negocio.

Del mismo modo, cabe tener en mente que deshacer la Ley de Conway requiere un cambio cultural y organizativo en toda la empresa. Requiere un compromiso y una voluntad de adaptar la forma en que los equipos se comunican, colaboran y se organizan. Además, debe haber un enfoque constante en la mejora continua y la alineación de la estructura organizativa con los objetivos y requisitos del sistema tecnológico.

Así que recuerda, puede que no sea Murphy, puede que sea Conway.