Validar una arquitectura de software requiere método, métricas y disciplina. Aquí se explica cómo combinar ATAM, atributos de calidad y ciclos ágiles para tomar mejores decisiones, detectar tradeoffs como mantenibilidad vs eficiencia, y convertirlos en acciones medibles con umbrales y alertas.
¿Cómo se valida una arquitectura antes y durante el desarrollo?
La validación cambia según el contexto: en enfoques tradicionales se decide antes de desarrollar; en enfoques ágiles se revalida en cada iteración. Lo clave es que todas las decisiones se expliciten, se analicen y reciban feedback continuo de las partes interesadas.
¿Qué aporta ATAM al diseño?
¿Qué tradeoffs y riesgos se identifican?
¿Cómo medir atributos de calidad con métricas accionables?
ATAM es un proceso formal de análisis y no requiere el sistema en ejecución. Para comprobar en software real, se necesita medir: definir métricas, crear pruebas automatizadas y establecer umbrales que activen alertas y trabajo correctivo.
¿Qué elementos componen una medición efectiva?
¿Cómo aplicar disponibilidad y seguridad?
¿Cómo evoluciona la arquitectura en metodologías ágiles?
En ágil, la arquitectura emerge del equipo autogestionado y debe evolucionar junto con el sistema. Para lograrlo, se integra la arquitectura al ciclo: planeamiento, ejecución, medición y retroalimentación continua.
¿Qué prácticas integrar en el ciclo del sprint?
¿Tienes dudas sobre tus métricas o umbrales de calidad? Cuéntame tu contexto y comenta qué estás midiendo hoy.
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.
David Andrade Morales
Lo más importante es que podamos medir cada atributo de calidad con métrica que estén siendo monitoreadas por pruebas automatizadas y que, en cuanto no se esté cumpliendo adecuadamente un atributo de calidad podamos disparar una alerta con ayuda de umbrales que nos lleven a una revisión.
Abril Darynka Tapia Sosa
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
JAVIER STIVEN MURILLO
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.
Mauricio Costanzo
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 ):
Juan Carlos Ortiz Romero
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.
Christian Gómez
Para cada uno de nuestros atributos de calidad debemos tener una métrica que haga sentido.
Alejandro Picado Brenes
Metodología ATAM
Alejandro Picado Brenes
Medir la arquitectura del software
Alejandro Picado Brenes
Arquitectura en evolución
Oriana Morillo
Decisiones de diseño de arquitectura con metodologías ágiles
Juan Carlos Ortiz Romero
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.
Fabián Andrés Arismendi Ferrada
Sergio Andrés Ruiz
En la mayoría de las clases, se resalta la ventaja de tener test automatizados. Automatizar es el futuro :D
Wilmer Quilaguy
El tema esta en que los gerentes cambian la lógica del negocio y toca ajustar el software y las API's a lo que se necesite según el negocio
Claro esta que es cuando el software no es el fuerte de la empresa
Fabián Andrés Arismendi Ferrada
Fabián Andrés Arismendi Ferrada
john fredy quimbaya orozco
que es más conveniente para un aplicativo decidir antes la arquitectura o en el camino re evaluarla.
Sergio Andrés Ruiz
Cuando tienes claros tus objetivos, cuando el proyecto cualquiera que sea, este en marcha sera más fácil para ti o tu equipo solventar cualquier novedad que se presenta. Espero haber ayudado, saludos!
Pablo Hurtado
¿La forma de trabajo que se explica abajo es correcta? o ¿Siempre se debe plantear la arquitectura completa del sistema desde el inicio?
Basado en mi experiencia, cuando un se plantea un sistema, no piensa en la arquitectura completa del mismo. Básicamente uno determina si el sistema es web con PHP/MySQL, entonce voy a necesitar un servidor web Apache o Nginx con PHP en línea o local, un servidor para la base de datos el mismo web u otro (esto dependerán del presupuesto del proyecto.
Básicamente porque uno se está parando sobre los hombre del gigante. Sabiendo que eso es lo usual. Se sabe de antemano que es arquitectura cliente servidor y distribuida.
En la medida que el sistema crece uno va adaptando el desarrollo a los requisitos. Va implementando API, Microservicios, análisis de datos, etc. Eso sin mencionar los Frameworks utilizados.
Alex Camacho
ProfesorLa experiencia dice que eso es lo más usual, pero una buena planeación de la arquitectura contempla el crecimiento de la plataforma a desarrollar.
