¿Qué hace un arquitecto de software? Estructura, compromisos y longevidad

Un arquitecto de software (o de soluciones) diseña cómo encajan los sistemas: límites de servicios, responsabilidad de datos, patrones de integración y requisitos no funcionales como escala, seguridad y operabilidad. Guía al equipo en los compromisos; no solo dibuja diagramas.

Le explico el puesto con claridad: qué hace la persona de verdad, qué competencias importan y cuándo conviene contratarla, sin jerga vacía.

Qué hace en el día a día

En una semana típica, el puesto cubre:

• Proponer opciones de arquitectura con costes y riesgos explícitos.
• Definir estándares, ADR y contratos de integración.
• Revisar diseños críticos y evitar la complejidad accidental.
• Alinear las decisiones técnicas con los límites de negocio y el plazo.
• Mentorar a los leads y mantener el sistema evolucionable.

Competencias que de verdad importan

Las herramientas cambian; lo de fondo sigue valiendo:

• Alfabetización amplia de stack, sistemas distribuidos, modelado de datos
• Explicar los compromisos a dirección e ingeniería
• Pensar en seguridad, rendimiento y operación
• Pragmatismo: arquitectura suficiente, no diseños de torre de marfil

Cuándo merece la pena contratar

Productos de varios equipos, migraciones de plataforma, integraciones complejas — o cuando «añadimos otro servicio» ya está armando un laberinto.

En síntesis

La arquitectura falla cuando ignora la realidad de la entrega. Los mejores arquitectos se quedan cerca del código y de los incidentes.