Mapa del curso — 24 módulos en seis partes

Un mapa de metro: primero ves todas las líneas de golpe y luego recorres estación por estación.

El curso va de la mentalidad a la práctica. Primero, cómo piensa un arquitecto (mindset). Después, cómo se construye un sistema por dentro (structure) y qué cambia cuando se reparte por una red (distribution). Luego vienen las propiedades de calidad (quality attributes), el trabajo con personas (people) y hacia dónde va la profesión (future).

Cómo leerlo: cada concepto tiene su término en inglés (el que buscarás en la documentación y oirás en las entrevistas), una imagen cotidiana, un diagrama y una tarjeta con los campos «qué es / ejemplo / coste / relaciones». Al final del curso hay una chuleta con todos los conceptos en una sola página.

Long-term thinking — el arquitecto piensa en años

Un ingeniero construye un puente por el que mañana pasará un coche. El arquitecto pregunta qué pasa cuando empiecen a usarlo camiones, cuando se levante un barrio nuevo al lado y cuando las reparaciones cuesten más que el propio puente.

Un ingeniero suele resolver el problema tal como se lo plantean. El arquitecto primero comprueba si el problema está bien planteado. No es postureo ni ganas de «hablar de cosas profundas». Simplemente, una decisión arquitectónica suele ser más cara de cambiar que una línea de código.

El cambio principal en la cabeza: dejas de preguntar solo «cómo hago X» y empiezas a preguntar «para qué necesitamos X, qué alternativas hay, qué vamos a perder y cómo se verá esto dentro de tres años».

Reversible vs irreversible decisions — hacerse cargo de la forma del sistema

Si un carpintero cuelga mal una estantería, se puede mover. Si el diseñador pone un muro de carga en el sitio equivocado, la casa vive con ese error durante décadas.

El arquitecto no tiene la obligación de tomar personalmente cada decisión técnica. Pero sí de responsabilizarse de las decisiones que dan forma al sistema: fronteras entre servicios, modelo de datos, protocolos de integración, estrategia de escalado, seguridad, observability, ruta de migración.

La distinción útil aquí es entre decisiones reversibles y decisiones irreversibles. Una decisión reversible se puede cambiar en un día o una semana: una librería de logging, el color de un botón, la estructura interna de un módulo pequeño. Una decisión irreversible, o cara de revertir, cambia la trayectoria del sistema: la base de datos, el modelo de tenancy, un contrato de API, la forma de guardar los eventos, las fronteras entre servicios.

Trade-off — una buena práctica sin contexto es un mal consejo

Un todoterreno gana a un turismo en un camino de barro. El turismo gana al todoterreno en la ciudad. Una bicicleta gana a ambos si hay que ir tres manzanas y no hay dónde aparcar.

Una decisión arquitectónica no se puede evaluar fuera de su contexto. REST, GraphQL, Kafka, PostgreSQL, Kubernetes, microservicios, monolito: todo son herramientas con precio. Un trade-off es un intercambio deliberado: latencia frente a throughput, consistencia frente a disponibilidad, time-to-market frente a mantenibilidad, simplicidad frente a flexibilidad.

El arquitecto no dice «Kafka es mejor que RabbitMQ». Dice: «necesitamos orden de eventos por clave, alto throughput, replay y un log duradero; a cambio pagamos la complejidad operativa de Kafka». Así suena el lenguaje profesional.

Over-engineering vs under-engineering — la complejidad es un impuesto

Cada abstracción nueva es como una habitación más en la casa. La habitación puede ser útil, pero hay que limpiarla, calentarla, repararla y explicársela a las visitas.

La complejidad es útil cuando compra una propiedad importante: aislamiento de fallos, despliegue independiente, seguridad, escalado, testabilidad. Pero la complejidad «para el futuro» suele convertirse en un impuesto permanente.

Los términos over-engineering y under-engineering solo sirven juntos. Over-engineering: la complejidad apareció antes del dolor real. Under-engineering: el sistema ya ha chocado con sus límites y la arquitectura no dejó espacio para crecer. El trabajo del arquitecto no es elegir un extremo, sino sostener el punto medio.

Technical debt — un préstamo, no basura

Un préstamo para comprar equipo puede acelerar un negocio. Un préstamo para una fiesta solo deja resaca e intereses.

La deuda técnica es una decisión que nos acelera ahora pero crea un coste futuro de cambio. A veces es lo correcto: hay que probar el mercado, cumplir un plazo, retener a un cliente. El problema empieza cuando el equipo etiqueta todo como deuda: código malo, falta de tests, dependencias caóticas, librerías anticuadas.

Un modelo útil es el Technical Debt Quadrant de Martin Fowler: deliberada / inadvertida y prudente / imprudente. Deuda deliberada y prudente: «de momento no hacemos multi-región porque tenemos 200 usuarios y un solo mercado». Deuda inadvertida e imprudente: «no sabíamos que necesitábamos transacciones».

Debt interest — la deuda cobra intereses

Si la carretera está rota, cada viaje dura cinco minutos más. Un mes después ya no es un bache: es un impuesto sobre toda la ciudad.

Los intereses de la deuda técnica son la ralentización de cada cambio siguiente. Cuanto más a menudo toca el equipo una zona, más cara es la deuda. Por eso la deuda en el dominio caliente es más peligrosa que la de un panel de administración que casi nadie usa.

El arquitecto negocia una estrategia de pago: qué cuenta exactamente como deuda, qué riesgo crea, cuándo revisamos la decisión, qué señal dice «es hora de pagar». Sin eso, la «deuda técnica» se vuelve un argumento emocional, no un instrumento gestionado.

Cognitive load — la arquitectura tiene que caber en una cabeza humana

Un mapa de metro es útil no porque muestre cada tornillo del túnel. Muestra líneas, transbordos y dirección de viaje. Eso basta para decidir.

La cognitive load es el esfuerzo mental que un sistema exige a un ingeniero. Existe la intrinsic load: la complejidad del propio dominio. Y la extraneous load: complejidad extra por mala arquitectura, vínculos poco obvios, excepciones accidentales y magia. El arquitecto no puede quitar la complejidad del negocio, pero está obligado a reducir la complejidad accidental.

Un buen módulo se entiende por sí solo. Un buen bounded context tiene su propio lenguaje y sus propios invariantes. Un buen equipo es dueño de un área que cabe en su cabeza.

Conway's Law — la estructura de los equipos se convierte en la estructura del sistema

Si tres departamentos no hablan entre sí, su producto casi siempre parece tres productos pegados en un solo menú.

La Conway's Law dice: una organización diseña sistemas que reflejan la estructura de comunicación dentro de la organización. Si las fronteras arquitectónicas no coinciden con las de los equipos, el equipo seguirá invadiendo territorio ajeno.

Team Topologies introduce etiquetas útiles: stream-aligned team, platform team, enabling team, complicated-subsystem team. No es moda de recursos humanos: es una herramienta arquitectónica. A veces, la descomposición correcta del sistema empieza por la descomposición correcta de la responsabilidad.

Cohesion & coupling — cortar por capas, por dominios o por flujo de datos

Un carnicero no corta la res al azar: corta por las articulaciones. Una buena descomposición también busca puntos de ruptura naturales.

Descomponer no es «ordenar en carpetas». Es elegir dónde termina la responsabilidad. Alta cohesión significa que todo dentro de un componente trata de una sola cosa. Bajo acoplamiento significa que el componente sabe poco de los demás.

Un corte horizontal da capas: UI, aplicación, dominio, infraestructura. Un corte vertical da features o bounded contexts: facturación, identidad, catálogo, comentarios. Los sistemas reales necesitan ambos, pero confundir uno con otro es peligroso.

Bounded context — una mala frontera se delata con el cambio

Si cambiar el grifo de la cocina obliga a desmontar el dormitorio, el problema no es el grifo.

Una señal de mala descomposición: un cambio pequeño se propaga por cinco módulos. Otra señal: un módulo cambia por razones distintas: hoy por el producto, mañana por la base de datos, pasado mañana por una integración.

El término de DDD bounded context es útil justo aquí. Es una frontera dentro de la cual las palabras tienen un solo significado. «Customer» en facturación y «Customer» en soporte pueden ser modelos distintos. Forzarlos en uno solo suele crear un modelo «universal» frágil.

Dependency Rule y DIP — las dependencias fluyen hacia el centro

La cimentación no debería depender del color de las cortinas. Si depende, la casa se diseñó al revés.

Clean Architecture, Hexagonal Architecture y Onion Architecture dicen lo mismo: la lógica importante va en el centro y los detalles, fuera. HTTP, SQLAlchemy, Next.js, Kafka, Redis, Stripe: son detalles. Importan, pero no deben definir las reglas de negocio.

El Dependency Inversion Principle dice: la lógica de alto nivel depende de abstracciones y las implementaciones se enchufan desde fuera. En código se ve como puertos y adaptadores: el servicio recibe un PaymentGatewayProtocol, no construye un StripeClient por dentro.

Abstraction — existe para absorber el cambio, no para quedar bonito

Un adaptador va donde los enchufes realmente son distintos. Si pones un adaptador en cada toma solo porque te gustan los adaptadores, la casa se vuelve menos segura.

No toda clase necesita una interfaz. Pero todo lo que toca el mundo exterior, el tiempo, la aleatoriedad, la red, el sistema de archivos o la base de datos debe poder reemplazarse en los tests. Si no, no estás probando lógica de negocio: estás levantando un pequeño sistema de producción dentro de un test unitario.

El precio de una capa son más archivos y más palabras. La recompensa es testabilidad, infraestructura intercambiable y fronteras limpias. Si no hay recompensa, la capa es lastre.

API contract — el contrato importa más que el transporte

Al control de pasaportes no le importa la marca de la puerta. Importa qué documentos se aceptan, qué reglas se aplican y qué pasa cuando algo falla.

REST, GraphQL, gRPC y WebSocket son formas distintas de hablar. REST encaja con APIs orientadas a recursos y con caché sencilla. GraphQL ayuda cuando clientes distintos necesitan formas distintas de lectura. gRPC va bien para comunicación tipada entre servicios. WebSocket sirve para eventos bidireccionales en tiempo real.

La elección del transporte es secundaria. Lo que importa es el API contract: esquema, errores, idempotencia, versionado, backward compatibility, deprecation policy.

Idempotency — te salva del mundo real

Si pulsas diez veces el botón del ascensor, el ascensor no debería llegar y marcharse diez veces. Debería entender que la intención es una sola.

La idempotencia significa que repetir una operación produce el mismo efecto final. En sistemas en red los reintentos son inevitables: timeouts, retries, webhooks duplicados, reinicios de workers. Si crear un pago, un pedido o un mensaje no es idempotente, tarde o temprano el sistema hará algo de más.

El arquitecto diseña la idempotencia a nivel de contrato: idempotency key, unique constraints, reintentos seguros, estados claros.

Data model — los datos viven más que las aplicaciones

Una fachada se repinta en una semana. Una cimentación mal vertida te lo recuerda durante toda la vida del edificio.

El lenguaje, el framework y la UI pueden cambiar varias veces. Pero las tablas, los eventos, las claves, las relaciones y los registros históricos se quedan. Un error en el modelo de datos suele convertirse en un error en todas las versiones futuras del producto.

La normalización reduce la duplicación y el riesgo de divergencia. La desnormalización acelera las lecturas y simplifica el read model. Los sistemas OLTP están optimizados para transacciones, los OLAP para analítica. No se puede diseñar un único modelo como si fuera a servir perfectamente a ambas clases de trabajo.

Event sourcing y CQRS — una herramienta potente, no una religión

Un extracto bancario no guarda solo el saldo actual: guarda el historial de operaciones. Eso es lo que permite explicar de dónde sale el saldo.

Event sourcing guarda los cambios como una secuencia de eventos y reconstruye el estado actual a partir de ellos. Es útil cuando importan el historial, la auditoría, la recuperación de estado y el replay. El precio es alto: evolución del esquema de eventos, complejidad de las consultas, eventual consistency, herramientas exigentes.

CQRS separa el modelo de escritura del modelo de lectura. Puede simplificar mucho los sistemas de lectura complejos, pero añade sincronización y retraso. Introducir CQRS solo porque «suena a arquitectura» es una forma cara de convertir un problema en dos.

Single source of truth — no significa una sola base de datos

Una empresa puede tener muchos informes, pero tiene que haber un único registro oficial de nóminas. Si no, el día de pago se convierte en teatro.

Single source of truth significa que, para cada hecho importante, sabes dónde vive la versión autorizada. Una caché, un índice de búsqueda, una read replica, una vista materializada: son copias derivadas. Pueden ser útiles, pero no deben hacerse pasar por la verdad primaria.

Los componentes stateful guardan estado y exigen cuidado: transacciones, bloqueos, recuperación, backup. Los componentes stateless son más fáciles de escalar y reemplazar, pero siguen dependiendo de un estado que vive en otro sitio.

Cache y locking — una segunda verdad que a veces miente

El horario pegado en la nevera es cómodo, hasta que alguien mueve la reunión en el calendario del móvil.

Una cache compra velocidad a costa de frescura. La pregunta más difícil sobre la caché no es «cómo meter cosas», sino «cuándo invalidar». TTL, explicit invalidation, write-through, write-behind, cache-aside: son compromisos distintos entre complejidad, frescura y carga.

Una race condition aparece cuando dos operaciones compiten por un estado. El optimistic locking dice: «los conflictos son raros, comprobaremos la versión al escribir». El pessimistic locking dice: «los conflictos son peligrosos, bloquearemos de antemano». Ambos son correctos en condiciones distintas.

CAP y PACELC — la red es una fuente de incertidumbre

Un monolito es una conversación en una sola habitación. Un sistema distribuido es una correspondencia entre personas en husos horarios distintos: las cartas a veces se pierden, llegan dos veces o se retrasan.

En un sistema distribuido no puedes simplemente «llamar a una función». Entre servicios hay red, timeouts, retries, partial failure, relojes distintos, versiones de código distintas. Lo que en el monolito era una transacción local se convierte en un protocolo de coordinación.

El teorema CAP se suele resumir mal. La versión útil en la práctica: durante una network partition, eliges entre consistencia y disponibilidad. PACELC añade: incluso sin partición, sigues eligiendo entre latencia y consistencia.

Consistency models y Saga — la consistencia viene en sabores

Dos personas mirando el mismo Google Doc ven lo mismo casi al instante. Dos personas mirando una transferencia bancaria no pueden conformarse con «casi».

La strong consistency te da la verdad fresca, pero cuesta latencia y disponibilidad. La eventual consistency tolera una divergencia temporal, pero a menudo escala mejor. La causal consistency conserva la causa y el efecto: si el evento B depende de A, B no debe hacerse visible antes que A.

El saga pattern divide una transacción de negocio larga en pasos con compensating actions. El two-phase commit da atomicidad entre recursos, pero es caro y frágil en sistemas distribuidos reales. El arquitecto elige no el modelo «más estricto», sino el suficiente para el riesgo.

Modular monolith — un comienzo a menudo infravalorado

Un almacén bien organizado es más rápido que diez pequeños si el mismo repartidor tiene que ir de uno a otro de todos modos.

Un monolito no es un insulto. Un mal monolito es una maraña de dependencias sucias. Un buen modular monolith tiene fronteras internas estrictas, dominios separados, interfaces explícitas y una sola deployment unit. Para un equipo pequeño suele ser el mejor punto de partida.

Los microservicios ayudan cuando necesitas releases independientes, equipos autónomos, perfiles de escalado distintos, aislamiento de fallos o stacks tecnológicos distintos. El precio: llamadas de red, observability, transacciones distribuidas, sobrecarga de DevOps, versionado, seguridad entre servicios.

Distributed monolith y Strangler Fig — lo peor de ambos mundos, y la salida

Es como vivir en apartamentos separados pero ir al de al lado a por cada cuchara.

Un distributed monolith parece microservicios, pero los servicios no son autónomos: esquema de base de datos compartido, cadenas de llamadas síncronas, releases que solo salen juntos, cambios que obligan a tocar a todos. El equipo paga el coste de la distribución sin obtener la independencia.

El Strangler Fig pattern permite migrar con cuidado: envolver el sistema viejo, extraer capacidades poco a poco, cortar por fronteras de negocio reales, no por tablas.

Una llamada de teléfono exige que ambos lados estén libres ahora. Una carta se puede leer luego, pero puede perderse, retrasarse o exigir respuesta.

Una llamada síncrona (sync) es fácil de razonar: envías, recibes respuesta. Pero si el receptor es lento o no está disponible, sufre el emisor. Async mediante una queue o pub/sub permite aguantar fallos y picos de carga, pero exige otro modelo mental.

Una cola suele repartir el trabajo entre consumidores. Pub/sub difunde un evento a muchos suscriptores. Kafka, RabbitMQ, SQS, Redis Streams: herramientas distintas con modelos distintos de orden, durabilidad, replay y operación.

At-least-once delivery — exactly-once casi siempre es marketing

Si una carta se envía dos veces, una contabilidad decente no debería pagar el sueldo dos veces.

En la práctica diseñas para at-least-once delivery más un idempotent consumer. Un mensaje puede llegar dos veces; el handler tiene que sobrevivir a eso. Una dead letter queue es para los mensajes que no se pudieron procesar tras un número razonable de intentos.

Backpressure es la señal «el receptor no da abasto». Sin ella, el sistema acepta todo con elegancia y luego muere por dentro.

Tail Latency — el tiempo de respuesta medio casi siempre miente

Si nueve personas recibieron su comida en un minuto y la décima esperó una hora, el promedio parece tolerable. La décima no opina lo mismo.

Este es el concepto de tail latency. Primero, tres palabras. Latency es el retraso de una sola operación. Throughput es cuántas operaciones maneja el sistema por unidad de tiempo. Los percentiles muestran la distribución: p50 es la mediana, p95 significa que el 95 % de las peticiones son más rápidas que ese valor, p99 es la cola.

El usuario no siente el promedio: siente la cola. La tail latency importa sobre todo en sistemas donde una pantalla depende de varias llamadas al backend: la probabilidad de una respuesta lenta se acumula.

Profiling — haz profile antes de optimizar

Arreglar el rendimiento sin un profile es como tratar a un paciente a partir de una foto de sus zapatos.

Esta es la práctica del profiling: primero mide, luego optimiza. Consultas N+1, round trips de más, un mal índice, serialización, contención de bloqueos, pausas de GC, caché fría: todo parece «lento», pero se cura de formas distintas.

La Ley de Amdahl te recuerda: la aceleración está limitada por la parte del sistema que realmente optimizas. La Ley de Little ayuda a pensar en colas: más latencia con el mismo throughput significa más trabajo en curso dentro del sistema.

Vertical vs Horizontal Scaling — compran cosas distintas

Puedes comprar un camión grande. Puedes comprar diez pequeños. El primero es más simple, los segundos más flexibles, pero requieren un despachador.

El vertical scaling (scale up) consiste en hacer más fuerte una máquina. Es simple mientras haya margen. El horizontal scaling (scale out) consiste en añadir más instancias. Es más flexible, pero requiere una capa de aplicación stateless, load balancing, una estrategia de estado compartido y observability.

Las bases de datos escalan peor que las aplicaciones. Las read replicas ayudan con las lecturas, no con las escrituras. El sharding reparte los datos pero te obliga a elegir una shard key. Una mala shard key convierte el escalado en un desequilibrio de carga.

Scale Cube — escalar funcionalidades importa tanto como escalar carga

Una ciudad no crece solo en población. Crece en escuelas, hospitales, carreteras y normas.

El sistema tiene que absorber no solo más tráfico, sino más superficie de producto. Si cada nueva funcionalidad exige reescribir un God-service compartido, el sistema no escala a nivel organizativo.

El modelo útil aquí es el scaling cube: el eje X es clonar, el eje Y es dividir por función, el eje Z es particionar por datos o tenants.

Retry, Circuit Breaker, Bulkhead — un retry sin estrategia es un ataque contra ti mismo

Si una puerta no se abre, llamar una vez es razonable. Llamar mil veces por segundo ya es un problema para la puerta y para los vecinos.

El Retry sirve para fallos transitorios. Pero los retries necesitan un límite, un timeout, exponential backoff y jitter. Si no, una caída parcial se convierte en una retry storm.

Un circuit breaker deja de llamar temporalmente a una dependencia atascada. El bulkhead pattern aísla recursos: si un downstream muere, no se lleva consigo todos tus threads de worker y pools de conexiones.

SLI / SLO / SLA — los SLOs convierten la fiabilidad en un contrato

«Haremos lo posible» no es un horario de trenes. Un horario dice qué cuenta como normal y qué cuenta como fallo.

SLI es lo que mides: tasa de éxito, latencia, frescura. SLO es el objetivo: 99,9 % de peticiones exitosas en 30 días. SLA es una promesa al cliente con consecuencias.

El error budget te dice cuánta falta de fiabilidad puedes gastar. Si el presupuesto se agota, el equipo deja de perseguir funcionalidades y arregla la fiabilidad. Esa es la versión, en lenguaje de negocio, de la calidad de ingeniería.

Authentication vs Authorization — cosas distintas

Un pasaporte prueba quién eres. Un billete prueba adónde puedes ir. Uno no sustituye al otro.

Authentication (AuthN) responde a «¿quién es?». Authorization (AuthZ) responde a «¿qué se le permite hacer?». Confundirlas es peligroso: un usuario puede haber iniciado sesión correctamente y aun así no tener derecho a leer la factura de otro.

RBAC concede permisos mediante roles. ABAC considera atributos: dueño del recurso, tenant, región, estado del objeto. La auth basada en sesión es más fácil de revocar; JWT es más fácil de verificar sin base de datos, pero más difícil de revocar. La elección depende de las amenazas y del ciclo de vida.

Threat Modeling — paranoia profesional

Un buen arquitecto piensa como un atacante no porque desconfíe de la gente, sino porque confía en la realidad.

El threat modeling es una búsqueda sistemática de amenazas antes del ataque. STRIDE ayuda a encontrarlas: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. La defense in depth significa varias capas de protección: validación de entrada, authz, cifrado, audit log, rate limiting, least privilege.

La gestión de secretos no es «poner la clave en env y olvidarse». Hay que entender la rotación, el acceso, la auditoría, el blast radius y qué pasa durante una fuga.

Observability — el monitoring te dice qué falla, la observability te ayuda a entender por qué

La luz de «check engine» es útil, pero el mecánico aún necesita indicadores, historial y herramientas de diagnóstico.

El monitoring responde a «algo va mal». La observability responde a «por qué». Los tres pilares de la observability: logs, metrics, traces. El structured logging permite consultar los logs. Las métricas muestran agregados. El distributed tracing sigue el camino de una petición por los servicios.

Un correlation ID es una cosita que salva noches: un único ID de petición fluye por gateway, servicio, cola, worker y downstream.

Symptom-based Alerting — alerta por síntomas

Al usuario no le importa que la CPU esté al 92 %. Le importa que el checkout no funciona.

Una buena alerta habla del dolor del usuario; esto es el symptom-based alerting: tasa de errores, latencia, pagos fallidos, datos obsoletos. Una mala alerta habla de una causa que puede ser perfectamente normal. Si las alertas hacen ruido, el equipo deja de confiar en ellas.

Un runbook responde a «qué hacer a las 3 de la madrugada». Un post-mortem responde a «cómo nos aseguramos de que no vuelva a pasar». Blameless: el objetivo es mejorar el sistema, no encontrar al culpable.

ADR — un Architecture Decision Record vence a la memoria

Un acuerdo oral vale hasta las primeras vacaciones, la primera renuncia o la primera discusión seis meses después.

Un Architecture Decision Record recoge el contexto, la decisión, las alternativas y las consecuencias. Un ADR no tiene que ser una novela. Un buen ADR responde: qué problema resolvíamos, qué elegimos, por qué no elegimos las alternativas, cuándo lo revisamos.

La documentación no está para la auditoría: está para el siguiente cambio. Un ingeniero nuevo tiene que entender no solo el «cómo», sino el «por qué».

C4 Model — un diagrama es una herramienta de trabajo, no una decoración

Un mapa de metro no muestra los cables ni los tornillos. Muestra líneas y transbordos. Eso basta para no perderse.

El C4 model te da cuatro niveles: Context, Container, Component, Code. Los tres primeros suelen bastar. Un sequence diagram es útil cuando importa el orden de las interacciones. El UML completo rara vez hace falta; los diagramas sueltos, sí.

La living documentation vive junto al código, se actualiza en el PR y se revisa. Un documento en un wiki olvidado se convierte enseguida en ficción histórica.

Risk Translation — traduce el riesgo al idioma de la audiencia

Un médico no usa solo nombres en latín con el paciente. Explica qué va a doler, cuánto dura el tratamiento y qué hay que evitar.

Esta es la práctica de la risk translation. A un ingeniero le puedes decir: «no tenemos idempotencia en el callback de pago». El negocio necesita oír: «si el webhook reintenta, podemos cobrar dos veces o enviar el producto dos veces; es un riesgo financiero y de reputación».

El stakeholder mapping te ayuda a ver a quién le importa qué: producto quiere time-to-market, seguridad quiere reducir riesgo, finanzas quiere un coste predecible, soporte quiere un comportamiento comprensible, ingeniería quiere mantenibilidad.

RFC — una propuesta escrita baja la temperatura de una discusión

Una discusión en la pizarra suele ganarla el que más grita. Una propuesta escrita obliga a que los argumentos se sostengan aparte de la voz.

Un RFC (Request for Comments) describe el problema, las restricciones, las opciones, la solución elegida, los riesgos y el plan de despliegue. Un buen RFC invita a la crítica antes de que la decisión se convierta en norma.

Disagree and commit solo funciona después de una discusión honesta. Si no se escuchó al equipo, eso no es commit: es supresión.

Influence without Authority

Un director de orquesta no toca todos los instrumentos, pero sin él la orquesta pronto se convierte en un conjunto de talentos que tocan piezas distintas.

Este es el concepto de influence without authority. El arquitecto no debe convertirse en un cuello de botella para cada decisión. Su trabajo es fijar principios, explicar fronteras, hacer crecer a la gente e intervenir donde el coste de un error es alto.

El mentoring de un arquitecto no es «haz lo que yo hago». Es enseñar las preguntas: qué alternativas has visto, a qué renunciaste, cómo vas a probar el riesgo, dónde termina la responsabilidad.

Delegation with Guardrails — delegar no es transferir la responsabilidad

Un capitán puede ceder el timón, pero no puede decir que el rumbo del barco ya no es asunto suyo.

Una parte de las decisiones arquitectónicas deben tomarlas los equipos. Si no, el arquitecto se convierte en una cola. Pero tiene que haber guardrails: principios, revisión, ADRs, restricciones de plataforma, quality gates.

El arquitecto interviene cuando una decisión es irreversible, rompe invariantes del sistema, crea riesgo de seguridad o afecta a varios equipos.

Non-functional Requirements — también son requisitos de negocio

Para una tienda, «el checkout funciona en el Black Friday» no es un detalle técnico: es dinero.

Los non-functional requirements (NFRs) —rendimiento, disponibilidad, seguridad, compliance, operabilidad— no son «caprichos técnicos». Son propiedades del producto. El arquitecto los traduce a impacto de negocio: ingresos perdidos, riesgo regulatorio, coste de soporte, velocidad de lanzamiento al mercado.

El cost of delay te ayuda a hablar no solo del coste de hacer el trabajo, sino del coste de esperar. A veces hace falta una inversión arquitectónica sin ROI inmediato, porque sin ella las siguientes funcionalidades empiezan a salir más caras.

Build vs Buy — no es cuestión de orgullo

No toda empresa debería construir su propia central eléctrica solo para encender la luz.

Construir te da control y diferenciación. Comprar te da velocidad y reduce la carga operativa. El vendor lock-in es un riesgo real, pero por sí solo no es un argumento contra comprar. La pregunta: ¿cuánto cuesta salir si el proveedor cambia el precio, la API o la calidad?

El arquitecto ayuda a producto a ver el capability map: qué capacidades son el núcleo del negocio y cuáles conviene comprar.

Specification-driven Development — la calidad de la spec se convierte en el cuello de botella

Si la cuadrilla de obra se vuelve diez veces más rápida, la restricción que manda deja de ser la velocidad de los ladrillos. Pasa a ser la calidad de los planos.

Los agentes de IA aceleran la implementación, pero no eliminan la arquitectura. Una tarea mal planteada simplemente se convierte en mal código más rápido. Specification-driven development significa que el artefacto principal es la especificación de comportamiento, fronteras, invariantes, tests y criterios de aceptación.

En un proceso AI-native, el arquitecto escribe menos código de bajo nivel y más prosa precisa. Revisa el diff, los tests, las fronteras arquitectónicas y la alineación con la spec.

Agent Output Review — el código de un agente merece la misma disciplina que el PR de una persona

Un junior rápido que escribe mil líneas por hora sigue necesitando revisión. La velocidad no hace correcto al código.

No puedes aceptar el código de un agente solo porque compila. Hacen falta tests, evals, fronteras de import, comprobaciones de tipos, revisión de seguridad. Las scenario evaluations importan especialmente: el sistema tiene que pasar casos reales, no solo el happy path.

Una organización AI-native gana no donde «todos hacen vibe-coding», sino donde hay especificaciones sólidas, iteraciones pequeñas, comprobaciones automatizadas y responsabilidad arquitectónica.

Ivory Tower Architect

Alguien dibuja una ciudad perfecta en lo alto de la colina, pero nunca baja a ver por dónde camina la gente en realidad.

Este es el antipatrón del ivory tower architect: decisiones tomadas lejos del código, de la operación y del equipo. Los diagramas son preciosos, pero la implementación sufre. La cura es simple: leer PRs, mirar incidentes, hablar con los ingenieros, recorrer tú mismo el camino de un cambio.

Resume-driven Development y Cargo Cult

Comprar un camión de bomberos porque impresiona a los vecinos es raro si no tienes agua ni bomberos.

El resume-driven development elige tecnologías por una línea en el CV. La cargo cult engineering copia la forma de la decisión de otro sin su razón. El síndrome NIH (Not Invented Here) te obliga a escribir lo tuyo donde una herramienta externa madura lo haría mejor.

Otra trampa es el technical perfectionism. La arquitectura perfecta que nunca llegó al usuario pierde frente a un sistema suficientemente bueno que se entrega y puede evolucionar.

T-shaped / M-shaped Skills — aprende de los sistemas, no del hype

Un cocinero no crece mirando anuncios de cuchillos, sino entendiendo los ingredientes, el calor, el tiempo y el sabor.

Vale la pena estudiar las tecnologías nuevas mediante preguntas: qué problema resuelven, qué precio introducen, dónde han fallado ya, cuáles son las alternativas, qué tiene que ser cierto para que resulten útiles.

Las T-shaped skills te dan profundidad en un área y amplitud en las vecinas. Las M-shaped skills aparecen en un arquitecto maduro: varios pilares profundos: datos, distribución, seguridad, producto, herramientas de IA.

Learning in Public — acelera la madurez

Cuando explicas una decisión por escrito, los huecos de tu pensamiento aparecen antes de que los encuentre producción.

Learning in public significa aprender abiertamente, por escrito. Escribe ADRs, RFCs, notas de ingeniería, post-mortems, desgloses breves de decisiones. Aprende de arquitectos más fuertes que tú: no solo qué eligieron, sino cómo razonaron.

El arquitecto al que la gente imita normalmente no es el que más términos conoce. Es la persona junto a la cual el equipo empieza a hacer mejores preguntas.

El mapa del curso: cómo se conecta todo

Un mapa de metro al final del viaje: ahora ves dónde se cruzan las líneas.

La mentalidad da forma a la estructura, a los datos y a la calidad. La estructura se registra en documentos, la calidad se verifica con seguridad y operaciones, y los documentos y los riesgos convencen al negocio. Todo junto escala hacia el trabajo AI-native y el crecimiento personal.