El Rol del Arquitecto de Software
Nivel básico — qué responsabilidades tiene un arquitecto, en qué se diferencia de un tech lead o un Engineering Manager, y qué tipos existen en la industria.
El problema
En algunas empresas el "arquitecto" es el desarrollador más senior que dibuja diagramas. En otras es un rol de gestión sin código. En otras, un consultor externo que aparece al inicio del proyecto y desaparece.
Situación típica: una empresa contrata un "Arquitecto de Software" esperando que diseñe el sistema completo. El arquitecto espera definir estándares y revisar código. El equipo espera un tech lead que resuelva problemas técnicos diarios. Tres meses después, todos están frustrados porque nadie alineó expectativas. // el título sin definición de scope genera fricción, no valor
Responsabilidades por capas
El arquitecto opera en la intersección de tecnología, negocio y personas. Cuatro áreas:
1. Decisiones técnicas estratégicas
- Definir la estructura fundamental del sistema
- Seleccionar tecnologías clave (lenguajes, frameworks, infraestructura)
- Establecer estándares y patrones a seguir
- Documentar decisiones arquitectónicas (ADRs)
2. Alineación con el negocio
- Traducir requerimientos de negocio a atributos de calidad
- Comunicar trade-offs técnicos a stakeholders no técnicos
- Priorizar capacidades técnicas según valor de negocio
3. Habilitación del equipo
- Mentorear a desarrolladores en decisiones de diseño
- Crear guías y documentación técnica
- Revisar código y diseños críticos
4. Evolución continua
- Monitorear deuda técnica y proponer remediación
- Evaluar nuevas tecnologías y su aplicabilidad
- Mantener la visión técnica a largo plazo
Liderazgo técnico vs. gestión de personas
| Liderazgo técnico (arquitecto) | Gestión de personas (Engineering Manager) |
|---|---|
| Decide QUÉ construir técnicamente | Decide QUIÉN construye qué |
| Responsable de la calidad del sistema | Responsable del desempeño del equipo |
| Influencia a través de expertise | Autoridad formal sobre el equipo |
| Éxito = sistema funcional y mantenible | Éxito = equipo productivo y motivado |
Hay zona de overlap: ambos participan en contratación técnica, ambos mentorean, ambos resuelven conflictos técnicos. En equipos pequeños, una sola persona suele hacer ambos roles.
Tipos de arquitecto
| Tipo | Foco | Scope |
|---|---|---|
| Arquitecto de Software | Un sistema/aplicación | Código, diseño, patrones |
| Arquitecto de Soluciones | Integración de sistemas | APIs, flujos, proveedores |
| Arquitecto de Plataforma/Cloud | Infraestructura | Servicios cloud, DevOps, seguridad |
| Arquitecto Empresarial | Portafolio de la organización | Estándares corporativos, gobernanza |
Cuándo aplicarlo
| Necesitas arquitecto dedicado si... | No lo necesitas si... |
|---|---|
| El sistema tiene más de 3 componentes mayores | Aplicación simple con equipo <5 personas |
| Varios equipos trabajan sobre el mismo sistema | Un solo equipo es dueño de todo el código |
| Las decisiones técnicas impactan >6 meses | Proyecto de vida corta (<1 año) |
| Hay requerimientos de calidad estrictos | MVP donde la velocidad es la única prioridad |
El material sugiere dedicación "full-time los primeros 3 meses, part-time 50% después" para un arquitecto en un proyecto nuevo. Es una heurística razonable, no una ley — depende del tamaño real del equipo, la complejidad del dominio y cuánta deuda arquitectónica hereda el proyecto. Trátalo como punto de partida a ajustar, no como cifra a defender en una reunión.
Practica: LMS con múltiples frentes
Tu empresa va a construir una plataforma de learning management system (LMS): web para estudiantes, app móvil, panel de administración, integración con pagos y generación de certificados.
Define: (1) qué responsabilidades de arquitecto asumirías tú directamente, (2) cuáles delegarías a tech leads por aplicación, y (3) qué tipo de arquitecto necesita este proyecto según la tabla de tipos.