Lo que “hace” un Arquitecto puede variar ampliamente de Empresa a Empresa, según la

realidad, volumen, circunstancias, contextos y necesidades de cada una de ellas.

El alcance del rol también tiene que ver sobre el “dominio” sobre el que le toca actuar: a nivel
Empresa, a nivel Procesos, a nivel Infraestructura, a nivel Datos, a nivel Aplicativos, a nivel
Plataforma, etc

Pero, en el común de las situaciones, un Arquitecto intenta guiar la evolución de ese dominio
arquitectural desde un estadio actual hacia un estadio futuro, basado en buenas prácticas y
políticas, velando para que esa evolución sea superadora y se sostenga en el tiempo.

Cuando el foco del Arquitecto es un determinado Software ó Aplicativo, las tareas se

concentran principalmente (pero no exclusivamente) en las etapas de diseño del Software:

- Asegura que el Software cumpla no solamente con los requisitos funcionales (el qué),
sino la mayor cantidad de requisitos no funcionales (Aspectos como seguridad,
mantenibilidad, usabilidad, escalabilidad, interoperabilidad, performance, etc)
- Mapea estos requerimientos a las componentes de software necesarias, respetando
los estándares existentes en la Empresa. (Arquitecturas de Referencia, Políticas,
Estándares de Código)
- Asegura la integridad de estos componentes, diseñando las interacciones entre estos.
- Cuando es necesario, retroalimenta la Arquitectura de Referencia, para colaborar en
su evolución (contribuye a determinar los estándares).
- Colabora con sus entregables a la planificación de los proyectos de software
(identificación de componentes a construir o modificar; dependencias; perfiles
necesarios)
- Durante la construcción, verifica que se respetan los diseños propuestos.
- Documenta y gestiona el backlog de todo aquello que, por diferentes circunstancias
(tiempos, recursos económicos y humanos) no se puede construir de la manera “ideal”
y se tenga que optar por alternativas intermedias.
- Cuando es necesario, construye piezas de software a modo de pruebas de concepto ó
incluso facilitadores para la adopción de estándares y conceptos (Frameworks).

El Arquitecto de Software interactúa principalmente con los equipos de Desarrollo (Líderes de

Proyectos, Scrum Masters, PMs, Codificadores), pero también con sus pares de proyectos
distintos a modo de comités y con quiénes gobiernan las guías, políticas y procedimientos de
los distintos bloques arquitecturales de la Empresa (normalmente llamados Arquitectos de
Referencia).

El principal desafío es poder realizar sus tareas haciendo un equilibrio entre el “ideal” y la
velocidad de entrega que demanda el usuario (el negocio), resignando la menor calidad
posible y enmarcado en contextos ágiles y de recursos escasos.

Se desprende de todo esto que un Arquitecto de Software no solamente tiene que tener
conocimientos sobre un conjunto determinado de tecnologías/lenguajes/frameworks, visión
sobre “lo que se viene” ó “los nuevos modos de hacer las cosas”, sino también habilidades de
comunicación y políticas para saber introducir las evoluciones en los momentos indicados. Se
suma a esto, la necesidad de manejar estándares de modelado (ej: UML)