Software Architecture and business objetives

El miercoles 4 de noviembre tuve la oportunidad de asistir a una conferencia del Phd Andres Diaz Pace (ADP) en donde presentó la metodologia del SEI para la documentación de arquitecturas de software. Al finalizar la presentación de Andrés varios panelistas hicieron sus comentarios y respondieron a preguntas de los asistentes.

A continuación voy a intentar resumir los aspectos relevantes del la presentación.

ADP comentó que hay muchas definiciones de Arquitectura de Software, entre ellas comentó la del SEI ("Software Architecture in Practice", Clements, 2008).
Entre los apsectos importantes que rescaté del seminario es que se tome en cuenta o no la arqteuictura de software siempre existe, en forma formal mediante procedimiento o informal o implicita. Es decir si no diseñamos arquitectura alguien en el proceso de desarrollo lo hará y de la mejor forma que pueda, con el peligro que ello acarrea.

Otro aspecto es el lugar de la arquitectura de software en el proceso de desarrollo, ADP mostró un proceso simplificado en donde se inicia por lso objetivos de negocios, luego los requerimientos funcionales, de allí la arquitectura de software y finalmente el sistema. Este es un proceso iterativo en donde del objetivo de negocio se deriva a especificaciones funcioanales de alli mediante diseño se contruye la arquitectura de software y luego el equipo de desarrollo la implementa.
Al grupo de arquitectura debe participar en todo el proceso de desarrollo de software teniendo mayor porcentaje de participación durante la etapa de elaboración del proceso, pero tambie´n requiere cierto grado de participación durante la etapa de incepción, transisión e implementación.
ADP considera incorrecto que el equipo se desvincule totalmente del proyecto luego de terminado el diseño arquitectónico, por eso es requerido un cierto grado de participación en la demás etapas.

Otro aspectos importante de mencioar es que el diseño arquitectónico permiti reducir los riesgos en el proyecto, pues se encarga de elicitar los atributos de calidad, validar la infraestructura, validar con áreas auxiliares (seguridad informatica, tecnología, stakholders etc). Cabe destacar que el disertantem comentó que involucrar a muchas áres implica un riesgo a la hora de documentar la arquitectura pues cada área tiene su propia visión del proyecto y puede querer incluir en la documentación aspectos que no son parte del diseño arquitectónico (tal vez si de documentación complementaria).

Se discutió sobre lo que NO es la arquitectura de software, y ADP dió algunos ejemplos como:
- No es la arquitectura del hardware.
- No es el modelo de datos.
- No es solo un diagrama de "cajitas" interconectadas.

De este último punto se desprende que por presiones varias los stakholders intentan reducir el tiempo de diseño para pasar rapidamente al momento de la implementación, por lo tanto la arquitectura dieñada tiene una visión muy general, no consdiera atributos de calidad, riesgos por el uso de tecnologías no estandares en la compañía etc.

Elicitación de atributos de calidad:
Estre los procesos recomendados por el SEI se comentó uno denominado QAW (Quality Atributte Workshop)http://www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm
Este proceso tiene como fin comprometer a los stakholders para definir precisamente los atributos de calidad requeridos en el proyecto. Basicamente la técnica implica litar los atributos de calidad y leugo mediante votación se pondera cada atributos. Luego de eso se puede elimiar algunos meno prioritarios (o dejar su analisis para un posterior release) dejando solo los más importantes.
La técnica es simple, pero lo que no es simple conseguir que los stakholders se involucren en este aspecto, pues la visión de los atributos de calidad de cada uno puede diferir bastante.

Basicamente lso siguientes son los aspectos más importante de eta técnica:

- Centrado en el sistema.
- Focalizado en los stakeholders.
- Técnica implementada antes de definier la arquitectura.

Una sesión de QAW debería seguir los siguientes pasos, la misma está moderada por un facilitador, el manager del proyecto y el arquitecto. Es importante que tiene que tener un time frame definido y en la manera de lo poible obtener un consenco documentado.

1- Introduction to QAW (Manager)
2- Business Mision Presentation (Arquitecto).
3- Indetification of Architecture Drivers
4- Scenarios Bainstorming.
5- Scenarios priorization
6- Scenario refinemente
7- Return to 1.


Esta técnica permite concentrar el esfuerzo en el diseño de aspectos no funcionales para los atributos de calidad más relevantes para los stakholders del proyecto.
la técncia define que en la documentación de atributo de calidad se deben considerar los siguientes aspectos:

1- Estímulo: Es el evento de entrada.
2- Respuesta al estímulo.
3- Fuente del estimulo.
4- Condición del ambiente.
5- Medida de la respuesta.

Por ejemplo si el atributo de calidad es la performance una simplificación (hiper simplificada) para estos aspectos serían:

1- Estimulo: Request a una determinado servicio.
2- Respuesta al estímulo: Mesaje de respuesta en XML (especifica peso en Kb).
3- Fuente de estimulo: proceso X que corre en servidor Z.
4- Condición de ambiente: X% de CPU, Z Mb de memoria consumir por el servidor, I/O, Byterates etc.
5- Medida de la respuesta: Reqeust por segundo, %CPU y %memoria conumida por el proceso en cuestion etc.

En la documentaciónd el SEI existen tablas donde están tabulados varios atributos de calidad.

Consderaciones sobre documentación de arquitectura.

Debe tener un enfoque basado en vista. Cada vita mostrará difentes niveles de detalle de la arquitectura y representaciones para diferentes interlocutores (lógica, capas, implementación etc).
En la documentación se debe tener el trace entre una objetos de una vista y de otra.
Un mayor nivel de detalle reduce el tiempo dedicado al mentoring y el coaching a la hora de implementar la arquitectura. Esto no implica que se reduzca a cero pues el arquitecto participa en todo el proceso de desarrollo.

Por ejemplo en un vista en donde se quiera detallar aspectos de seguridad deber indicar zonas de seguridad, puntos de entrada, conexiones etc.
Si es por un tema de performance, incluiría vistas de procesos, interacción etc.

En la documentación del SEI se clasificar las diferentes vistas.

En resumen las vistas deben consdierar los siguientes aspectos:

1- Estructura del sistema en térmicos de unidades de código.
2- Interacciones en tiempo de ejecución.
3- Como se relacionan con estrucmturas no software.
4- Interfaces.
5- Comportamiento.

Tambien se puede ver desde tres perpectivas diferentes:

1- Módulos: Contrucción, analisis de impacto, pruebas etc
2- Componentes y conectores: performance , disponibilidad etc.
3- Asignación de responsabilidades: Diponiblidad , seguridad, performanceetc

Para evaluar la completitud de una vista hay que considerar la descripción de sus elementos constitutivos, mapeo entre vistas, deben existir diferentes vistas según perfil de stakholders, asegurarse que contengan información útil.

Evaluación de arquitecturas:

Luego de esta introducción el disertante comento sobre el proceso ATAM (Architecture Tradeoff Analysis Method) http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm

ATAM provee tendencias sobre la evaluación de la arquitectura, no aspectos precisos. Esta técnica ayuda a evaluar aspectos de la arquitectura como nivel de enfioque en el producto software, detección temprana de riesgos, prácticas de ingenieria de software, aspectos de calidad etc.
Dado qeu es un proceso complejo se sugiere efectuarlo luego de tener terminada la primera iteración de la documentación de arquitectura y luego de finalizada cada etapa de elaboración de las sucesivas iteraciones.

Un aspecto que comentó como introducción el disertante fue la técnica de diseño definida por el SEI, es la ténica ADD(Atribute-Driven Desing) http://www.sei.cmu.edu/library/abstracts/reports/06tr023.cfm

De eta descripción podrai resumir que la técnia ADD permite articular lso objetivos de negocio con la arquitectura, mitigar riesgos y se considera en todo el proceso de desarrollo.

Como conslusión ADP mencionó que en el futuro próximo es importante considerar istemas que requieran gran escalabilidad (ej Facebook) o gestionados con recursos no cetralizados (ej Eclipse).

Finalmente el SEI tiene su blog en donde la comunidad puede participar

Saturn Netwotk Blog

SOA anti-patterns

Como en diseño de aplicaciones multicapas, web, cliente-servidor u otras existen patrones que describen problemas comunes y sus soluciones estandarizadas, en el caso de SOA no es la excepción. En este post no vamos a describir los patrones más comunes, pues son muchos y son de referencia para arquitectos y desarrolladores que trabajen en el diseño de servicios SOA, en el sitio de “SOA patterns”, http://www.soapatterns.org/ hay publicado muchos patrones y constantemente se agregan nuevos.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.


Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo

FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);

Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.

Interfaces Chatty

Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón

bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);

Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.

En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.