Arquitectura de software, fundamentando el concepto…

Como introducción al artículo voy a detallar el porqué de nombre especificado, creo que actualmente se definen de diversas maneras los conceptos de arquitectura de software y ni hablar de las responsabilidades del arquitecto de software.

En mi semana laboral he asistido a una charla sobre arquitectura en donde tenía esperanzas de encontrar conceptos sólidos y bien fundados sobre que comprende la arquitectura del software y principalmente el rol y actividades del arquitecto. En cierta forma encontré respuestas pero poco fundadas y que en un 80% se contradecían.

En fin voy a intentar recrear una óptica de arquitectura de software para poder entender las funciones de un arquitecto.

¿Qué se entiende por arquitectura?

En primer lugar voy a colocar un enfoque muy interesante definido por (Bennett, McRobb y Frarmer) en donde se cita a RIBA (The Royal Institute of British Architects) para la definir que hacen los arquitectos:

"Los arquitectos están entrenados para entender sus explicaciones y pueden ver el conjunto, ellos miran más allá de sus requisitos inmediatos, para diseñar edificios flexibles y que se adapten a las necesidades cambiantes de sus empresas"

"Los arquitectos solucionan los problemas de forma creativa, cuando están implicados en las primeras etapas de planificación, disponen de más oportunidades para entender sus empresas, para desarrollar soluciones creativas y para proponer formas de reducir costos".

Este enfoque propone sustituir "Edificios" por "Sistemas de Información", y yo creo al igual que muchos que me sentiría implicado en el rol. Pero hagamos un análisis superior sobre la comparativa de la arquitectura de sistemas y la arquitectura de edificios (aspectos comunes en las frases definidas anteriormente):

• Los arquitectos de sistemas actúan en nombre del cliente
  

Este primer punto es real se trata de dar el mejor soporte mediante una solución de sistema de información, en su forma básica. Ahora el cliente generalmente aplica conceptos conflictivos y en este punto es el arquitecto quien debe solucionar los mismos.

• La arquitectura de sistemas se dirige al conjunto del sistema.
  

Esto tiene que ver con la vista global aplicada al dominio de resolución. Normalmente no se encarga del diseño detallado pero si puede bajar lineamientos sobre el mismo. Esto punto es radicalmente importante de comprender según mi punto de vista.

• La flexibilidad es importante, el arquitecto tiene que tener en claro el concepto de forma excluyente.
  

Sin duda se debe tener como critico el concepto de flexibilidad para analizar y diseñar un arquitectura pero el cliente puede suponer otras características que el arquitecto debe incluir en el desarrollo del sistema.

• Los arquitectos de sistemas están preocupados por la solución de problemas.
  

En sistemas los problemas se manifiestan como riesgos, la idea es concentrándose en la arquitectura y tomando decisiones en función de la misma en etapas tempranas del ciclo de vida del proyecto, estos riegos pueden reducirse y hasta mitigarse.

• La reducción de costos no es un objetivo principal de los arquitectos de sistemas.
  

Esto es una gran verdad, pero tomemos el enfoque por el análisis arquitectónico al inicio del ciclo de vida minimizando los riegos de cambio que si implican grandes costos dentro de los desarrollos.

Ahora la pregunta es: ¿En que soportamos una arquitectura?

Como primer punto voy a poner algo que se conoce desde tiempo en la ingeniera de software, el análisis es inevitable sobre los detalles, se necesita comprender y documentar hasta el más mínimo requisito de una forma clara y sin ambigüedades, además se requiere de un diseño que trate de reflejar todos los aspectos del modelo de análisis. En este punto tenemos la interacción de (roles) una analista de negocios, analista de sistemas y un diseñador de sistemas.

Entonces ahora si voy a definir arquitectura, "la arquitectura contempla las funciones a gran escala del sistema y como esas funciones trabajan como un todo, el arquitecto agrupa las clases de paquetes, modela el sistema como un conjunto de componentes que interactúan y considera las plataformas para desplegar esos componentes para conseguir las cualidades requeridas para el sistema".

Es necesario detallar que existen diferentes perspectivas de arquitectura dentro del desarrollo de sistemas, es por este motivo que el objetivo que tengo es basarme en arquitectura de software:

Antes de continuar les propongo analizar lo que dice la IEEE con respecto al tema:

Standart IEEE 1471-2000:

• Sistema: conjunto de componentes que cumplen una función o un conjunto de funciones específicas.
  
• Arquitectura: es la organización fundamental de un sistema incorporada en sus componentes, en sus relaciones mutuas y en el entorno, y los principios que guían su diseño y evolución.
  
• Descripción de la arquitectura: es un conjunto de productos que documentan la arquitectura.
  
• Perspectivas de la arquitectura: es una representación desde una perspectiva especifica de un determinado sistema o de una parte del mismo.
  
• Punto de vista arquitectónico: plantilla que describe la forma de crear y utilizar un perspectiva de la arquitectura.
  

Descripto el estándar vamos a ver la propuesta de Arquitectura de Software "Es la organización de un sistema en términos de sus componentes de software, incluyendo los subsistemas y las relaciones e interrelaciones entre ellos, y los principios que guían el diseño de ese sistema de software"

En fin el objetivo principal creo que está cumplido, la idea es continuar modelando el concepto desde varias ópticas, en posteriores artículos voy a exponer las fuentes más interesantes según mi punto de vista sobre definiciones de arquitectura, principalmente hablando de "Arquitectura de Software".

Espero les sea de utilidad….