Arquitectura de software - Parte 1

¡Hola a todos!

Tal como mencioné en el post anterior hoy comenzaré con un acercamiento al tema Arquitectura de software. Como introducción voy a compartir una definición de arquitectura, siguiendo por cual es su propósito, quienes la influencian y finalmente el rol del arquitecto.

Tiempo de lectura estimado: 5-6 minutos.

Una de las definiciones modernas de arquitectura de software y que a mi entender es simple y clara es la del Software Engineering Institute (SEI) de la Universidad de Carnegie-Mellon “...es la estructura o estructuras del sistema, que comprende elementos de software, las propiedades visibles externamente de dichos elementos y la relación entre ellos”, basada en el libro Software Architecture in Practice.

Desde una visión no tan conceptual, se puede decir que la arquitectura es estructura y comportamiento, se enfoca en elementos significativos o relevantes, se presenta a un alto nivel de abstracción, está presente en cualquier sistema y balancea necesidades de los involucrados.

Su propósito es comprender el sistema y organizar el desarrollo, fomentar la reutilización de componentes y facilitar la evolución del sistema

Generalmente, la arquitectura se ve influenciada por distintos factores que afectan significativamente tanto su definición como su mantenimiento, algunos de ellos se pueden clasificar en:

• los stakeholders (involucrados)
• la organización que desarrolla el sistema
• el ambiente tecnológico 
• la experiencia del arquitecto 

El Arquitecto debería gestionar estas influencias sobre la determinación de la arquitectura y debería crear la arquitectura junto con otros stakeholders que tienen ciertos requerimientos, objetivos, intenciones y aspiraciones. Es el arquitecto quien tiene la responsabilidad de emitir juicio y tomar decisiones de compromiso en estos aspectos.

Vale la pena detenerse en el concepto de stakeholders y en la definición de los escenarios de arquitectura, dos temas relevantes para lo que será el proceso de definición de la arquitectura.

En cuanto a los stakeholders, es muy importante su detección e identificación temprana, así como su clasificación para luego realizar el seguimiento adecuado de sus concerns (requerimientos, intereses y necesidades).

El software habitualmente es diseñado, construido, operado, reparado, usualmente mejorado y por supuesto pago por alguien. Cada una de estas actividades involucra un conjunto significativo de personas, cada una de ellas con sus propios concerns.

Es fundamental mantener a los stakeholders informados y comprometidos, pero es necesario hacerse algunas preguntas al respecto para determinar correctamente a quienes informar y comprometer.

• A quien queremos mantener Informado... ¿tiene la información, experiencia y comprensión para tomar las decisiones correctas?
• A quien queremos mantener Comprometido... ¿está disponible para participar y preparado para tomar decisiones?

Incluso con estas preguntas aún no es suficiente, estas personas o instituciones también deben estar autorizadas y ser representativas...

• A quien queremos mantener Autorizado... ¿es seguro que las decisiones que tome no serán modificadas (al menos potencialmente con un alto costo)?
• Quien debiera ser Representativo... si es un grupo y no un individuo, ¿es una muestra representativa?, ¿cada uno de ellos cumple con los criterios anteriores?

Este tipo de preguntas nos ayudan a conocer un poco más a los stakeholders y poder actuar en base a ello.

En cuanto a los escenarios, como definición podemos decir que un escenario arquitectural es una descripción concisa de una situación que el sistema enfrentará en el ambiente de producción, junto con una definición de la respuesta esperada de éste.

Los escenarios podemos dividirlos en dos grupos: 

• Funcionales :: secuencia de eventos externos a los cuales el sistema debe responder (normalmente derivado de los casos de uso) 
• No Funcionales o de Calidad :: cómo el sistema debe reaccionar a un cambio en un ambiente de forma tal de exhibir una o más propiedades de calidad.

A su vez, podemos utilizar los escenarios como datos de entrada para diferentes actividades, tales como:

• Proveer información a la definición de la arquitectura
• Evaluar la arquitectura
• Comunicarse con stakeholders
• Encontrar requerimientos faltantes
• Guiar el proceso de pruebas

Es fundamental capturar un conjunto útil de escenarios y priorizarlos para ver dónde centrar los esfuerzos. Generalmente los escenarios se derivan de los requerimientos, los stakeholders y la propia experiencia. La prioridad depende de aspectos como la importancia que le asignen los stakeholders y el riesgo que involucra la implementación de dicho escenario.

Para ir terminando con este primer acercamiento a la Arquitectura de Software, hay algunos puntos importantes a tener en cuenta respecto al Rol del Arquitecto que me gustaría mencionar:

• Debe ser formador de opinión
• Debe proporcionar la visión, orientación y experiencia que permita a otros hacer realidad esa visión
• Necesita comprender los aspectos técnicos y de negocio de un proyecto para comprometerse con la mejor solución
• Debe ser flexible para incorporar opiniones útiles de desarrolladores y otros involucrados
• Debe dirigir y coordinar las actividades y los artefactos técnicos durante el proyecto

Espero les resulte interesante la temática y les aporte en algo... como dije al comienzo, la idea es compartir, difundir y discutir, así que si tienen opiniones y experiencias para plantear, sería interesante que dejaran un comentario al respecto.

La próxima semana estaré tratando cómo debería ser un Proceso de definición de la arquitectura y sobre los Atributos de calidad de la Arquitectura.

¡Hasta la próxima!