Arquitectura de Software

El día 22 de febrero tuvimos el agrado de compartir un desayudo/presentación del grupo arquitectum.org en la ciudad de Córdoba. Pudimos ver que en muchas de las definiciones sobre el rol que cumple el arquitecto de software en una empresa estaban bien concebidas dentro del perfil que se está desarrollando en Harriague & Asociados. Entre los temas que se discutieron entra la forma recomendada por Microsoft del organigrama del área de Arquitectura, además, cuales son las responsabilidades del arquitecto en cada una de sus "facetas" por decirlo así, comencemos por el principio.

Definición del área de arquitectura (el qué, cómo y con qué)

Si bien el rol del arquitecto de software viene circulando desde hace mas de 10 años por los laboratorios de sistemas y las áreas de ingeniería de software, no se ha estandarizado una definición exacta de que es un arquitecto de software, es en este sentido que se busca en diferentes fuentes bibliográficas definiciones más claras de que es o como este debiera ser tanto como rol unipersonal como de un área que se dedique a la arquitectura de software, la siguiente definición.

“Arquitectura de software es la suma de los módulos complejos, procesos y los datos del sistema, su estructura y exactas relaciones entre sí, cómo puede ser y se espera que sea, sus extensiones y qué tecnologías participan, deducir las capacidades exactas y flexibilidad del sistema desde el cual se puede formar un plan para la implementación o modificación del sistema.” (Hohmann, 2003)

Con seguridad esta definición no abarca todos los aspectos de un arquitecto de software pero, toca las esenciales. Cabe mencionar que dentro de la gran gama de definiciones de diferentes autores se puede considerar que la arquitectura es diseño, si bien una de las tareas del arquitecto es “diseñar” una solución, el término diseño está siendo mal empleado y causa confusión al momento de la delegación de responsabilidades.

Si bien al momento de la creación de una solución de software para un cliente participan muchos roles y con responsabilidades muy claras sería bueno definir el objetivo (en términos no técnicos) que es lo que un arquitecto y el resto de su equipo debe hacer.

¿Qué?

El “Que” del desarrollo de una solución es el resultado de la unión de los requerimientos de un cliente que llegan a un arquitecto y este al tener una visión clara del entorno en el que se encuentra el cliente, las necesidades del mismo y las expectativas de crecimiento de este como resultado del uso de la solución que vamos a proveer, definen el propósito u objetivo de la aplicación de la mano de un modelado de negocios que es realizado en forma conjunta con los analistas que forman parte del equipo. Considérese que el arquitecto es el director de una orquesta sinfónica se encarga de coordinar a cada uno de los músicos para que la pieza que interpretan salga de acuerdo a la partitura.

¿Cómo?

Una vez con el modelado de negocios en mano y con un equipo de analistas funcionales, se confecciona la documentación técnica del proyecto, esto consiste en el análisis, modelado y diseño de la solución a los requerimientos del cliente. El arquitecto cumple el rol de organizador y facilitador de definiciones y como un validador de la evidencia del modelado.

¿Con qué?

Esta tarea es orquestada ( de nuevo por el arquitecto) y esta vez cambia el equipo de trabajo, ahora seguirá su trabajo junto con un metodólogo y un líder técnico con un framework de trabajo bien consolidado para definir cada una de las partes de la solución, esta vez si se toma muy en detalle a la solución, las decisiones deberán ser tomadas de acuerdo a la tecnología que vaya ser utilizada por el equipo de desarrollo, presupuesto y cronograma del proyecto (a esta altura ya debiera estar bien definido el equipo de trabajo del proyecto).

Organigrama propuesto

Esta más que claro que cada compañía tiene sus propios organigramas y definiciones de puestos de trabajo, y no es intención de nadie tratar de cambiar esto, lo que se intenta es dar una guía de cómo se pudiese que un área de desarrollo de soluciones se organice.

 

Si bien este organigrama toma en cuenta todas las áreas que se puedan involucrar en el mantenimiento y medianamente el desarrollo de aplicaciones, no cuenta con un área específica de ingeniería de software esta es esencial para toda aquella empresa que desee brindar servicios de software factory.

Calidad del servicio de arquitectura

Así como el término es aun algo poco definido, el servicio de arquitectura es aun más desconocido, la pregunta es, ¿Necesito un arquitecto para el proyecto? La respuesta a esa pregunta (si uno hace las cosas bien) va a ser siempre SI. Un arquitecto es aquel individuo que posee la visión más clara del negocio donde va a implementar una solución, y es capaz de hablar varios idiomas, por esto entiéndase, que es capaz de hablar con el cliente acerca de cómo encarar la solución en el mismo lenguaje que usa el cliente (lenguaje de negocios) y por otra parte es capaz de bajar a tierra todos esos conceptos en la forma más clara y técnica posible para poder comunicarse con los desarrolladores.

Características

A grandes rasgos se considera que un arquitecto de software debiese tener algunas (sino todas) de las siguientes características:

• Visionario (ver el bosque y no solo los árboles)
• Referente para su equipo de trabajo – consultor
• Guardián de las estrategias y definiciones
• Evangelizador de frameworks sin estar atado con la tecnología
• Diseñador con criterio corporativo

Conclusiones

Está claro que el rol de un arquitecto, de forma estándar, no está definida del todo, sobretodo en nuestro entorno latinoamericano de trabajo, y depende de las buenas definiciones y trabajo arduo que tenemos por delante el definir a cabalidad el rol, sus responsabilidades y habilidades.

Bibliografía

Albin, S. T. (2003). The Art of Software Architecture—Design Methods and Techniques. Indianapolis, Indiana: Wiley Publishing, Inc.

Hohmann, L. (2003). Beyon Software Architecture: Creating and Sustanining winning Solutions. Boston Ma: THE ADDISON-WESLEY .