ROLES

Software Architect

La persona responsable de la forma del software a nivel de sistema: las grandes decisiones estructurales que son caras de revertir y los requisitos no funcionales que nadie más asume.

Última revisión: 2026-06-02 porKevin Riedl wiki ↗

Un Software Architect es dueño de las decisiones difíciles de deshacer. Cómo se divide el sistema en servicios o módulos, cómo fluyen los datos a través de él, dónde están los límites, a qué tecnologías se compromete el stack y cómo aguanta el conjunto bajo carga, fallo y crecimiento. Las funcionalidades individuales son baratas de cambiar. Estas decisiones estructurales no lo son, por lo que necesitan a alguien pensando a nivel de sistema en lugar de a nivel de funcionalidad.

El valor real está en los requisitos no funcionales: rendimiento, escalabilidad, seguridad, fiabilidad, mantenibilidad. Son las cosas que ningún ticket de funcionalidad asume y que hunden silenciosamente un producto cuando se ignoran. El trabajo del arquitecto es nombrar las contrapartidas en voz alta. Más rápido de construir ahora frente a más barato de cambiar después. Simple y limitado frente a flexible y complejo. No hay arquitectura gratis, solo contrapartidas que elegiste a propósito o contrapartidas que heredaste por accidente.

La mayoría de las startups no necesitan un Software Architect dedicado, y contratar uno pronto suele ser un error. A pequeña escala la arquitectura es pequeña, y el tech lead o el CTO la asume como parte de su trabajo. Un arquitecto a tiempo completo sin código que escribir y sin equipo que liderar tiende a producir diagramas y documentos de estándares que el equipo luego ignora. El rol se gana su sitio una vez que el sistema es lo bastante grande como para que nadie tenga el cuadro completo en la cabeza.

La opinión honesta: “Solutions Architect” en el organigrama de un proveedor a menudo significa un rol de preventa que diseña sistemas que nunca tendrá que mantener. Un buen arquitecto se mantiene lo bastante cerca del código como para sentir las consecuencias de sus propias decisiones. Si la persona que dibuja las cajas nunca tiene que vivir dentro de ellas, las cajas estarán mal.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Es dueño de las decisiones a nivel de sistema que son caras de revertir: cómo se estructura el sistema, cómo fluyen los datos, a qué tecnologías se compromete y cómo aguanta bajo carga y fallo. También es dueño de los requisitos no funcionales como rendimiento, seguridad y fiabilidad que ningún ticket de funcionalidad cubre.
Un tech lead lidera el trabajo técnico de un equipo en el día a día. Un arquitecto piensa en todo el sistema y la estructura a largo plazo. En un equipo pequeño son la misma persona. La separación aparece solo cuando el sistema es demasiado grande para que una persona sostenga el cuadro completo y a la vez lidere un equipo.
Normalmente no. A pequeña escala la arquitectura es lo bastante pequeña como para que el tech lead o el CTO la asuma. Un arquitecto dedicado pronto tiende a producir documentos que el equipo ignora. El rol se gana su sitio una vez que ninguna persona puede ya sostener todo el sistema en la cabeza.