La arquitectura no es un rol, es una skill
Es ownership colectivo
Tradicionalmente, muchas organizaciones han depositado la responsabilidad arquitectónica en un rol específico: el “arquitecto de software”. Sin embargo, esta aproximación cada vez encaja menos en las metodologías de desarrollo de software modernas y ágiles. La arquitectura no debería ser un rol aislado, sino una habilidad transversal que todo equipo de desarrollo debe compartir y fomentar.
El peligro del rol del arquitecto
Delegar por completo las decisiones arquitectónicas a un rol separado puede traer problemas peligrosos. Se crea una brecha de conocimiento (y silos importantes) entre el “arquitecto” y el resto del equipo, donde los desarrolladores implementan, pero no entienden a fondo las razones detrás del diseño. Esto aumenta el riesgo de incoherencias arquitectónicas y dificultad para mantener y evolucionar el sistema.
Uno de los cuatro valores del manifiesto ágil es directamente “Colaboración del cliente por encima de la negociación de un contrato”. De la misma manera que los desarrolladores que no conocen el producto que desarrollan no pueden adaptar el software a las necesidades que intenta cubrir, si lo que hacemos es negociar un contrato de arquitectura con un tercero dentro de nuestro propio ciclo de desarrollo, nos estamos poniendo trabas a nosotros mismos.
Además, la arquitectura no es para nada una tarea que se realiza una vez y queda congelada. Cada línea de código, cada librería utilizada, cada patrón aplicado tiene implicaciones arquitectónicas. Es casi imposible que una persona pueda prever y controlar todas estas decisiones de antemano sin otras perspectivas.
Una skill en vez de un rol
Por eso la arquitectura debe ser vista como una habilidad esencial que todo desarrollador de software ha de trabajar y dominar. Un profundo entendimiento de principios, patrones y estilos arquitectónicos es clave para escribir código realmente mantenible, escalable y evolutivo en el largo plazo.
Entonces, ¿cómo fomentar este entendimiento y alineación arquitectónicos en todo el equipo? Las dinámicas y prácticas ágiles son la solución: code reviews, slicing técnicos, retrospectivas técnicas y pairing como práctica para elevar la calidad, todo puede ser una oportunidad para construir y reforzar una visión arquitectónica compartida.
Algunas dinámicas específicas que pueden ayudar a formar y fomentar la arquitectura en el equipo son:
- Planificación de tareas/historias: En esta fase, se deben discutir las implicaciones arquitectónicas de cada historia o tarea antes de ser asignada. Identificando los patrones, principios o restricciones arquitectónicas que se deberán tener en cuenta durante su implementación. Es recomendable rotar quién lidera estas discusiones para que todo el equipo participe activamente.
- Sesiones de refinamiento: Antes de comenzar a trabajar en funcionalidades complejas, realizar sesiones específicas de refinamiento de la arquitectura. En estas sesiones se exploran distintos enfoques y diseños de alto nivel utilizando pruebas de concepto. Todo el equipo debate y comenta hacia la mejor arquitectura antes de continuar con la implementación. Un buen formato puede ser el de las Bytesize Architecture Sessions de Andrea Magnorsky.
- Retrospectivas: De forma regular, se deben revisar cómo se están aplicando los principios y patrones arquitectónicos definidos para el proyecto. Identificando “deudas técnicas” y problemas arquitectónicos recurrentes. Estas retrospectivas permiten proponer acciones y mejoras en los procesos y diseños arquitectónicos.
- Formaciones y difusión: Organizar sesiones periódicas de formación en distintos aspectos de la arquitectura de software. Los propios miembros del equipo se turnan para preparar y dirigir estas sesiones formativas. Complementariamente, se comparten libros, tutoriales, videos y otros recursos sobre arquitectura. Finalmente, fomentar la participación en eventos, blogs, podcasts, etc. para compartir lecciones aprendidas.
Y cuando llegue el momento de tomar las grandes decisiones arquitectónicas que definirán el rumbo del sistema, deben tomarse de forma colectiva con la participación de todo el equipo. Reuniendo los conocimientos y experiencias de todos, logramos diseños más robustos y consistentes que los que lograría cualquier “arquitecto” individual.
La arquitectura es un tema de equipo
La arquitectura es demasiado importante como para dejarla en manos de roles aislados. Requiere un entendimiento profundo y un esfuerzo constante de todo el equipo de desarrollo. Sólo promoviendo la arquitectura como una habilidad transversal, y tomando decisiones de forma colaborativa, lograremos sistemas verdaderamente mantenibles y evolutivos. Es hora de dejar atrás los roles arquitectónicos aislados y avanzar hacia un nuevo paradigma de colaboración y ownership colectivo.