LAS SIETES CLAVES DEL ÉXITO SOA

Hola a todos, esta semana hablaremos de las claves dl éxito diseñar e implementar SOA.

La aplicación de estas siete claves permitirán minimizar los riesgos y  en general, aumentar las probabilidades de éxito a la hora de entregar los proyectos a tiempo y  dentro del presupuesto.

• Demandar la rentabilidad de la inversión en cada servicio :Incorpore cada servicio en un proceso de negocio activo que genere rentabilidad de la inversión (ROI).

• Definir un Comité de Gestión de Servicios:El comité de gestión de SOA será el responsable de identificar los escenarios de uso de los servicios potenciales y evaluarlos para saber si se justifica la transformación de una función en un servicio.

• Organizar adecuadamente los comités de gestión:Para organizaciones de desarrollo centralizado debe  designar un único grupo que realice la evaluación, especificación y control de todos los servicios. Y para empresas con un modelo de desarrollo distribuido se debe en crear comités de gestión en torno a aplicaciones principales.

• Crear y especificar tareas y responsabilidades: Normalmente, los procesos de negocio unidos por servicios abarcan varias aplicaciones y, muy frecuentemente, varias plataformas y organizaciones. Por eso resulta de vital importancia definir a los participantes clave y aclarar sus funciones. 

• Ir más allá de la solicitud-respuesta:No se pueden crear procesos de negocios reales únicamente con los servicios de solicitud-respuesta por esta razón se tiene que tener presente la necesidad de servicios dirigidos por eventos cuando establezca la capa de transporte de servicio de su infraestructura.

• Tener en cuenta los estándares emergentes:Muchos de los estándares relacionados con SOA todavía están evolucionando. Si tiene que tomar una decisión sobre un estándar que se encuentra en proceso de formación, debe solucionar el problema inmediato con la tecnología disponible pero considerar el estado y planificar la futura incorporación de estándares emergentes.

• Desarrollar para expandir y soportar todas las tecnologías y plataformas:Evite crear su infraestructura con enfoques SOA o soluciones que limiten sus opciones a plataformas, servidores de aplicación o lenguajes de programación específicos.

Referencias 

http://sigc.wikidot.com/system:las-siete-claves-del-exito-soa

http://na-h-www0.tibco.com/international/spain/resources/es_soa_together_adv.pdf

¿ COMO IMPLEMENTAR SOA ?

Hola a todos, esta semana hablaremos de lo necesario para llevar una buena implementación de SOA en las organizaciones, Lo que conlleva retos que de no llevarse a cabo pueden convertirse en problemas  

La adopción de SOA requiere de cambios en las organizaciones, entre los que encontramos:

• Se requerirán cambios organizacionales, especialmente a las estructuras administrativas.
• Se requerirá educar totalmente al personal de TI y los socios de negocio para asegurar un conocimiento consistente de la arquitectura y el desarrollo.
• Se requerirá una nueva infraestructura y actualizaciones.
• La gente se resiste al cambio y puede regresar a los viejos hábitos, perdiendo así los beneficios de SOA.

Si podemos llevar estos cambios a cabo la implementación de SOA la podemos hacer de la siguiente forma: Se comienza definiendo áreas de negocio e integrando conjuntos de necesidades de negocio. Más tarde se definen los servicios y su ensambladura para satisfacción de las necesidades. Sólo al final del proceso se diseñan los elementos modulares mínimos que se engranarán para suministrar los servicios.

La implementación SOA se realizará progresivamente para no generar estrés o traumatismo en los otros procesos existentes, y su aceptación y puesta en marcha será  progresiva. De esta forma, se asegura que si llega a existir un fallo o problema se puede  resolver en el proceso de implementación y así no generar gran conflicto con el resto de  procesos existentes.

Referencias 

http://www.iworld.com.mx/iw_news_read.asp?iwid=5544

http://www.financialtech-mag.com/_docum/111_Documento_SOA_Profit.pdf
http://www.theserverlabs.com/es/implementacioa.html

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