Arquitectura de software - Parte 4 (fin)

¡Hola a todos!

Para continuar con la cuarta y última parte sobre Arquitectura de Software me centraré en los temas Arquitecturas Orientadas a Servicios y Evaluaciones de Arquitecturas.

Tiempo de lectura estimado: 8-9 minutos.

Antes de comenzar, me gustaría recordar que en la parte anterior (parte 3) sobre Arquitectura de Software vimos Representación de la Arquitectura (Viewpoints, Views, Perspectives, SAD) y Patrones de Arquitectura (Contexto + Problema  + Solución, ej. Broker). Sigamos ahora con estos dos últimos temas: SOA y Evaluaciones.

Arquitectura Orientada a Servicios

La puesta en práctica del paradigma Service Oriented Computing (SOC) requiere la implementación de una Service Oriented Architecture (SOA).

SOC es un paradigma de computación que utiliza servicios como elementos fundamentales para dar soporte al desarrollo rápido y de bajo costo, de aplicaciones distribuidas en ambientes heterogéneos.

SOA es una forma lógica de diseñar un sistema de software para proveer servicios a usuarios finales, aplicaciones u otros servicios, a través de interfaces públicas que pueden ser descubiertas.
Algunas características de este tipo de arquitecturas son:

• Los servicios se mapean a funcionalidades de negocio

• Cada servicio tiene una interfaz bien definida que le permite ser publicado, descubierto e invocado

• Una organización puede publicar sus servicios de forma externa, para interactuar con sus socios de negocio, o de forma interna a la organización

• Debe cumplir con principios tales como Contratos estandarizados, Abstracción, Reusabilidad, Autonomía

La siguiente imagen muestra un ejemplo de lo que sería el diseño de una arquitectura antes y después de aplicar el concepto de SOA.

Compraración de una Arquitectura antes y después de SOA

Del lado derecho, en el After SOA se puede ver como se plantea claramente una separación en capas de las responsabilidades, comenzando por Aplicaciones que ofician de consumidores, luego una capa de Procesos de negocios que son soportados por la capa de Servicios, que cuenta con distintos Componentes que dan respuesta y solución a las solicitudes que llegan, y finalmente en la capa más baja los distintos Sistemas operacionales que manejan los repositorios de datos correspondientes.

A mi entender, uno de los beneficios más importantes de las SOA es la agilidad que brinda para exponer servicios que agregan valor en base a la combinación de servicios ya existentes, lo cual generalmente significa menos duplicación de recursos, más reutilización y como consecuencia menores costos.

Sin embargo, hay algunos desafíos que se nos plantean si utilizamos SOA, como por ejemplo identificar los servicios adecuados y definir los contratos de los mismos, no es una tarea trivial si realmente queremos darle valor y utilidad a nuestra arquitectura.

Vale agregar que si bien los principios de SOC y SOA no dependen de una tecnología en particular, los Web Services se han convertido la tecnología preferida para implementar una SOA.

Como último punto en esta temática Arquitectura de Software, me gustaría dejar una reseña sobre evaluaciones de arquitecturas, qué son y para qué sirven.

Evaluación de Arquitecturas

El hecho de realizar evaluaciones a las arquitecturas apunta a incrementar la calidad, controlar los costos y disminuir el riesgo de la inversión (al igual que el testing y la documentación). No es una actividad que garantiza alta calidad ni bajo costo, pero sirve para identificar riesgos.

¿Cuándo realizar la evaluación de la arquitectura?

• Es más efectivo al principio del ciclo de vida del producto, pero puede ser realizada en varios puntos del desarrollo
• También se puede evaluar la arquitectura de los sistemas legados (no necesariamente los que se están por construir)
• Incluso se podría evaluar software adquirido

¿Qué Métodos de Evaluación de Arquitecturas podemos utilizar?

• ATAM es un método estructurado que da como resultado una lista de riesgos de la arquitectura de no cumplir con sus objetivos de negocio
• CBAM es un método para determinar qué riesgo atacar primero, enfrentando el costo de modificar la arquitectura para reducir el riesgo y el beneficio de removerlo

Existen otros métodos de evaluación de arquitecturas tales como Software Architecture Analysis Method (SAAM), Architecture Level Modifiability Analysis (ALMA), Family – Architecture Analysis Method (FAAM).
Para poder profundizar en cada uno de estos métodos sería necesario un post por cada uno de ellos, pero mi intención no es ir al detalle de un método específico si no dejar planteado el tema Evaluaciones de Arquitecturas para generar inquietud en quienes no lo conozcan o en quienes tenegan un poco olvidado el tema. Hay mucha documentación en la web sobre estos métodos, incluso varios documentos con casos de estudio o ejemplos.

Simplemente a modo de ejemplo, a continuación dejo un pequeño pantallazo de ATAM y CBAM, y una referencia sobre cada uno de ellos a unas ppt de la Universidad de los Andes (Colombia) que están interesantes para entender un poco más en qué consisten estos métodos, qué implica aplicarlos y cuáles son los beneficios.

ATAM

El propósito del Architecture Trade-off Analysis Method (ATAM) es evaluar las consecuencias de las decisiones arquitecturales en función de los atributos de calidad.

Algunas características de ATAM:

• Utiliza los objetivos del negocio
• Hace partícipe a los involucrados
• Se enfoca en la porción de la arquitectura que es central para lograr dichos objetivos

Este método cuenta con varias fases a seguir y cada una de ellas propone ciertos pasos como guía.

CBAM

Basado en que ATAM no considera un punto importante: las principales decisiones en sistemas complejos de gran porte tienen que ver con factores económicos; el Cost Benefit Analysis Method (CBAM), se basa en ATAM para modelar el costo y beneficio que tienen las decisiones arquitecturales y sirve como medio para optimizarlas

Algunas características de CBAM:

• No toma decisiones por los involucrados
• Colabora en la especificación y documentación de los costos, beneficios e incertidumbre acerca de un "portafolio" de inversiones arquitecturales
• Provee un marco para aplicar un proceso de decisión racional que cumpla con las necesidades de los involucrados y sus posibilidades de inversión

Al igual que en el caso de ATAM, este método cuenta con varias fases/pasos a seguir:

1. Intercalar, perfeccionar y priorizar escenarios
2. Asignar utilidad a los escenarios
3. Desarrollar estrategias arquitecturales para escenarios y determinar los niveles de respuesta de sus atributos de calidad correspondientes
4. Determinar la utilidad “esperada” de los niveles por interpolación
5. Calcular el beneficio total obtenido por una estrategia arquitectural
6. Elegir estrategias según su ROI sujeto a las restricciones de costo y calendario
7. Confirmar resultados con la intuición

Resumen

Para finalizar con esta primer temática sobre Ingeniería de Software, aquí dejo un resumen de los distintos temas que fuimos viendo en esta cuatro etapas sobre Arquitectura de Software:

• Parte 1 - Introducción (definición, propósito, quienes la influencian, rol del arquitecto)
• Parte 2 - Proceso de definición y Atributos de calidad
• Parte 3 - Representación y Patrones
• Parte 4 - SOA y Evaluaciones

Espero les haya resultando interesante la temática y les haya aportado en algo, o al menos les haya despertado el interés o la intriga sobre esta área de la Ingeniería de Software que en muchas ocaciones pasa desapercibida. Como dije en la primera entrega, 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.


¡Hasta la próxima!