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 
• 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 holder 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, 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.