Reseña: El rol del Arquitecto de Software

El rol del Arquitecto de Software

Nicolás Manuel Ruiz

Modelado de Aplicativo de Software

Universidad EAN

Bogotá, Colombia

Este artículo se basa en la opinión personal del presente autor respecto al documento The Role of the Architect de Bredemeyer Consulting.

I. INTRODUCCIÓN

Este artículo intenta dar un enfoque académico respecto al documento mencionado desde el punto de vista de opinión personal. El documento de la consultora Bredemeyer Consulting, plantea mencionar los dominios o aptitudes que creen que un arquitecto debe poseer para cumplir con su rol con éxito. Ellos son tecnología, estrategia empresarial, políticas organizacionales, consultoría y liderazgo.

II. DOMINIOS DE UN ARQUITECTO

Basándose en los dominios previamente mencionados, se realizará un análisis de cada uno de ellos. Hay un considerable énfasis en los primeros dos dominios, mencionando que son los que definen la palabra ‘archi-tect”.

A. Tecnología

Se ve en las universidades en los estudiantes y en  muchos profesores, que la tendencia es aprender un poco de varios temas, pero enfocarse en una rama en particular para ser lo que dicen ‘bueno’ en eso. Contraria a esta creencia es la del autor aquí presente, que cree que todas las ramas pueden ser exploradas de igual manera, si arquitecto es la carrera deseada. Un arquitecto maneja todo el sistema, desde su definición, pasando por su seguimiento, hasta su conclusión y pruebas. Para ser un buen arquitecto, este debe conocer las tecnologías actuales. No sólo para proponerlas como solución, sino también para poder participar en la evolución y resolución de conflictos importantes del sistema. Un arquitecto que no tenga conocimientos de tecnología, no puede idear una buena arquitectura y menos darle un correcto seguimiento. Es ideal que los desarrolladores tengan una idea respecto al arquitecto de facilitador de guías y ayudas para solucionar problemas; sin los conocimientos, el liderazgo es difícil de mantener (dominio que se detallará más tarde) y se pone en riesgo el fin del proyecto.

B. Estrategia Empresarial

El otro concepto importante de “archi-tect” se refiere a la estrategia empresarial que se adquiere tanto mediante la experiencia como el entendimiento del negocio; no sólo de la empresa, sino también de los sectores involucrados en el sistema. Entender los ritmos de la empresa permite que sean estrategias aliadas a la arquitectura en vez de problemas. Un buen arquitecto debe ser un buen administrador, que vaya más allá de los conceptos técnicos y que pueda interrelacionarlos con los organizacionales. Con un buen entendimiento, se pueden traducir más eficientemente los requerimientos y funciones administrativas en funciones técnicas.

C. Políticas Organizacionales

Luego de los dos dominios más importantes para la definición de la arquitectura, el resto terminan de definir estrategias y actitudes que se deben tener para concretar el proyecto. Las políticas organizacionales son importantes para, como el punto anterior, usarlas de aliadas para conseguir consenso y participación de los actores involucrados. Es mejor conseguir que las personas entiendan hacia a donde apunta el proyecto en vez de estar dictaminando por autoridad. Un mayor alineamiento permite una mejor coacción entre los involucrados. Es muy similar al punto anterior, pero la diferencia radica en que la estrategia empresarial es más hacia donde apuntan y las políticas organizacionales como apuntan. Ambas son igual de importantes para conseguir los objetivos. Como se mencionó anteriormente, estrategia empresarial es para definir la arquitectura, mientras que las políticas son para definir como se emplea.

D. Consultoría

Es muy cierto y se ve muy seguido, que la arquitectura termina siendo una guía poco utilizada por los desarrolladores. Comúnmente no la terminan de entender, no comparten la perspectiva o simplemente no le dan la atención que se merece. Consultoría se refiere más, en este caso, a la administración del seguimiento del proyecto, identificar desviaciones y ver la forma de lograr el entendimiento de todas las partes. Si la arquitectura es tan importante, su seguimiento debería serlo con igual importancia para no perder el objetivo. Si no se logra esto, el rumbo del proyecto se desvía y su final es incierto. Identificar las necesidades, ver las falencias y guiar a las personas, son actividades diarias de un arquitecto en la etapa de desarrollo y construcción. Su seguimiento debe ser garantizado.

E. Liderazgo

Este concepto se ve reflejado en los dominios anteriores. El liderazgo no es solo saber cómo decir las cosas, el liderazgo incluye ser diferente al resto, siendo más proactivo y proponiendo soluciones. Para eso, el arquitecto debe estar a la vanguardia en la tecnología y estrategias, y así poder realizar las decisiones correctas, fundamentadas apropiadamente por los conocimientos. Adicionalmente, el líder debe lograr la unión del equipo para que estén alineados con la visión del proyecto. Esto se logra con carisma y dedicación que puede ser contagiada o transmitida al resto; pero para eso, no solo, si bien es de suma importancia, hay que tener confianza en sí mismo.

III. CONCLUSIONES

El enfoque que presenta el documento ha sido de grata lectura. De por sí, da la impresión de ser destinado a personas inicializándose en la carrera de arquitecto (juniors) o estudiantes de ingeniería. Permite una buena perspectiva, a grandes rasgos, de lo que hay que tener en cuenta así como también permitir una breve idea de si uno se siente capaz de poder realizar estas actividades. Es importante remarcar que si bien no hay gran detalle de cada punto planteado, y no habla desde un punto de vista técnico propio de un arquitecto, si son aspectos a tener en cuenta para poder cumplir con el rol apropiadamente. Se podrían tomar como estrategias actitudinales o, como dice el documento, de dominio.

REFERENCIAS

[1]  Dana Bredemeyer and Ruth Malan, Bredemeyer Consulting  - The Role of the Architect

[2]  Formato IEEE para presentar artículos