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…