1. Presentación del módulo: del deseo del negocio al atributo de calidad

Descripción

Al terminar esta lección vas a entender de dónde salen, de verdad, las decisiones de arquitectura —y la respuesta te va a sorprender por lo poco técnica que es—. No salen del gusto del arquitecto ni de la última moda de tecnología. Salen del negocio: de gente que quiere cosas y las dice en su idioma. Un VP de producto dice "queremos crecer 10x este año". Un director de finanzas dice "no podemos triplicar la factura de infraestructura". Un fundador dice "no nos podemos caer en Black Friday, es el día que hace el año". Eso es el material bruto del que se hace toda arquitectura, y viene en un idioma que no es el de la arquitectura: son deseos, metas, miedos —no requisitos técnicos—. El trabajo del arquitecto, antes de dibujar una sola caja, es la traducción: convertir esas metas de negocio en atributos de calidad, los que en inglés se llaman los -ilities (scalability, availability, security, performance, cost). "Crecer 10x" se traduce a scalability. "No caernos en Black Friday" se traduce a availability. "Los datos de pago no se pueden filtrar" se traduce a security. Esa traducción es la materia prima de este módulo, y es la habilidad que separa a un arquitecto de un técnico que espera que le dicten qué construir.

Esto importa porque es donde el oficio del arquitecto toca al negocio, y donde más gente competente fracasa sin enterarse. Hay dos formas de arruinar esta traducción. La primera es no hacerla: tomar el deseo del stakeholder al pie de la letra —"me pidió un caché, le pongo un caché"— y construir la solución que el otro imaginó en vez del problema que de verdad tenía; terminas resolviendo lo que no era, con elegancia técnica, y nadie entiende por qué el negocio sigue insatisfecho. La segunda es hacer la traducción pero solo en una dirección: derivas los atributos, diseñas, y cuando el VP pregunta "¿por qué tan caro?" le contestas "porque necesitamos 99.99% de disponibilidad con replicación multi-región", y lo pierdes —porque el VP no habla en nueves, habla en dólares, y acabas de responderle en un idioma que no entiende—. La habilidad de este módulo va en las dos direcciones: traducir el negocio a atributos (para poder diseñar) y traducir los trade-offs de vuelta al negocio (para poder acordar). Sin la primera no tienes con qué diseñar; sin la segunda no tienes permiso para construir lo que diseñaste.

Conexión con el módulo: esta lección es el mapa, no el territorio. Aquí no traduces nada a fondo todavía; entiendes por qué las seis lecciones que siguen van en el orden que van. Primero la traducción misma: la lección 2 toma el conjunto de metas de Mercado y ejecuta el mapeo a atributos priorizados, con sus conflictos. Luego el problema de que un atributo, recién traducido, sigue siendo vago: la lección 3 lo vuelve medible con el quality attribute scenario de seis partes. Después, cómo separar lo que importa de lo que no: la lección 4 filtra los architecturally-significant requirements —la señal— del ruido. Enseguida, lo que nadie dijo pero todos esperan: la lección 5 descubre los atributos implícitos. Y las dos últimas son la conversación: la lección 6 enseña a hablar el idioma del stakeholder (traducir el trade-off a dinero) y la lección 7 a decir no —o "sí, pero cuesta esto"—. La lección 8, el proyecto, te pone a derivar los atributos de un lanzamiento nuevo con tus manos.

El arquitecto de casas que traduce "una casa para envejecer aquí"

Piénsalo con un oficio que se parece más al nuestro de lo que creemos: el arquitecto de casas. Llega una pareja mayor y le dice: "queremos una casa para envejecer aquí, para pasar los últimos treinta años de nuestra vida." Eso es una meta, un deseo, dicho en el idioma de la vida —no en el idioma de los planos—. Un mal arquitecto la toma literal y les pregunta "¿cuántas recámaras, de qué color las paredes?", como si fuera cualquier casa. Un buen arquitecto oye algo completamente distinto. Oye una lista de requisitos concretos que la pareja no dijo pero que su meta exige: sin escaleras (o con una recámara en planta baja), porque en veinte años las rodillas no suben; puertas anchas, por si algún día hay una silla de ruedas; el baño principal en planta baja y con barras de apoyo; pisos antiderrapantes; buena iluminación para ojos que ven menos; quizás un cuarto extra en la planta baja por si necesitan a alguien que los cuide. Nada de eso lo pidió la pareja. Todo eso lo derivó el arquitecto de la meta "envejecer aquí".

Fíjate en lo que hizo el buen arquitecto, porque es exactamente nuestro oficio. No tomó la solución que el cliente podría haber imaginado; tomó el problema que el cliente tenía. Si la pareja hubiera dicho "queremos una escalera de mármol preciosa" y el arquitecto la hubiera puesto sin más, habría construido la solución equivocada para el problema real —una casa hermosa que a los ochenta años se vuelve una trampa—. El arquitecto tradujo el deseo ("envejecer aquí") a atributos de la casa (accesibilidad, seguridad, comodidad de largo plazo) y de ahí a requisitos concretos (sin escaleras, puertas anchas, baño abajo). Y esa traducción es la parte difícil y valiosa: cualquiera dibuja una casa; el arquitecto sabe qué casa dibujar porque entendió qué necesita de verdad quien la va a vivir.

Es lo mismo que el mesero que sabe su oficio. Un comensal dice "quiero algo ligero y sin picante". Eso no es un platillo, es un deseo. El buen mesero lo traduce: descarta los guisos pesados, descarta lo que lleva chile, y recomienda —digamos— un pescado a la plancha con verduras. Tradujo "ligero y sin picante" (el idioma del comensal) a un platillo del menú (el idioma de la cocina). Si en cambio le hubiera preguntado "¿quiere el salmón teriyaki o los tacos al pastor?", habría fallado: le da opciones sin entender que "sin picante" ya descartó el pastor y "ligero" ya descartó lo pesado. El arquitecto de software hace este mismo trabajo, todos los días: alguien del negocio dice "algo ligero y sin picante" —"queremos crecer sin caernos y sin gastar de más"— y el arquitecto lo traduce a un platillo concreto: estos atributos, en este nivel, con estos trade-offs. Esta lección, y todo el módulo, es aprender a ser ese arquitecto de casas y ese mesero: el que oye un deseo y sabe qué construir.

El caso: Mercado y su estrategia de 18 meses

Bajemos de la casa al software. A lo largo de esta guía acompañamos a Mercado, el marketplace del ecosistema. En los módulos anteriores lo vimos como un sistema y como una organización de cinco squads. Ahora lo vemos desde arriba: desde el negocio que le pide cosas. El liderazgo de Mercado acaba de cerrar su estrategia para los próximos 18 meses, y se la entregó al arquitecto como una lista de metas —en el idioma del negocio, no en el nuestro—:

• Abrir Mercado a vendedores externos vía API. La apuesta insignia: dejar que terceros vendan en la plataforma, integrándose por una API pública. De ser una tienda, Mercado pasa a ser un marketplace de verdad.
• Crecer 10x en usuarios y transacciones en 18 meses.
• No caernos durante Black Friday, el día que concentra buena parte de la facturación del año.
• Blindar los datos de pago: que no se filtren nunca, pase lo que pase.
• No triplicar la factura de infraestructura al crecer —el CFO fue explícito—.
• Un checkout que se sienta instantáneo, porque cada segundo de espera cuesta conversión.

Ninguna de esas frases es un requisito de arquitectura. Todas son deseos legítimos del negocio, y todas están en un idioma que no le dice al arquitecto qué construir —le dice qué quiere lograr el negocio—. El trabajo del arquitecto de Mercado, y el de todo este módulo, es tomar esa lista de deseos y volverla una lista de atributos de calidad priorizados con la que sí se pueda diseñar. Antes de medir nada a fondo, veamos la traducción en su forma más pura: cómo una sola de esas frases se abre en varios atributos. Fíjate bien, porque en este pedacito de código está condensado el módulo entero.

# Teaser: una sola meta de negocio no es UN requisito -- se abre en varios
# atributos de calidad, cada uno con un nivel exigido distinto.

goal = "Abrir Mercado a vendedores externos via API"

# Lo que esa sola frase EXIGE, sin que nadie lo haya dicho todavia:
derived = [
    ("scalability",  "el catalogo y los vendedores crecen 10-100x"),
    ("security",     "cada vendedor ve SOLO sus datos (aislamiento multi-tenant)"),
    ("availability", "si Mercado cae, caen las tiendas de miles de vendedores"),
    ("usability",    "la API debe ser tan clara que un tercero la integre sin ayuda"),
]

print("Meta de negocio (lo que dijo el VP):")
print(f'  "{goal}"')
print()
print("Atributos de calidad que esa sola meta EXIGE (lo que oye el arquitecto):")
for attr, why in derived:
    print(f"  - {attr:<13} porque {why}")
print()
print(f"Una (1) frase de negocio  ->  {len(derived)} atributos de calidad a priorizar.")

Qué esperar. Al correrlo:

Meta de negocio (lo que dijo el VP):
  "Abrir Mercado a vendedores externos via API"

Atributos de calidad que esa sola meta EXIGE (lo que oye el arquitecto):
  - scalability   porque el catalogo y los vendedores crecen 10-100x
  - security      porque cada vendedor ve SOLO sus datos (aislamiento multi-tenant)
  - availability  porque si Mercado cae, caen las tiendas de miles de vendedores
  - usability     porque la API debe ser tan clara que un tercero la integre sin ayuda

Una (1) frase de negocio  ->  4 atributos de calidad a priorizar.

Detente en la última línea, porque es toda la tesis en una frase. Una sola meta de negocio se abre en cuatro atributos de calidad —y ninguno de los cuatro lo pidió el VP—. El VP dijo "abrir a vendedores externos"; no dijo "scalability", no dijo "aislamiento multi-tenant", no dijo "availability". Todo eso lo derivó el arquitecto de la frase, igual que el arquitecto de casas derivó "sin escaleras" de "envejecer aquí". Y fíjate que no es una traducción uno-a-uno, como cambiar una palabra por su sinónimo: es una expansión. Una meta de negocio esconde varios atributos porque lograrla exige varias cosas a la vez —para abrir a vendedores externos el sistema tiene que escalar, tiene que aislar los datos de cada uno, tiene que estar arriba porque de él dependen miles de tiendas, y tiene que ofrecer una API que un extraño pueda usar—. Esa expansión de uno a varios es el primer trabajo del arquitecto, y es invisible para quien no lo hace: el que toma "abrir a vendedores externos" como un solo requisito técnico se va a estrellar contra los tres atributos que no vio venir.

Ahora fíjate en algo que este teaser ya insinúa y que va a ser el hilo del módulo: los cuatro atributos no son igual de importantes, y algunos van a chocar entre sí. El aislamiento (security) para que un vendedor no vea los datos de otro puede pelearse con la velocidad (performance) de la API; escalar a 100x (scalability) se pelea con no triplicar la factura (cost). Traducir la meta a atributos es apenas el primer paso; el segundo es priorizarlos (¿cuál va primero?) y el tercero es detectar dónde se pelean (¿qué trade-off tendré que negociar?). Eso es exactamente lo que la lección 2 ejecuta sobre las seis metas completas. Por ahora, quédate con la intuición: cada deseo del negocio esconde varios atributos, y el oficio empieza por sacarlos a la luz.

El mapa de las seis lecciones

Las seis lecciones que siguen van en este orden por una razón: cada una arma la pieza que la siguiente necesita.

Lección	Qué te da	Por qué va aquí
2	La traducción ejecutada de metas a atributos priorizados	Es el corazón del módulo: no puedes hacer nada sin convertir los deseos en atributos con un orden
3	El quality attribute scenario que vuelve medible lo vago	Un atributo recién traducido sigue siendo un deseo hasta que tiene una medida con la que probarlo
4	El filtro de ASRs: la señal contra el ruido	No todo requisito moldea la arquitectura; hay que saber en cuáles gastar la energía
5	Los atributos implícitos que nadie pidió	El contrato tácito del dominio; lo que estalla si solo entregas lo pedido
6	Cómo hablar el idioma del stakeholder (el trade-off en dinero)	Traducir de vuelta al negocio es la mitad del oficio; sin ella no hay acuerdo
7	Cómo decir no —o "sí, pero cuesta esto"—	Prometer todo al máximo es imposible; el arquitecto administra un presupuesto de calidad

El arco es claro: primero aprendes a traducir y priorizar (2), luego a volver medible cada atributo (3), luego a filtrar lo que de verdad importa (4) y a descubrir lo que nadie dijo (5), y al final las dos habilidades de conversación —hablar el idioma del stakeholder (6) y decir no con un costo (7)—. La lección 8, el proyecto, junta todo sobre un lanzamiento nuevo de Mercado —los pagos a plazos— para que confirmes que aprendiste el método y no memorizaste el caso de los vendedores externos.

Lo que este módulo NO toca

Conviene marcar la frontera desde ahora, porque hay un tema vecino que parece de aquí y es de la guía hermana.

El concepto profundo de atributo de calidad y cómo se DECIDE entre ellos es de architecture-decisions-and-tradeoffs. Ahí, en su módulo 2, se estudia qué es cada atributo por dentro —qué significa exactamente scalability horizontal contra vertical, qué es un SLA de disponibilidad, cómo se modela la seguridad— y, sobre todo, el método para decidir cuando dos atributos compiten: la matriz de decisión, cómo ponderar, cómo documentar la elección en un ADR, cómo poner una fitness function que la vigile. Este módulo se detiene un paso antes: aquí aprendes a derivar los atributos desde el stakeholder y a detectar que compiten, pero cuando llegue el momento de resolver el conflicto —elegir 99.9% en vez de 99.99%, elegir seguridad sobre velocidad— ese es el método de la otra guía, y lo vas a enlazar, no a re-enseñar. La línea es nítida: de dónde salen los atributos y la conversación con quien los pide (aquí); cómo se decide entre ellos (allá).

Los patrones y estilos técnicos para lograr un atributo quedan fuera. Cuando digamos "para availability hace falta redundancia" o "para scalability hace falta particionar", no vamos a enseñar cómo se implementa la redundancia o el particionamiento —eso es de architectural-styles-and-boundaries y de las guías de patrones—. Aquí trabajamos la capa de arriba: qué atributo necesita el negocio y con qué prioridad. El cómo técnico es la caja de herramientas que ya cubren otras guías del ecosistema.

La gestión de las personas que piden las cosas queda fuera. Vamos a hablar mucho de conversaciones con el VP, con el CFO, con el fundador. Pero cómo se maneja políticamente a un stakeholder difícil, cómo se negocia una fecha, cómo se lidia con un ejecutivo que cambia de opinión —eso es liderazgo y política organizacional, y de eso el módulo 4 tocó lo técnico—. Aquí nos concentramos en la traducción: cómo se le explica un trade-off en su idioma, cómo se le dice no con un costo. El resto de la relación humana es otro oficio.

Errores comunes

Tomar la solución que pide el stakeholder en vez del problema (de literalidad). Qué pasa: el VP dice "necesitamos un caché" o "hay que migrar a microservicios", y el arquitecto lo construye tal cual, sin preguntar qué problema de negocio hay detrás. Meses después el caché no resolvió nada, porque el problema real era otro. Por qué pasa: es más fácil ejecutar una instrucción concreta que descifrar el deseo que la originó; y decir "sí, lo hago" se siente más colaborativo que decir "espera, ¿qué problema estamos resolviendo?". Cómo detectarlo: si estás implementando una solución técnica y no puedes nombrar la meta de negocio que la justifica, estás tomando la solución, no el problema. Cómo corregirlo: ante cada pedido con forma de solución, pregunta "¿qué queremos lograr con eso?" hasta llegar a la meta de negocio, y desde ahí deriva los atributos —quizás el caché era la respuesta correcta, quizás no, pero ahora lo sabes—. Es el arquitecto de casas que no pone la escalera de mármol sin preguntar quién va a vivir ahí.

Quedarte en el deseo sin traducirlo a atributos (de vaguedad). Qué pasa: el arquitecto recibe "queremos crecer 10x", asiente, y se pone a diseñar sin haber convertido eso en scalability, availability y cost con un nivel y una prioridad. Diseña a ojo, y cuando alguien pregunta "¿por qué esta decisión?", no tiene con qué defenderla, porque nunca hizo explícito qué atributo estaba optimizando. Por qué pasa: la traducción se siente como un paso burocrático que retrasa el trabajo "real" de diseñar. Cómo detectarlo: si tu diseño no se puede rastrear a una lista de atributos priorizados, estás diseñando sobre un deseo, no sobre requisitos. Cómo corregirlo: no dibujes nada hasta haber traducido las metas a atributos priorizados (lección 2); ese es el requisito del que cuelga todo lo demás.

Traducir solo en una dirección (de monolingüismo). Qué pasa: el arquitecto sí traduce el negocio a atributos, diseña bien, pero cuando le toca explicárselo al stakeholder lo hace en jerga técnica —"necesitamos consistencia eventual y replicación multi-región"— y lo pierde. El VP aprueba a regañadientes sin entender, o rechaza por miedo a lo que no comprende. Por qué pasa: el arquitecto vive en el idioma técnico y olvida que el permiso para construir viene de alguien que no lo habla. Cómo detectarlo: si tus explicaciones al negocio están llenas de términos que un VP de producto no usaría, estás traduciendo en una sola dirección. Cómo corregirlo: la lección 6 —traducir el trade-off de vuelta al idioma del negocio (dinero, riesgo, tiempo)—; "más disponibilidad" no le dice nada, "cuatro millones al año en ventas perdidas" sí.

Ejercicios

Ejercicio 1 — Traduce el deseo. Un fundador te dice: "quiero que Mercado nunca pierda un pedido, aunque se caiga medio internet". Sin escribir código, ¿qué atributos de calidad esconde esa sola frase? Nombra al menos tres y explica por qué cada uno se deriva de esa meta.

Ver solución

La frase "nunca perder un pedido, aunque se caiga medio internet" es un deseo del negocio que esconde varios atributos:

• Availability (disponibilidad) — "aunque se caiga medio internet" es una petición explícita de que el sistema siga funcionando ante fallas de infraestructura. El sistema tiene que estar arriba cuando las cosas de las que depende no lo están.
• Reliability / data integrity (integridad de datos) — "nunca perder un pedido" no es solo estar arriba: es que un pedido, una vez aceptado, no se pierda ni se duplique aunque haya una falla a la mitad. Eso es integridad de datos y durabilidad, un atributo distinto de estar disponible (un sistema puede estar arriba y aun así perder datos en una falla).
• Recoverability (recuperabilidad) — "aunque se caiga" implica que después de una falla el sistema tiene que recuperarse sin perder lo que ya había aceptado. Es la capacidad de volver a un estado consistente tras un desastre.

Fíjate en el patrón del módulo: una frase de negocio ("nunca perder un pedido") se expandió en tres atributos técnicos que el fundador no nombró. Y nota que integridad de datos y recuperabilidad son atributos que nadie pidió por su nombre pero que la meta exige —un anticipo de los atributos implícitos de la lección 5—. El arquitecto que solo oye "availability" y monta redundancia, pero no protege contra la pérdida de un pedido a la mitad de una transacción, entregó la mitad de lo que el fundador quería.

Ejercicio 2 — El caché que no era. Un product manager llega y dice: "el equipo de datos necesita que agreguemos un caché de Redis a los reportes". Le preguntas por qué, y responde "porque los reportes tardan mucho y el CFO se queja". ¿Tomarías la solución (poner Redis) o el problema? ¿Qué preguntarías, y qué atributo(s) hay de verdad detrás?

Ver solución

Tomarías el problema, no la solución. "Agregar un caché de Redis" es una solución técnica que alguien ya eligió; el problema real, dicho por el propio PM, es "los reportes tardan mucho y el CFO se queja". El atributo detrás es performance (latencia de los reportes), quizás con un matiz de usability (la experiencia del CFO esperando).

Qué preguntarías antes de tocar Redis:

• ¿Cuánto tardan hoy y cuánto deberían tardar? ("Tarda mucho" no es medible; necesitas un número —esto es el response measure de la lección 3—. Quizás el CFO se queja de 40 segundos y con 5 estaría feliz.)
• ¿Con qué frecuencia se piden esos reportes, y los datos cambian? (Si el reporte se pide una vez al día, un caché de Redis puede ser sobre-ingeniería; quizás basta pre-calcular el reporte de noche. Si se pide mil veces por minuto sobre datos que casi no cambian, un caché sí tiene sentido.)
• ¿El problema es la consulta, la base de datos, o el volumen de datos? (Un caché esconde el síntoma; si la consulta está mal escrita, quizás optimizarla resuelve sin agregar una pieza nueva de infraestructura que hay que operar.)

Redis podría ser la respuesta correcta —o no—. El punto del módulo no es "nunca hagas lo que te piden"; es traducir el pedido (solución) a su meta (performance de los reportes) y desde ahí elegir la mejor solución con evidencia, que quizás es Redis, quizás es una consulta mejor, quizás es pre-cálculo. Tomar la solución literal te habría hecho operar un Redis nuevo para siempre sin saber si resolvía el problema.

Ejercicio 3 — Traducción en dos direcciones. Eres el arquitecto de Mercado. Tradujiste "no caernos en Black Friday" a availability de nivel muy alto, y diseñaste una solución con redundancia multi-región que cuesta bastante. El VP de finanzas te pregunta en una junta: "¿por qué necesitamos gastar tanto en esto?". Da dos versiones de tu respuesta: una en jerga técnica (la mala) y una en el idioma del negocio (la buena). ¿Por qué la segunda funciona y la primera no?

Ver solución

Versión mala (jerga técnica): "Necesitamos disponibilidad de 99.99%, lo que exige redundancia activa-activa en dos regiones con failover automático y replicación síncrona del estado de los pedidos, porque un solo punto de falla en la región primaria nos deja sin capacidad de servir tráfico durante el pico." — Todo cierto, y todo inútil para este interlocutor: el VP de finanzas no sabe qué es activa-activa ni por qué 99.99% importa, así que oye "cosas caras que no entiendo" y su instinto es recortar.

Versión buena (idioma del negocio): "Black Friday nos factura, digamos, un millón de dólares por hora. Con la infraestructura actual, si se cae la región principal —y en un pico de tráfico es cuando más se cae— perdemos ventas hasta que se recupere, que pueden ser horas: eso es cientos de miles de dólares que se van y no vuelven, más los clientes que se van con la competencia. La inversión que propongo es un seguro: cuesta X al año y hace que, si una parte se cae, la otra siga vendiendo sin que el cliente lo note. Es más barato que una sola hora caída en Black Friday." — El VP de finanzas entiende perfectamente: comparó un costo (la inversión) contra un riesgo cuantificado (la venta perdida) y puede decidir.

Por qué la segunda funciona: porque tradujo el atributo técnico (availability 99.99%) a la consecuencia de negocio (venta perdida por hora caída, en dólares) —que es el idioma en el que el VP de finanzas piensa y decide—. La primera versión traduce el negocio a atributos (bien) pero se queda ahí; la segunda cierra el círculo y devuelve la traducción al idioma del stakeholder. Es la doble dirección del módulo: traducir el deseo a atributos para diseñar, y traducir el trade-off a dinero para acordar. La lección 6 convierte esto en método, con la tabla de nueves-a-dólares ejecutada.

Resumen y siguiente paso

En esta lección conociste la tesis que sostiene el módulo: las decisiones de arquitectura no salen del arquitecto, salen del negocio —de gente que quiere cosas y las dice en su idioma—, y el primer trabajo del arquitecto es traducir esas metas a atributos de calidad (los -ilities). Con el arquitecto de casas viste que "una casa para envejecer aquí" se traduce a requisitos concretos que el cliente nunca pidió (sin escaleras, puertas anchas, baño abajo), y que el oficio está en tomar el problema del cliente, no la solución que imaginó. Conociste la estrategia de 18 meses de Mercado —vendedores externos y cinco metas de soporte—, el material bruto del módulo. Y con el teaser ejecutado viste la traducción en su forma más pura: una sola frase de negocio ("abrir a vendedores externos") se abre en cuatro atributos de calidad, ninguno de los cuales pidió el VP.

Antes de avanzar deberías poder: explicar por qué una meta de negocio es un deseo y no un requisito de arquitectura; tomar una frase del negocio y expandirla en los atributos de calidad que esconde; distinguir "tomar la solución" de "tomar el problema"; y entender por qué la traducción va en dos direcciones —del negocio a los atributos para diseñar, y de los trade-offs de vuelta al negocio para acordar—.

Lo que sigue es hacer la traducción completa y con método. En la lección 2 vas a tomar las seis metas de Mercado con su peso de negocio, y vas a ejecutar el mapeo a atributos priorizados: derivar qué atributo implica cada meta y con qué fuerza, sumar para obtener un ranking (vas a ver scalability arriba y cost abajo, con números), y detectar cuáles atributos compiten entre sí (el conflicto scalability-vs-cost va a resultar el que más pesa). Es el paso de "intuyo que este deseo esconde varios atributos" a "sé exactamente cuáles, en qué orden, y dónde se van a pelear" —la base de todo lo que el arquitecto decide después—.

Recursos

• Len Bass, Paul Clements, Rick Kazman — Software Architecture in Practice — el texto canónico sobre atributos de calidad y cómo se derivan de las metas de negocio (los business goals y los quality attribute requirements). El capítulo sobre entender los atributos de calidad es la fuente académica de todo este módulo.
• Gregor Hohpe — The Software Architect Elevator — el libro sobre el arquitecto que "sube y baja en el elevador" entre el idioma del negocio (el penthouse) y el de la ingeniería (el sótano). La metáfora exacta de la doble traducción de esta lección; imprescindible para la conversación con el stakeholder (lección 6).
• Mark Richards & Neal Ford — Fundamentals of Software Architecture — el capítulo sobre identificar atributos de calidad ("architecture characteristics") desde los requisitos y el dominio; el mejor puente moderno entre lo que pide el negocio y lo que diseña el arquitecto.
• ISO/IEC 25010 — modelo de calidad del producto de software — el estándar internacional que cataloga los atributos de calidad (los -ilities): functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability. El vocabulario común al que traduces las metas del negocio.