¿Arquitectos de Software? ¿Son necesarios?

En este artículo voy a analizar un material que me gustó y me hizo reflexionar sobre el concepto de arquitecto, cualidades y habilidades necesarias sobre el rol.

Para comenzar voy a citar el material sobre el cual quiero reflexionar y de paso les recomiendo la lectura en su totalidad:

http://msdn.microsoft.com/en-us/arcjournal/cc505974.aspx

Autor: Joseph Hofstader

"En proyectos de software, el título Arquitecto es a menudo definido de forma ambigua y el valor que brindan los arquitectos no se mide con facilidad"

Este frase resume la actualidad sufrida en los actuales proyectos de ingenieria de software, incluso se torna muy complejo para las organizaciones encontrar el valor agregado por el concepto de arquitecto. La idea es encontrar como objetivo general el valor que los buenos arquitectos aportan a los procesos de desarrollo de software.

¿Les parece un buen objetivo?

Algo de lo que debemos partir para esta discusión es una definición de un buen arquitecto, para este objetivo voy a citar textualmente el artículo de Joseph:

"La función de un arquitecto de IT es resolver un problema mediante la definición de un sistema que se pueda implementar con el uso de tecnología. Los buenos arquitectos definen sistemas mediante la aplicación de conocimiento abstracto y métodos comprobados con el fin de crear una solución que se pueda extender y mantener."

La definición es genérica y tiene según mi punto de vista un buen equilibrio, cita el uso de tecnología, punto indispensable, pero el concepto toma fuerza en el conocimiento abstracto y aplicación de métodos comprobados para recrear soluciones extensibles y mantenibles.

Joseph continúa explicando su definición:

"A partir de esta definición concisa, podemos extrapolar que los buenos arquitectos utilizan una base de conocimientos para ser exitosos en el desempeño de sus funciones. Para "resolver un problema", el arquitecto debe tener una buena comprensión del dominio del problema. "Definir un sistema mediante el uso de tecnología" implica que el arquitecto posee visión técnica. El "conocimiento abstracto" requiere que el arquitecto pueda conceptualizar la solución técnica. Los "métodos comprobados" implican la comprensión de los patrones que se utilizan para resolver problemas similares"

Desde mi punto de vista impecable….

En este punto la pregunta que me formulo es:

¿Qué me aporta un arquitecto?

"El principal beneficio que un arquitecto aporta a un proyecto es la capacidad de aplicar estas habilidades en la definición y desarrollo de una solución potente de software"

Nota: Cuando se define "habilidades" son las desarrolladas por Joseph en la explicación del rol arquitecto, se las dejo en el gráfico expuesto.

Otro interrogante que me surge en este momento es definir qué riesgo tengo de no tener un arquitecto en alguno de los desarrollo, veamos que aporta Josept a este punto:

"El riesgo de no contar con un arquitecto que participe activamente en el desarrollo del producto aumenta la probabilidad de que el producto demore más en desarrollarse o que se desarrolle de forma incorrecta"

Ahora es momento de analizar cada uno de los escenarios:

• Conocimiento del Dominio
  
• Pensamiento Conceptual
  
• Visión Técnica
  
• Patrones
  

Conocimiento del Dominio

Para este escenario hay mucho que analizar pero me voy a quedar con un extracto del artículo, sabemos que el conocimiento del dominio puede ser horizontal o vertical, pero veamos este punto:

"A veces, los gerentes de IT subestiman el valor del conocimiento del dominio. Hace tiempo, trabajé para una compañía de telecomunicaciones cuyos directivos de IT deseaban cambiar la organización desde una estructura en torno a "centros de excelencia" dedicados a un dominio empresarial hacia una estructura con "conjuntos" de recursos basados en habilidades técnicas sin tener en cuenta el conocimiento del dominio."

Pasa seguido este tipo de situaciones, creo que es bueno replantear algunos mecanismos con respecto al escenario desarrollado dentro de las organizaciones actuales de desarrollo de software y analizar de forma acabada el dominio del problema a trabajar.

Pensamiento Conceptual

En este punto si me voy a explayar un poco más, veamos la óptica expuesta por Joseph:

"Una de las principales responsabilidades de un arquitecto es comunicar la solución a los diferentes participantes técnicos y no técnicos"

Comunicación primer concepto citado, concepto que muchas organizaciones sufren y en gran medida.

"Definir una arquitectura conceptual antes de comenzar el desarrollo de una solución de software ayuda a facilitar el bucle de retroalimentación necesario para definir el alcance de un producto así como también a determinar un nivel inicial de esfuerzo y estimación de costos para un producto."

Esto es un proceso desde mi óptica muy importante, los ciclos de vida en los cuales estamos metidos a diario lo contemplan, ¿Se aplica? ¿Seguro?

"El modelo conceptual es el artefacto más asociado con la arquitectura de software. Por lo general, el modelo conceptual muestra los componentes de un sistema de software que cumplirán los requisitos funcionales y el lugar en el que se aplicarán en una solución de software (interfaz de usuario, capa de dominio, etc.). con frecuencia, el modelo conceptual está acompañado de una cantidad de diagramas que muestran el flujo de la información en la solución propuesta"

Sin lugar a dudas el modelo conceptual es muy importante y el arquitecto tiene amplia participación en estas definiciones.

Visión Técnica

Un arquitecto tiene que ser técnico es la pregunta que a menudo recibo, y este interrogante lo transfiero a las soluciones de software, a ver, leamos el enfoque…

"Comprender el modo en el que funciona una tecnología no es suficiente para desarrollar una solución de software eficaz, comprender el lugar en el que se aplica la tecnología dentro de una solución es esencial para el desarrollo de un producto de calidad"

Esto es claro para las soluciones de software, pero en resumidas cuentas, ¿Cual es la relación del arquitecto con la visión técnica?

"Un arquitecto debe comprender, como mínimo, el objetivo y la aplicabilidad de cada tecnología antes de requerir su uso en el contexto de una solución de software. El arquitecto también debe mapear la tecnología para los requisitos funcionales o para la parte aplicable de la arquitectura conceptual"

Impecable!!

Ahora, esto va para quienes desempeñamos en alguna media el rol de arquitecto, reflexionemos sobre lo que expone Joseph:

"Con mucha frecuencia, me he encontrado con la mala práctica en la que un arquitecto establece un mandato técnico sin explicar la aplicación prevista para la tecnología. Para ser sincero, a veces he cometido el mismo error al comienzo de mi carrera.

A veces, los arquitectos permiten que su pasión por la tecnología deje en un segundo plano los problemas que se deben resolver"

Este segmento tiene mucho más por analizar pero quiero completar el artículo de forma concreta para dar un sentido de completitud en la síntesis del rol arquitecto, veamos el último punto.

Patrones

Bien, este punto sí que me gusta, y creo en la gran potencialidad del concepto, veamos qué opina Joseph.

"Una habilidad fundamental que poseen todos los grandes arquitectos es la comprensión del modo en el que se aprovechan los patrones en la definición de una solución de software"

Desde mi punto de vista, nada que objetar. Pero si puede surgir el interrogante, sobre que implica este conocimiento de patrones, ¿Viene de un día para el otro? ¿Cómo se forma?

Sin duda esto no llega de forma simple y Joseph lo detalla de forma bastante clara.

"El uso convencional de patrones en un desarrollo de software ha provocado que esto sea una habilidad fundamental para arquitectos. Comprender el modo en el que se usan los patrones implica tiempo y esfuerzo"

¿Hay motivaciones para usar patrones? ¿Qué les parece?

"Una de las motivaciones principales para aprovechar patrones en una solución de software es la capacidad de diseñar marcos que permiten que la solución se extienda con facilidad"

Este es uno de los tantos enfoques sobre patrones…

Conclusiones

Creo que esto es una buena aproximación al rol de arquitecto, como siempre existen diversas corrientes para analizar pero quiero dejarles un segmento que expone Joseph y que me ha ocurrido también:

"Hace algunos meses, mientras esperaba para hacer una presentación en un evento de un cliente, fui presentado a un desarrollador que participaba del evento como arquitecto de Microsoft. Esperando alguno de los saludos habituales, como por ejemplo "un gusto conocerlo", me sorprendió que lo primero que dijo fue "creo que los arquitectos son irrelevantes". Como no deseaba crear una discusión antes de mi presentación, respondí con una sonrisa y dije: "Espero que no"."

¿Curioso tema no?

Para cerrar solo una frase final:

"Un proyecto que se diseña mal se debilita sin resultados o se entrega con resultados inferiores. Por otro lado, una solución de software exitosa es bien diseñada por alguien que posee conocimientos de dominio, la capacidad de pensar conceptualmente con visión técnica y la habilidad de aprovechar patrones para resolver problemas"

Espero les sea de utilidad….

Nota: ¿Quién es Joseph Hofstader?

Joseph Hofstader es arquitecto para la organización Developer and Platform Evangelism de Microsoft. También es profesor adjunto del departamento de Tecnología de la Información y Comercio Electrónico de la Universidad de Denver. Antes de unirse a Microsoft, era Miembro Distinguido del Personal Técnico en Avaya. Joe dedicó su carrera a crear, diseñar y desarrollar soluciones en la industria de las telecomunicaciones