Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 1 de 5
Brief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
21 min aprox.
01Modelo mentalBrief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
+
Brief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
El proyecto final comienza con decisiones, no productos. Define volumen, latencia, freshness, calidad, retención, RPO/RTO, consumidores, clasificación, regiones y presupuesto. Después asigna cada requisito a una capacidad: Auto Loader/Lakeflow Connect para ingesta, pipelines declarativos para transformación, Jobs para orquestación, Unity Catalog para gobierno y system tables para operación.
Documenta alternativas rechazadas y condiciones de cambio. Una arquitectura Professional no es la que usa más servicios, sino la que minimiza estados y responsabilidades ambiguas. Cada tabla, checkpoint, job, policy y alerta tiene owner; cada SLO tiene una señal medible y un runbook. Mapea además evidencias a los dominios del blueprint sin convertirlo en memorización.
product: commerce-orders
owners:
product: commerce-analytics
platform: data-platform
slos:
freshness_minutes: 15
completeness_percent: 99.95
p95_pipeline_minutes: 12
recovery:
rpo_minutes: 15
rto_minutes: 60
governance:
classification: confidential
regions: [eu-west, us-east]
finops:
monthly_budget_eur: 18000Cada valor debe enlazar a una medición y una respuesta; un SLO sin observabilidad es sólo una aspiración.
¿Qué convierte un requisito 'casi en tiempo real' en una decisión arquitectónica comprobable?
Profundiza
Una arquitectura Professional es una cadena de decisiones trazables, no un collage de servicios. Cada requisito se transforma primero en una propiedad medible: frescura en SLO, exactitud en reconciliaciones, seguridad en principals y policies, recuperación en RPO y RTO, y coste en unidad de valor. Después se asignan componentes que satisfacen esas propiedades y se documentan tradeoffs y fallos. Ownership y contratos definen quién responde cuando el sistema se degrada. La certificación evalúa escoger la opción más adecuada bajo restricciones, por lo que una respuesta defendible conecta requisito, mecanismo y evidencia. Si dos soluciones funcionan, gana la que usa capacidades administradas, mínimo privilegio, idempotencia y menor carga operativa sin violar una condición explícita.
Objetivo cuantitativo de fiabilidad o rendimiento, como frescura, disponibilidad o latencia, medido durante una ventana acordada.
Convierte expectativas ambiguas en criterios que guían arquitectura, alertas, capacidad y decisiones durante incidentes.Frontera donde cambian identidad, control administrativo, residencia o nivel de confianza de datos y operaciones.
Obliga a diseñar autenticación, minimización, cifrado y auditoría exactamente donde aumenta el riesgo.Registro breve del contexto, decisión, alternativas, tradeoffs y señales que justificarán revisar una elección arquitectónica.
Hace defendible el diseño y evita perder el razonamiento cuando cambian requisitos, equipos o capacidades de plataforma.Resumen
Puntos clave
- Requisitos cuantificados preceden a la selección de servicios.
- Cada componente necesita estado, owner, SLO y estrategia de recuperación.
- Registra alternativas y triggers que obligarían a revisar la decisión.
Evita
- Elegir componentes antes de aclarar latencia, volumen y ownership.
- Confundir alta disponibilidad de la plataforma con idempotencia y recuperación de la aplicación.