Software Architect · Módulo 19
La arquitectura se vuelve real sólo cuando el equipo entiende la decisión, acepta su costo y puede actuar sin supervisión constante.
Stakeholders · facilitation · vocabulary · diagrams
El arquitecto tiene que hablar el idioma de su audiencia sin aplanar el sentido en consignas vacías.
Audiencias distintas necesitan explicaciones distintas
El conductor, el pasajero y el mecánico describen la misma ruta de tres maneras diferentes. Las tres descripciones pueden ser correctas.
Un ingeniero necesita boundaries, contratos, edge cases, un migration plan. Un product manager quiere entender el impact on roadmap, el riesgo y el sequencing. Al negocio le importan cost, time-to-market, compliance, reliability y future optionality.
Un mal arquitecto le habla a todos igual y después se ofende porque no le entendieron. Uno bueno mantiene la precisión técnica y cambia el nivel de abstracción.
El arquitecto facilita la decisión
Un buen moderador no gana la discusión. Ayuda al grupo a ver las opciones, los riesgos y elegir un rumbo.
La comunicación del arquitecto no es una presentación tipo "mi solución es la correcta". Es un proceso: formular el problem statement, juntar los constraints, nombrar las options, comparar los trade-offs, registrar la decisión y sus consequences.
Cuando la gente entiende por qué se descartó una alternativa, la resistencia suele bajar — incluso si la decisión es incómoda.
La comunicación profesional hace los compromisos visibles y verificables.
Ejemplo: explicar por qué no nos pasamos a microservicios
A veces la forma más rápida de acelerar la obra no es sumar otra cuadrilla — es sacar pasos de aprobación.
El arquitecto dice: "Nos quedamos en modular monolith por dos trimestres. Razones: un solo equipo, ritmo de release compartido, baja carga, no hay ownership independiente por servicio. Vamos a introducir module boundaries y ADRs. Lo revisamos cuando aparezca un equipo separado de billing o un release de compliance independiente".
Eso no es "los microservicios son malos". Es una decisión con contexto y un trigger de revisión.
Antiejemplo: apoyarse en la autoridad
"Soy el arquitecto, por eso" cierra la conversación pero nunca crea entendimiento.
El arquitecto impone Kafka porque "es el enterprise standard", sin explicar el problema, el costo ni las alternativas. El equipo acepta formalmente, no entiende el modelo, comete errores y empieza a esquivar la decisión.
En arquitectura, la autoridad sin claridad casi siempre genera resistencia silenciosa.
- ¿Cómo voy a explicar esta decisión a un ingeniero, a un PM y al CEO? - ¿Qué alternativas se consideraron honestamente? - ¿Dónde están escritas las consequences? - ¿Qué va a poder decidir el equipo por sí solo después de esta conversación?