Validar las decisiones de diseño: Arquitectura en evolución

Evaluating Software Architectur para ver algo más de ATAM

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.

Validar decisiones.
Dependiendo el contexto, la validación de arquitectura, es un proceso que tenemos que hacer antes de entrar en desarrollo o bien como un proceso continuo cada vez que desarrollamos.
En metodologías tradicionales, el diseño de la arquitectura es importante antes de empezar a desarrollar
En metodologías ágiles se revalúa la arquitectura en cada iteración.

Método ATAM (Método de análisis de Trade-off) ->
Los objetivos de negocio, atributos de calidad y los escenarios planteados se combinan con la arquitectura que definamos, sus estrategias y decisiones. Se analizan para que las partes interesadas tengan voz y voto y decidir sobre la misma

Sprint Sprint es el nombre que va a recibir cada uno de los ciclos o iteraciones que vamos a tener dentro de dentro de un proyecto Scrum.

Nos van a permitir tener un ritmo de trabajo con un tiempo prefijado, siendo la duración habitual de un Sprint unas cuatro semanas, aunque lo que la metodología dice es que debería estar entre dos semanas y un máximo de dos meses.

En cada Sprint o cada ciclo de trabajo lo que vamos a conseguir es lo que se denomina un entregable o incremento del producto, que aporte valor al cliente.

La idea es que cuando tenemos un proyecto bastante largo, por ejemplo un proyecto de 12 meses, vamos a poder dividir ese proyecto en doce Sprints de un mes cada uno. En cada uno de esos Sprints vamos a ir consiguiendo un producto, que siempre, y esto es muy importante, sea un producto que esté funcionando.

Backlog El Backlog es una lista ordenada de todo el trabajo pendiente.

Dependiendo del método ágil utilizado, los elementos incluidos en el Backlog se denominan ítems, historias de usuario, unidades de trabajo, etc.

Método de análisis de arquitectura: ATAM (Método de análisis de trade): sirve para evaluar las desiciones de arquitectura en momento de diseño. Aquí se combinan los objetivos de negocios, los atributos de calidad y los escenarios, con el fin de poder evaluar entre todas las partes (stakeholders ):

• Cuales son los riesgos
• Poder definir que atributos de calidad son más prioritarios
• Que estrategía de arquitectura aplica mejor

Para cada uno de nuestros atributos de calidad debemos tener una métrica que haga sentido.

Metodología ATAM

Medir la arquitectura del software

Arquitectura en evolución

Decisiones de diseño de arquitectura con metodologías ágiles

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.

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.

)

En la mayoría de las clases, se resalta la ventaja de tener test automatizados. Automatizar es el futuro 😄

que es más conveniente para un aplicativo decidir antes la arquitectura o en el camino re evaluarla.