Me temo que en los últimos tiempos, al término arquitecto le ha pasado lo mismo que al de consultor algunos años atrás. Se llegó a un punto en que todo el mundo era consultor, incluso los recién licenciados sin experiencia (a pesar de tener un contrato de becario en muchos casos).
Se usa y abusa de la palabra, evidentemente por motivos de marketing. ¿cómo se explica si no que en un proyecto de desarrollo con un equipo de 7 personas haya 3 arquitectos? ¿para que se necesitan 3 arquit
ectos en un equipo de desarrollo? ¿que fue de los desarrolladores senior? Evidentemente parece que se ha realizado una transmutación del perfil de desarrollador senior a arquitecto.
Supongo que este frenesí “arquitectural” cesará tarde temprano, cuando se encuentre otra palabra que venda más. Así que nos ocuparemos del significado real de lo que se significa ser arquitecto software en el área de las T.I.:
Hace tiempo leí una sencilla definición de lo que significa ser arquitecto comparándolo con un analista, quizás una de las formas más claras de entenderlo. Según el libro “Sun Certified Enterprise Architect for J2EE™ Technology Study Guide” (traducción libre):
Una analista se ocupa de qué ocurre cuando un usuario le da a un botón, y el arquitecto se ocupa de qué ocurre cuando mil usuarios le dan a ese botón
Más elaborada es la reflexión de Simon Brown dónde se pregunta ¿eres un arquitecto?. En esta página se dice que evidentemente para ser arquitecto se necesita experiencia, que llegar a serlo no se logra de la noche a la mañana. Divide sus atribuciones en dos “fases”:
- Definición de la arquitectura: hay que tener en cuenta cuales son los requirimientos y diseñar una arquitectura que los satisfaga. Para ello divide esta fase en cinco elementos:
- Gestión de los requisitos no funcionales: deben ser específicos, medibles, conseguibles y poder ser probados. No sirve nada tan ambiguo como “debe tener buen rendimiento”.
- Definición de la arquitectura: se deben proporcionar guias, principios de arquitectura, y fijar las características técnicas.
- Selección de la tecnología: este paso tiene una gran importancia. Ya que como es obvio hay que seleccionar la mejor alternativa del mercado (en cuanto a precio, documentacion disponible, soporte, etc.) y evitar “reinventar la rueda”. Normalmente es mejor y más barato adoptar una solución ya existente que hacer un desarrollo propietario.
- Evaluación de la arquitectura: probar que la arquitectura funciona, para ello debe proporcionar el suficiente soporte al código de la aplicación intentando que éste se ocupe únicamente de la lógica de negocio y no de aspectos técnicos.
- Colaboración: es necesario que los equipos de desarrollo de aplicaciones de negocio (los usuarios) entiendan la arquitectura.
- Aplicación y divulgacion: la segunda fase se ocupa de la divulgación y la comunicación de la arquitectura a sus usuarios. Para ello hace hincapié en “vender” la arquitectura a quien la va a usar para el desarrollo de sus aplicaciones (algo sobre esta línea ya lo traté en la entrada de este blog).También se responde a la pregunta de si debe un arquitecto “sufrir” su propia creación desarrollando una aplicación para sentir en carne propia las “penas” por las que pasaría el desarrollador. A fin de cuentas, un arquitecto puede considerarse como un desarrollador avanzado y con mucha experiencia, por lo que no debe quedarse en el plano teórico y “remangarse” con el código. De esta manera se logrará una mejor arquitectura.Yo estoy de acuerdo con esta opinión, evidemente con el tiempo que se disponga (que será poco seguramente) se tendría que hacer el esfuerzo de “empatía” con el equipo de desarrollo. Aunque en mi opinión, no solo en la codificación, sino también en el empaquetado, despliegue y pruebas de la aplicación.
No cabe duda que es difícil definir cuales son es el cometido de un arquitecto, sin embargo, yo las resumiría en las siguientes:
- Seleccionar los mejores estándares, API’s, etc. disponibles con arreglo a su precio, disponibilidad de documentación y comunidad que lo soporta
- Simplificar y ocultar la complejidad técnica inherente al usuario (el desarrollador) para que éste se concentre en la lógica de negocio.
- Ayudar a acortar el time to market de las aplicaciones de negocio
- Garantizar el rendimiento y escalabilidad necesarios
¿crees que falta alguna?
Comparte este artículo…
24/03/2010 at 08:36
Yo creo que agregaría algo más:
Un arquitecto es quien se encarga de que nunca haya que dar al “cliente” respuestas como:
– Es que el sistema no lo permite
– Deberíamos cambiar toda la programación
– Tenemos que agregar 640GB de RAM al servidor si queremos ampliar de 15 a 60 los usuarios del sistema.
– Podríamos hacer una apaño, en menos de 7 meses lo vamos a hacer
– No tenemos idea de porque se desloga a 1000 usuarios de la aplicación
– Lo pensamos para IE, no para Mac, o lo que es igual que decir que no me interesan algo así como 250.000 usuarios repartidos en todo el mundo (solo clientes del banco que auspicia a Ferrari)
Y muchas más…
Los arquitectos estamos para hacerle ganar más dinero a quienes usan nuestro software, sino a trabajar a un video club.
24/03/2010 at 20:31
Un arquitecto debe abstraerse del “dinero”, su objetivo es garantizar el funcionamiento y la estabilidad de su arquitectura, facilitando la tarea de desarrollo, velando por su correcto uso, y proporcionando el soporte y evolución adecuada para superar los obstáculos técnicos que se encuentren durante su vida util.