domingo, agosto 05, 2007

El arquitecto "porque lo he leido"

domingo, agosto 05, 2007 por Martín

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 :-)

comments

4 Respuestas a "El arquitecto "porque lo he leido""
CarlosBlanco dijo...
19:34

Es como un arquitecto ( de edificios) que jamás ha hecho mezcla o ha puesto una escayola ...
.... o como un ingeniero aeroespacial que nunca ha ido al espacio....

... o ....


He conocido a analistas buenísimos que en la disciplina en cuestión no han hecho ni las 10 líneas de código.

a cada un lo suyo


Martín dijo...
20:17

Carlos, claro que los hay. Pero fíjate que el artículo de Frank ( y creo que quizás yo también lo debería haber mencionado ) dice justo al principio: "como arquitectos no estoy hablando de la persona que trabaja a nivel empresarial y que apenas ve código en su vida. Estos son más bien estrategas de las TI y no necesitan disculparse".

Por supuesto que hay analistas muy buenos que conocen sus modelos de negocio a la perfección y no necesitan preocuparse por las tecnologías subyacentes ni escribir 10 líneas de código.

Ahora bien, entrando en un nivel más técnico, en mi opinión un arquitecto de software (con responsabilidad sobre la parte técnica) no debe recomendar una tecnología que no se ha evaluado y que simplemente ha oido hablar de ella, y a esto es a lo que me refiero en esta entrada.

O aplicando uno de tus ejemplos, un arquitecto seguramente no diseñará una casa únicamente en base a lo que lee en las revistas y lo que está de última moda, sino que probablemente realizará un análisis previo de esos diseños, intentará visitar obras para ver pruebas de concepto de esas tecnologías tan novedosas, y se preocupará por los detalles técnicos como que si la casa se va a caer porque el terreno es demasiado arcilloso para esa técnica en concreto.


CarlosBlanco dijo...
23:19

Estamos de acuerdo que debe conocer las tecnologías subyacentes, lo que puede y no hacer, y para que está indicado, es mas, si el arquitecto de sistemas (o analista), conoce el sistema de desarrollo mucho o muchísimo mejor, pero no necesario para ser un buen analista, de hecho, algunos errores de muchos analistas es querer hacer ellos mismo en vez de delegar tareas rutinarias (por muy trascendentes que sean) y por muy bueno que sea el analista picando código.
Bueno esa es mi lucha diaria, un saludo.

un saludo


Juan dijo...
14:12

Las comparaciones entre el desarrollo de software y el desarrollo de edificios; o en general de la ingeniería del software con otras "ingenierías civiles" son muy frecuentes, y aparentemente tienen mucho sentido, pero quizá inducen a muchos mitos.
No se, puedo estar equivocado, pero si tuviera que comparar al encargado de diseñar el sistema, lo compararía con un compositor musical antes que con un arquitecto. Si no sabe tocar...
Otra cosa es que por supuesto haya intérpretes que toquen mejor que él.

En fin, es una opinión.
Un saludo.
Juan Palacio.