Software Architect · Módulo 01
El arquitecto no es quien dibuja diagramas bonitos. Es el ingeniero que se hace cargo de la forma del sistema y de las consecuencias de las decisiones a lo largo del tiempo.
Rol · ownership · horizonte temporal
Un senior engineer resuelve bien los problemas. El arquitecto verifica si los problemas correctos llegaron siquiera a entrar en el trabajo.
El arquitecto es dueño de las consecuencias
El ingeniero coloca la puerta derecha. El arquitecto decide en qué parte del edificio debería estar la puerta — para que no la cruce todo el tráfico del depósito.
La diferencia entre un senior engineer y un arquitecto no está en que el arquitecto conozca más patterns. El senior normalmente se hace cargo de la calidad de la solución dentro de una tarea bien definida: implementar, simplificar, acelerar, cubrir con tests, hacer code review. El arquitecto se hace cargo de que la forma de la solución sobreviva al paso del tiempo: nuevos equipos, nuevos clientes, crecimiento de datos, requisitos que cambian, incidentes, auditorías, migraciones.
Un buen arquitecto sabe decir: "Esta feature parece chica, pero cambia el modelo de ownership de los datos", o "Si exponemos este contrato ahora, lo vamos a estar manteniendo durante años". Eso no es frenar el delivery. Es proteger al equipo de decisiones que parecen baratas sólo dentro del sprint actual.
Lo que el arquitecto sostiene personalmente
El capitán no aprieta cada tornillo del barco, pero responde por el rumbo, la carta de navegación, los riesgos y el momento en que hay que cambiar la ruta.
El arquitecto no está obligado a elegir personalmente cada librería. Pero sí debe ser dueño de las decisiones que fijan la trayectoria del sistema: boundaries entre subsistemas, modelo de datos, contratos de integración, estrategia de tenancy, seguridad, observability, reliability, deployment topology, camino de migración.
Hay una distinción útil: reversible decisions e irreversible decisions. Las reversibles se pueden delegar agresivamente: un componente concreto de UI, un internal helper, el formato de una línea de log dentro de un servicio. Las decisiones caras de revertir el arquitecto las tiene que ver, como mínimo: la elección de base de datos, una external API, el ownership de los datos, partir el monolito, el modelo de autenticación.
Una misma tarea puede ser de ingeniería o arquitectónica — depende de las consecuencias.
Ejemplo: agregar comentarios al blog
A primera vista parece una feature chica: un formulario, una lista, un botón de enviar. Debajo aparecen rápido un sistema de permisos, moderación, antispam, almacenamiento, borrado y notificaciones.
La mirada de ingeniería: armar un endpoint POST /comments, una tabla comments, un componente de lista y un formulario. La mirada arquitectónica suma preguntas: ¿los comentarios se atan al slug del post o al locale? ¿Qué pasa cuando se renombra un slug? ¿Quién puede borrar? ¿Cuál es la source of truth para el usuario? ¿Necesitamos un modelo de soft-delete? ¿Cómo nos defendemos del spam y del rate abuse? ¿Cómo agregamos owner moderation más adelante?
Una buena decisión arquitectónica puede seguir siendo simple: una tabla comments, thread por slug, typed domain errors, rate limiting, owner moderation después. Pero ya es una decisión consciente.
Antiejemplo: el arquitecto como aprobador en jefe
Si todos esperan a una persona para renombrar un campo, eso no es arquitectura. Es una cola.
Un mal arquitecto se convierte a sí mismo en bottleneck. Exige review de cada clase, discute el nombre de variables locales y llama a eso "control de la arquitectura". El equipo deja de pensar por sí mismo y el arquitecto se ahoga en detalles.
El modelo correcto es otro: el arquitecto define principios, boundaries y quality gates. El equipo toma decisiones locales por sí solo, pero sabe dónde empieza la zona de alto riesgo.
- ¿Qué decisiones en tu sistema son caras de revertir? - ¿Quién es hoy el owner del modelo de datos? - ¿Qué decisiones puede tomar el equipo sin el arquitecto? - ¿Dónde se volvió el arquitecto un bottleneck en lugar de un amplificador?