El Rol del Arquitecto de Software

A lo largo de las distintas entregas de esta columna hemos cubierto las actividades del ciclo de desarrollo de la arquitectura de software y su integración dentro del ciclo de desarrollo de software. En todas estas actividades, hay un rol específico que juega un papel preponderante y es el del arquitecto de software. Mucho ha sido escrito en relación con este rol, sin embargo, en esta columna hablaremos al respecto enfocándonos más bien en las actividades que debe realizar el arquitecto a lo largo del ciclo de desarrollo, particularmente en el contexto de desarrollos de software a la medida.

Actividades del arquitecto

Concepción del proyecto. Un proyecto de desarrollo de software, particularmente cuando se trata de un desarrollo a la medida, inicia generalmente por una etapa en la cual se debe de generar una propuesta técnica y económica, muchas veces en un periodo corto de tiempo. En ésta etapa, el arquitecto juega un papel muy importante pues en general en él recae la responsabilidad de realizar una traducción de las necesidades que expresa un cliente hacia una solución técnica preliminar, que es una pieza clave para producir una estimación del esfuerzo necesario para realizar el desarrollo. El arquitecto puede, de hecho, también participar en el trabajo de estimación del sistema. Durante esta etapa del proyecto, el arquitecto debe hacer uso de habilidades técnicas (“duras”) y no-técnicas (“suaves”). Como parte de las habilidades técnicas, debe poder identificar estilos arquitectónicos y tecnologías que sean apropiados para resolver el problema y proponer una solución preliminar. Como parte de las habilidades no-técnicas, debe ser capaz de realizar un análisis de las necesidades del cliente, especialmente desde una perspectiva de negocio y poder explicar la solución técnica que propone a los distintos involucrados del proyecto.

Requerimientos. Durante la fase de requerimientos, el arquitecto de software se involucra con los requerimientos que influyen en la arquitectura (“drivers”) y particularmente con respecto a los atributos de calidad del sistema. El arquitecto debe preocuparse por que se identifiquen atributos de calidad pertinentes para el sistema (alineados a los objetivos de negocio) y que las métricas asociadas estén justificadas. En caso de que el cliente solicite atributos de calidad con métricas muy demandantes (por ejemplo una disponibilidad del 99.99%) debe ser capaz de entender la justificación de esas métricas y, en caso necesario, debe poder negociar con el cliente para establecer métricas adecuadas. Nuevamente, el arquitecto debe emplear aquí una combinación de habilidades “duras” y “suaves” con el fin de lograr una identificación adecuada de los requerimientos que influirán sobre el diseño arquitectónico.

Diseño del sistema. La etapa de diseño del sistema es aquella donde el arquitecto de software juega el papel principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer uso de todas sus habilidades técnicas con el fin de establecer una solución técnica pertinente que satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura (ver Figura 1. La realización del diseño requiere de muchos conocimientos técnicos.


Durante la etapa de diseño, el arquitecto debe también hacer uso de muchas habilidades no-técnicas. La comunicación durante esta etapa es fundamental, ya que el arquitecto debe ser capaz de comunicar el diseño, y las decisiones que lo llevaron al mismo, ya sea de forma escrita, como parte de la documentación de la arquitectura, o bien de forma oral al explicar el diseño de la arquitectura al equipo de desarrollo. Durante la evaluación del diseño de la arquitectura, el arquitecto debe ser capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación, y debe ser capaz de responder a las preguntas de dicho comité, o bien de aceptar las observaciones que se hacen al diseño.

Construcción y pruebas del sistema. Durante de la construcción del sistema, el esfuerzo técnico del arquitecto disminuye, aunque ésto no significa que ya no se realizan actividades técnicas. En esta etapa, desde un punto de vista técnico, el arquitecto debe terminar de completar las partes faltantes del diseño de la arquitectura y corregir las decisiones previas que hayan resultado ser equivocadas. Desde un punto de vista no-técnico, el esfuerzo aumenta pues el arquitecto debe enfocarse en cuidar que el sistema se desarrolle de acuerdo a la arquitectura que se definió para el mismo. Aquí el arquitecto juega un papel de mentor y muchas veces debe explicar cuestiones del diseño del sistema al equipo de desarrollo. El arquitecto puede también realizar actividades de aseguramiento de calidad tales como inspecciones de productos de trabajo, ya que su nivel técnico y conocimiento del dominio del problema le da una ventaja para identificar problemas que posiblemente podrían no ser identificados por ingenieros con un nivel técnico y conocimiento del dominio del problema menores. Al momento de realizar pruebas del sistema, la participación del arquitecto es importante, particularmente al momento de realizar pruebas relativas a los atributos de calidad del sistema.

Liberación. Al momento de implantar el sistema en el ambiente productivo, muchas veces es necesario realizar ajustes finos sobre el sistema, en particular una vez que el sistema ya está operando en el ambiente de uso definitivo. La participación del arquitecto puede estar enfocada a realizar ajustes finos de la aplicación con el fin de lograr un funcionamiento óptimo de la misma.

Categorías de arquitectos

Dependiendo del tamaño del sistema, es posible que no haya un solo arquitecto que participe a lo largo de todo el proyecto y que, más bien, existan distintos arquitectos especializados que intervienen a distintos momentos del desarrollo. Así, frecuentemente, el arquitecto que participa en la concepción de un proyecto es conocido como el “Arquitecto de Soluciones” mientras que el arquitecto que participa durante el desarrollo es conocido como el “Arquitecto de Software”. Pueden haber otras especializaciones tales como el “Arquitecto de Sistemas”, que se encarga de tomar decisiones de diseño que van más allá del software y que involucran hardware, o bien el “Arquitecto Empresarial” que, como su nombre indica, se especializa en el diseño de una arquitectura empresarial. Existen también ciertas especializaciones a nivel tecnológico, como por ejemplo el “Arquitecto SOA”. Cualquiera que sea la especialidad del arquitecto, en general, un aspecto común es que su rol involucra la toma de decisiones que tienen un fuerte impacto sobre el sistema.

Conclusión

Es muy difícil poder establecer un perfil único del arquitecto de software, es por esa razón que en este artículo más bien se habló acerca de las actividades que juega este rol a lo largo del desarrollo. Un aspecto complejo del rol del arquitecto de software es que es responsable de conciliar las demandas de los distintos involucrados dentro del desarrollo. Así, debe buscar satisfacer las necesidades (no siempre compatibles) de los clientes y de la organización de desarrollo. Un arquitecto no puede, por ejemplo, proponer el uso de cualquier tecnología sin considerar aspectos tales como la curva de aprendizaje del equipo de desarrollo, si éste último no está familiarizado con la herramienta propuesta. Adicionalmente, el arquitecto de software debe asumir un papel de liderazgo y ser alguien con mucha iniciativa capaz de aprender continuamente, pero a la vez debe poder comprender que los miembros del equipo de desarrollo pueden no tener el mismo nivel técnico que él y, por ello, debe también fungir como un mentor dentro del equipo.

Frecuentemente se considera que el rol de arquitecto de software es un rol extremadamente técnico y que personas que son muy buenas para la tecnología automáticamente pueden ocupar este papel. La realidad es que el rol de arquitecto de software es un rol complejo que requiere de una combinación equilibrada de habilidades técnicas y no-técnicas que son indispensables en las distintas etapas del desarrollo de un sistema.