¿Quién necesita un Arquitecto? - Síntesis

RESUMEN

Definir a un arquitecto de software es una tarea compleja, ya que es demasiado común que términos como Arquitecto de Software o Arquitectura de Software sean utilizados de forma errónea, dándole más valor sin justificar realmente (o al menos diferenciar de forma correcta) la existencia del término. En una primera instancia, se puede definir a la Arquitectura de Software como el nivel más alto de un sistema, es la organización o estructura de componentes significantes. Esto, sin embargo, nos trae el problema de decir: qué es un componente significante, qué lo convierte en uno? Siendo objetivos es significante porque los desarrolladores quieren que sea significante.

Por otro lado, otra de las definiciones que se dan para la arquitectura de software (y por consecuencia, los arquitectos) es que es el conjunto de decisiones referentes al diseño que deben ser realizadas de forma temprana en un proyecto, un detalle que menciona el autor respecto a eso es que, en base a dicha definición, el lenguaje de programación que se utilizará en el proyecto forma parte de la arquitectura, lo cual choca con la primera definición, que explicaba a la arquitectura como el nivel más alto del sistema.

Entonces, si la arquitectura son las cosas importantes, el arquitecto es la persona que se preocupa por las cosas importantes, lo que nos lleva directamente a la creencia popular del arquitecto como el pináculo del desarrollo. Al igual que con la arquitectura, existen diversas formas de definir al arquitecto de software, hay unos que los definen como aquellos que son la cabeza completa del proyecto, son los únicos que lo entienden en su totalidad y aquellos que toman las decisiones, principalmente por creer que los demás no poseen la capacidad de hacerlo.

Por supuesto, que existen definiciones para el Arquitecto que le quitan de dicho valor supremo, y lo definen más como un guía, aquella persona en un equipo de desarrollo que si bien tiene el mayor entendimiento en los asuntos importantes del sistema completo, permite aceptar ideas ajenas para la toma de decisiones, lo que aumenta las habilidades del equipo completo, lo que a su vez lleva a que el Arquitecto de Software deba tomar las menores decisiones posibles, pues el valor del arquitecto, como menciona la lectura, es inversamente proporcional al número de decisiones que toma.

OPINIÓN PERSONAL

En lo personal, sí comulgo con el pensamiento de la arquitectura como aquella rama encargada de la estructuración y organización de los diversos modulos que componen a un sistema de software, y también que es muy dependiente de cada proyecto y de líder de proyecto, sin embargo, no creo que la arquitectura sea únicamente la rama sobre las “cosas importantes” pues eso es conlleva demasiada subjetividad lo cual puede ser perjudicial. Y con respecto al arquitecto, pienso que en un equipo de desarrollo, el arquitecto es aquella persona con más experiencia detrás, y por lo mismo de que posee una amplia experiencia, es capaz de tomar mejores decisiones basadas enteramente en casos ya vistos; sin embargo, eso no debería darle de un  poder absoluto de decisión, y que se involucre en cada decisión que deba ser tomada en el proyecto, pues si bien la toma de decisiones sería una de sus tareas principales, también debe fungir como un guía para el resto del equipo, pues esto le beneficia a el mismo, ya que así el número de decisiones que debe tomar se reduce a las más importantes solamente, y que puedan llegar a afectar a módulos completos del sistema. Ya por último, decir que estoy en desacuerdo con lo que se menciona al final cuando se compara la arquitectura con la arquitectura de software, diciendo cosas como que el software no está limitado por cuestiones físicas y que solo lo limita la imaginación, pues pienso que no es cierto.

...