Arquitectura de Software: ORM, Object-Relational Mapping - I Parte

Arquitectura de Software: ORM, Object-Relational Mapping - I Parte

¿(Des) Orientación a Servicios?

Un tema analizado en el Microsoft Architecture Day de Buenos Aires es un tema que a mi criterio resulta polémicos, la aplicación de SOA en la práctica.

SOA y su aplicación práctica en grandes empresas, según el disertante SOA no tuvo el exito esperado debido a multiples factores. La misma conclusión expresó Wilson Chelsa de Microsoft pero desde el punto de vista de retorno de inversión, modelos de beneficios etc.

- SOA resultó ser muy complejo de implemementar.
- La industria en general no se alineo a la filosofía de SOA en sus procesos de negocio.
- Requiere gran inversión en el cambio cultural de la organización.
- En sus etapas iniciales no existían servicios laterales de importancia cmo registry, governance etc.
- Las implemetaciones muchas veces no tuvieron los resultados esperados porque fue muy dificil adecuar la cultura del negocio a la folosofía SOA.
- Aún continua la discusión acerca de la granularidad de los servicios, pues si es muy granular se corre el riesgo de no exponer servicios de negocio, poco granular surge que es muy poco reutilizable. En mi experiencia los servicios expuestos muy pocas veces son reutilzables.
- El tema del versionado también está es discusión.
- El desempeño de las implementaciones SOA resultaron ser muy costosas por su grano grueso, muchas capas, gran overhead en sistemas laterales.

El disertante introdujo el concepto de (Des)SOA:
- Reducir la cantidad de capas lógicas y físicas.
- Framework como helpers externos en lugar de contenedores.

Actualmente la nueva arquitectura de Microsoft sobre sistemas distribuídos en clouds Azure, utilizan un modelo con menos capas en donde expone los servicios en forma independiente. Evidentemente es un tema para discutir en profundidad.

Este tema da para un interesante discusión.

Microsoft Architecture Day

En el día de hoy se hizo la reunión de la Comunidad de Arquitectos de Microsoft. Fue una reunión muy interesante en la que gente de Microsoft y otra empreass presentaron sus experiencias en soluciones de sistemas utilizando las últimas tecnologías de Microsoft,también se presentaron nuevos feactures de tecnologias como Windows 7 , WPF , Siverligh etc. Los asistentes pudieron preserciar presentaciones como:

Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.

Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.

Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.

Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software

- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.

En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.

Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.

Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:

- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.

Productos: SQL Services, Drizzle,Amazon WebServices etc.

Windows Communication Fundation

El WCF fue dado a la luz junto con el framework .Net 3.0 en 2006. En ese momento existían addíns para el Visual Studio 2005 que permitían generar proyectos WCF en forma simple, muchas de esas herramientas eran beta, y se debían usar un poco por linea decomandos y un poco dentro del VS2005,algo muy poco práctico para implementar en una empresa o sector de desarrollo de software.
No voy a describir los problemas que tuve con el desarrollo de proyectos WCF en VS2005 pues el el Visual Studio 2008 incluye todas esas herramientas que se debian agregar a la anterior versión del IDE pudiendo generar proyectos WCF en forma mucho más simple.

Para aquellos que aún no han trabajado con el WCF o necesitan una capacitación de diferentes aspectos que provee esa tecnología les sugiero los siguientes recursos. Los WebCasts están basado enel Visual Studio 2008, por ese motivo es conveniente usar ese entorno.

En ingles
WCF Getting Started
http://msdn.microsoft.com/en-us/library/ms734712.aspx

Microsoft Windows Communication Foundation Step by Step, John Sharp
Disponible para su compra en Microsoft-Press

http://www.microsoft-press.co.uk/scripts/product.asp?ref=811252

O bien en librerias online como http://www.books24x7.com

Pro WCF: Practical Microsoft SOA Implementation

by Chris Peiris, Dennis Mulder et al.
Apress © 2007 (505 pages) Citation
ISBN:9781590597026

Providing coverage of the unified programming model, reliable messaging, security, peer-to-peer programming, and more, this is a complete guide to WCF from the SOA architecture perspective and shows why WCF is important to web service development.
(este aun no lo lei,pero me parece muy interesante)

En Portugues (Brasil)

MSDN Webcast: Melhores práticas no uso do WCF
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032409560&flag=3

Webcast Arquitetura: Arquitetura Orientada a Serviços: WCF Boas práticas (do levantamento, construção e hospedagem
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032415471&flag=3

¿Por qué es necesario un arquitecto de software?

“Architecture in an over used term and therefore doen’t mean anything anyway”

“Oh we don’t need training, we are Enterprise Architecture”,

“Help I need to hire architects but cannot define the role”, HR manager

“Why should I hire architects?, No one has ever made the case to me ”, CEO

“Architects just vision jockeys right?, We need coders no talkers”, developer manager

Estas frases fueron recolectadas de varias conferencias sobre arquitectura de software, encuestas y otros eventos de IT [Preiss Paul T, 2006, “Magician apprentice”] e indican en grado de confusión que existe respecto a la arquitectura de software, entonces como arquitectos es importante tener una buena respuesta a la siguiente pregunta: ¿Por qué es necesario un arquitecto de software?

Los sistemas de información soportados por aplicaciones informáticas son cada vez más comunes y en muchos casos imprescindibles para el funcionamiento del negocio de la empresa. En estas últimas dos décadas la evolución de esos sistemas fue exponencial y además los procesos son más complejos y la tecnología permite hacer más cosas en forma más sencilla y más rápida. Este aspecto tiene el riesgo de crear grandes sistemas en forma relativamente simple y rápida sin tener el adecuado control en la calidad, el costo de esto es grande a la hora de mantener el sistema, de solucionar errores y fallas y de evolucionarlo para agregar nuevas funcionalidades.

Standish Group en su “Chaos Report” describe un estudio realizado sobre mas de 175000 proyectos en donde los resultados no fueron nada alentadores. La siguiente tabla indica los valores promedios de sobre costo, exceso en tiempo y baja satisfacción de la funcionalidad del producto con los deseado.

Parámetro (exceso sobre los estimado)	% promedio
Costo	189%
Tiempo	222%
Deficiencias en el producto final	60%

De los proyectos relevados solo el 12% terminó en tiempo y dentro del presupuesto asignado.

La investigación mencionada incluye el resultado de un encuesta entre algunos de los CIOs de esas empresas preguntando cuales serían los aspectos que se deberían mejorar para reducir estos indicadores en los proyectos. De esa encuesta surgió que los tres principales factores a mejorar fueron un mejor involucramiento del usuario, mejora en la administración del proyecto y tener requerimientos claros y bien documentados.

En cambio si consideraban que aspectos perjudicaban el éxito del proyecto se consideraron como prioritarios aspectos tales como malas de comunicación con el usuario, requisitos y especificaciones incompletas y cambios constantes en especificaciones y requerimientos.

De este análisis se describe que es muy importante tener una buena planificación, documentación de requisitos y especificaciones y fluída comunicación con el usuario para tener éxito en el desarrollo del software. Los cambios en las especificaciones y requisitos son imposibles de detener pues muchas veces son causa de cambios en el contexto del negocio que las crearon, por eso una buena planificación y requisitos bien documentados mitigan este riesgo, además si se trabaja con un entorno de trabajo estable, bien documentado que resuelva las tareas rutinarias, de mayor complejidad y administradas por la menor cantidad de roles posibles se mitiga en gran medida los riesgos en todas las etapas del desarrollo del software.

Por este último aspecto es que se necesito un grupo de arquitectura, pues interviene en como un grupo staff en todo el ciclo de vida del desarrollo, definiendo estándares, buenas prácticas, ofreciendo soporte, coaching al desarrollo y diseño, metodologías, frameworks (conceptúales y ejecutables): Participan también en definiciones o adopción de metodologías de desarrollo de administración de cambios que faciliten la tarea de los de más integrantes del equipo de desarrollo y de los stakeholder .

Por lo tanto necesitamos arquitectos para afrontar la complejidad de los sistemas, para ofrecer agilidad en los negocios, para reducir los costos en IT, para mejorar la alineación del área de IT en los negocios etc .

Como se habia mencionado las soluciones de software distribuidas sueles tener una alta complejidad, esa complejidad puede ser inherente a la tecnología y la especificación funcional del negocio o bien puede ser accidental. Muchos procesos de negocio presentados como complejos luego de una buen análisis se pueden simplificar, es importante recordar que los sistemas se basan en los procesos y no lo procesos a los sistemas, por lo tanto dedicarle tiempo a optimizar los procesos de negocios a ejecutar es fundamental en la etapa de inicio pues la construcción de los sistemas se basarán en esos procesos. El arquitecto debe tener la habilidad necesaria para entender el proceso, el problema y crear un modelo que se ajuste al mismo.

En cambio, la complejidad accidental está muy relacionado con las tecnologías y estilos de las arquitecturas elegidos. Una tarea muy importante que debe cumplir el arquitecto es la determinación de aspectos no funcionales de la arquitectura, tales como flexibilidad al cambio, mantenimiento, escalabilidad, reusabilidad, usabilidad, monitores, performance , seguridad etc.

Cuando se tienen definidos estándares de calidad no funcionales y restricciones tecnológicas impuestas por políticas de la compañía muchas veces la arquitectura puede ser más compleja porque se debe alinear a las mismas.

Además tiene que considerar políticas tales como restricciones debido a estándares externos, como por ejemplo SOX , internos de negocios , regulaciones gubernamentales etc.

El cumplimiento de estos conceptos permite reducir costos de IT, mejorar la satifacción del cliente interno proveyendo para el primer caso mejores herramientas que faciliten las tareas del personal de la empresa dedicada a la operatoria diaria del negocio y áreas relacionadas. Estas mejoras también benefician a los clientes externos puer les permite disponer de mayor control en sus pedidos, despachos de los productos adquiridos.