Por sus consecuencias en el largo plazo, la arquitectura es, fue y será clave en el desarrollo de un software. El tema es que su implementación puede entrar a chocar con otros aspectos relevantes para el cliente que van desde aspectos tan abstractos como su idiosincrasia personal (o corporativa, en el caso de una empresa) hasta asuntos muy concretos, como la fecha de lanzamiento de una herramienta. En este contexto, la arquitectura evolutiva viene a ser una respuesta a estos dilemas que durante tanto tiempo han entrampado la relación entre desarrolladores, arquitectos y clientes.
Martin Fowler define la arquitectura de software como “las cosas que la gente percibe difíciles de cambiar”. Para Ralph Johnson, en tanto, son “las cosas importantes, cualquiera sea el significado de esta”.
Desde un punto de vista ágil, es relevante porque es la base donde se desarrollan los elementos del sistema y sus componentes. De ahí que una buena arquitectura sea la clave para el éxito en el largo plazo.
En el enfoque tradicional, la arquitectura trata de entender al detalle la implementación de un software y trata de predecir todos los problemas que se podrían enfrentar. Se piensan posibles soluciones y, desde esta reflexión, se realiza un plano sobre el que se implementará todo el proceso de desarrollo.
Hasta ahí, todo parece estar bien. ¿No?
La verdad es que no. El problema es que muchos supuestos en que se basa el arquitecto que utiliza el enfoque tradicional, simplemente, no se dan. Y es que este profesional no puede ser un adivino. No tiene una bola de cristal y solo cuenta con su conocimiento experto en un ambiente muy dinámico como el mundo de la computación y los negocios.
Entonces, el proyecto toma nuevos caminos. Se complejiza más que lo planeado. Empiezan a surgir necesidades que nunca fueron consideradas. Y empieza a surgir un verdadero tsunami de cambios difícil de surfear. El tiempo y esfuerzo del arquitecto se van a la basura. ¿El resultado? Algo así como el puente Cau-Cau, pero de la programación. Terminamos trabajando atrasados, con elementos que no se conectan y tratando de implementar planes B, C, D y E (si es que no llegamos a la Z, derechamente).
Como respuesta a ese contexto, aparece la arquitectura evolutiva que es, básicamente, la arquitectura ejecutada desde el punto de vista ágil.
Si en el enfoque tradicional la realidad sobrepasaba a la arquitectura en la gran mayoría de las veces provocando una distancia entre lo esperado y lo que se logra, el foco evolutivo permite que la arquitectura vaya adaptándose desde un principio a la realidad. Esto le permite ir dando soluciones paso a paso, con un crecimiento gradual.
El paradigma, entonces, cambia. Siempre habrá que rediseñar, pagar la deuda técnica y refactorizar. En vez de poner esfuerzo, inteligencia, tiempo y dinero en ser Nostradamusde la computación y predecir el futuro, deberemos centrarnos en que implementar cambios sea lo más económico posible para adaptarnos a los obstáculos que aparecen en el camino. Y el resultado final se ajustará mejor al desafío que debemos resolver.
Para el arquitecto de software, también hay un nuevo papel. De ser el que hacía cajitas y diseñaba flujos encerrado en su oficina, pasa a ser un profesional cercano a la unidad de desarrollo. Se preocupa de los dolores de su equipo y participa activamente del proceso creativo de una arquitectura en constante cambio: sabe cuáles son los problemas que aparecen y se retroalimenta de lo que emerge en el camino para redefinir, cambiar o mejorar sus decisiones.
La arquitectura de software pasa a ser una respuesta ante el cambio siguiendo un plan y no solo respuestas al cambio sin ningún tipo de planificación.
¿Qué facilita crear una arquitectura evolutiva? Experimentar, crear microservicios, planear feature toggle y tener una disposición proactiva por sobre la predictiva (aunque sin abandonar esta última). Constantemente, hay que estar haciendo pipelines de despliegue. La integración continua ya no se realiza una vez cada tres meses, sino que una práctica diaria. Y las migraciones de base de datos también se realizan con mayor frecuencia.
El desafío es que la arquitectura pase a ser un proceso vivo, no un documento muerto, como venía pasando hasta hoy.
