Entendiendo los Roles que Nadie Te Explica Bien
El problema de las etiquetas
Llevo años viendo cómo la industria usa el término “arquitecto” de forma bastante confusa. Vas a una empresa y el arquitecto está picando código. Vas a otra y el arquitecto no ha tocado un IDE en cinco años. ¿Quién tiene razón? Pues mira, probablemente los dos. El problema es que estamos usando la misma palabra para roles fundamentalmente distintos.
Vamos a intentar aclarar esto de una vez.
Tres niveles, tres realidades distintas
Cuando hablamos de arquitectura de software, en realidad estamos hablando de tres niveles de responsabilidad que muchas veces se solapan, pero que conviene separar mentalmente:
El arquitecto a nivel de proyecto (o el que no tiene el título)
Este es el rol más común y el que menos se reconoce como “arquitectura”. Es lo que hace un tech lead o un senior engineer cuando arranca un proyecto desde cero.
¿Qué hace esta persona? Pues básicamente diseña. Decide cómo se estructura la aplicación, qué patrones usar, cómo organizar el código, cómo se comunican los componentes internos. Si estás creando una API desde cero y tienes que decidir cómo separar capas, definir contratos y elegir tecnologías, estás haciendo arquitectura. Punto.
El matiz importante aquí es que este trabajo es arquitectura real, aunque tu tarjeta no diga “arquitecto”. Estás tomando decisiones de diseño que van a afectar al proyecto durante años. Si la cagas aquí, el equipo lo va a pagar después.
Este nivel es la base de todo lo demás. Si no sabes diseñar una aplicación bien estructurada, no puedes ser arquitecto de nada. Es así de simple.
El arquitecto de soluciones (el que mira desde arriba)
Aquí la cosa cambia. El arquitecto de soluciones no está en las trincheras de un proyecto específico. Su responsabilidad es transversal: mira todos los proyectos de la empresa (o de un área grande) y se asegura de que las piezas encajen.
¿Qué significa esto en la práctica?
- Establece patrones y estándares que aplican a todos los proyectos
- Define cómo se integran los sistemas entre sí
- Se obsesiona con los requisitos no funcionales: seguridad, escalabilidad, observabilidad, costos
- Sirve de árbitro cuando un tech lead tiene tres opciones y no sabe cuál es la más alineada con la estrategia de la empresa
Un detalle importante: el arquitecto de soluciones no impone dogmas. O no debería. Su trabajo es colaborar con los equipos, entender qué funciona en la práctica, recoger feedback y refinar los estándares basándose en experiencia real. Si tu arquitecto llega con un documento de 200 páginas que nadie ha validado en producción, tienes un problema.
Principio clave: colaboración pragmática sobre imposición de reglas.
Ahora bien, hay una variable que cambia mucho el rol: el tamaño de la empresa.
- En una empresa con un solo producto importante, el arquitecto de soluciones está mucho más cerca del código. Puede que sea él quien diseñe la arquitectura de ese producto, porque al final es el único que importa.
- En una empresa con múltiples proyectos, el arquitecto no tiene tiempo de meterse en el diseño de cada uno. Delega eso a los tech leads, pero les da el marco de referencia y está disponible para decisiones que requieren visión global.
El arquitecto empresarial (el que habla con negocio)
Este nivel existe, pero siendo honesto, está fuera del alcance técnico de esta conversación. El arquitecto empresarial piensa en alineación con el negocio, estrategia tecnológica a largo plazo, gobernanza… Son conversaciones importantes, pero muy alejadas del día a día de quienes diseñamos sistemas.
Lo menciono para que sepas que existe, pero no vamos a profundizar aquí.
¿Dónde está la frontera real?
La pregunta del millón: ¿cuándo dejas de ser tech lead y te conviertes en arquitecto de soluciones?
Mi respuesta: cuando tu responsabilidad deja de ser un proyecto y pasa a ser el ecosistema.
El tech lead toma decisiones locales. Optimiza su proyecto. El arquitecto de soluciones toma decisiones que afectan a varios proyectos. Cuando un tech lead tiene un dilema y viene a preguntarte “oye, tengo estas tres opciones, ¿cuál encaja mejor con lo que estamos haciendo como empresa?”, ese es el momento en que el arquitecto de soluciones aporta valor.
Y fíjate en algo: esa pregunta no es “¿cuál es técnicamente mejor?”. Es “¿cuál quiere la empresa?”. El arquitecto de soluciones tiene que entender el contexto de negocio, los costos, las prioridades estratégicas. No es solo técnica.
El foco del arquitecto de soluciones
Si tuviera que resumir en qué se centra un arquitecto de soluciones, diría que en requisitos no funcionales. Los requisitos funcionales son específicos de cada proyecto. Los no funcionales son transversales.
¿Cuáles? Los de siempre, pero priorizados:
-
Seguridad: Sin esto, nada más importa. Una brecha de seguridad puede destruir una empresa. El arquitecto define patrones de autenticación, autorización, cifrado, compliance.
-
Confiabilidad: El sistema tiene que funcionar cuando se necesita. Esto incluye disponibilidad (que responda) y rendimiento (que responda en tiempo razonable).
-
Escalabilidad: Que funcione igual con 10 usuarios que con 10 millones. Sin degradación proporcional.
-
Observabilidad: Que podamos ver qué está pasando. Logs, métricas, trazas. Si no puedes observar el sistema, no puedes operarlo.
-
Costos: Sí, esto es responsabilidad del arquitecto. Un sistema que funciona técnicamente pero que es inviable económicamente es un fracaso. El arquitecto tiene que estimar costos de construcción y operación, especialmente en cloud donde es fácil que se te vaya de las manos.
El modelo de trabajo que funciona
He visto arquitectos que se encierran en una torre de marfil a diseñar frameworks que nadie usa. No funciona.
Lo que sí funciona:
- Reuniones regulares con los equipos para entender qué problemas tienen de verdad
- Recoger feedback sobre qué patrones funcionan y cuáles son un dolor de cabeza
- Workshops para introducir nuevas tecnologías o corregir prácticas que se han desviado
- Refinar estándares continuamente basándose en lo que pasa en producción, no en lo que dice un libro
El arquitecto que no escucha a los equipos acaba siendo irrelevante. Sus estándares se ignoran, sus diseños se reinterpretan, y al final cada proyecto hace lo que le da la gana. La autoridad del arquitecto viene de aportar valor real, no del título.
La progresión natural
Si estás pensando en tu carrera, la progresión típica es:
- Desarrollador senior: Dominas el código, empiezas a pensar en diseño
- Tech lead / Arquitecto de proyecto: Diseñas sistemas completos, tomas decisiones arquitectónicas locales
- Arquitecto de soluciones: Tu alcance se expande a múltiples proyectos, te centras en lo transversal
Cada nivel requiere el anterior. No puedes ser arquitecto de soluciones si no has diseñado sistemas reales. La experiencia en las trincheras es lo que te da credibilidad y criterio.
Y un consejo: no tengas prisa por subir. Cada nivel tiene su valor. He conocido tech leads brillantes que no tenían ningún interés en ser arquitectos de soluciones, y está perfecto. El rol de arquitecto implica alejarse del código, pasar más tiempo en reuniones, negociar con stakeholders. No es para todo el mundo.
Conclusión
Los tres niveles que hemos visto existen, aunque las empresas los llamen de formas distintas:
| Nivel | Alcance | Foco |
|---|---|---|
| Tech Lead / Arquitecto de proyecto | Aplicación individual | Diseño técnico, código, decisiones de implementación |
| Arquitecto de soluciones | Múltiples proyectos | Requisitos no funcionales, patrones transversales, estándares |
| Arquitecto empresarial | Organización completa | Estrategia tecnológica, alineación con negocio |
Lo importante es entender que todos hacen arquitectura, pero a distintas escalas y con distintas responsabilidades. El arquitecto de proyecto diseña sistemas. El arquitecto de soluciones diseña ecosistemas. Y ambos son necesarios.
Si estás empezando, céntrate en dominar el primer nivel. Aprende a diseñar aplicaciones bien. Entiende patrones, trade-offs, cómo estructurar código que otros puedan mantener. Esa es la base sobre la que se construye todo lo demás.
Y si ya estás en un rol de arquitecto de soluciones, recuerda: tu trabajo no es imponer. Es habilitar. Los equipos tienen que querer seguir tus estándares porque les hacen la vida más fácil, no porque aparecen en un documento oficial.
--- La arquitectura no es un título. Es una práctica. ---
arquitectura-software solution-architect tech-lead roles-ingenieria requisitos-no-funcionales liderazgo-tecnico carrera-profesional diseño-sistemas escalabilidad seguridad observabilidad patrones-arquitectonicos NFR organizacion-equipos