Una vez un jefazo que tuve comentó (no literalmente) en una reunión que un jefe de proyecto debía de gestionar el proyecto desde la atalaya, no pegado al barro de la máquina.
Creo que el arquitecto de software debe tener un planteamiento similar. Por una serie de motivos:
Todologo
Es prácticamente imposible en un proyecto un poco grande el que una única persona conozca al detalle todas las herramientas y tecnologías como para poder ayudar a un programador. De algunas si que podrás ayudar a un programador, porque en tu carrera te hayas tenido que pelear con ella. Pero de otras no.
Un arquitecto tiene que lidiar tanto con el desarrollo puro con todas sus herramientas, que si JSF, que si JPA, que si,…. También con las bases de datos, con la gente de sistemas, para la arquitectura de las máquinas, de las comunicaciones, etc
Como dice la sabiduría popular: «el que mucho abarca, aprieta poco».
Por eso creo que un arquitecto debe tener la siguiente actitud:
Coordinador
Por eso es importante que la persona que lleve la arquitectura sea alguien con un perfil de coordinación. Que tenga un equipo de trabajo con diferentes especialistas.
Si te pegas mucho al barro pierdes la visión de la globalidad del proyecto y acabas corriendo el riesgo de dar soluciones parciales y lo que arreglas en un apartado lo estropeas en otro. O también corres el riesgo de dar soluciones poco elaboradas, que se acaban volviendo en contra del proyecto.
En el libro sobre Expreme Programing se hacia referencia a un cuadro de mandos en el que se ponía todos los mandos al máximo y el sistema era estable, porque una técnica se compensaba con la otra.
Esta es la labor del arquitecto, ver la globalidad y hacerlo estable. Por ejemplo, tengo MySQL y como tiene ciertas carencias lo tengo que diseñar con un sharding y eso me provoca ciertos problemas que puedo solucionar con una caché transversal. Esa visión transversal es la que debe tener un arquitecto. No tanto el ponerse a instalar el caché o a optimizar el JSF.
Sino los de sistemas acaban viendo solo los problemas de sistemas y los de desarrollo solo los de desarrollo y eso no es bueno. Es el planteamiento tradicional que se intenta superar con planteamientos de DevOps.
No caer en las tentaciones
A mi, a pesar de venir de la rama de desarrollo, me gusta el tema de sistemas, más como hobby que profesionalmente. Tengo mi nube casera y cosas similares.
A veces es muy tentador cuando te encuentras con cosas de sistemas, por ejemplo, que no van bien, remangarte y hacerlas tu. Pero ese no es el trabajo del arquitecto. En todo caso si es el hacer que la gente de sistemas haga las cosas bien. Lo mismo pasa con temas de desarrollo. Si por ejemplo un código no pasa la auditoria de código. Es muy tentador el adecuarlo tu.
El problema no es lo que puedas hacer sino lo que dejas de hacer. He conocido a más de un jefe de proyecto que venia de la rama técnica y que ayudaba mucho a los programadores cuando no sabían hacer cosas. El problema es que descuidaban sus verdaderas responsabilidades. Y que un programador no lo haga muy bien, es delicado, pero que no lo haga bien un jefe de proyecto lo es mucho más.