ARQUITECTOS INFORMATICOS

El arquitecto de software como un ser visionario

El presente artículo viene a ser algo así como una versión poética y muy propia sobre las posturas que, a veces, se ve obligado a tomar un arquitecto de software, relacionando al arquitecto y su arquitectura, con un visionario y su visión, respectivamente.

Cuando hablo de visionarios, me quiero referir a una persona capaz de tomar o crear una idea o ideal y llevarlo a la práctica. Según mi propia consideración (y de muchas personas que saben en serio sobre el tema), una persona que sólo es capaz de tener ideas, sin llevarla a la práctica o promoverlas para que otros las hagan realidad, no es, ni será jamás, un visionario.

Un visionario

Sin dudas, un ejemplo de visionario fue Galileo Galilei (cache). Es válida la historia que de él se cuenta, en la cual, luego de su retractación forzada sobre la veracidad de la teoría Copernicana (cache) del Heliocentrismo , se fue diciendo por lo bajo Eppur si muove (y sin embargo, se mueve).

Galileo fue un visionario y tuvo que lidiar con la adversidad. Llevar adelante una visión implica tomar algo que se encuentra en el plano ideal, y muchas veces irreal en la práctica actual y establecida, para hacerlo una realidad tangible. Las ideas originales o revolucionarias, e incluso aquellas no tan originales, que tienen que lidiar con la idiosincrasia y el saber establecido, encontrarán casi siempre un plano adverso.

La visión

En una visión -por ejemplo la de una empresa- las bases axiomáticas que conforman la visión tienden a doblarse, debido a la presión ejercida por el entorno (la realidad actual). El mantener una visión no implica cumplir a rajatabla los axiomas sin la menor noción de instinto de supervivencia, sino luchar para que éstos sean una realidad tangible en el futuro. El problema con la visión es que sitúa en el futuro el destino al cual queremos llegar y no nos dice cómo.

La realidad muestra de manera despiadada, que quién quiera llevar adelante una visión tiene que, primero que nada, sobrevivir para que se haga realidad. En ese sobrevivir, el instinto de supervivencia producirá que las bases axiomáticas se doblen, como le pasó a Galileo; pero si la visión es real, nunca permitirá que se quiebren (Eppur si muove).

El arquitecto y su visión de la arquitectura

Muchas veces, un arquitecto se encuentra en ambientes hostiles a sus ideales. Muchas veces es sólo culpa del arquitecto debido a su soberbia y/o cuestiones ambientales; viéndose en la necesidad de torcer los axiomas de su arquitectura ideal. En estos momentos, suele ganar la desesperación, preguntándose: ¿Por qué, si estoy haciendo algo que trae tantos beneficios, existen tanta resistencia? Seguramente, el problema radique en el arquitecto, ya que es difícil que existan personas que no entiendan ninguna explicación; creo, más bien, que existen personas que no pueden comunicarse debidamente con otras. Sin embargo, ante una situación de éstas, siempre es posible flexibilizar nuestros axiomas y así lograr dar el primer paso hacia la implementación real de la visión (arquitectura), manteniendo la esperanza de lograr el cumplimiento de todos ellos en el futuro.

Por estos motivos es que, a veces , la arquitectura es a su arquitecto, lo que su visión a un visionario.

El rol de los Arquitectos de Software


Introducción

De la misma manera que ocurre con la Arquitectura de Software, existen múltiples definiciones sobre el rol de los arquitectos. Podríamos incluso citar una definición por autor. Esto parece ser causa de que, en general, se ubica a los arquitectos en el contexto de una organización en particular, con las propias necesidades y requerimientos de esa organización. La realidad parece indicar que es poco probable que se pueda dar una definición de arquitecto, transversal a cualquier organización, y definir un estereotipo de arquitecto que especifique cuáles son sus responsabilidades y habilidades necesarias dentro de un proyecto. Lo que sí es posible es definir prototipos de arquitectos “a muy grandes rasgos” y aplicar cada uno de estos arquetipos, en una situación en particular, dependiendo del contexto de la empresa, del proyecto y del equipo de trabajo.

Confusiones comunes

El término Arquitecto de Software se ha convertido en el título de moda en toda empresa de sistemas o con un área propia de sistemas. Decimos de moda, debido a que no todas las empresas necesitan realmente arquitectos de software y, tal vez, ni siquiera todos los proyectos necesiten de un verdadero arquitecto de software. Es común que muchas de las tareas relevantes de un proyecto puedan ser perfectamente resueltos con desarrolladores experimentados, sin tener la necesidad de contratar un arquitecto. Muy frecuentemente se tiende a confundir estos dos perfiles, que son abismalmente diferentes. También es importante notar la diferencia entre los “gurúes tecnológicos” y los verdaderos arquitectos. Estas cuestiones aumentan la confusión existente sobre qué es un arquitecto y cuáles se supone tendrían que ser sus responsabilidades.

Existen otras figuras a las que habitualmente se les asigna este título de forma arbitraria; y que no siempre lo justifican, como ser:

Ingenieros

Científicos

Web masters

Project managers

Consultores

Analistas con profundo conocimiento del negocio

DBA’s

Tipos de arquitectos de software

Para definir qué es un arquitecto de software, debemos tener en cuenta un contexto y un escenario en particular. Dicho de otra forma, depende de la organización, de su negocio, de sus objetivos, de la influencia del área de sistemas, de la importancia de el/los proyecto/s y del tamaño de los mismos. Teniendo en cuenta este contexto, podemos proponer una serie de categorizaciones:

Arquitecto técnico

Se trata de profesionales con amplios conocimientos técnicos, conocedor del negocio de los proyectos y que, probablemente, esté asignado a uno o varios proyectos al mismo tiempo. Algunas de sus responsabilidades suelen ser: definir los lineamientos de diseño, su arquitectura y demás cuestiones técnicas de los proyectos.

Arquitecto funcional

Tienden a ocupar el rol de team leader y, a su vez, de líder técnico. Manejan el project y planifican junto al PM las iteraciones. Suele representar un canal de comunicación fluida entre el PM y los equipos de desarrollo. Validan diseños; guían a los desarrolladores, para que cumplan con las expectativas de calidad tomando métricas, organizando y promoviendo la documentación y las buenas prácticas; aseguran que el proyecto no se desvíe de la arquitectura previamente definida.

Arquitecto Corporativo

Unifica los dos casos mencionados anteriormente; pero con algunos agregados. Este modelo, tomado sobre la base que propone Bredemeyer Consulting , es al que apunta Epidata Consulting para sus arquitectos de software.

Probablemente, en la literatura referida al tema se logre recopilar una mayor cantidad de perfiles o roles de arquitectos. Esta mayor variedad, en general, apunta a grandes organizaciones, donde cada función está claramente dividida y, sobre todo, limitada, transformando al arquitecto en un ente con responsabilidades restringidas.

Rol de los arquitectos

Como base, el rol de los arquitectos suele comprender las siguientes tareas:

definición de las vistas de la arquitectura de una aplicación (o sea, CREAR la arquitectura, ya que la arquitectura, en pocas palabras es un conjunto de vistas de alto nivel);

dar soporte técnico-tecnológico a desarrolladores, clientes y expertos en negocios;

conceptualizar y experimentar con distintos enfoques arquitectónicos;

crear documentos de modelos y componentes y especificaciones de interfaces;

validar la arquitectura contra requerimientos, suposiciones;

Y además:

tener una dosis de estrategia y política, o sea, ser, en parte, un CONSULTOR.

De esta forma logramos unificar el arquitecto técnico con el arquitecto funcional, resultando un arquitecto corporativo. Una figura que probablemente se ajuste a cualquier realidad (adaptando algunos puntos específicos de sus tareas).

Dominios de los arquitectos

En el rol cotidiano de los arquitectos, existen varias tareas o dominios (más allá de las tareas propias incluidas en el ciclo de vida de un proyecto en particular) en los que suelen estar enfocados los arquitectos y que es conveniente determinar. Estos son:

tecnología

enfocado más en los objetivos de la organización que en las decisiones técnicas

creación de modelos problema/solución

exploración de alternativas de soluciones

preparación de documentos

convencer y comunicar de la factibilidad de las decisiones técnicas a los sponsors y stake holders (cache)

estrategias de negocios:

claro conocimiento de la estrategia de negocio de la organización, de los ciclos de planificación, proceso de toma de decisiones; conocimiento del contexto de la organización (competencia, productos, factores principales que afectan el éxito de la organización)

todo esto se resume en VENDER, pero no desde el punto de vista comercial, sino mas bien, desde el punto de vista de la actitud,

la comunicación y lo valores de calidad trasmitidos.

políticas de la organización:

conocer los principales stake holders (cache) de la organización. Especialmente, saber lo que ellos quieren y necesitan; mantener una comunicación fluida con éstos.

generación de reportes y comunicación de resultados.

liderazgo:

tener una visión del contexto

toma de decisiones

selección y creación equipos

motivador

tener carisma y credibilidad

compromiso y dedicación

evangelización tecnológica

puente entre desarrolladores, PM's y expertos de negocio.

Sabemos que los arquitectos también forman parte del proceso de desarrollo de un proyecto. Durante este proceso, las fases comúnmente reconocidas como más importantes en la actuación del Arquitecto de Software son:

pre-diseño:

entender el alcance del proyecto

entender los puntos más importantes del diseño: validar y manejar requerimientos y expectativas del cliente

análisis de dominio:

entender en detalle los requerimientos del cliente

crear bocetos de los comportamientos deseados del sistema

diseño esquemático:

definir el look&feel

si es necesario, construir prototipos

desarrollo de diseño:

ampliar los detalles y refinar el diseño para llegar al diseño final

finalizar todos los diseños

documentos del proyecto:

soporte a desarrolladores: lidiar con problemas concretos, revisión de código para controlar la calidad, ver cómo funcionan (o no) las cosas

definir el proceso de desarrollo, los roles de los miembros del team y la secuencia de construcción de la aplicación

especificar metodologías y tecnologías.

definir todos los detalles necesarios para todos aquellos que construirán la aplicación

contratación o staffing:

seleccionar desarrolladores

si el desarrollo es tercerizado, participar en la elección del proveedor

construcción:

asegurar que la visión del cliente sea mantenida y respetada durante el desarrollo

revisar y validar los diseños de nivel de construcción si la complejidad de los mismos lo amerita

diseñar modificaciones pedidos por el cliente.

participar en el testeo y aceptación de la revisiones solicitadas por el cliente

post construcción:

asistencia en la migración del sistema nuevo (implementación)

puede llegar a manejar el entrenamiento de los usuarios nuevos

definir procesos de mantenimiento

También existen una serie de adjetivos que, probablemente, terminen explicando la forma de ser y actuar de los arquitectos. Aunque más que características, se podría decir que son requisitos:

visionario: saber identificar las oportunidades que se le presentan. Crear y mantener una visión del modelo de la solución.

analítico: comprensión y validación de especificaciones y modelos.

comunicativo: frecuentemente "puente" entre distintos jugadores de la organización

decisivo: toma de decisiones críticas.

responsable: actitud ejemplar en el equipo de trabajo. Comprometido con "su creación".

orientado a aprender: para cumplir con una de las metas: la evangelización. Es imprescindible la actualización y capacitación constantes en todas las área que le competen (management, tecnología, metodologías, etc.)

jugador de equipo: predisposición para cooperar y convivir con distintos perfiles.

"bien hablado": correcto uso del lenguaje, por la necesidad constante de comunicar de forma eficiente.

Esperando la estandarización

Desde sus orígenes, en la universidad Carnegie Mellon (cache), la arquitectura de software espera que llegue finalmente una verdadera especificación que sea válida y aplicable en todos los contextos empresariales conocidos. La diversidad de opiniones y experiencias llevan a que varias organizaciones internacionales intenten (por ahora en vano) crear un modelo de arquitecto y arquitectura.

Por ahora, queda a criterio de cada organización el moldeo y “customización” de sus propios arquitectos. Es importante entender que no cualquier profesional puede ser nombrado arquitecto, ya que este punto nos ha llevado al día de hoy, a necesitar un ente superior que ponga un poco de claridad sobre el tema.

Nombrando sólo algunas de estas organizaciones, encontramos a la Enterprise-wide IT Architecture (EWITA ) (con la participación de Bredemeyer Consulting ) y la Worldwide Institute of Software Architects WWISA ) que con sus trabajos difunden el “buen uso” de la arquitectura de software y sus actividades relacionadas.