Hace un tiempo me crucé con mi colega Dave Rice, y él estaba bastante enojado. Mi breve pregunta ocasionó una respuesta violenta: "No deberíamos entrevistar a nadie que dice ser 'arquitecto' en su currículum". Al principio me puso incómodo, porque usualmente presentamos a Dave como nuestro arquitecto líder...
El motivo de su enfurecimiento con el cargo es el hecho de que, incluso dentro de los estándares de la industria, las palabras "arquitecto" y "arquitectura" están muy vagamente definidas. Para muchos, el término "arquitecto de software" encaja perfecto con la imagen del personaje inalcanzable que todo lo controla al final de Matrix Reloaded. Y sin embargo, incluso en organizaciones en donde reniegan de esta imagen, existe un rol vital para el liderazgo técnico que lo ocupa un arquitecto como Dave.
¿Qué es la arquitectura?
Mientras pensaba en el título del libro Patterns of Enterprise Application Arquitecture, todos estaban de acuerdo que la palabra "arquitectura" pertenecía al título. Y sin embargo todos nos sentíamos incómodos al momento de tener que definir esa palabra. Como era mi libro, me sentí obligado a definirla.
Mi primer paso fue evitar las cosas vagas, dejando surgir al cínico de adentro. De algún modo, defino a la arquitectura como la palabra que usamos cuando queremos hablar sobre el diseño con la intención de glorificarlo para hacerlo parecer importante (si, podemos imaginar un fenómeno similar para el arquitecto). Sin embargo, y como suele ocurrir, dentro de esta ceguera cínica hay una pizca de verdad. Y terminé de comprenderlo cuando léi un mensaje de Ralph Johnson en la lista de correo de Extreme Programming. Es un excelente post, así que lo transcribo completo.
Un mensaje previo decía:
RUP, a partir de la definición de la IEEE, define a la arquitectura como "el concepto de más alto nivel de un sistema en su entorno. La arquitectura de un sistema de software (en cualquier momento en el tiempo) es su organización o estructura de los componentes importantes que interactúan a través de interfaces, y estos componentes se componen de componentes e interfaces sucesivamente más pequeños"
Johnson respondió:
Yo participé en la revisión del estándar de la IEEE que usó esa definición, y discutí en vano que claramente era una definición erronea. No existe un "concepto de más alto nivel de un sistema". Los clientes tienen un concepto distinto a los desarrolladores. A los clientes no les importa toda la estructura de componentes importantes. Entonces, quizás la arquitectura sea el concepto de más alto nivel que tienen los desarrolladores sobre un sistema en su entorno. Olvidemos a los desarrolladores que sólo entienden sus piezas pequeñas. La arquitectura es el concepto de más alto nivel de los desarolladores expertos. ¿Qué hace que un componente sea importante? Es importante porque un desarrollador experto así lo dice.
Entonces, una mejor definición sería "En la mayoría de los proyectos de software exitosos, los desarrolladores expertos que trabajan en ese proyecto tienen un entendimiento compartido sobre el diseño del sistema. Este entendimiento compartido se llama 'arquitectura'. Este entendimiento incluye cómo se divide el sistema en componentes, y cómo interactuan estos componentes a través de interfaces. Estos componentes suelen estar compuestos de partes más pequeñas, pero la arquitectura sólo incluye los componentes e interfaces que entienden todos los desarrolladores".
Esta sería una mejor definición porque deja en claro que la arquitectura es una construcción social (bueno, el software también, pero la arquitectura más) porque no depende sólo del software, sino qué partes del software son importante por consenso del grupo.
Hay otro estilo de definición de arquitectura, que es algo como "la arquitectura es el conjunto de decisiones de diseño que tienen que hacerse temprano en el proyecto". Tampoco me gusta, porque la arquitectura son las decisiones que deseamos que salgan bien temprano en el proyecto, pero pasa lo mismo con cualquier otra cosa.
De todas formas, si usamos esta segunda definición, el lenguaje de programación sería parte de la arquitectura para la mayoría de los proyectos. Con la primera definición, no.
Si algo pertenece o no pertenece a la arquitectura se basa completamente en si los desarrolladores creen que es importante. Las personas que construyen "sistemas corporativos" tienden a pensar que la persistencia es crucial. Cuando empiezan a dibujar la arquitectura, comienzan con tres capas. Dicen cosas como "vamos a usar Oracle para la base de datos, y vamos a crear nuestra propia capa de persistencia para mapear objetos". Pero una aplicación de imágenes médicas podría usar Oracle sin considerarlo como parte de la arquitectura. Esto es así porque la mayor complicación está en analizar imágenes, no en almacenarlas. Una muy pequeña parte de la aplicación busca y almacena imágenes, y la mayoría de los desarrolladores lo ignora.
Entonces, todo esto hace que a las personas les resulte dificil describir sus arquitecturas. "Decinos lo que es importante". La arquitectura trata sobre las cosas importantes. Sean lo que sean.
El rol del arquitecto
Entonces, si la arquitectura traba sobre las cosas importantes, el arquitecto es la persona (o personas) que se ocupa de las cosas importantes. Y aquí llegamos a la esencia de las diferencias entre el arquitecto de Matrix Reloaded y el estilo de arquitecto que Dave Rice hace referencia.
El Arquitectus Reloadus es la persona que toma todas las decisiones importantes. Lo hace el arquitecto porque se necesita a una única mente para asegurar la integridad conceptual del sistema, y quizás porque el arquitecto no cree que los miembros del equipo tengan la capacidad para tomar esas decisiones. A menudo, estas decisiones tienen que tomarse de manera temprana para que todo el resto pueda seguir un plan.
El Arquitectus Oryzus es un animal diferente (si no adividan, prueben buscar en latín). Este tipo de arquitecto necesita estar muy al tanto de lo que ocurre en el proyecto, busca temas importantes y cómo superarlos antes que sean problemas serios. Cuando veo un arquitecto así, la parte más notable de su trabajo es la colaboración intensa. En la mañana, el arquitecto programa con un desarrollador, tratando de solucionar algún problema bloqueante. En la tarde, al arquitecto participa en reuniones de requerimientos, ayudando a explicar a las personas que tienen estos requerimientos las consecuencias técnicas de sus ideas usando términos no técnicos - como por ejemplo, términos de costos de desarrollo.
La actividad más importante del Arquitectus Oryzus es enseñarle al equipo de desarrollo y elevar su nivel para que puedan tratar temás más complejos. Al mejorar las habilidades del equipo de desarrollo, el arquitecto tiene mucha más libertad que si fuera la única persona que puede tomar decisiones (además de no ser un cuello de botella). Y esto nos lleva a la siguiente conclusión: el valor de un arquitecto es inversamente proporcional a la cantidad de decisiones que tiene que tomar.