Hace poco leí un comentario en LinkedIn que me resonó profundamente. En él se decía que muchos arquitectos de TI terminan siéndolo no por formación, sino porque resolvieron problemas, asumieron responsabilidades y dieron sentido al caos. Estoy de acuerdo en parte. Pero también creo que no podemos generalizar ni romantizar el hecho de que, en muchas organizaciones, el arquitecto simplemente es “el que más sabe” o “el que estuvo ahí cuando se necesitaba”.

🔍 El problema de fondo

En realidad, el rol del arquitecto es mucho más complejo y necesario, especialmente hoy, cuando la cantidad de opciones disponibles (tecnologías en la nube, movilidad, IoT, inteligencia artificial, lenguajes, robótica, no-code, múltiples proveedores, etc.) ha crecido exponencialmente. En este contexto, contar con alguien que tenga la capacidad de decidir correctamente se ha vuelto más crítico que nunca.

🎓 Formación y preparación no son opcionales

A lo largo del tiempo, me he preparado en el ámbito de la arquitectura de TI. Desde 2008, cuando escuché por primera vez sobre este rol, comencé a profundizar en el tema comparando entre el rol del arquitecto de TI y el de la arquitectura tradicional que construye edificios. Posteriormente, tuve la oportunidad de estudiar con expertos en el área, obtener una maestría en arquitectura de TI y liderar proyectos desde su conceptualización hasta su operación. Sin embargo, la experiencia no es solo un número de años: es una colección de decisiones difíciles, de proyectos al borde del fracaso que pudieron rescatarse gracias a una visión sistémica y al coraje de actuar.

🧭 Decidir: la esencia del arquitecto

Si hay algo que diferencia al arquitecto del resto del equipo técnico, es su responsabilidad de tomar decisiones a nivel de sistema. Decidir no solo qué tecnología usar, sino cómo hacerlo de forma alineada con el contexto, las necesidades del negocio y los atributos de calidad que debe tener la solución.

De la misma forma en que un arquitecto de edificios es responsable del éxito de una obra —pero también es el primer responsable si el edificio colapsa o genera pérdidas para los inversionistas—, el arquitecto de TI es responsable del resultado final de las soluciones puestas en producción. No se trata solo de diseñar, sino de asumir la responsabilidad por lo que se entrega. La arquitectura no termina en el plano; se valida en el impacto real que produce.

🧠¿Qué esperar de un arquitecto?

A lo largo de mi carrera, he tenido la oportunidad de dar mentoría a nuevos arquitectos, y siempre insisto en que el rol no se trata solo de conocimientos técnicos, sino de asumir una responsabilidad sistémica y estratégica. Más allá de los títulos o las herramientas, un arquitecto debe ser capaz de:

• Asegurar que el alcance, el contexto y las limitaciones estén documentados y aceptados.
• Identificar e involucrar a los stakeholders y sus intereses desde el inicio.
• Facilitar la toma de decisiones a nivel de sistema, basadas en buena información y alineadas con los objetivos.
• Capturar e interpretar conocimiento técnico y de dominio de negocio.
• Definir estrategias, estándares y guías que orienten la construcción del sistema.
• Asegurar que la arquitectura cumpla con los atributos de calidad definidos.
• Desarrollar y administrar la documentación arquitectónica.
• Verificar que los principios y estándares arquitectónicos se apliquen al sistema entregado.
• Proveer liderazgo técnico, tanto dentro del equipo como hacia el negocio.

Ser arquitecto no es simplemente “ascender” dentro del equipo. Es asumir un rol de liderazgo técnico y estratégico, con visión holística, capacidad de síntesis, y lo más importante: criterio para decidir. Porque cuando todo es posible, lo difícil no es construir, sino elegir bien.