Gobernanza en una estrategia SOA

 

Integración con la estrategia de TI y su gobernanza

La capacidad de utilizar la tecnología para impulsar la agilidad y la innovación en el negocio, constituye un elemento fundamental para el alto rendimiento y tener éxito.

La SOA como marco de trabajo para el desarrollo de software de implantación de los servicios que se constituyen. El desarrollo de sistemas basado en SOA, requiere de un compromiso con este modelo en términos de planificación, metodología, herramientas y la infraestructura requerida.

El uso de técnicas y ayudas neutralizará algunos factores negativos que tendrán un impacto en su análisis y aumentarán el valor de otros factores positivos.

Al implementar la conectividad SOA a través de la conectividad de servicios, se realiza el siguiente valor:

• Ahorrar el costo de la conectividad personalizada o convencional.
• Eliminar la redundancia al ampliar los activos de TI ya existentes en lugar de duplicarlos.
• Proporcionar una experiencia de usuario segura y consistente al exponer el mismo proceso a través de nuevos canales empresariales y dispositivos.
• Fortalecer las relaciones de socios comerciales a través de conexiones gestionadas basadas en servicios.

La creación de servicios y conectividad SOA proporcionará más flexibilidad empresarial y una base firme para realizar otros proyectos de SOA, para nuestro caso estaremos implementando nuestra solución a través de webservices debido a la flexibilidad que este tipo de tecnologías conlleva. 

La idea básica consiste en que el canal de catálogo publica su servicio, luego un consumidor se conecta para encontrar los servicios deseados y una vez que lo hace se realiza un lazo entre el consumidor y el canal.

Los web services apuntan a ser la piedra fundamental en este sistema. Puntos que a continuación se enlistan.

• Interoperabilidad: Como los web services pueden ser implementados en cualquier lenguaje, los desarrolladores no necesitan cambiar sus ambientes de desarrollo para producir o consumir web services.
• Ubicuidad: Los web services se comunican utilizando HTTP y XML. Por lo tanto cualquier dispositivo que soporte estas tecnologías pueden implementar o acceder web services.
• Fácil de utilizar: El concepto detrás de los web services es fácil de entender, incluso existen toolkits de vendedores como IBM o Microsoft que permiten a los desarrolladores crear web services en forma rápida y fácil. 
• Soporte de la Industria: Todos las empresas de software importantes soportan SOAP, e incluso están impulsando el desarrollo de web services. 

La gobernanza hace cumplir la forma acordada entre los miembros clave de la empresa para trabajar en conjunto con el objetivo de planificar y supervisar el sistema SOA. La empresa pretende implementar una política rigurosa de gobernanza SOA. La gobernanza tiene dos aspectos:

• Establecer cadenas de responsabilidad, autoridad y comunicación para dar autoridad a las personas y determinar quiénes tienen derecho a tomar cada tipo de decisión.
• Establecer mecanismos de medidas, políticas y control para habilitar a las personas a cumplir con sus roles y responsabilidades.

Cualquier esquema de gobernanza SOA debe adecuarse a la gobernanza de TI de la empresa, que hace lo siguiente:

• Establece los derechos de toma de decisiones relacionados con TI.
• Establece los mecanismos y las políticas que se usan para medir y controlar la forma que se toman y ejecutan las decisiones de TI.

La gobernanza de TI tiene que ver con quién es responsable de cada cosa en el departamento de TI y cómo el departamento averigua si están cumpliendo con las responsabilidades.

Aspectos específicos a la gobernanza:

• Actúa como una extensión de la gobernanza de TI que enfoca el ciclo de vida de los servicios para asegurar el valor empresarial de la SOA.
• Determina quién debe supervisar, definir y autorizar cambios en los servicios ya existentes en una empresa.

Aspectos operativos y funcionales a considerar y evaluar para su desarrollo

Puntos a considerar en el desarrollo:

• Servicios de interacción y colaboración: Se debe presentar un servicio o conjunto de servicios a un usuario humano a través de varios dispositivos, como un navegador, PC y dispositivos móviles. Los servicios de interacción y colaboración también mejoran la productividad de las personas al agregar esos servicios como vistas que facilitan informaciones e interacción en el contexto de un proceso empresarial.
• Gestión de procesos empresariales posibilitada por SOA: La gestión de procesos empresariales es una disciplina que combina posibilidades de software y pericia empresarial para acelerar la mejora de los procesos y facilitar la innovación empresarial.
• Información como servicio: La información como servicio ofrece acceso a informaciones a través de fuentes de datos complejas y heterogéneas dentro de su compañía como servicios reutilizables.

Al implementar SOA a través de la conectividad de servicios, se realizará el siguiente valor:

• Ahorrar el costo de la conectividad personalizada o convencional.
• Eliminar la redundancia al ampliar los activos de TI ya existentes en lugar de duplicarlos.
• Proporcionar una experiencia de usuario segura y consistente al exponer el mismo proceso a través de nuevos canales empresariales y dispositivos.
• Fortalecer las relaciones de socios comerciales a través de conexiones gestionadas basadas en servicios.

La creación de servicios y conectividad SOA proporcionará al negocio más flexibilidad empresarial y una base firme para realizar otros proyectos de SOA.

10 cosas que todo Arquitecto debe saber..

Tomado de: 10 cosas que todo Arquitecto debe saber..

Como mucha gente sabe una de mis pasiones es la vertiente más tecnológica de la Ingeniería del Software, personificada en el concepto de Arquitectura. Antes de nada os dejo una pequeña reflexión.

Cuando hablo de Concepto Arquitectura pienso, sobre todo, en que cada día se demuestra más la tendencia a que vamos a una ingeniera del software gobernada por la Arquitectura, y sin embargo desde el punto de vista del usuario de negocio, esto tiene que dejar de existir ya. La tecnología debe dejar de ser una barrera, sobre todo en cuanto a su continua evolución, y cada día vemos más empresas manteniendo viejos sistemas, aunque es mejor que migrarlos todos cada poco.. no es la solución.

Para mi cada vez esta más claro que el éxito de las arquitecturas empresariales viene dado por pensar en una clara orientación a servicios (SOA) , (quizás es pronto para orientación a eventos EDA) para acabar llegando a BPM. Donde el usuario de negocio debe ser capaz de definir sus propios procesos de negocio… que si ¡!! que esto es viable, preguntar a BEA.

Tenemos que pensar que no podemos construir un BPM como primer paso, sino empezar a pensar en una estructura de Gobierno SOA sobre la cual vayamos creciendo hasta tener una suficiente estructura de servicios de negocio, que nos permitan montar BPM. Por tanto el modo de llegar es ir dando pasos.. no esperar a empezar los últimos la carrera.

A donde quería llegar, sobre las arquitecturas, es proporcionaros un interesante documento que ha llegado a mis manos, el cual se titula “ 10 cosas que todo arquitecto debe saber” y la verdad es que son ciertamente interesantes:

1. La base esta en las personas.

2. Todas las soluciones llegan a ser obsoletas.

3. Los Datos son para siempre.

4. La flexibilidad genera complejidad.

5. Nada funciona según se esperaba.

6. La documentación es el codigo fuente universal.

7. Conozca el negocio.

8. Mantenga la visión.

9. Los arquitectos deben ser programadores.

10. La experiencia es insustituible.

Sobre cada una existen frases reflexivas, que realmente dan que pensar.

10 cosas que todo Arquitecto debe saber..

Tomado de: 10 cosas que todo Arquitecto debe saber..

Como mucha gente sabe una de mis pasiones es la vertiente más tecnológica de la Ingeniería del Software, personificada en el concepto de Arquitectura. Antes de nada os dejo una pequeña reflexión.

Cuando hablo de Concepto Arquitectura pienso, sobre todo, en que cada día se demuestra más la tendencia a que vamos a una ingeniera del software gobernada por la Arquitectura, y sin embargo desde el punto de vista del usuario de negocio, esto tiene que dejar de existir ya. La tecnología debe dejar de ser una barrera, sobre todo en cuanto a su continua evolución, y cada día vemos más empresas manteniendo viejos sistemas, aunque es mejor que migrarlos todos cada poco.. no es la solución.

Para mi cada vez esta más claro que el éxito de las arquitecturas empresariales viene dado por pensar en una clara orientación a servicios (SOA) , (quizás es pronto para orientación a eventos EDA) para acabar llegando a BPM. Donde el usuario de negocio debe ser capaz de definir sus propios procesos de negocio… que si ¡!! que esto es viable, preguntar a BEA.

Tenemos que pensar que no podemos construir un BPM como primer paso, sino empezar a pensar en una estructura de Gobierno SOA sobre la cual vayamos creciendo hasta tener una suficiente estructura de servicios de negocio, que nos permitan montar BPM. Por tanto el modo de llegar es ir dando pasos.. no esperar a empezar los últimos la carrera.

A donde quería llegar, sobre las arquitecturas, es proporcionaros un interesante documento que ha llegado a mis manos, el cual se titula “ 10 cosas que todo arquitecto debe saber” y la verdad es que son ciertamente interesantes:

1. La base esta en las personas.

2. Todas las soluciones llegan a ser obsoletas.

3. Los Datos son para siempre.

4. La flexibilidad genera complejidad.

5. Nada funciona según se esperaba.

6. La documentación es el codigo fuente universal.

7. Conozca el negocio.

8. Mantenga la visión.

9. Los arquitectos deben ser programadores.

10. La experiencia es insustituible.

Sobre cada una existen frases reflexivas, que realmente dan que pensar.

Fases de Madurez de SOA

Blogs de Referencia:

modelos-de-madurez-porque-tenerlos

soa-maturity-model

Modelo de Madurez SOA


Tomado de: Fases de Madurez de SOA

Aquellas organizaciones que se plantean iniciar una nueva iniciativa en el mundo tecnológico deben plantearse el siguiente interrogante: ¿Cómo determinar el grado de beneficio que aporta una tecnología a mi sistema empresarial? SOA no es diferente al resto de paradigmas tecnológicos por lo que centrará sus objetivos (tecnológicos y de negocio) en lograr unos beneficios, muy centrados en alta flexibilidad de respuesta y adaptación al negocio, y reducir los costes inicialmente planteados. La respuesta puede parecer sencilla: “Para evaluar el grado de beneficio es necesario medir los costes que suponen alcanzar los objetivos planteados”; sin embargo esta respuesta, por todas las organizaciones conocida, suele ser el inicio de enormes quebraderos de cabeza de usuarios de negocio, arquitectos, analistas funcionales, desarrolladores, jefes de proyecto, etc. Una vía de enfocar la evaluación y análisis del grado de madurez en SOA se puede basar en CMM (Capability Maturity Model, SEI, 1991) y sus niveles básicos:

- Inicial: Procesos no instaurados, desarrollo de proyectos no transparentes.

- Repetible: Proyectos gestionados y controlados durante el desarrollo de los mismos. Los resultados satisfactorios se repiten. - Definido: Forma de desarrollar proyectos se encuentra establecida y gestionada. Proceso de Ingeniería controlado.

- Controlado y Cuantificado: Nivel en el que los proyectos se encuentran con objetivos fácilmente medibles y cuantificables.

- Optimizado: Mejora continúa. Se producen iteraciones continuas para la mejora del desarrollo de los proyectos. A continuación podemos observar una pirámide donde se ven las fases de madurez de SOA relacionadas con el modelo de madurez CMM: Modelo de Madurez SOA – Niveles CMM Los niveles de madurez de SOA se dividen en:

1. Servicios Iníciales: Fase en la que aun no se ha producido un alineamiento con las necesidades de negocio, simplemente se implementa tecnológicamente cierta funcionalidad para cubrir las primeras necesidades de negocio. 
2. Servicios con Arquitectura: Se definen los límites que evitan un crecimiento descontrolado de los servicios de negocio implementados en la fase anterior del modelo. En esta fase crecen la consistencia, la fiabilidad y el control de los servicios. 
3. Servicios de Negocio y Colaborativos: Se produce una consolidación de los procesos de negocio en forma de servicios, en esta fase la tecnología converge con las necesidades de negocio. Existen dos tipos de servicios: 

• Servicios de negocio donde el mundo tecnológico se pone al servicio del negocio.
• Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades compuestas colaboradores, partners o los mismos departamentos de la organización. 

1. Medición de los Servicios de Negocio: Se analizan los resultados de los servicios mediante el uso de métricas definidas y analizadas por usuarios de negocio y tecnológicos. 
2. Optimización de los Servicios de Negocio: Fase en la que los servicios son analizados para encontrar puntos de mejora continúa. Esta fase se lleva a cabo dentro de un ciclo que tiene como final la retirada del servicio de negocio analizado. 

Es importante considerar que los servicios no solo de analizan de manera individual sino también de forma conjunta analizando las interacciones entre ellos. Determinar en qué nivel de madurez SOA se encuentra una organización suele ser una quimera en la mayoría de los casos, ya que una organización suele considerar que está más arriba de la pirámide cuando en realidad no es más que una ilusión. Es necesario realizar una evaluación realista no solo desde un punto de vista tecnológico, sino también funcional y de negocio. Una evaluación realista de donde nos encontramos nos llevara al éxito en cualquier iniciativa SOA que llevemos a cabo.



Muchas cosas con las que he trabajado y otras de las que habia oido hablar (ESB, BAM, BPM, BPEL etc) hicieron sentido cuando revise el modelo de madurez.

El modelo se compone de 5 niveles...

• Initial Services: Indica fases de exploracion y adopcion SOA, se logra que en los proyectos de desarrollo se integre SOA como parte de la arquitectura, se utilizan como estandar WSDL, SOAP, J2EE y .NET, en este nivel existen servicios creados para necesidades inmediatas NO para servicios de negocio
• Architected Services: En este nivel entra la mediacion de servicios, ¿les suena a ESB?, en efecto, aqui entra en juego las caracteristicas de un ESB, mensajeria confiable (WS-RM), transformacion (Xquery), etc.. ademas de contar con un registros de los servicios como lo es UDDI. En este nivel se encuentra la integracion a bases de datos mediante EII.
• Business Services/Collaborative Services: Aqui entra en juego un punto de vista importante de los usuarios: EL NEGOCIO. Para estar en este nivel, ya se debe contar con el desarrollo de servicios de negocio. Existe tambien lacolaboracion de servicios para lograr procesos que den mayor sentido a la organizacion, aqui es donde hace sentido lo que se conoce como Business Process Management
• Mesuared Business Services: Aqui en punto principal es el monitoreo de procesos.. tal como lo marca Business Activity Monitoring, por ejemplo proactivity es uno de ellos. En este nivel puedes tener metricas de los procesos de negocio basados en servicios ;)
• Optimized Business Services: como el nombre lo dice... ya que logarste tener metricas, viene la optimizacion de los procesos de negocio, aqui entra una cultura de mejoramiento continuo.

Como veran muchos estamos en el nivel 1 o quizás 2, lo cual me dice que hay mucho trabajo que hacer.....

La adopción de un Programa SOA y sus implicaciones

Tomado de: La adopcion de un programa soa y sus Ventajas
Blog Original: http://mijao.blogspot.com

Cuando una organización pretender desarrollar un programa SOA, tiene entre sus objetivos establecer servicios flexibles, reusables e integrales para toda la organización. Este objetivo, requiere un ordenamiento profundo ,requiere que todas  las necesidades de sistemas de informacion estén alineadas y vinculadas con una plataforma de servicio. Esta premisa, tiene grandes implicaciones en la organización, entre las mas importantes:

1. Los sistemas de informacion y proyectos deben estar alineados, vinculados y soportados sobre una arquitectura SOA (servicios compartidos y reusables).
2. La metodología de desarrollo debe estar alineada con una clara orientación a servicios.
3. Los desarrolladores deben adaptarse a un conjunto de practicas y políticas para garantizar coherencia en sus desarrollos.
4. Las políticas de gobernabilidad de la organización deben garantizar que todos los proyectos estén basados en un modelo canónico organizacionalmente centralizado para representar sus datos.

Si las diversas iniciativas en tecnologia de informacion en una organización deben estar vinculados con un programa SOA, es primordial que exista una unidad de arquitectura que garantice una arquitectura simple, flexible, ágil, con un modelo canónico centralizado para representar los datos y la distribucion de servicios fachada o facade, que ocultan la complejidad y representan un contrato de servicio especifico para cada consumidor.

Para garantizar una exitosa introducción de un programa SOA en la organización, se requiere de un marco de gobernabilidad que establezca, comunique, e implemente los principios de orientación a servicios, mejores prácticas, metodologías, procesos, tecnologías, talento humano y estrategia.

Que establece la unidad de arquitectura?

Políticas de Valor

1. Que vinculacion exite entre el servicio o necesidad de informacion con el cuadro de mando y mapa estrategico de la organizacion.
2. Como se aprueba la entrada de un servicio a producción?

Politicas de Especificación

1. Cual es la política para la especificacion del diseño de un servicios?
2. Cual es la política para establecer el indice de reuso de servicios?
3. Cual es la política para garantizar la interoperabilidad del servicio?
4. Cual es la política para los cambios y el versionamiento de servicios?
5. Cual es la politica para acordar la mejor logica de servicios, con sus practicas, nivel de granulardad, entre otros.

Políticas del Modelo Canonico

1. Cual es la política para los cambios y el versionamiento del modelo canónico?

Politicas de Implementacion de Servicios

1. Cual es la política para el manejo de excepciones en los servicios?
2. Cual es la política para el manejo de trazas o log en los servicios?
3. Cual es la política para auditar un servicios?
4. Cual es la política para generar eventos o alertas en los servicios?
5. Cual es la política para autentificar el consumidor del servicio?
6. Cual es la política para autorizar al consumidor del servicios?
7. Cual es la política para encriptar los datos del servicio?
8. Cual es la política para firmar digitalmente los datos del servicio?
9. Cuales es la política para establecer las credenciales?
10. Cual es la política para garantizar la disponibilidad del servicio?
11. Cual es la política para gestionar los timeout de los servicio?
12. Cual es la política para gestión de servicios de compensación?
13. Cual es la política para garantizar la vida de los procesos o servicios de orquetacion ante fallas en la disponibilidad de base de datos, red, servicios informáticos, servidores, entre otros.

Como vemos, son muchas las consideracion que deben ser fortalecidas con el tiempo y la experieincia.

10 cosas que todo Arquitecto debe saber...

Tomado de: 10 cosas que todo Arquitecto debe saber...

Como mucha gente sabe una de mis pasiones es la vertiente más tecnológica de la Ingeniería del Software, personificada en el conceptode Arquitectura. Antes de nada os dejo una pequeña reflexión.

Cuando hablo de Concepto Arquitectura pienso, sobre todo, en que cada día se demuestra más la tendencia a que vamos a una ingeniera del software gobernada por la Arquitectura, y sin embargo desde el punto de vista del usuario de negocio, esto tiene que dejar de existir ya. La tecnología debe dejar de ser una barrera, sobre todo en cuanto a su continua evolución, y cada día vemos más empresas manteniendo viejos sistemas, aunque es mejor que migrarlos todos cada poco.. no es la solución.

Para mi cada vez esta más claro que el éxito de las arquitecturas empresariales viene dado por pensar en una clara orientación a servicios (SOA) , (quizás es pronto para orientación a eventos EDA) para acabar llegando a BPM. Donde el usuario de negocio debe ser capaz de definir sus propios procesos de negocio… que si ¡!!que esto es viable, preguntar a BEA.

Tenemos que pensar que no podemos construir un BPM como primer paso, sino empezar a pensar en una estructura de Gobierno SOA sobre la cual vayamos creciendo hasta tener una suficiente estructura de servicios de negocio, que nos permitan montar BPM. Por tanto el modo de llegar es ir dando pasos.. no esperara empezar los últimos la carrera.

A donde quería llegar, sobre las arquitecturas, es proporcionaros un interesante documento que ha llegado a mis manos, el cual se titula “ 10 cosas que todo arquitecto debe saber” y la verdad es que son ciertamente interesantes:

1. La base esta en las personas.
2. Todas las soluciones llegan a ser obsoletas.
3. Los Datos son para siempre.
4. La flexibilidad genera complejidad.
5. Nada funciona según se esperaba.
6. La documentación es el codigo fuente universal.
7. Conozca el negocio.
8. Mantenga la visión.
9. Los arquitectos deben ser programadores.
10. La experiencia es insustituible.

Sobre cada una existen frases reflexivas, que realmente dan que pensar.

Doy las gracias al autor del mismo Richard Monson-Haefel por sus “10 Things Every Architect Should Know”, que aquí publico, creo que siguiendo correctamente la licencia.

¿Por qué un Enterprise Service Bus (ESB)?

Tomado de: Por que un enterprise service bus

Por qué un Enterprise Service Bus (ESB)?
Juan José Vázquez

Se ha hablado mucho en los últimos años sobre los ESB, los web services y el fenómeno SOA en general. Gartner pronosticó que SOA sería usado en más del 80% de los procesos de negocio y aplicaciones críticas que se desarrollen en 2010. Estamos en 2010 y mi percepción es que, al menos en España, aún no hemos llegado a esos porcentajes en lo que se refiere al despliegue de soluciones SOA. Lo que sí es cierto sin embargo es que el ascenso de SOA y los ESB como solución tecnológica parece imparable en la mayoría de organizaciones y sectores.

Cuando una tecnología o un cierto paradigma se pone de moda, como ocurre con SOA, tenemos que mantenernos alerta ante la tentación de aplicarlo sin más en el contexto de mi negocio sin preguntarnos si es realmente lo que necesitamos. SOA implica analizar globalmente las necesidades del negocio para dar una respuesta tecnológica coordinada, reutilizable y que permita por tanto ahorrar en costes de desarrollo. Implica pensar en la evolución tecnológica de mi organización en el medio y largo plazo evaluando cuáles son mis necesidades de negocio actuales y cuáles serán en los próximos 10 o 20 años. Si nuestra única preocupación es el corto plazo, probablemente debamos considerar enfoques de desarrollo más tradicionales, que aunque resulten menos escalables, nos darán una respuesta rápida a los retos de hoy.
Enterprise Application Integration

Dicho esto, hay que hacer notar que la complejidad de las organizaciones es cada vez mayor. Caminamos hacia un modelo de organización sin barreras que se comunica a través de distintos canales de información y datos sobre un conjunto heterogéneo de sistemas de información operacionales que deben permanecer integrados para dar una respuesta conjunta a las demandas del negocio. No obstante, cada departamento o equipo de trabajo debe poder evolucionar tecnológicamente acorde a sus propias necesidades sin limitaciones impuestas por la visión integrada de la organización. Los responsables de sistemas de información deben pues asumir que es necesario mantener intacto el doble compromiso de evolución tecnológica para el negocio y la integración de los sistemas.

No es posible tener un único super-sistema operacional, pero igualmente, los sistemas no pueden permanecer aislados. Necesitan por un lado ser autónomos y por otro lado permanecer federados. Pensemos por ejemplo en el negocio sobre Internet o cloud computing. Es verdad que hoy en día es posible comunicar espacios de trabajo sobre redes WAN o VPN pero cada vez es más necesario poder establecer dichas comunicaciones más allá del firewall por ejemplo con partners o proveedores. Para un administrador de sistemas puede resultar un verdadero reto pasar a través del firewall cualquier protocolo y formato. Ante este escenario, se demandan nuevas soluciones tecnológicas que permitan la ubicuidad del negocio sin comprometer cuestiones como la seguridad o la calidad del servicio (QoS).

La competitividad y los nuevos retos del negocio hacen indispensable la innovación tecnológica. La innovación se traduce en la proliferación de sistemas de información que a menudo degenera en un estado de entropía tecnológica. La respuesta ante dicha entropía no puede ser la renuncia a la innovación sino que debe dar pie a abordar seriamente el problema de la integración de los nuevos sistemas con los sistemas legados, lo que se denomina comúnmente EAI o Enterprise Application Integration.

El EAI es el intercambio sin restricciones de datos y procesos de negocio entre cualquier aplicación y fuente de datos existente en la empresa. A un nivel básico, las arquitecturas de integración inicialmente implementadas en la empresa han sido:

* Punto a Punto: cada par de sistemas se integran atendiendo únicamente a sus requerimientos particulares. FTP, RMI o Remoting han sido protocolos típicamente empleados en llevar a cabo este tipo de integración.
* Base de Datos: a un nivel muy simple, una base de datos puede establecerse como unidad central de intercambio de datos entre sistemas e implementar por tanto un modelo de integración básica.

Estas dos arquitecturas, probablemente por su simplicidad y bajo coste aparente, siguen siendo hoy día la respuesta mayoritaria al problema de la integración en la empresa. Sin embargo, a medida que la complejidad tecnológica aumenta y las integraciones punto a punto se suceden, se evidencia una necesidad de mantenerlas controladas, administradas y gestionar su aprovisionamiento. Para atender a esta necesidad, se han sucedido nuevas respuestas al problema de la integración necesariamente más sofisticadas y ambiciosas:

* Hub-and-Spoke: todos los sistemas se conectan a un punto central o hub como en el caso de Microsoft BizTalk. A diferencia de la integración punto a punto, los sistemas se conectan al hub a través de conectores ligeros muy independientes de la tecnología particular de cada solución. El problema es que este punto central se convierte en extremadamente importante para la organización. Un fallo en el hub podría comprometer todos los procesos de negocio de la empresa.
* Enterprise Message Bus o broker de mensajes: en este caso no hay un punto central sino que los conectores están desacoplados gracias al intercambio de mensajes a través de un broker como el de IBM Websphere MQ (WMQ), Microsoft MSMQ o Apache ActiveMQ.

Enterprise Service Bus

Finalmente, comentaremos la arquitectura que se está imponiendo y que podría decirse resulta la más fiel implementación de SOA: el ESB o Enterprise Service Bus.

Un ESB parte de la idea de desacoplamiento introducido por el broker de mensajes incorporando una definición abierta de la forma de integración entre consumidores y publicadores de servicios. Un ESB usa WSDL y XML, estándares abiertos e interoperables, sobre una capa de transporte, típicamente HTTP. De esta manera los conectores no definen la implementación sino la capa de transporte y una interfaz de servicio. En el caso de un broker de mensajes los consumidores y publicadores de servicios asumen cierto conocimiento sobre los tipos de mensajes intercambiados y la tecnología empleada como es el caso de JMS o MSMQ.

Por consiguiente, un ESB puede distribuirse a lo largo de la organización, no necesitando un punto central de integración, y permitiendo la interoperabilidad entre sistemas implementados en las más diversas tecnologías. Las características básicas que debe presentar un ESB son las siguientes:

* Enrutamiento y redireccionamiento de mensajes.
* Estilo de comunicación síncrono y asíncrono.
* Multiplicidad de tipos de transporte y protocolos de enlace.
* Transformación de contenido y traducción de mensajes.
* Orquestación y coreografía de procesos de negocio.
* Procesamiento de eventos.
* Presencia de adaptadores a múltiples plataformas.
* Herramientas de diseño de la integración, de implementación y despliegue.
* Características de garantia de la calidad del servicio (QoS), como transaccionalidad, seguridad y persistencia.
* Auditoría, registro y métricas.
* Gestión y monitorización.

Como ejemplos de ESBs podemos nombrar Sonic ESB, Oracle Enterprise Service Bus, como ESBs comerciales, y Apache ServiceMix o Mule como implementaciones open source. El caso de ServiceMix es especialmente interesante por su alto grado de adecuación a estándares, sumando a los propios de un ESB como XML y WSDL, otros propios del universo Java como JBI (Java Business Integration) y OSGi.
Conclusión

La necesidad de un ESB surge de la complejidad de las organizaciones que deben coordinar e integrar sus procesos de negocio, sistemas operacionales y datos sin renunciar a la innovación tecnológica imprescindible para ser competitivos. Un ESB es la implementación de SOA, una arquitectura que permite mantener integrados los sistemas, nuevos y legados, en un estilo completamente distribuido e interoperable.

¿Por qué SOA?

Tomado de: Url Original
Por qué SOA?
Juan José Vázquez

En un post anterior hemos discutido sobre las ventajas que aporta un Enterprise Service Bus como implementación de SOA (Arquitectura Orientada a Servicios) en la organización. Sin embargo, previo a la decisión de desplegar un ESB en la compañía cabe plantearse por qué necesitamos SOA en nuestra implementación de los procesos de negocio.

Para entender qué ventajas aporta la arquitectura SOA tenemos que hablar del concepto de Coste de Propiedad o TCO (Total Cost of Ownership). El TCO es una estimación financiera que ayuda a los consumidores y gestores a determinar cuáles son los costes directos e indirectos de un producto o servicio. Es decir, independientemente del precio de un producto o servicio, debemos plantearnos cuáles son los costes de renovación, mantenimiento o incluso ecológicos y sociales ligados a la adquisición de dicho producto o servicio. En la industria del hardware y del software es particularmente importante considerar cuáles van a ser los costes implicados en la integración del nuevo desarrollo o producto adquirido con nuestros sistemas previos. Es decir, cómo de fácil o difícil será el encaje del nuevo sistema y de los futuros en la nueva configuración del mapa de sistemas.
Los enemigos de la integración

Más concretamente, en la industria del software, los dos grandes enemigos de la integración son el acoplamiento y la no adecuación a estándares. Se dice que un sistema está fuertemente acoplado cuando resulta muy complicado o incluso imposible modificar alguna de sus partes sin que no resulten afectadas las demás. Es decir, cada módulo o subsistema conoce y necesita demasiada información del entorno en el que opera, resultando por tanto poco autónomo y muy dependiente. En términos de integración, cuanto más acopladas estén las distintas partes de un sistema más difícil resulta integrarse con alguna de ellas sin tener que hacerlo con las demás o con el sistema al completo.

Pensemos por ejemplo en un escenario de fusión de empresas. Si los sistemas de las empresas que se fusionan presentan un acoplamiento bajo resultará más sencillo proceder a un intercambio de datos, por ejemplo de clientes o ventas, de forma gradual y sin traumas. Los dos sistemas podrían estar conviviendo durante mucho tiempo participando de forma transparente en los procesos de negocio. Por el contrario, si los sistemas están fuertemente acoplados la convivencia será prácticamente imposible implicando la toma de partido por uno de los sistemas. Esto último sin embargo suele plantear un importante reto en términos de adecuación de los datos y procesos embebidos en el sistema que desaparece en el sistema definitivo. Estos proyectos de fusión suelen resultar muy complejos, traumáticos y costosos, hasta el punto de generar caídas en el servicio con la consiguiente insatisfacción de empleados y clientes.

Como comentamos antes, otro de los grandes enemigos de la integración es la no adecuación a estándares. Los sistemas bien planificados y diseñados presentan interfaces de integración que permiten el diálogo con el resto de sistemas de la compañía y con sistemas de terceros, partners, proveedores y organismos reguladores por ejemplo. El uso de estándares facilita enormemente este diálogo dado que minimiza la necesidad de desarrollar software específico para llevar a cabo esta integración. Si cada módulo del sistema se desarrolla teniendo en mente los estándares se está preparando para una larga vida interviniendo en los procesos de negocio de la organización.
¿Qué es SOA?

Dicho esto, debemos hacer notar que SOA (Service Oriented Architecture) no es una tecnología ni un producto que podamos comprar e instalar. SOA es un conjunto de patrones, principios y prácticas para construir piezas de software que puedan interoperar independientemente de la tecnología empleada en su implementación. En este sentido, SOA implica la superación de tecnologías como Java RMI o .NET Remoting que no permiten la interoperabilidad entre distintas tecnologías de desarrollo de software.

La clave de la arquitectura SOA está en la exposición de interfaces abstractas que aíslen de la implementación particular de cada pieza de software. Para conseguir este objetivo resulta especialmente útil el uso de servicios web basados en los estándares SOAP, XML y WSDL. Sin embargo, hay que tener en cuenta que es posible tener web services y no por ello tener SOA dado que como hemos comentado, SOA es un problema de diseño y no de aplicación de una determinada tecnología.

Como características típicas de una arquitectura SOA podemos comentar:

* SOA está basado en estándares, por ejemplo las especificaciones WS-*.
* Los servicios deben ser autónomos y granulares.
* Los proveedores y consumidores deben estar débilmente acoplados.

Por último, comentar que la aplicación de una arquitectura SOA en el contexto de un problema de integración se conoce como SOI o Integración Orientada a Servicios.
Conclusión

Hoy en día las organizaciones tienen la necesidad de adaptarse a constantes cambios en el mercado, y por tanto, deben ser capaces de adaptar sus procesos a unas condiciones dinámicas como única forma de mantener y mejorar su competitividad.

A su vez, los sistemas que dan soporte a esos procesos deben poderse adaptar fácilmente para responder de forma ágil a las necesidades del negocio. El estado del arte actual de la tecnología da respuesta a este reto con SOA.