En los últimos meses he estado colaborando en algunos proyectos e investigación que tiene que ver con la habilitación, rediseño y construcción de soluciones de software basadas en la arquitectura de SOA (Service Oriented Architecture). En este artículo trataré los conceptos básicos de SOA, los enfoques de los principales proveedores de Software y compartiré algunas lecciones aprendidas.

La definición generalmente aceptada de SOA es una arquitectura desacoplada de componentes de software que proveen funciones específicas (proveedor) y que pueden ser invocadas por otros componentes (consumidor) independientemente de la plataforma en que se encuentren ambos.

La ventaja inherente a una arquitectura de este tipo es lograr una mayor flexibilidad al construir nuevas aplicaciones o modificar aplicaciones ya existentes, con lo cual el negocio se ve beneficiado en términos de tiempo y costo, así como lograr una mayor eficiencia y plataforma para habilitar el cambio y la innovación dentro de la empresa.

También existen ventajas en términos de ahorro en TCO (Total Cost of Ownership) de los componentes de software y de las aplicaciones construidas utilizando estos componentes. El ahorro viene en cuanto a la independencia de plataforma, reuso de aplicaciones ya instaladas (legacy applications), utilización de protocolos asi como metodologías estándares para especificar y diseñar aplicaciones.

El ideal de la arquitectura orientada a servicios es poder construir aplicaciones compuestas (Composite Applications) que reutilicen funcionalidades comunes expuestas como servicios; permitiendo de esta forma encapsular procesos de negocios que usualmente involucran utilizar varias herramientas de software sin una interfaz común. Asimismo, se busca flexibilidad al momento de modificar las reglas de negocio, en el sentido de solamente cambiar la aplicación compuesta para adaptarla al nuevo proceso de negocio, sin tener que modificar las funciones básicas expuestas como Servicios.

Una analogía de este idea es la forma en que los fabricantes de autos reutilizan partes de los autos como chasis, puertas, asientos para crear diferentes diseños y modelos de autos; en este caso el valor principal del negocio existe en crear estos nuevos diseños y modelos reutilizando los mismos componentes en lugar de volver a crear todas las piezas con cada modelo nuevo.

La mayoría de los grandes proveedores de software como IBM, Microsoft, SAP, etc han iniciado su ola de producción de herramientas alrededor de esta arquitectura, y en los siguientes años veremos un crecimiento en el uso de la terminología de SOA para una gran cantidad de productos de software, que se modificarán para ser de cierta forma “SOA compliant”. En los siguientes párrafos resumiré la propuesta de IBM y SAP, y concluiré con algunas recomendaciones.
La propuesta de IBM está centrada en el uso de su bus de servicios o ESB (Enterprise Service Bus) y el uso de herramientas específicas como Websphere Business Modeler, Integration Developer, Process Server y Business Monitor durante el ciclo de vida de las soluciones. El siguiente diagrama muestra el ciclo de vida propuesto por IBM:

[photopress:ibmSOA.jpg,full,centered]

La propuesta de SAP está basada en el framework o suite llamada SAP Netweaver que he descrito en otro artículo; las piezas claves de SAP son el Application Server, su herramienta de integración (XI o Exchange Infrastructure ahora renombrada a PI o Process Integration), el portal y MDM (Master Data Management). La propuesta de SAP es ESA (Enterprise Service Architecture también referida como Enterprise Service-Oriented Architecture), y la propuesta realmente es modificar los Web Services para reflejar funciones completas de negocios que serían las piezas de las soluciones compuestas.

En la propuesta de SAP un Web Service debe exponer una función de negocio, por ejemplo “Cancelar Orden” en lugar de “Borrar Orden”. La diferencia es que “Cancelar Orden” contiene semántica del negocio, en el sentido que esta funcionalidad implica modificar el nivel de inventario, cancelar los envíos programados, etc. a diferencia de “Borrar Orden” per se que significar el borrado de un registro en la base de datos de órdenes.
Mi propuesta para atacar el tema de arquitectura orientada a servicios (SOA) se basa en un enfoque del más alto al bajo nivel, en parte soportada por ideas de Thomas Mattern y Dan Woods en su libro “Enterprise SOA: Designing IT for Business Innovation”
Mattern and Woods comentan un enfoque de 5 C: Conceive, Consume, Compose, Create, and Control. Una vista más gráfica se muestra en el siguiente diagrama:

[photopress:ESAmap.JPG,full,centered]

Mi recomendación para iniciar la transición hacia una arquitectura basada en servicios se describe en el siguiente plan de alto nivel:

1. Definir un Roadmap que contemple los aspectos de negocio y de tecnología.
2. Identificar los componentes de negocio reutilizables
3. Modelar y diseñar un piloto o prueba de concepto de una aplicación compuesta que abarque de preferencia al menos dos áreas de negocio.
4. Seleccionar una plataforma, herramientas de desarrollo, tratando de ser lo más independiente de un solo proveedor.
   Desarrollar los building blocks o Web Services que complementan la aplicación compuesta.
5. Controlar o administrar la aplicación o Web Services definiendo un modelo de Governance y mantenimiento de los mismos.

Existen varios puntos de coincidencia que personalmente veo entre el modelado de las aplicaciones compuestas y las herramientas actuales y desarrollos de BPM (Business Process Management) asi como del modelo de Governance y control que existen actualmente en una implementación de IT Service Management como ITIL sobretodo para la parte de monitoreo, estadísticas, help desk, esto último porque con esta información es posible implementar y cerrar el ciclo de mejora continua de las aplicaciones construidas sobre un arquitectura de SOA.