Arquitecturas Orientadas A Servicios

Arquitecturas Orientadas a Servicios (SOA)

Arquitecturas BPM SOA

La nueva generación de soluciones de integración de sistemas y ejecución de procesos de negocio se basan en arquitecturas orientadas a servicios. SOA permite maximizar el rendimiento de las inversiones en TI, disminuir los costes en desarrollo, y acortar el time-to-market de productos y soluciones.

Las arquitecturas orientadas a servicios mejoran el rendimiento y la eficiencia de las organizaciones permitiendo un aprovechamiento de las inversiones en tecnología y mayor agilidad y ahorro de costes en los nuevos desarrollos.

Las organizaciones se enfrentan a un escenario de continuo cambio en las condiciones del mercado y la legislación. Una rápida y ágil adaptación a estos cambios resulta de vital importancia de cara a adquirir una posición de privilegio frente a los competidores.

Por otro lado, los costes de propiedad que introducen los sistemas adquiridos aumentan si estos no se adecuan a los estándares y no siguen buenas prácticas de integración.

SOA da respuesta a estos retos proponiendo soluciones basadas en la flexibilidad, autonomía y adecuación a estándares.

Construyendo SOA (por la vía rápida)

La crisis económica, y la parálisis en la que se encuentran muchos proyectos SOA, ponen de manifiesto la necesidad de una revisión profunda de las motivaciones reales para el cambio y la redefinición de SOA como solución a medida de las necesidades del negocio.

A lo largo de las últimas semanas he seguido con interés la polémica generada en torno al post de Anne Thomas Manes titulado SOA ha muerto; larga vida a los servicios. En este post la autora reflexiona sobre el dudoso éxito que han tenido las iniciativas de implantación de SOA en las organizaciones afirmando, no sin cierto afán de protagonismo, la defunción prematura de este paradigma tecnológico.

Como suele ocurrir en estos casos de titulares polémicos, el contenido del post matiza bastante el titular y finalmente uno acaba preguntándose, a tenor del número de reacciones provocadas, si realmente era necesario armar tanto revuelo. Finalmente, y según esta autora, lo que definitivamente ha muerto no es la orientación a servicios como arquitectura o conjunto de buenas prácticas sino más bien el paquete comercial de solución SOA que han tratado de imponer los grandes fabricantes e integradores de software.

El 'producto' SOA bajo sospecha

Es verdad que en los últimos meses ha empezado a evidenciarse una corriente crítica hacia SOA basada en las insatisfacciones y en las promesas no cumplidas (no hay que olvidar que los mayores beneficios esperados de la aplicación de SOA son la reducción de costes y la agilidad organizativa). Estas expectativas generadas no casan bien con la sensación, que parece se está imponiendo, de que SOA implica proyectos más caros, más largos y con peores resultados. Todo apunta además a que esta corriente crítica se irá agudizando conforme las consecuencias de la recesión económica se hagan más palpables.

En mi opinión, se ha generado una gran confusión identificando a las suites de productos SOA con la propia implantación de arquitecturas orientadas a servicios. Obviamente, esta identificación se ha fomentado, con grandes dosis de evangelización, desde los grandes fabricantes e integradores. Se ha vendido y promocionado la idea de que SOA es un producto que puedes comprar (aunque te pueda costar varios años implantar). El mensaje repetido machaconamente es que si quieres implantar SOA necesitas: un proveedor de servicios, un registro, un ESB, un motor de reglas de negocio, gestor de eventos, monitorización, BPEL, SOA governance y además llevar a cabo toda una reingeniería de procesos y un cambio cultural sin precedentes en tu organización. Todo ello poniendo en práctica un stack de tecnologías emergentes que casi nadie domina, mucho más en los últimos años en los que ha habido una notable carencia de profesionales en el sector de las TI.

Por otro lado, se produce una circunstancia cuanto menos paradójica. La adopción de SOA, tal como ha sido planteada mayoritariamente en el mercado, se traduce en un viaje iniciático hacia la madurez tecnológica que comenzaría con la definición de procesos de negocio, continuaría con la identificación e implementación de web services, y tras unos cuantos pasos más, que podrían significar años, se aterrizaría en SOA governance. En resumidas cuentas, durante equis años, los proyectos de TI de una compañía se centrarían en la consecución de un roadmap de hitos basados en objetivos tecnológicos y no directamente en objetivos de negocio. Sinceramente, creo que es indispensable hacer una reflexión sobre los riesgos que introduce una decisión de estas características, más aún teniendo en cuenta la coyuntura económica en la que nos encontramos.

SOA sigue vivo

Bajo mi punto de vista, SOA sigue vivo. En realidad, siempre lo ha estado desde que alguien se preguntó cómo podía reutilizar su código encapsulándolo en un componente y presentándolo al mundo a través de una interfaz bien definida. Hay que tener en cuenta sin embargo que:

◦SOA no es un conjunto de tecnologías concretas

◦SOA no emerge automáticamente de la implantación de web services, BPEL o un ESB

Es decir, es perfectamente posible diseñar una solución de software compuesta principalmente de web services y no estar aplicando SOA en absoluto. Y lo contrario también es posible (un buen ejemplo de ello sería las soluciones basadas en servicios OSGi o SCA).

Lo fundamental es diseñar soluciones de software alineadas con el estatus de madurez tecnológica de la organización y totalmente centradas en sus objetivos de negocio (¿es que es admisible a día de hoy diseñar software bajo otros supuestos que no sean los mencionados?). Si de paso, y las circunstancias lo permiten, es posible aplicar determinados aspectos de SOA, a través de la elección de ciertas tecnologías y/o enfoques metodológicos, bienvenido sea.

Frente al todo o nada de las estrategias top-down, una cuidada gestión de la calidad y de la configuración, una potente estrategia de testing, y una mejora continua de los sistemas hará posible que de un enfoque bottom-up emerjan las buenas prácticas de SOA.

Construyendo SOA real

En mi opinión, para aplicar SOA no hay mejor receta que empezar a hacerlo, sin complejos pero minimizando los riesgos y sobre todo persiguiendo resultados de negocio tangibles en el corto plazo. Por ejemplo, para minimizar los riesgos de tener que realizar una gran inversión inicial, es posible optar por una combinación de productos open source, como pueden ser Apache ServiceMix o Apache CXF, e ir de la mano de un partner

...