El arquitecto "porque lo he leido"

Frank Kelly tiene una entrada muy buena en su blog donde explica como descubrir a los arquitectos "de pega", es decir, aquellos arquitectos de pequeños equipos técnicos que deberían ser muy técnicos para ser capaz de apoyar a su equipo y que por el contrario no serían capaces de ponerse a programar diez líneas de código seguidas.

Sería lo que Frank llama NCAs (Non-Coding Architects) y que otros han ido denominando Ivory Tower Architects, Astrounaut Architects y PowerPoint architects.

Leyendo esta divertida entrada me he acordado de algo que me pasó hace unos meses con un senior architect. En su momento me dejó marcado, lo dejé pasar, y ahora lo he vuelto a recordar. La conversación podría haber sido perfectamente así:

- Arquitectos en conversación normal: Tenemos que actualizar este EJB de sesión para que envie un mensaje al topic de eventos de sistema. Hay que controlar las transacciones.

... la conversación continua durante minutos exponiendo problemas, soluciones, etc. ...

- Arquitecto NCA: Al final estamos con lo mismo, esto es muy complicado. Deberíamos estar utilizando Spring y migrar a un servidor de aplicaciones Open Source. Y utilizar AOP. Oh, Spring es increible. Si utilizásemos Spring nos iría todo muchísimo mejor. Nuestra arquitectura es muy pesada. Sin Spring vamos a fracar, lo dice todo el mundo. Es lo mejor que ha ocurrido en el mundo desde el pan de molde.

¿Cuál es el problema? Aparentemente ninguno, ¿verdad? Tecnologías novedosas a la vez que asentadas, recomendaciones razonables. El problema es cuando semanas después en una conversación te sale:

-Yo: La verdad es que el otro día leyendo las novedades de Spring 2.0 pues resulta que ahora las transacciones son mucho más fáciles de definir y utilizar.
-Arquitecto NCA: ¿De verdad?
-Yo: Muchísimo, no sabes cuando en Spring 1.x tenías que definir que utilizabas el TransactionProxyFactoryBean, ¿te das cuenta?
-Arquitecto NCA: mmmmm ... no.
-Yo: Que sí hombre, cuando defines el bean.
-Arquitecto NCA: Bueno, no me hables de cosas tan concretas que es que yo nunca he utilizado Spring..
-Yo: huh

La verdad es que fue algo que en su momento me chocó muchísimo, porque esta persona tenía la capacidad de defender algo de una manera muy vehemente, tanto que prácticamente no te atreverías nunca a afirmar que esta persona no conocía realmente de lo que hablaba.

Supongo que esta sería una nueva clase de arquitectos peligrosos a unir a la lista. En este caso las recomendaciones suelen ser seguras (Spring, me pasó otro tanto con Hibernate) porque estas personas es mantienen muy al día de las tendencias. Pero en mi opinión es necesario tener algún conocimiento técnico de lo que se habla. Ya no voy a decir tener que haber programado en todo lo habido y por haber porque esto hoy por hoy es casi imposible; pero al menos leer algún libro, conocer su estructura técnica y crear alguna pequeña prueba de concepto me parecen tareas básicas antes de mojarte con algo. Si no tenemos tiempo para hacerlo, entonces otra persona del equipo lo debería hacer.

En mi opinión, no se debería promover vehementemente tecnologías que no se han probado o no se conocen profundamente, sólo porque todo el mundo hable de ellas y salgan en muchos artículos, aunque sea Spring :-)