SOA Y BPM

Hola a todos esta semana hablaremos de la relación entre SOA y BPM, De cómo estas dos estrategias se pueden complementar para lograr que TI este alineado con las estrategias del negocio.

El reto se presenta en las  organizaciones las cuales generalmente  están compuestas de diferentes aplicaciones y sistemas construidos con tecnologías heterogéneas, utilizando múltiples bases de datos, y ejecutándose en varias plataformas .Además de la falta de mecanismos de comunicación entre el negocio y el departamento de TI.

Con el objetivo de hacer frente a estos desafíos, las organizaciones han dirigido su mirada hacia dos disciplinas y tecnologías: BPM (Business Process Management) y SOA (Services Oriented Architecture).

Aunque BPM y SOA tienen características que las hacen muy diferentes, lo más importante es que se complementan perfectamente realizando considerables aportaciones a los procesos de negocio .

La función de cada una de estas disciplinas las podemos resumir en:

·        BPM posibilita el desarrollo y la automatización de la gestión por procesos en una organización.

·        SOA  proporciona elementos clave para la transformación de las distintas aplicaciones existentes en las organizaciones,  en servicios reutilizables basados en estándares de integración, que al mismo tiempo facilitan la integración de las diferentes aplicaciones y sistemas entre sí.

BPM y SOA ayuda en gran medida a reducir la complejidad de las tecnologías de la información, acelerando la automatización de los procesos en las organizaciones y posibilitando un desarrollo más rápido de las aplicaciones de negocio, a la vez que contribuye a hacer los procesos de negocio más ágiles y flexibles.

En conclusión la unión de estas dos herramientas posibilita a las  empresas ajustar mejor los objetivos de los servicios informáticos y los objetivos de  negocio, mejorando el rendimiento de sus procesos de negocio, y convirtiéndose en una  empresa más ágil y competitiva.  




Referencias 
http://www.delfos.co.cu/boletines/bsa/PDF/28soaybpmlacombinacionperfecta.pdf
http://www.computing.es/Informes/201002190035/-BPM---SOA-una-sinergia-ventajosa-Lorena-Delgado-e-Inigo-Vega;-Area-de-Consultoria-y-Conocimiento-BPM-de-Ibermatica.aspx
http://www.activevos.com/blog/soa/bpm-and-soa-belong-together/2009/09/10/

FASES DE MADUREZ DE SOA

Hola a todos, esta semana hablaremos de las diferentes fases que describen el grado de madurez de una arquitectura SOA implementada en una organización, esta evaluación no solo contempla la perspectiva  tecnológica sino  que  tiene en cuenta las  perspectivas funcionales y de negocio.

 Las fases de Madurez son:

1. Servicios Iníciales: En esta fase no existe un alineamiento con las necesidades de negocio, Se implementan funcionalidades para cubrir necesidades primarias.
2. Servicios con Arquitectura: En esta fase se ejerce un control sobre los servicios lo cual proporciona consistencia y  fiabilidad de estos.
3. Servicios de Negocio y Colaborativos: Existe un alineamiento con las necesidades de negocio a través de los servicios, de tipo:
• Servicios orientados a los negocios, tales como gestión de procesos de negocio (BPM).
• Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades, partners o los mismos departamentos de la organización.
4. 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.
5. Optimización de los Servicios de Negocio: Fase en la que los servicios son analizados para encontrar puntos de mejora continua no solo se  analizan de manera individual sino también de forma conjunta analizando las interacciones entre ellos.

Referencias:
http://blogs.vass.es/?p=423
http://www.mydeveloperconnection.com/html/service_oriented_architecture.htm
http://www.steerahead.com/soastrategy-ep.htm

SOA Governance

Hola esta semana hablaremos de la importancia del control de la implementación del modelo de arquitectura SOA en la organización a través de SOA Governance.

Implementar una Arquitectura Orientada a Servicios (SOA) en una compañía es un proceso complejo, debido a que SOA se basa en desarrollar componentes (servicios) reutilizables, y con estos servicios componer nuevas soluciones tecnológicas para el negocio, esto implica un cambio cultural en como se construyen los sistemas, y un cambio en el ámbito de las soluciones:

•  En SOA los proyectos son transversales abarcan distintas áreas, y distintas aplicaciones, siguiendo el flujo transversal de los procesos de negocio de las compañías.
• En SOA las soluciones se comparten, y se construyen para que los próximos proyectos se vean beneficiados.

“SOA Governance define cambios en la administración del área tecnológica (TI) para  asegurar que los conceptos y  principios de SOA, y su arquitectura distribuida sean manejados apropiadamente, y que sea capaz de lograr los objetivos de negocio de los servicios”

SOA Governance debe definir:

• Que Hacer: El plan global de proyecto SOA de la Empresa, define el “SOA Roadmap” (Plan de Ruta SOA).
•  Quien lo Hace: La estructura organizacional (los grupos de trabajo), define la “SOA Office”.
•  Como Hacerlo: Los procesos (procedimientos) de administración, las normas.
• Como Medirlo: Las métricas para medir el éxito.

Algunos Problemas por falta de Governance:

• Se han implementado servicios con falencias en SOA, que no aseguran reutilización o flexibilidad.
• No está definido quien diseña el Servicio.
• No hay instancia de revisión del diseño del Servicio.
• Cada proyecto crea sus propias herramientas, o librerías, y estas no quedan documentadas, y accesibles para los demás.
• Las experiencias buenas o malas de los proyectos quedan en el proyecto. 

Referencias

http://www.grupocmc.es/articulos/soaPorQueYParaQue_eCuadrado.pdf

http://soaagenda.com/journal/articulos/soa-governance-es-fundamental/

http://www.slideshare.net/soaagenda/soa-governance-enfoque-practico

¿Qué es Bajo Acoplamiento?

Para las personas familiarizadas con la Programación Orientada a Objetos y los patrones de diseño GRASP (General Responsibility Assignment Software Patterns), una clase está altamente acoplada si tiene muchas asociaciones con otras clases, la principal consecuencia es la poca mantenibilidad que le da al código, pues modificar una clase involucra también realizar cambios en muchas otras.

Ahora, a modo más general y hablando no en términos de clases sino de aplicaciones, el contexto de acoplamiento cambia, pues empieza a tomar importancia cuando es necesario usar mecanismos de integración para lograr interoperabilidad entre aplicaciones. Se habla de distintas dimensiones que permiten medir este acoplamiento, a continuación algunas de estas:

Ubicación: Una aplicación no debe tener datos “quemados” en su código fuente como la dirección física o IP de donde residen otras aplicaciones con las cuales se desea establecer una comunicación. Esta mala práctica o antipatrón de diseño se conoce como Hard code.

Número de receptores: Una aplicación se considera altamente acoplada si tiene un orden explicito de llamados a otras aplicaciones. Esta tarea de controlar los mensajes entre aplicaciones la debe realizar una capa superior, por ejemplo, mediante orquestación de servicios web.

Disponibilidad de los sistemas: Una aplicación no debe depender de la disponibilidad de otras aplicaciones para funcionar, si necesita enviar un mensaje, se debe contar con un mecanismo de buffering en caso de que la aplicación destino no se encuentre disponible, y entregárselo una vez cambie de estado.

Tiempo de respuesta: cuando una aplicación hace llamados a otras aplicaciones, la decisión sobre el límite de tiempo de espera para recibir una respuesta debería considerar distintos factores como los canales de comunicación o la carga sobre otros sistemas.

Referencias:

http://wiki.sdn.sap.com/wiki/display/BBA/Loose+Coupling+Through+Web+Services

http://es.wikipedia.org/wiki/Hard_code

http://www.infoq.com/articles/tilkov-10-soa-principles

¿El FUTURO DE SOA?

Ante la aparición de Web  2.0 estos servicios cada día se ven  necesitados a enfocarse en el tema de la red. Por lo cual se busca la  consolidación de un nuevo modelo arquitectónico, el cual está llamado a ser el modelo a utilizar en el futuro, donde todo, desde la información hasta el acceso a otros recursos están orientados a la web. Es habitual encontrar que  en una organización la adopción de SOA se limita a ser implementada y accesible desde un ámbito privado de la organización (red privada).Por lo tanto es necesario adoptar una arquitectura orientada  a la web (WOA).

WOA (Web-Oriented Architecture o Arquitectura Orientada a la Web)  Podemos  definir WOA como una extensión de SOA en la que los artefactos son implementados como recursos REST (Representational State Transfer) y que serán accesibles por medio de UDDI (Universal Description Discovery and Integration) que se encargará de identificar la ubicación de los recursos en la red.

Una de las características más importantes de WOA, es que los mensajes y las interacciones están auto-contenidos.WOA no requiere de un contrato de servicios como los tradicionales webservices ya que este está implícito en la URL y en la forma del recurso.

Por último  se puede diferenciar la concepción de  SOA como la necesidad de hacer sistemas de negocios de TI que sean agiles respecto a los cambios en el mercado y a WOA como la necesidad de llevar estos sistemas a la evolución de la web con la llegada de la web colaborativa. Por lo tanto SOA es un tipo de arquitectura que sigue vigente y se acomoda a las nuevas necesidades que se van presentando.

Referencias:

http://www.zdnet.com/blog/hinchcliffe/the-soa-with-reach-web-oriented-architecture/27
http://www.tec.url.edu.gt/boletin/URL_19_SIS07_REDES.pdf
http://blogs.vass.es/?p=535

UDDI

Universal Description Discovery and Integration (UDDI) es un framework independiente de plataforma que permite describir, descubrir e integrar Web services.


Como principales beneficios de UDDI están las facilidades de reutilización y ahorro en tiempo y costos de implementación de servicios web, pues mediante el descubrimiento de servicios ya existentes y publicados por terceros, es posible mantener procesos de negocio de forma ágil y lograr interoperabilidad no solo a nivel interno de la organización, también entre diferentes empresas.

Para dar una idea de los posibles usos de este framework, podemos hablar de las aerolíneas, estas pueden registrar sus servicios de reserva de vuelos en un directorio de UDDI, las agencias de viajes pueden buscar las interfaces o los contratos de los servicios web de las aerolíneas, y una vez encuentren el que necesitan, puede empezar a usarlo inmediatamente.

Los principales conceptos de UDDI son:

• UDDI Data Model: Incluye tipos de datos que incluyen descripción de los servicios, por ejemplo, cual es su función (businessService) o quien es el publicador del servicio (businessEntity).

• UDDI Nodes and Registers: incluye una específica definición de las relaciones de jerarquía que hay entre los servidores que tienen implementaciones de UDDI.

• Essential Programmatic Interfaces: provee funcionalidades claves como publicar o buscar información sobre un servicio en el registro UDDI.

UDDI es patrocinado por OASIS (Organization for the Advancement of Structured Information Standards), un consorcio que impulsa el desarrollo, convergencia y adopción de estándares abiertos y la organización que más desarrolla estándares de servicios web.

Referencias:

http://www.w3schools.com/WSDL/wsdl_uddi.asp

http://www.oasis-open.org/who/

http://uddi.xml.org/uddi-101

http://www.ibm.com/developerworks/webservices/library/ws-featuddi/

CUANDO LOS MUNDOS DE LA ARQUITECTURA SOA Y WEB 2.0 CHOCAN

Hola esta semana les hablaremos de como dos tipos de arquitecturas como SOA y WEB 2.0 las cuales tienen propósitos diferentes pero su integración permite una mejor forma de soportar los procesos de una organización.

Aparentemente SOA y WEB 2.0 se basan en filosofías muy diferentes, El primero se basa en la idea de la fuerza de la  estandarización  cuidadosa  a través de contratos. Los cuales me permiten la integración de los diferentes sistemas  que soportan los  diferentes procesos de negocio de la organización. Por otro lado Web 2.0 tiene como objetivo principal la oportunidad de conectar personas y soportar sus esfuerzos colaborativos. Ciertamente Web 2.0 también dirige elementos asociados a conexión de aplicaciones y datos, pero se distingue en que se dirige explícitamente a una dimensión más social. Por esta razón se cuestiona su uso empresarial.

Como se puede observar estas dos arquitecturas comparten  los siguientes aspectos de :

1.          La integración de plataformas de servicios.
2.          La no dependencia de un unico proveedor. 

La combinación de estas dos filosofías que va a permitir la obtención de las siguientes características:

Mejora de accesibilidad
Una mejor  forma de acceder a  los servicios SOA es  proporcionando una interfaz mas sencilla mediante WEB 2.0 a través de REST, lo que implica más facilidad en la comunicación.

Reutilizacion 

Tanto WEB 2.0 y SOA poseen el concepto de reutilizacion. lo que permitirá la construcción de aplicaciones mas complejas a partir de unas ya existentes.

Fácil Desarrollo 

Tienen entornos para el desarrollo rápido y fácil de aplicaciones.

Innovación 
Realizar aplicaciones de gran impacto visual utilizando WEB 2.0 soportando sus operaciones con servicios SOA.

Referencias
http://www.itsc.org.sg/pdf/synthesis08/Five_SOA.pdf
http://www.zdnet.com/blog/hinchcliffe/when-the-worlds-of-soa-and-web-20-collide/35
http://webdoscero.blogspot.com/2006/05/soa-versus-web-20-en-espaol.html

La