Cómo validamos que estas estas decisiones de arquitectura y que este diseño que acabamos de hacer, tiene sentido?.
Dependiendo en el contexto en el que estemos, la validación de una decisión de arquitectura va a ser un proceso que vamos tener que hacer antes de entrar a desarrollo o bien un proceso que va a ser continuo y va a suceder cada vez que iteramos, así es en metodologías tradicionales en donde la decisión de arquitectura es muy importante antes de empezar a desarrollar o en metodologías ágiles en donde vamos estar reevaluando la arquitectura en cada iteración.
Metodología para evaluar la Arquitectura “ATAM” (Trade-offs de Arquitecturas)
Un ejemplo de una Metodología para Evaluar Arquitecturas en momento de diseño es “ATAM”. Este método se llama Método de análisis de “Trade-offs de Arquitectura” o por sus siglas en inglés ATAM.
En este método vemos como, tanto los objetivos de negocio, los atributos de calidad y los escenarios que planteamos para nuestra arquitectura se van a combinar con la arquitectura que definamos sus estrategias y sus decisiones.
Todo esto se va a analizar de tal manera que todos los stakeholders, todas las partes interesadas de esta arquitectura puedan tener una voz y un voto y decidir qué es importante y a que no se le daría importancia.
Este análisis se profundiza y se destila en diferentes decisiones. Ejemplos:
El entender los Trade off de darle importancia a la mantenibilidad por sobre la eficiencia.
Entender los puntos sensibles de tener una traza de auditoría porque podemos tener problemas legales.
El entender cuales de estos no son realmente riesgos. Por ejemplo, quizás al principio no tenemos un riesgo en nuestra disponibilidad ya que todavía no tenemos ningún contrato de nivel de servicio, mientras que hay riesgos que si también los vamos a entender qué van hacer un feedback y van a volver a entrar a este método como decisiones nuevas de arquitectura.
Estos riesgos quizás fueron atendidos con algunos atributos de calidad o quizás no y los encontramos al analizar todas estas decisiones.
Usar este framework implica el hacer un proceso formal de el análisis de la arquitectura y esto implica también que todavía no tenemos todavía el sistema en ejecución entonces todo esto sólo es un ejercicio intelectual y no es todavía medido en el software mismo.
Medición para nuestro Diseño de Software
Si queremos medir qué es lo que pasa en nuestro software, lo más importante que tenemos que hacer es tener una forma de métrica, es decir todas estas decisiones que estamos tomando como vamos a saber si el sistema las está implementando o no y cómo vamos a saber que esa implementación realmente tuvo sentido?
Entonces para cada uno de los atributos de calidad deberíamos encontrar una métrica que tenga sentido en nuestra aplicación, luego tener una prueba automatizada para esa métrica es decir alguna forma de obtener en tiempo real la información de cómo está nuestro sistema con respecto a esa métrica y luego umbrales configurados de tolerancia o de cuán bien o mal estamos respecto a eso.
Por ejemplo en el caso de la disponibilidad si podemos medir a través de un ping o a través de un Health check nuestra disponibilidad, tenemos que tener esa métrica visible y saber cuál es el porcentaje o el umbral que queremos poner para decir que tenemos una disponibilidad acorde a nuestra arquitectura. Si dijéramos que la disponibilidad es del 95% y luego en el período de un mes tenemos más del 5% de sistema fuera de servicio, entonces ese umbral debería disparar una alerta y poder hacernos trabajar nuevamente sobre ese atributo de calidad. Lo mismo podría pasar con la seguridad si tenemos ataques, lo mismo podría pasar con cualquier otro atributo de calidad y es súper importante recordar cómo medirlos para poder accionar sobre ellos
Arquitectura en Evolución
La arquitectura en evolución es un desafío especialmente para las metodologías ágiles ya que en una metodología más tradicional se asume que la arquitectura es lo suficientemente detallada como para funcionar en todo la especificación del desarrollo que se va hacer sin embargo la metodología ágil plantea que la arquitectura se va a ir construyendo, va a emerger del equipo autogestionado.
¿Entonces cómo hacemos para que emerja la arquitectura correcta y a su vez que a medida que el sistema evoluciona la arquitectura, evolucione junto al sistema?
Como vimos en fundamentos de arquitectura es importante incluir la arquitectura en nuestro ciclo, entonces cómo es que la incluimos? Por un lado en el planeamiento del Sprint tenemos que hablar de arquitectura, tenemos que hablar de estas métricas que tenemos, tenemos que ser conscientes de estos umbrales y de cuán bien o mal estamos en todos los atributos de calidad que estamos priorizando.
Luego cuando priorizamos el backlog y decidimos en que vamos a trabajar vamos a priorizar todas esas áreas de arquitectura, en donde encontramos que deberíamos trabajar nuevamente, esto va a requerir esfuerzo para implementarlo.
Una vez que se despliegue esta nueva implementación, vamos a través de retrospectivas dondé fueron los puntos en donde no pudimos trabajar correctamente, es decir donde tenemos todavía problemas en la mantenibilidad o tenemos problemas de seguridad que todavía no podemos cubrir o detectamos algún problema en nuestra eficiencia de ejecución qué tenemos que volver a priorizar.
Este feedback se da no solamente por encontrar nosotros proactivamente problemas, sino de nuevo con métricas y con alertas programadas en el sistema.
Los test automatizados también pueden ser buenas alertas incorporarlas en nuestro pipeline de despliegue para saber si alguna de estas métricas no sólamente en ejecución sino métricas del código mismo están siendo comprometidas y luego este feedback se cierra cuando volvemos a planear el sprint y reevaluamos nuestras decisiones de arquitectura .
Así Cada vez que avanzamos encontramos los puntos en donde nuestra nuestra arquitectura ya no está cumpliendo con las expectativas que teníamos y volvemos a pensar qué es lo que hay que hacer para mejorarla.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?