Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.
Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:
Arquitectura incremental
Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.
IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.
Validación continua
Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.
Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.
Demasiado importante para dejárselo a los Arquitectos
Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.
Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.
Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.
Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.
Continuando la discusión
Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:
- El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.
(Original en inglés, en el Architecture Journal; ó versión en español, actualizada en 2013) - Mi libro en progreso, Agile Software Architecture.
- Mi Agile Architecture Workshop, que doy varias veces al año en distintas ciudades de América Latina
(cuando hay fechas programadas aparecen a la derecha) - Otros libros relacionados de colegas varios:
- Building Evolutionary Architectures, de Rebecca Parsons, Neil Ford y Patrick Kua
- Lean Architecture, de James Coplien y Gertrud Bjørnvig
