Quality Attributes

Pregunta de entrada

¿Qué resultados hacen adecuada una arquitectura para sus stakeholders y cómo podemos evaluarlos? Este MOC navega Software Architecture / Quality Attributes. Conecta preocupaciones, escenarios, prioridades, decisiones y evidencia.

La entrada no es una lista de tecnologías ni una obligación de optimizar todas las qualities. Primero recuperar qué resultado importa, para quién y en qué contexto. Si la conversación comienza con «rápido», «seguro» o «flexible», hay trabajo de precisión antes de comparar soluciones.

Cinco entradas de fundamento

Pregunta	Documento	Qué buscar
¿Qué es una Quality Attribute?	quality-attributes-overview	Contexto, funcionalidad, restricciones y significancia.
¿Cómo convierto una quality vaga en algo evaluable?	quality-attribute-scenarios	Estímulo, entorno, respuesta y evidencia aceptable.
¿Cómo priorizo los escenarios?	utility-trees	Importancia, dificultad y discusión entre stakeholders.
¿Qué decisiones pueden modificar una respuesta de calidad?	architectural-tactics	Hipótesis de diseño y límites de mecanismos concretos.
¿Cómo analizo consecuencias entre qualities?	quality-attribute-trade-offs	Efectos conjuntos, incertidumbre y condiciones de revisión.

Cada entrada tiene profundidad propia. El MOC organiza recorridos; no reemplaza sus modelos ni concentra un catálogo de tactics. Las prioridades orientan evaluación y las soluciones permanecen candidatas hasta contrastarlas con escenarios.

Cambio y entrega

Las siguientes agrupaciones reúnen nueve qualities para navegación. No son una taxonomía universal, un ranking ni dimensiones que puedan sumarse en un puntaje.

Quality Attribute	Pregunta principal para navegar
modifiability	¿Qué costo, riesgo y propagación tiene un cambio concreto?
evolvability	¿Puede la arquitectura continuar adaptándose a cambios significativos?
testability	¿Qué tan fácil es obtener evidencia confiable sobre comportamiento?
deployability	¿Cómo llega un cambio a ejecución de forma segura y con coordinación acotada?

Son preguntas de entrada, no definiciones exhaustivas. Los canonicals distinguen condiciones, respuestas, medidas y trade-offs. «Good architecture» solo tiene sentido respecto del contexto y prioridades que queremos satisfacer.

Operación, colaboración y entorno

Quality Attribute	Pregunta principal para navegar
operability	¿Qué tan eficazmente podemos entender, operar y controlar el sistema en producción?
interoperability	¿Pueden los participantes intercambiar y utilizar información o capacidades correctamente?
portability	¿Qué tan fácilmente puede el software moverse o adaptarse entre plataformas y entornos?

Los tres canonicals incluyen escenarios completos y límites de evaluación. Observability no demuestra intervención segura; connectivity no demuestra interpretación correcta; deployment en un entorno no demuestra traslado a otro.

Recursos y lifecycle

Quality Attribute	Pregunta principal para navegar
cost-efficiency	¿El servicio requerido justifica su costo económico y consumo de recursos?
sustainability	¿Podemos sostener el sistema con impacto de recursos y lifecycle justificado?

Costo unitario y proxies de recursos necesitan alcance, workload y evidencia. No sustituyen mediciones ambientales ni convierten estas dos qualities en prioridades universales.

Un ejemplo transversal: agregar un proveedor de pagos

La misma evolución admite cuatro preguntas diferentes:

• Modifiability: ¿qué áreas cambian y cuánto trabajo y riesgo se propagan?
• Evolvability: ¿podremos seguir reemplazando proveedores y protocolos durante los años siguientes sin rediseñar el conjunto?
• Testability: ¿podemos validar decisiones del nuevo proveedor con dependencias controladas, y complementar esa evidencia con pruebas representativas del adaptador?
• Deployability: ¿podemos llevar el cambio a ejecución sin coordinar capacidades ajenas y manteniendo compatibilidad y reversión real?

Una frontera estable puede ayudar a las primeras tres, con indirection y gestión contractual adicionales. No demuestra entrega independiente: un cambio localizado puede pertenecer a un artifact compartido. Volver a quality-attribute-trade-offs para comparar esas consecuencias.

Orders: tres preguntas sobre la misma capacidad

• Operability: ¿puede la guardia diagnosticar y mitigar una degradación de Orders en producción?
• Interoperability: ¿interpreta Orders correctamente estados de envío o pago de participantes externos?
• Portability: ¿puede Orders trasladarse a otra plataforma aprobada con cambios y esfuerzo acotados?

ports-and-adapters puede localizar contratos y dependencias para favorecer varias de esas respuestas, además de Testability y Modifiability. Agrega traducción, indirection y mantenimiento contractual; comprobar una frontera no prueba las otras qualities. Los escenarios y sus medidas viven en cada canonical.

Interacciones para contrastar

• Más redundancia puede proteger disponibilidad y aumentar costo y recursos; el balance depende del fallo y continuidad requeridos.
• Una integración nativa puede favorecer Operability y Cost Efficiency actuales y dificultar Portability si dispersa conocimiento del proveedor.
• Más telemetría puede favorecer diagnóstico y control y aumentar procesamiento, transferencia y retención; interesa evidencia útil con detalle justificado.

Son hipótesis situadas. Volver a Trade-offs y a las medidas de cada escenario; ninguna relación decide toda la arquitectura.

Ciclo de razonamiento con feedback

Business goals
    ↓
Requirements / ASRs
    ↓
Architectural drivers
    ↓
Quality attributes
    ↓
Scenarios + response measures
    ↓
Prioritization
    ↓
Tactics / decisions
    ↓
Trade-offs
    ↓
Architecture
    ↓
Evidence
    └──→ refine scenarios, drivers and decisions

El feedback es parte del razonamiento. El recorrido no prescribe waterfall ni exige completar cada caja antes de entregar. Un experimento puede cambiar un supuesto; una revisión puede revelar un driver omitido; una observación puede mostrar que la medida no refleja la necesidad.

architectural-drivers conecta objetivos e influencias relevantes. architectural-significance ayuda a decidir qué merece tratamiento arquitectónico. Volver a esas entradas cuando aparece una restricción nueva conserva el propósito de la evaluación.

Recorrido desde una expectativa vaga

Para «la búsqueda debe ser rápida», comenzar por Overview y después Scenarios. Identificar operación, carga, artifact y frontera de respuesta antes de elegir una optimización. El ejemplo de runtime muestra por qué concurrencia y percentil no describen por sí solos todo el entorno.

Seguir hacia Utility Trees si varias expectativas compiten por atención. Después entrar por Tactics y Trade-offs para contrastar efectos esperados y costos. No elegir caching solamente porque suele asociarse a performance.

Para «queremos flexibilidad», recorrer Scenarios desde un cambio concreto: otro proveedor, contrato o entorno. El ejemplo de development-time ayuda a acordar esfuerzo y localización. La pregunta puede revelar fronteras útiles o mostrar que todavía no existe una variación comprometida.

Recorrido para comparar arquitecturas

Si la discusión comienza con Microservices frente a Modular Monolith, recuperar primero architecture-profile y architecture-profiles. Sus paquetes de decisiones ofrecen contexto; este cluster ayuda a convertir ventajas potenciales en preguntas evaluables.

Ir a Scenarios para precisar deployment independiente, recuperación, cambios o costo operativo. Utility Trees ayuda a enfocar lo importante y difícil. Trade-offs muestra por qué una mejora situada no decide toda la comparación.

El resultado puede confirmar un profile, justificar una variante o mantener la arquitectura actual. No hay una escala de madurez que obligue a separar procesos. Tampoco una etiqueta seleccionada demuestra cumplimiento de los escenarios.

Recorrido desde un mecanismo existente

Si alguien propone Retry, Bulkhead o redundancia, entrar por Tactics para distinguir decisión enfocada, patrón y mecanismo de implementación. Después precisar qué respuesta debería cambiar y qué condiciones necesita esa hipótesis.

retry y bulkhead mantienen sus canonicals operacionales. Trade-offs conecta recuperación, presión adicional y contención con los costos del contexto. Aquí no se rediseñan sus políticas ni se cambia su metadata.

Para colaboraciones locales, pattern-selection conserva la comparación con alternativas pequeñas. Un patrón puede ayudar a satisfacer una necesidad, sin constituir prueba de calidad ni determinar el profile entero.

Recorrido para revisar evidencia

Para «las pruebas pasan, entonces la arquitectura cumple», empezar por Scenarios. Comparar entorno del escenario con entorno de prueba y revisar qué frontera observa la medida. Una comprobación puede ser útil y cubrir solo una parte de la necesidad.

Ir a Trade-offs para distinguir resultado observado, efecto esperado e incertidumbre. Sensitivity points y tradeoff points orientan atención cuando una propiedad resulta crítica para respuestas relevantes; no exigen crear documentos independientes para cada parámetro.

Si la evidencia contradice un supuesto, volver al driver o al escenario. Cambiar una expectativa requiere razones y stakeholders; modificar la medida solo para aprobar una solución pierde la trazabilidad del problema.

Áreas operacionales y alcance editorial

El Knowledge Map V0.3 ubica aquí el tratamiento arquitectónico de qualities: concern, driver, scenario, tactic, trade-off y evaluation. Security, Reliability y Performance pueden tener cuerpos detallados en otras áreas.

resilience-patterns, load-and-flow-control y failure-dynamics permiten continuar hacia mecanismos y comportamiento operacional. Este MOC conecta esos cuerpos cuando ayudan a investigar un escenario, sin copiar tuning, controles o procedimientos.

Una misma solución puede observarse desde varios marcos. La relación se documenta por intención y contexto, conservando identidad y ubicación canónica. No se crean carpetas ni reclasificaciones para cada mirada.

Cobertura y continuación

La rama Quality Attributes definida en Knowledge Map V0.3 queda materializada: cinco fundamentos y nueve qualities. Sus documentos mantienen status draft; completar cobertura no equivale a validar todos los escenarios. Los ejemplos incluyen runtime y development-time; las cifras y prioridades son ilustrativas. No representan mediciones del sitio ni requisitos universales.

Modifiability, Evolvability, Testability y Deployability amplían la cobertura con escenarios de cambio, adaptación, evidencia y entrega. Operability, Interoperability y Portability agregan escenarios de operación, colaboración y cambio de entorno. Cost Efficiency y Sustainability completan las nueve qualities con escenarios de servicio, recursos e impacto durante el lifecycle.

Para una primera lectura, seguir Overview → Scenarios → Utility Trees → Tactics → Trade-offs. Para una revisión situada, entrar por la pregunta y recorrer solo lo necesario. Las fuentes SEI, ATAM y Software Architecture in Practice están junto a las afirmaciones de los canonicals.

El siguiente avance debe responder a un hueco útil del Atlas y conservar feedback. La pregunta final del recorrido es qué compromiso podemos explicar y evaluar ahora, y qué evidencia o necesidad nos hará revisarlo.