5. Los atributos implícitos que nadie pidió

Descripción

Al terminar esta lección vas a saber ver los requisitos que no están escritos en ninguna parte y que, sin embargo, van a decidir si tu sistema se considera un éxito o un desastre —porque existen, todos cuentan con ellos, y nadie los pide—. Hasta ahora trabajaste con lo explícito: el negocio puso metas sobre la mesa (lección 2), las volviste scenarios medibles (lección 3), filtraste las que moldean la arquitectura (lección 4). Todo ese trabajo parte de algo que alguien dijo. Pero hay una clase entera de atributos de calidad que nadie dice porque todos los dan por hecho, como el aire: que un pedido, una vez cobrado, no se pierda ni se duplique (integridad de datos); que toda transacción de dinero se pueda rastrear (auditabilidad); que los datos personales estén protegidos (privacidad); que si algo falla, el sistema se recupere sin perder datos (recuperabilidad); que si algo se rompe a las 3am, alguien se entere (observabilidad). Son el contrato tácito del dominio: lo que se espera de cualquier sistema que maneje dinero y datos de terceros, lo diga o no el stakeholder. Vas a ejecutar una comparación entre lo que las metas explícitas de Mercado nombraron (cinco atributos) y lo que el dominio siempre exige, y vas a ver la brecha: seis atributos más, ninguno pedido.

Esto importa porque los atributos implícitos son la fuente número uno de las catástrofes que hacen quedar mal a un arquitecto competente. El sistema puede cumplir perfectamente todo lo que el negocio pidió —escala 10x, aguanta Black Friday, blinda los datos de pago— y aun así ser un fracaso, porque un día un pedido se cobró dos veces (falló la integridad de datos, que nadie pidió), o porque el regulador preguntó "muéstrenme el rastro de esta transacción" y no había rastro (falló la auditabilidad, que nadie pidió), o porque un servicio llevaba tres horas caído y nadie se enteró hasta que los clientes se quejaron (falló la observabilidad, que nadie pidió). El VP nunca escribió "el sistema debe ser auditable" en su lista de metas, del mismo modo que nadie que compra una casa escribe "que el techo no se caiga" —se da por hecho—. Pero cuando el techo se cae, no vale de nada decir "usted no pidió que el techo aguantara". El arquitecto que solo entrega lo explícito entrega un sistema lleno de sorpresas caras esperando a estallar. La habilidad de esta lección es descubrir lo implícito antes de que estalle: conocer el contrato tácito del dominio y traerlo a la superficie, para que se diseñe a propósito en vez de descubrirse en una crisis.

Conexión con el módulo: esta lección tapa el punto ciego que las anteriores dejaron abierto explícitamente. La lección 2 lo advirtió: el mapeo de metas captura lo que el negocio nombra, y hay atributos con score cero que no aparecen porque ninguna meta los empuja. Esta lección va a buscar esos justamente. Los atributos implícitos que descubras aquí se tratan igual que los explícitos de las lecciones anteriores: se vuelven scenarios medibles (lección 3) y se clasifican como ASR o no (lección 4) —de hecho, muchos implícitos son ASR de los más pesados, como viste con GDPR—. Y alimentan las conversaciones que vienen: en la lección 6 vas a tener que explicarle al VP por qué el proyecto cuesta más de lo que él imaginó, y buena parte de ese "más" son los atributos implícitos que él no pidió pero que hay que construir. La frontera se mantiene: aquí descubres qué atributos implícitos exige el dominio; cómo se decide el nivel de cada uno y cómo compite con los explícitos es el método de architecture-decisions.

La casa que "nadie pidió que no se inundara"

Piénsalo con quien compra una casa. La pareja le da al arquitecto su lista de deseos: tres recámaras, cocina abierta, un jardín, mucha luz natural, un estudio. Es una lista completa —para ellos—. Ahora imagina que el arquitecto construye exactamente esa lista, y solo esa lista: tres recámaras hermosas, cocina abierta preciosa, jardín, luz, estudio. Y entonces llega la primera tormenta y la casa se inunda, porque nadie pidió un buen drenaje. Y en verano es un horno, porque nadie pidió aislamiento térmico. Y la instalación eléctrica no tiene tierra física, porque nadie la pidió. Y no hay detectores de humo, porque nadie los pidió. La pareja está furiosa —"¡construiste una casa que se inunda!"— y el arquitecto, absurdamente, se defiende: "ustedes no pidieron que no se inundara". Tiene razón literal y está completamente equivocado. Nadie pide que la casa no se inunde, que no sea un horno, que no te electrocutes, que no se queme sin aviso —porque son el contrato tácito de lo que significa "una casa"—. Un arquitecto de casas que no los incluye sin que se lo pidan no es un arquitecto: es alguien que dibuja recámaras.

Fíjate en lo que distingue al buen arquitecto de casas: no espera a que le pidan el drenaje, el aislamiento, la tierra física y los detectores de humo —los pone porque sabe qué exige el oficio y el clima del lugar—. Su conocimiento del dominio (cómo son las casas, cómo es este clima, qué exige el reglamento) le dice qué requisitos implícitos vienen con el territorio, aunque el cliente jamás los mencione. Y hace algo más, que es la otra mitad del oficio: se los dice al cliente, para que entienda por qué la casa cuesta lo que cuesta. "Además de sus tres recámaras, incluí drenaje pluvial, aislamiento y sistema eléctrico con tierra —no lo pidieron, pero una casa sin eso se inunda, es un horno y es peligrosa—; eso explica parte del presupuesto." El arquitecto de software hace exactamente esto: conoce el contrato tácito de su dominio —qué exige cualquier sistema que maneja dinero, datos personales, integraciones con terceros— y trae esos requisitos a la superficie, tanto para diseñarlos como para explicar por qué el sistema cuesta más de lo que el negocio, mirando solo su lista de deseos, imaginó.

Ejemplo trabajado: la brecha entre lo pedido y lo esperado

Vamos a ejecutar la comparación. De un lado, lo que las metas explícitas de Mercado nombraron —los cinco atributos del ranking de la lección 2—. Del otro, el contrato tácito de un marketplace que maneja dinero y datos de terceros: los atributos que se esperan aunque nadie los pida. La brecha —lo que el dominio exige y las metas no nombraron— es la lista de atributos implícitos que el arquitecto tiene que descubrir.

# Los atributos IMPLICITOS: nadie los pide, pero todos los dan por hecho.
# Comparamos lo que las metas EXPLICITAS nombraron contra lo que un
# marketplace que maneja dinero y datos de terceros SIEMPRE debe cumplir.

# Lo que las metas explicitas de Mercado nombraron (los atributos de la leccion 2):
explicit = {"scalability", "availability", "security", "performance", "cost"}

# El "contrato tacito" del dominio: lo que se espera aunque nadie lo pida.
expected_by_domain = {
    "security":       "obvio, pero ademas todo lo de abajo",
    "data_integrity": "un pedido cobrado NO puede perderse ni duplicarse",
    "auditability":   "toda transaccion de dinero debe poder rastrearse",
    "privacy":        "datos personales protegidos (GDPR / LFPDPPP)",
    "usability":      "un vendedor debe poder operar sin llamar a soporte",
    "recoverability": "si algo falla, se recupera sin perder datos",
    "observability":  "si algo se rompe a las 3am, alguien se entera",
}

implicit_gap = [a for a in expected_by_domain if a not in explicit]

print("Atributos que NADIE nombro pero TODOS esperan:")
for attr in implicit_gap:
    print(f"  - {attr:<15} {expected_by_domain[attr]}")

print()
print(f"Metas explicitas -> {len(explicit)} atributos nombrados.")
print(f"El dominio exige  -> {len(implicit_gap)} atributos MAS, ninguno pedido.")
print(f"Entregar solo lo pedido = entregar {len(implicit_gap)} sorpresas caras despues.")

Qué esperar. Al correrlo:

Atributos que NADIE nombro pero TODOS esperan:
  - data_integrity  un pedido cobrado NO puede perderse ni duplicarse
  - auditability    toda transaccion de dinero debe poder rastrearse
  - privacy         datos personales protegidos (GDPR / LFPDPPP)
  - usability       un vendedor debe poder operar sin llamar a soporte
  - recoverability  si algo falla, se recupera sin perder datos
  - observability   si algo se rompe a las 3am, alguien se entera

Metas explicitas -> 5 atributos nombrados.
El dominio exige  -> 6 atributos MAS, ninguno pedido.
Entregar solo lo pedido = entregar 6 sorpresas caras despues.

Lee la lista y date cuenta de algo incómodo: el negocio nombró cinco atributos, y el dominio exige seis más que nadie nombró. La lista de deseos del stakeholder, que parecía completa, cubría menos de la mitad de lo que el sistema de verdad necesita. Y fíjate qué son los seis implícitos —no son caprichos técnicos del arquitecto, son cosas que cualquier persona razonable asume que un marketplace tiene—. Nadie que compra en Mercado piensa "espero que mi pedido no se cobre dos veces"; simplemente lo da por hecho (integridad de datos). Nadie que vende piensa "espero que si el sistema se cae no pierda mis ventas del día"; lo asume (recuperabilidad). El regulador no pide auditabilidad al principio; la exige el día que investiga un fraude, y para entonces tiene que haber existido siempre. Cada uno de esos seis es un requisito real y a menudo pesado, y ninguno apareció en la lista del negocio porque son demasiado obvios para el usuario —tan obvios que nadie los dice—.

Detente en la última línea, porque es la advertencia del módulo: entregar solo lo pedido es entregar seis sorpresas caras después. Imagina al arquitecto que toma la lista del negocio como la especificación completa y construye exactamente los cinco atributos explícitos, ignorando los seis implícitos. Su sistema escala, aguanta Black Friday, blinda los datos de pago —cumple todo lo que le pidieron— y aun así es una bomba de tiempo. Un día, por un reintento mal manejado, un pedido se cobra dos veces (falló data_integrity): clientes furiosos, reembolsos, reputación dañada. Otro día, el regulador pide el rastro de una transacción sospechosa y no existe (falló auditability): problema legal. Otro, un servicio lleva horas caído sin que nadie lo note porque no hay alertas (falló observability): pérdida silenciosa de ventas. Ninguna de esas catástrofes viola la especificación explícita —todas violan el contrato tácito—. Y cada una se pudo prevenir diseñando el atributo implícito desde el principio, cuando era barato, en vez de descubrirlo en una crisis, cuando es carísimo. La brecha de seis atributos es, literalmente, una lista de seis formas de quedar mal a pesar de haber cumplido todo lo pedido.

Fíjate en un detalle del código que enseña sobre el oficio: security aparece en las dos listas. Estaba en las metas explícitas (el negocio sí pidió "blindar los datos de pago") y está en el contrato del dominio. Pero incluso ahí hay una trampa: el negocio pidió security para una cosa concreta (los datos de tarjeta), mientras el dominio la exige más ampliamente —aislamiento entre vendedores, protección contra inyección, control de acceso en toda la API—. Un atributo puede ser explícito y tener una parte implícita: el negocio nombró la punta del iceberg (datos de pago) y el arquitecto tiene que ver el resto (todo lo demás que "seguridad" implica en un marketplace multi-tenant). Por eso security no entró en la brecha (ya estaba nombrada) pero igual esconde requisitos implícitos dentro de sí misma. El descubrimiento de lo implícito no es solo "qué atributos faltan por completo"; es también "qué partes de un atributo nombrado el negocio no imaginó".

Un matiz honesto sobre el método. La lista expected_by_domain de este ejemplo la escribió el arquitecto a partir de su conocimiento del dominio —marketplaces que manejan dinero—. No es una verdad universal que salga de una fórmula: para un videojuego, el contrato tácito sería otro (baja latencia, anti-cheat, fairness); para un sistema médico, otro (seguridad del paciente, trazabilidad clínica, certificaciones). El valor del ejercicio no está en esta lista particular, sino en la disciplina de preguntarse, para cada dominio, cuál es su contrato tácito y compararlo contra lo que el negocio nombró. La herramienta no descubre lo implícito por arte de magia; te obliga a hacer explícito tu conocimiento del dominio y a confrontarlo con la lista de deseos. De dónde sale ese conocimiento —de la experiencia, de los estándares del sector, de hablar con quien ya construyó algo parecido, de los regulaciones aplicables— es parte del oficio que se cultiva. Lo que la lección te da es el hábito de buscar la brecha, no una lista que sirva para todo.

Profundización: de dónde sale el contrato tácito, y cómo traerlo a la superficie

Vale la pena entender de dónde vienen los atributos implícitos, porque conocer sus fuentes es lo que te permite descubrirlos en un dominio nuevo donde no tienes la lista memorizada.

Del dominio del negocio. Cada industria tiene expectativas que vienen con el territorio. Un sistema que maneja dinero implica integridad de datos (no perder ni duplicar transacciones), auditabilidad (rastrear cada movimiento) y a menudo cumplimiento regulatorio (PCI-DSS, antilavado). Un sistema que maneja datos personales implica privacidad y los derechos que la ley otorga (acceso, borrado, portabilidad). Un sistema que maneja terceros (como los vendedores externos de Mercado) implica aislamiento y equidad entre ellos. El primer lugar donde buscar lo implícito es preguntarse "¿qué tipo de cosas maneja este sistema —dinero, datos personales, salud, identidad, terceros— y qué exige cada una por defecto?".

De la operación real. Muchos atributos implícitos no salen del negocio sino de la cruda realidad de operar un sistema en producción. Observabilidad (si algo se rompe, hay que enterarse), recuperabilidad (los sistemas fallan; tienen que poder volver), mantenibilidad (alguien va a tener que cambiar esto en dos años) no las pide ningún stakeholder de negocio porque viven en el mundo de quien opera, no de quien usa. El equipo de operaciones, el de guardias, el que va a mantener el sistema —esos son los stakeholders silenciosos cuyas necesidades son puro atributo implícito—. Preguntarse "¿quién va a operar esto a las 3am, y qué necesita para no volverse loco?" saca a la luz media brecha.

De lo que el usuario asume sin decir. Usabilidad, accesibilidad, que las cosas "simplemente funcionen" —el usuario no las pide porque las da por sentadas—. Nadie escribe en una lista de requisitos "que la interfaz no sea confusa"; se asume. Estos implícitos se descubren poniéndose en los zapatos del usuario final y preguntando "¿qué esperaría esta persona sin siquiera pensarlo?".

Ahora, la parte más difícil, que es la otra mitad del oficio: cómo traer lo implícito a la superficie sin que suene a que estás inflando el proyecto. Porque hay un riesgo real: si el arquitecto llega con una lista de seis atributos que "nadie pidió pero hay que construir", el negocio puede oír "el arquitecto quiere hacer más caro y más largo el proyecto con cosas que no necesitamos". La forma de evitarlo es la misma que usó el arquitecto de casas: explicar cada implícito en términos de la catástrofe concreta que previene, en el idioma del negocio. No "necesitamos auditabilidad" (suena a capricho técnico), sino "necesitamos poder rastrear cada transacción, porque el día que el regulador investigue un fraude —y va a pasar— no poder mostrarle el rastro es una multa y un problema legal". No "necesitamos observabilidad", sino "necesitamos alertas automáticas, porque hoy si un servicio se cae de noche nos enteramos por los clientes enojados en Twitter, y cada hora caída son ventas perdidas". Cada atributo implícito se justifica no por su nombre técnico sino por el desastre que evita —y ese desastre, contado en dinero o en riesgo, es algo que el negocio entiende y aprueba—. Descubrir lo implícito es la mitad; venderlo como prevención de catástrofes concretas es la otra. Esa venta es exactamente la conversación de la lección 6.

Y la frontera. Descubrir que Mercado necesita auditabilidad es el trabajo de esta lección. Cuánta auditabilidad —cada campo, cada acceso, retención de cuántos años, con qué costo— y cómo pesa contra otros atributos (la auditabilidad completa puede añadir latencia y costo de almacenamiento) es una decisión con trade-offs que se resuelve con el método de architecture-decisions. Aquí traes el atributo implícito a la lista; allá decides su nivel. Lo importante de esta lección es que el atributo llegue a la lista —porque un atributo que nunca se nombró jamás se diseña, y un atributo que jamás se diseña es la sorpresa cara del futuro—.

Errores comunes

Tratar la lista del stakeholder como la especificación completa (de literalidad, otra vez). Qué pasa: el arquitecto recibe las metas del negocio, las trata como todo lo que el sistema necesita, y construye exactamente eso —sin auditabilidad, sin observabilidad, sin recuperabilidad, porque no estaban en la lista—. El sistema cumple la especificación y falla el contrato tácito. Por qué pasa: la lista del negocio se ve completa (es lo que el negocio sabe pedir), y es cómodo tratarla como el alcance total. Cómo detectarlo: si tu especificación no incluye ningún atributo que el negocio no nombró, no buscaste lo implícito. Cómo corregirlo: para cada sistema, construye explícitamente la lista del contrato tácito del dominio (qué maneja: dinero, datos, terceros) y compárala contra lo pedido —la brecha es tu lista de implícitos—.

Descubrir lo implícito pero no comunicarlo (de descubrimiento silencioso). Qué pasa: el buen arquitecto sí sabe que hace falta auditabilidad y recuperabilidad, y las diseña, pero no se lo dice a nadie —las mete "por dentro"—. Entonces, cuando el proyecto cuesta más y tarda más de lo que el negocio imaginó, el negocio no entiende por qué, y el arquitecto queda como el que "sobre-ingenió". Por qué pasa: el arquitecto asume que los implícitos son tan obvios que no hace falta explicarlos, olvidando que para el negocio no eran obvios (por eso no los pidió). Cómo detectarlo: si el negocio se sorprende del costo o el tiempo del proyecto, no comunicaste lo implícito. Cómo corregirlo: haz visible cada atributo implícito y su justificación (la catástrofe que previene) antes de construirlo —así el costo tiene una razón que el negocio aprobó, no una sorpresa—.

Inflar lo implícito hasta la paranoia (de sobre-ingeniería). Qué pasa: en el extremo opuesto, el arquitecto descubre el contrato tácito y lo lleva al absurdo —audita cada clic, replica en cinco regiones "por si acaso", diseña para un desastre que este negocio jamás enfrentará—. Convierte "no perder pedidos" en un sistema de alta disponibilidad de misión crítica para una startup que factura poco. Por qué pasa: una vez que se empieza a pensar en lo que puede salir mal, es fácil no parar. Cómo detectarlo: si estás diseñando para catástrofes que este negocio, a su escala, casi con seguridad nunca vivirá, te pasaste. Cómo corregirlo: cada atributo implícito también se prioriza y se acota por su nivel (lección 3) y se decide contra su costo (la guía de decisiones); "auditable" no significa "audita todo para siempre", significa "audita lo que el riesgo real justifica". Lo implícito hay que descubrirlo y dimensionarlo —traerlo a la lista no es ponerlo todo al máximo (lección 7)—.

Ejercicios

Ejercicio 1 — El contrato tácito de otro dominio. Un equipo va a construir una app de mensajería para un hospital, para que médicos y enfermeras coordinen sobre pacientes. La lista de deseos del cliente dice: "mensajes rápidos, grupos por área, notificaciones, historial de conversaciones". Nombra al menos cuatro atributos implícitos que el dominio (salud + comunicación sobre pacientes) exige y que no están en la lista, y explica la catástrofe que cada uno previene.

Ver solución

Cuatro atributos implícitos del dominio (salud + comunicación sobre pacientes), con la catástrofe que previene cada uno:

• Privacidad / confidencialidad (cumplimiento HIPAA o equivalente). Los mensajes contienen información médica de pacientes, que es de las más protegidas por ley. Catástrofe que previene: una filtración de datos clínicos, que además de dañar a los pacientes es una violación regulatoria con multas severas y responsabilidad legal para el hospital.
• Auditabilidad / trazabilidad. En salud, quién dijo qué y cuándo sobre un paciente puede tener consecuencias clínicas y legales. Catástrofe que previene: que ante un incidente médico (una indicación mal comunicada) no haya forma de reconstruir qué se comunicó, dejando al hospital sin defensa y sin poder aprender del error.
• Confiabilidad de la entrega (data integrity de los mensajes). Un mensaje sobre un paciente que "se pierde" o llega tarde puede ser peligroso. Catástrofe que previene: que una indicación urgente ("suspender este medicamento") no llegue o llegue duplicada y confusa, con daño directo al paciente.
• Disponibilidad / recuperabilidad. Un hospital opera 24/7; la app no puede "estar caída un rato". Catástrofe que previene: que el sistema se caiga durante una emergencia y el personal no pueda coordinar, justo cuando más lo necesita.

(Otros válidos: usabilidad para personal no técnico y bajo estrés; control de acceso por rol; retención y borrado de datos según normativa.) La lección: ninguno estaba en la lista de deseos ("mensajes rápidos, grupos, notificaciones, historial"), y todos son requisitos pesados que decidirán si la app es usable en un hospital o un riesgo legal y clínico. El contrato tácito de "comunicación sobre pacientes" es enorme y casi todo implícito.

Ejercicio 2 — El atributo explícito con parte implícita. El negocio de Mercado pidió "blindar los datos de pago" (security, explícito). Argumenta por qué, aun siendo un atributo explícito, esconde requisitos implícitos que el negocio no imaginó, y nombra tres partes de "seguridad" que el negocio no pidió pero el dominio exige.

Ver solución

"Blindar los datos de pago" es la punta del iceberg de la seguridad: el negocio nombró la parte que le preocupa conscientemente (que no se roben los números de tarjeta), pero "seguridad" en un marketplace multi-tenant que se abre a terceros implica muchísimo más, y esas partes son implícitas —el negocio no las imaginó porque no piensa como atacante ni como arquitecto—. Tres partes de seguridad que el dominio exige y el negocio no pidió:

• Aislamiento entre vendedores (multi-tenancy security). Al abrir a vendedores externos, cada uno debe ver solo sus datos —sus ventas, sus clientes, sus productos—. El negocio pidió proteger los datos de pago de los compradores, pero no pensó en que un vendedor no pueda espiar los datos de otro vendedor. Una fuga cross-tenant es un desastre distinto y el negocio no lo nombró.
• Control de acceso y autorización en toda la API. Abrir una API pública significa que cualquiera puede intentar llamarla; cada endpoint necesita verificar quién llama y qué tiene permitido. El negocio pidió proteger datos de pago, no diseñó el modelo de permisos de una API abierta a miles de terceros.
• Protección contra abuso: rate limiting, validación de entradas, prevención de inyección. Una API pública es un blanco: ataques de fuerza bruta, inyección, denegación de servicio. El negocio no pidió "que no nos tumben la API con un ataque"; lo asume.

La lección de la profundización, en concreto: un atributo puede ser explícito y tener un enorme cuerpo implícito. El arquitecto que lee "blindar los datos de pago" y solo cifra los números de tarjeta cumplió la letra explícita y dejó abiertos tres frentes que el dominio da por obligatorios. Descubrir lo implícito no es solo buscar atributos ausentes; es también mirar dentro de cada atributo nombrado y ver qué partes el negocio no imaginó.

Ejercicio 3 — Descúbrelo y véndelo. Eres el arquitecto de Mercado. Descubriste que el proyecto de vendedores externos necesita observabilidad (alertas cuando algo falla) y auditabilidad (rastro de transacciones), ninguna de las dos pedida por el negocio. El VP, mirando el presupuesto, te pregunta: "¿por qué está tan caro? Yo solo pedí abrir la plataforma a vendedores". Escribe cómo le explicarías esos dos atributos implícitos en su idioma, sin jerga, de forma que los apruebe en vez de recortarlos.

Ver solución

La clave es justificar cada implícito por la catástrofe concreta que previene, en dinero y riesgo, no por su nombre técnico. Algo así:

"Tienes razón en que solo pediste abrir la plataforma, y eso es exactamente lo que estamos construyendo. Pero abrirla a miles de vendedores externos trae dos cosas que no pediste porque no tenías por qué pensarlas, y que si no las incluimos nos van a costar mucho más caro después. Te las explico:

La primera es poder saber cuándo algo se rompe, al instante. Hoy, con nuestros propios equipos, si un servicio se cae de noche, más o menos nos enteramos. Pero cuando haya miles de vendedores dependiendo de la plataforma para vender, un servicio caído dos horas sin que nos demos cuenta significa miles de vendedores que no pudieron vender —y que se van a quejar, público, y algunos se van a ir a la competencia—. Estamos incluyendo un sistema de alertas que nos avisa en minutos, no en horas. Cuesta algo, sí; pero es muchísimo más barato que una caída silenciosa en temporada alta.

La segunda es poder rastrear cada transacción. El día —y va a llegar— en que un vendedor reclame 'me cobraron de más' o el regulador investigue una operación sospechosa de lavado, vamos a tener que mostrar exactamente qué pasó, cuándo y quién lo hizo. Si no guardamos ese rastro desde el principio, ese día no lo podremos reconstruir, y eso es una multa, un problema legal, o un vendedor que nos demanda. Guardar el rastro desde ahora es barato; intentar reconstruirlo cuando no existe es imposible.

Ninguna de las dos es un lujo técnico: son los dos seguros que hacen que abrir la plataforma no se convierta en un problema mayor que el que resuelve. Puedo mostrarte el costo de cada una contra el riesgo que cubre, para que decidas el nivel."

Por qué funciona: (1) valida la petición del VP ("eso es lo que construimos") en vez de contradecirlo; (2) traduce cada atributo implícito a una catástrofe que el VP entiende (ventas perdidas por caída silenciosa, multa/demanda por falta de rastro); (3) enmarca el costo como seguro contra un riesgo mayor, que es el idioma del negocio; (4) ofrece decidir el nivel contra el costo, respetando que la decisión final de cuánto es del negocio. Es descubrir lo implícito (esta lección) y venderlo como prevención (lección 6) en una sola conversación.

Resumen y siguiente paso

En esta lección aprendiste a ver los requisitos que nadie escribe y todos esperan: los atributos implícitos, el contrato tácito del dominio. Con la casa que "nadie pidió que no se inundara" viste que un arquitecto que entrega solo la lista de deseos —recámaras sin drenaje, sin aislamiento, sin detectores de humo— no es un arquitecto, y que el buen profesional incluye lo implícito porque conoce el oficio, y lo explica para justificar el costo. Lo mediste ejecutando: la brecha entre los cinco atributos que las metas de Mercado nombraron y los seis que el dominio exige sin que nadie los pida (integridad de datos, auditabilidad, privacidad, usabilidad, recuperabilidad, observabilidad) —seis sorpresas caras esperando a estallar—. Entendiste que lo implícito sale de tres fuentes (el dominio del negocio, la operación real, lo que el usuario asume), que un atributo explícito puede esconder un enorme cuerpo implícito (la seguridad va más allá de los datos de pago), y que descubrir lo implícito es la mitad —la otra es venderlo como prevención de catástrofes concretas, en el idioma del negocio—.

Antes de avanzar deberías poder: construir el contrato tácito de un dominio preguntando qué maneja el sistema (dinero, datos, terceros) y quién lo opera; encontrar la brecha entre lo pedido y lo esperado; mirar dentro de un atributo explícito para hallar sus partes implícitas; y justificar cada implícito por la catástrofe que previene, sin inflarlo hasta la paranoia.

Lo que sigue es la habilidad que ha estado asomándose en cada lección y que ahora toma el centro: la conversación con el stakeholder. Ya sabes traducir el negocio a atributos (lección 2), volverlos medibles (3), filtrar los que importan (4) y descubrir los implícitos (5). Todo eso es trabajo del lado del arquitecto. Pero nada se construye sin el permiso —y el presupuesto— de alguien que no habla tu idioma. En la lección 6 vas a aprender a hablar el idioma del stakeholder: a traducir un trade-off técnico a su consecuencia de negocio, en dinero. Vas a ejecutar la tabla que convierte niveles de disponibilidad en minutos caídos al año y en ventas perdidas —"más disponibilidad = más dinero", con números—, y vas a entender por qué esa traducción de vuelta al negocio es la mitad del oficio que decide si tu arquitectura llega a existir.

Recursos

• Len Bass, Paul Clements, Rick Kazman — Software Architecture in Practice — su tratamiento de los atributos de calidad incluye los que rara vez se piden explícitamente (modifiability, testability, availability) y cómo relevarlos; la base para entender que la lista del stakeholder nunca es completa.
• ISO/IEC 25010 — modelo de calidad del producto de software — recorrer sus ocho características y sus sub-características es una forma sistemática de descubrir atributos implícitos: por cada categoría que el negocio no mencionó, pregúntate si su dominio la exige tácitamente.
• Michael Nygard — Release It! — el libro entero trata de los requisitos implícitos de operar en producción (estabilidad, recuperabilidad, que las cosas fallen sin arrastrar a todo el sistema) —justo los atributos que nadie pide hasta que estallan—. La mejor lectura para el contrato tácito de la operación.
• OWASP — Application Security Verification Standard — un catálogo de los requisitos de seguridad que un sistema debe cumplir aunque nadie los pida; el ejemplo perfecto de un cuerpo enorme de atributos implícitos dentro de "seguridad".