Arquitectura Software y Metodologías Ágiles. ¿Realmente son compatibles?

En este artículo discutiremos sobre cómo Arquitectura Software y Metodologías Ágiles pueden trabajar en conjunto para sacar lo mejor de ambos.

¿Qué es Arquitectura Software?

Existen bastantes definiciones sobre qué es Arquitectura Software. A mí, particularmente, me gusta esta:

«Grupo de principios y restricciones sobre cómo las soluciones software deben ser construidas dentro de un ámbito dado (normalmente una empresa o subconjunto de ella)».

Algunos ejemplos de principios y restricciones podrían ser:

• Solo se pueden utilizar lenguajes de programación basados en JVM
• La comunicación síncrona entre componentes se realizará mediante sus correspondientes APIs REST. Cada API estará documentada en Swagger.
• La comunicación asíncrona se realizará utilizando el bróker de mensajería corporativo (ej: RabbitMQ).
• Las trazas (logs, auditoría) que generen los módulos serán centralizados en ELK. Cada mensaje debe tener un formato específico.

Además de este grupo de principios y restricciones, todo software contiene de manera inherente unos atributos de calidad (requisitos no funcionales) que deben ser tenidos en cuenta. Por ejemplo:

• Alta disponibilidad.
• Seguridad.
• Rendimiento.
• Modificabilidad.
• Testeabilidad.
• Etc.

El grado de aplicación de cada uno de estos atributos debe ser proporcional a la solución que queremos construir. No será lo mismo construir una pequeña aplicación web que usarán dos usuarios para consulta de información no sensible dentro de una LAN que crear un sistema que gestione historia clínica de pacientes (SEGURIDAD), o que un software para el control del tráfico ferroviario (RENDIMIENTO, DISPONIBILIDAD, ROBUSTEZ…). Evidentemente el grado de aplicación de los atributos de calidad diferirá sustancialmente entre cada solución.

Por tanto, “arquitecturar” una solución será aplicar dichos principios, restricciones, requisitos funcionales y no funcionales para construir una solución software: sus componentes, interfaces, relaciones, estructuras, etc…

Martin Fowler describe Arquitectura Software como las decisiones que son difíciles de cambiar. Una descripción tan simple como brillante.

¿Por qué Arquitectura Software?

Conforme el número de soluciones software va creciendo, se empieza a requerir un cierto grado de homogeneización. En la mayoría de los casos, esto tiene implicaciones económicas (ahorro de costes de manera directa o indirecta).

Veamos esto mejor con un ejemplo volviendo al punto anterior donde decíamos que en una compañía (o parte de ella) la Arquitectura de referencia requería que solo se pudiesen utilizar lenguajes de programación basados en JVM. Visto de este modo, cualquiera podría pensar:

• ¿Qué lleva a un grupo de arquitectos (o quien sea) a tomar esta decisión?
• ¿Por qué restringir el desarrollo de software a un único lenguaje (o grupo de ellos)?

Más aún, si además dijimos que la comunicación entre componentes sería a través de APIs REST, el lenguaje en sí no debería ser una barrera en este sentido ya que el propio API nos abstraerá del lenguaje en el que esté escrito el servicio: principio de alta cohesión y bajo acoplamiento.

Las razones, como comentamos anteriormente, suelen tener connotaciones económicas.

• ¿Qué sucederá si toda nuestra plataforma está escrita utilizando siete lenguajes diferentes?
• ¿Qué habilidades deberán tener los desarrolladores que incorporemos para trabajar en ella?
• ¿Qué sucederá si queremos contratar un soporte empresarial para cada lenguaje?
• ¿Cómo mantenemos todo esto en producción: monitorización, actualizaciones, infraestructura, etc.?
• ¿Qué sucederá si queremos proporcionar un framework corporativo para desarrollar los diferentes componentes? ¿Tendremos que escribirlo y mantenerlo en siete lenguajes diferentes?

Estos son solo algunos de los problemas que podríamos tener sin dicha restricción. Por tanto, lo que en un principio podría considerarse como una limitación (usar un solo lenguaje de programación), puede convertirse en un modo de ahorro de costes en un futuro. Por supuesto, este tipo de restricciones también tienen sus inconvenientes que deben ser analizados para ver cómo encajan con la cultura de la compañía.

Por tanto, podremos decir que nuestra Arquitectura Software es útil si ayuda a mantener los principios y restricciones en los que se basa al mismo tiempo que sienta las bases para desarrollar las soluciones que demanda negocio.

¿Qué es Agile?

La esencia de Agile gira en torno a la entrega rápida y constante de valor y la aceptación del cambio. Es mejora continua. Es entregar una solución con un alto grado de calidad en un periodo corto de tiempo. Es eliminar el desperdicio.

En Agile existen diferentes metodologías como Scrum, que se basa en equipos autónomos y auto-organizados. Scrum se apoya en un proceso iterativo (repetido en pequeños ciclos) e incremental (entrega nueva funcionalidad).

Ahora bien, ¿cómo encajan estos equipos autónomos y que entregan valor de manera rápida con una serie de principios y restricciones a la hora de construir software? ¿No retrasará el proceso de “arquitecturar” la solución esta entrega continua de valor? ¿Cuánto tiempo debemos invertir en “arquitecturar” en cada iteración?

Sin duda no existe una respuesta sencilla a esta última pregunta. Probablemente lo más sensato sea decir: lo justo. La mínima cantidad de arquitectura para alcanzar estos principios, visión y restricciones para construir la solución. Ahora bien, ¿cuánto es “lo justo”?

En este punto deberíamos valorar la propia naturaleza del producto/proyecto en el que nos encontramos inmersos. Si es un proyecto muy caótico con múltiples cambios drásticos, probablemente la cantidad de “Arquitectura” que debemos aplicar en el diseño por adelantado deberá ser menor que en otro tipo de proyectos más estables.

Como regla general, podría ser interesante hacer algo de diseño por adelantado antes del inicio del proyecto (¿Sprint 0?) y otra pequeña cantidad antes de cada iteración. Además, podríamos incluir una revisión de la Arquitectura como parte del Definition of Done (DoD) de cada historia de usuario. Esto último debe ser tenido en cuenta a la hora de planificar el Sprint. Podría ser también muy interesante que, al menos, un miembro del equipo fuese responsable de asegurar que la Arquitectura y el desarrollo del producto se encuentran alineados.

Si simplemente esperamos que la Arquitectura Software emerja, podemos acabar en un ciclo de “Sprints de refactorización” debido a la falta de diseño por adelantado, especialmente en proyectos grandes y complejos. Como decía Martin Fowler, la Arquitectura Software es un grupo de decisiones relevantes que son difíciles de cambiar. No tener en cuenta estas decisiones durante el desarrollo del producto puede llevar a una enorme deuda técnica y no es esto, precisamente, lo que promueven las metodologías ágiles.

¿Qué cantidad de Arquitectura Software necesitamos?

Idealmente, la mínima cantidad para cumplir con los principios y restricciones, requisitos funcionales y no funcionales además de proporcionar las bases para construir la solución.

Veamos diferentes escenarios. Si vamos a construir una solución para la recolección y consulta de datos de historia clínica de pacientes (información muy sensible), probablemente la Arquitectura Software estará muy enfocada a diferentes políticas de acceso a datos, ofuscación, certificados, trazabilidad, protocolos, etc.

Por otro lado, si vamos a rehacer un sistema debido a que se ha vuelto tecnológicamente obsoleto además de inmantenible, seguramente aparecerán muchos principios relativos a la modularidad, testeabilidad, nuevo stack tecnológico, etc.

Por último, si vamos a trabajar en un producto nuevo que, de manera experimental, trata de enfocarse en un nuevo nicho de mercado, probablemente con una arquitectura muy ligera bastaría debido a la gran incertidumbre que rodea al producto.

Muchas empresas tienen un framework corporativo que implementa o ayuda a implementar muchos de los principios de la Arquitectura de referencia. Usar dicho framework de manera apropiada puede ser muy valioso para el equipo ágil. Para ello, debemos asegurarnos de que, al menos, uno de los miembros del equipo lo conozca profundamente para asegurar un uso óptimo y ayudar a mejorarlo.

Arquitectura Software y Metodologías Ágiles en empresas grandes

Alguien podría preguntarse, ¿cómo pueden los equipos autónomos y auto-organizados dar lo mejor de sí al mismo modo que se benefician de la Arquitectura Software? ¿Cómo podemos hacer que la Arquitectura continúe evolucionando sin ralentizar el ritmo de los equipos?

Vayamos por partes. Por un lado, cada uno de estos equipos suele estar enfocado en un área de negocio específica dentro de una organización, lo que es genial. Sin embargo, es muy difícil que un equipo que trabaja de esta forma se pueda anticipar a problemas que puedan aparecer fuera del contexto (dominio de negocio) en el que se mueve.

Probablemente, el equipo no tenga un conocimiento y visión global de todo el sistema, lo que puede derivar en la construcción de soluciones redundantes o heterogéneas dentro del contexto global de la compañía: probablemente otros equipos ya se habrán enfrentado a un problema parecido. Esto hace que sea muy deseable que algún componente del equipo tenga un conocimiento de la Arquitectura de referencia a alto nivel.

Por otro lado, la mejora y optimización de la Arquitectura de referencia, al igual que el propio proceso de innovación, no debería ser propiedad de un grupo cerrado de individuos, sino que debería poder emerger de manera natural desde cualquiera de los equipos de la organización. Lógicamente, cada nueva iniciativa en este sentido tendría que ser gestionada por un equipo destinado a ello.

En este sentido, existe un concepto muy interesante dentro del framework SAFe que se llama Agile Architecture y que trata de sacar lo mejor de los dos enfoques. Parte de una Arquitectura diseñada por adelantado y que se va alimentando de los diseños que emergen de los equipos autónomos.

De este modo obtenemos dos grandes beneficios:

• Contar con una Arquitectura de referencia que nos ayude a construir nuestras soluciones.
• Permitir a los equipos contar con un cierto grado de innovación al mismo tiempo que alimentan la Arquitectura, permitiendo a otros equipos beneficiarse de ello.

¿Cómo podemos alinear Arquitectura Software y Equipos Ágiles?

Cuando nos referimos a equipos ágiles y autónomos, también nos estamos refiriendo a equipos multidisciplinares. Dichos equipos pueden estar compuestos por roles tales como: devops, scrum master, desarrollador back, desarrollador front, product owner, líder técnico, etc… Y es justo aquí donde el líder técnico jugará un papel fundamental.

El líder técnico (en algunos casos esta labor la desempeña el Arquitecto Software) será el responsable de hacer entender la Arquitectura de referencia (visión y roadmap) con el resto del equipo. Esta persona estará a cargo de la resolución de cuestiones técnicas, gestionar los atributos de calidad, manejar los requisitos que requieran un cierto grado de innovación y sincronizar los que apliquen en la Arquitectura de referencia.

Por supuesto, el Arquitecto no es una autoridad dentro del equipo sino un mentor que ayuda al equipo ágil a mejorar su efectividad trabajando codo a codo con ellos. Por otro lado, este rol debe tener un profundo conocimiento de la Arquitectura de referencia al mismo modo que se mantiene en permanente contacto con el resto de Arquitectos de otros equipos (¿Chapter de Arquitectura Software?).

Si queremos contar con equipos autónomos y que esto no acabe desencadenando en el caos, la comunicación y el alineamiento de principios deberán ser piezas clave. Es imposible conseguir coherencia y consistencia sin un cierto grado de control.

Enlaces relacionados

• Artículo original (en inglés): Software Architecture and Agile. Are they both really compatible?
• Libro: Software Architecture in Practice
• Libro: Software Architecture for Developers
• Libro: Scaled Agile Framework (SAFe)

Conclusiones

Las Métodologías Ágiles y la Arquitectura Software no son conceptos incompatibles sino totalmente complementarios. La Arquitectura no debería ser considerada como un factor limitante sobre los equipos sino como un impulsor dentro de la propia cadena de entrega de valor.