¿Cómo se diseña la arquitectura de software en un proceso ágil?

Creo que es fructífero si distinguimos entre arquitectura y diseño.

Si definimos la arquitectura como aquellas decisiones de diseño que son difíciles o costosas de cambiar más adelante, la arquitectura de un sistema o las partes esenciales del mismo deben decidirse por adelantado. Estas decisiones entonces típicamente seguirían directamente de los requisitos no funcionales. En este sentido, la “arquitectura” no es realmente iterativa. Una vez que una arquitectura está en su lugar, solo puede jugar con ella tanto. Después de un tiempo, tal vez incluso años después, si te encuentras luchando contra la arquitectura o siendo limitado por la arquitectura, significa que los requisitos han cambiado.

La arquitectura debe admitir requisitos no funcionales como

• Flexibilidad: debe ser posible modificar o personalizar la lógica empresarial en el momento de la implementación.
• Escalabilidad: determina los principales componentes de terceros que conforman el sistema.
• Rendimiento: por ejemplo, el sistema debe admitir 10K tps con una latencia promedio de 20 ms

La persona o equipo responsable de la arquitectura conocerá (y debería) conocer muy bien el dominio para comprender los requisitos no funcionales que pueden o no estar bien articulados por los gerentes de producto.

El diseño, por otro lado, es muy iterativo . Los casos de uso cambian todo el tiempo y siguen apareciendo nuevos casos de uso, por lo que el diseño debe ser fluido. Siempre hay una compensación entre las entregas a corto plazo y la estabilidad a largo plazo, por lo que habrá períodos en los que la deuda técnica se acumulará a corto plazo y se pagará en versiones o iteraciones posteriores. Esto está muy en el dominio de Agile porque Agile, en esencia, se trata de ser una respuesta al cambio.

En mi humilde opinión, con más frecuencia de lo que pensamos, pero con menos frecuencia de lo que debería ser …

• Como otros mencionaron, el enfoque de la metodología Agile es el desarrollo (también conocido como la elaboración) de software, es decir, cómo se entrega un conjunto de funcionalidades de manera iterativa y hace que ese proceso sea lo más efectivo posible.
• Pero la arquitectura en sí misma debe ser ágil e iterativa, en sintonía con el desarrollo, incorporando los comentarios y las lecciones aprendidas a medida que se construye la arquitectura.
• Volviendo a la pregunta, la agilidad de la arquitectura generalmente se manifiesta en las fases de un producto, implícitamente en lugar de explícitamente. No hay “sprints arquitectónicos” per se.
• Tomemos un escenario canónico: una gruesa especificación de producto se arroja sobre la pared a la ingeniería; Engineering se da cuenta de que tardará entre 12 y 18 meses en entregarse y, por lo tanto, trabaja con el equipo del producto para dividir la especificación en entre 4 y 6 entregas trimestrales progresivas que los clientes pueden utilizar. Mientras uno mira el conjunto para diseñar el sistema, esencialmente la arquitectura se vuelve iterativa con 4/6 “sprints arquitectónicos”. Y cada fase pasa por el proceso ágil normal de sprints quincenales et al.
• El desafío aquí es la optimización. Empaquetar en múltiples entregas utilizables podría resultar en un poco de reelaboración y nueva arquitectura, incluso algunos andamios que no serían parte del sistema final, pero se requieren para mantener las fases intermedias.
• OTOH, de esta manera la arquitectura en sí sería fluida y absorbería la retroalimentación del sistema en ejecución en fases. Suposiciones de escala, tuberías, flujos de trabajo: todo sería iterativo.

Metáfora del sistema