Software Architect · Módulo 24
Un arquitecto no crece coleccionando tecnologías. Crece viendo las consecuencias de las decisiones, aprendiendo de los sistemas y elevando la calidad de su reasoning.
Practice · incidents · writing · mentoring · review
La maestría arquitectónica surge de una práctica repetible: leer sistemas, tomar decisiones, comprobar las consecuencias y refinar el modelo de pensamiento.
Hay que aprender sobre sistemas reales
Un ajedrecista no mejora memorizando los nombres de las aperturas. Mejora analizando partidas y errores.
Los libros y los artículos importan, pero el arquitecto crece más rápido cuando revisa decisiones reales: por qué cayó el sistema, por qué se demoró la migración, por qué el equipo eligió esta API, por qué este módulo se volvió difícil de cambiar.
Un hábito útil es llevar un decision journal: qué se decidió, cuáles eran las assumptions, cuáles los risks, el expected outcome y cuándo revisarlo. Después de unos meses se transforma en material para calibrar el pensamiento.
El writing hace verificable el pensamiento
Mientras la idea sólo vive en tu cabeza, parece clara. En el papel se ven enseguida las uniones que faltan.
El arquitecto tiene que escribir con regularidad: ADRs, design notes, migration plans, incident reviews, technical strategy. Escribir obliga a nombrar de forma explícita context, constraints, alternatives y consequences.
Un buen texto no tiene que ser largo. Tiene que permitir que otro ingeniero retome el reasoning y siga el trabajo.
El crecimiento del arquitecto se mide por la calidad de las decisiones del equipo, no por la cantidad de tecnologías que sabe nombrar.
Ejemplo: un incident review sin buscar culpables
Después de un accidente, la aviación mira el sistema: procedimientos, instrumentos, entrenamiento, fatiga, comunicación. No sólo a la última persona frente al panel.
El equipo hace un blameless postmortem: timeline, impact, detection, contributing factors, what went well, action items. El arquitecto busca mejoras sistémicas: un missing timeout, un runbook débil, una alerta ausente, una dependency chain peligrosa.
Así el incidente se vuelve material para que crezcan la architecture y las operations.
Antiejemplo: coleccionar tecnologías en lugar de judgment
Una colección de herramientas caras no te convierte en un buen artesano si no entendés el material.
El ingeniero estudia todo lo nuevo: el próximo framework, base de datos, broker, cloud service. Pero nunca entrena trade-off thinking, comunicación, ownership, reliability ni data modeling. El vocabulario crece; la calidad de las decisiones, no.
Las tecnologías importan, pero un arquitecto vale por su judgment: cuándo aplicar, cuándo no aplicar y qué costo crea la decisión.
- ¿Cuáles de mis assumptions de los últimos seis meses resultaron equivocadas? - ¿Qué decisiones revisé después de que llegaron los datos? - ¿Qué escribí para que el equipo sea más autónomo? - ¿Qué habilidad limita hoy más fuerte mi nivel arquitectónico?