SOA: Un Modelo de Dominios que Ataca Todos los Aspecto de una Organización

En el camino hacia una Arquitectura Orientada a Servicios, son muchos los aspectos en los que una organización debe madurar. Este artículo trata de

describir cada uno de estos aspectos en base al Modelo de Dominios para SOA propuesto por BEA.

Introducción En los últimos años, SOA (Service Oriented Arquitecture) se ha transformado en la sigla de moda. En toda conferencia de tecnología que se precie, encontraremos al menos un par de charlas relacionadas con el tema, y en cada exposición y white paper se define y redefine el término en un esfuerzo por explicar un concepto que desde el punto de vista puramente tecnológico es bastante sencillo, y desde el punto de vista de diseño de software, sinceramente, nada novedoso. Para no ser menos, y para caer en los mismos lugares comunes que el resto del universo de arquitectos y opinólogos que hablan sobre la materia, comenzaré con una definición del concepto, y trataré de explicar qué es lo que diferencia a esta nueva tendencia de las viejas arquitecturas que exponían servicios de una manera al menos similar a la propuesta hoy en día por SOA. Qué es SOA? Particularmente veo a SOA como un “Paradigma de Arquitectura Corporativa”. Así como en su momento, el Paradigma de Orientación a Objetos cambió la forma en que pensamos en términos del análisis, diseño y construcción de aplicaciones, SOA propone un modelo de pensamiento con el cual atacar la definición de arquitecturas, y ya no las de aplicaciones individuales, sino las arquitecturas de organizaciones completas. Desde el punto de vista tecnológico, SOA propone varias capas de servicios que exponen funcionalidad, fundamentalmente de negocio, que permiten la composición de aplicaciones a partir de los mismos. En el nivel más bajo, tendremos una capa de servicios de “Acceso a Información y Datos”, cuya función es exponer en un ESB (Enterprise Service Bus, por sus siglas en inglés) la funcionalidad y facilidades provistas por los sistemas corporativos. Muchas veces, estos servicios básicos no representan realmente “servicios de negocio” que aporten real valor al resto de la organización, al menos no por sí solos. Es por esto que sobre esta primer capa, encontraremos una segunda capa de servicios que denominamos de “Servicios de Negocio Compartidos” que componen y enriquecen la funcionalidad expuesta en la capa precedente, con el objeto de agregar valor desde el punto de vista del negocio de una organización. Con base en estos servicios básicos y de negocio, es posible comenzar el desarrollo de aplicaciones compuestas. Estos desarrollos son los que aprovechan los beneficios de un esquema SOA en cuanto a reusabilidad de servicios existentes y adaptabilidad al negocio. Sin embargo, es

necesario que en esta capa, las aplicaciones también expongan en el Bus de Servicios la funcionalidad que resuelven, para que sean aprovechadas por otras aplicaciones y servicios.

En arquitecturas que avanzan en este paradigma lo suficiente, encontraremos servicios que se exponen incluyendo su propia lógica de presentación. El caso más representativos es el de “Portlets”; aplicaciones -o más bien componentes funcionales- cuya presentación se visualiza en una ventana que puede ser incluída y reutilizada en distintos Portales. Este tipo de servicios se publican en la capa de “Servicios de Presentación”. Finalmente, y para dar soporte a la arquitectura en su conjunto, encontraremos una serie de servicios de infrestructura, que proveen facilidades de seguridad, administración y soporte al esquema completo, y que es fundamental cuando la arquitectura escala en volúmen y complejidad. Imaginemos, en este punto, un esquema que se reitera usualmente en aplicaciones de Banca, en las que un conjunto de transacciones CICS Cobol esponen la funcionalidad del core bancario en el mainframe. ¿ Cuál es la diferencia entre esa arquitectura y lo que hoy nos propone SOA ? Esto tiene fundamentalmente que ver con el estado actual de la tecnología y los estándares. Acceder a los servicios CICS Cobol e integrarlos a distintos lenguajes y tecnologías no era una tarea trivial. Exponer estos servicios a terceras empresas involucraba acuerdos complejos e integraciones punto a punto difíciles de mantener y administrar. Una de las diferencias claves en la adopción de SOA es la utilización de tecnologías basadas en estándares que faciliten e incluso permitan automatizar la publicación e integración de aplicaciones y servicios.

En relación a este último tema, cabe mencionar que Web Services no es sinónimo de

SOA. Por el contrario, es posible utilizar Web Services y seguir en un esquema de integración punto a punto, así como es posible implementar un esquema SOA sin utilizar Web Services. Sin embargo, tanto Web Services como los estándares asociados (XML, SOAP, WSDL, UDDI, WS-I) conforman una base de tecnologías y estándares que facilitan la implementación de SOA. El Modelo de Dominios de SOA Hemos hablado hasta aquí de un aspecto básicamente técnológico de SOA. Sin embargo, lo cierto es que por más que se cuente con una implementación total de la arquitectura de referencia descripta antes, si una organización no avanza al mismo tiempo en aspectos organizacionales, culturales, de desarrollo, de presupuesto y de alineación al negocio; el beneficio que obtendrá de un esquema SOA será nulo o cercano a nulo. Es por esto que surge el Modelo de Dominios de SOA que proponemos desde BEA. El mismo, describe seis aspectos en los cuales una organización que planea adoptar SOA debe avanzar, incorporando soluciones concretas a las problemáticas que cada dominio plantea. El Modelo de Dominios de SOA decribe tres dominios fundamentalmente técnicos: el de Arquitectura, el de Bloques Básicos y el de Proyectos y Aplicaciones; y tres dominios no técnicos: el de Estratégia de Negocio y Procesos, el de Costos y Beneficios y el de Organización y Gobierno.

Costos y Beneficios

Organización y Gobierno

Proyectos y Aplicaciones

Bloques Básicos

Arquitectura

Estrategia de Negocio y Procesos

El nivel de madurez de una organización en su adopción de SOA, estará dado por la factorización del nivel de madurez en cada uno de los dominios mencionados. Es así, que si una compañía ha avanzado en todos los aspectos del modelo (Bloques Básicos, Arquitectura, etc.), pero no ha montado una estructura de Gobierno y Organización para dar soporte al funcionamiento del esquema, los beneficios que obtendrá de SOA serán escasos. Veamos con más detenimiento qué problemática ataca cada dominio para entender este concepto... Arquitectura Este es el dominio más tecnológico, y el más fácil de comprender por los departamentos de IT de una organización. Para avanzar en este dominio, los pasos son bastante claros, e involucran la definición de una Arquitectura Empresarial de Referencia, que será básicamente una instanciación del esquema descripto en la definición inicial de este artículo, y sobre la cual se diseñarán e implantarán las soluciones y sistemas de información.

En la mayoría de las empresas, la proliferación de tecnologías y aplicaciones departamentales ha dado origen a que la Arquitectura Corporativa surja como una consecuencia imprevista de lo implementado, y no como un diseño planeado y consensuado. Luego de esto, es usual ver una serie de “Proyectos de Integración” tratando de solucionar la problemática originada.

La definición de una Arquitectura de Referencia, sentará bases para la construcción de

una Arquitectura Orientada a Servicios sólida que permita:

* Cambiar procesos de negocio existentes e implementar nuevos rápidamente * Modificar y desarrollar aplicaciones con mayor rapidez, ensamblando

componentes y combinando múltiples aplicaciones y procesos en nuevas aplicaciones compuestas

* Aprovechar el uso de tecnologías basadas en estándares * Proeveer facilidades de administración, seguridad, integración y monitoreo de la

infrestructura

Seguidamente a esto, las distintas componentes de la Arquitectura de Referencia deberán ser movidas a un ambiente de producción como parte de un plan de largo plazo. Bloques Básicos En relación a este dominio, la organización deberá identificar los servicios básicos que componen la funcionalidad de su infrestructura de IT y montarlos en un hub de servicios; más precisamente en la capa de Servicios de Acceso a Información y Datos. Es en este dominio en el cual se deberán atacar temas relacionados con la identificación de la funcionalidad relevante resuelta por cada uno de los aplicativos corporativos, incluyendo bases de datos y sistemas backend, y su publicación en forma de servicio.

Estos servicios pueden ser expuestos en base a tecnologías diversas como Web services, RMI, JMS, etc. En los siguientes párrafos estudiaremos en detalle este punto.

Un servicio, consta de tres partes fundamentales:

Es así que por ejemplo, una consulta de datos de un empleado, o mejor dicho, el “Servicio de Obtención de Datos de un Empleado” en una empresa, podría estar implementado por un componente Java; por ejemplo, por un EJB. Esta sería la “Implementación” del servicio. En esta implementación, seguramente el componente Java accederá a algún sistema corporativo donde los datos residen, éste puede ser un sistema empaquetado como SAP o PeopleSoft, o un desarrollo propio; y será accedido a través del conector apropiado.

Ahora bien, los EJB (Enterprise Java Beans) naturalmente exponen su funcionalidad a través de métodos java invocables remotamente desde distintos servidores de la red a través del protocolo estándar RMI (Remote Method Invocation). Esta constituiría una primer “Interfase”. Eventualmente las aplicaciones de Recursos Humanos en la Intranet o IVRs corporativos podrían hacer uso de esta interfase, invocando a las funciones de esta componente a través de RMI y sabiendo que el servicio cumplirá para cada uno de ellos con un “Contrato” específico, en el cual se definen cuestiones como tiempos de respuesta esperados, cantidad de invocaciones por segundo soportadas, cantidad de clientes simultáneos, etc.

Por otro lado, podría suceder que alguna aplicación batch de envío de correspondencia, necesite en determinado momento utilizar este servicio. Siendo una aplicación que ejecuta en background, podría hacer requerimientos de datos de distintos empleados en determinado momento al comienzo de su proceso, y realmente utilizarlos al final del mismo, cuando completa la impresión de los sobres. En este caso, el mismo componente Java descripto antes podría exponer una interfase basada en colas de mensajes JMS (Java Messaging Services, un estándar de mensajería Java). De este modo, el proceso de envío de correspondencia se comunicaría con el mismo servicio pero a través de una interfase asincrónica, eventualmente de menor prioridad que la interfase RMI (orientada a consumidores on-line de tiempo real), es decir, con un “Contrato” distinto en cuanto al nivel de servicio y tiempos de respuesta esperados.

Finalmente, podría ocurrir que un proveedor de esta empresa imaginaria, por ejemplo una empresa de Medicina Prepaga para los empleados, tenga preparadas campañas en sus sistemas informáticos, y que para ejecutarlas necesite de ciertos datos de los empleados. Supongamos que el sistema de nuestra empresa de Medicina Prepaga está implementado en .Net, por lo que no le es posible utilizar el servicio que nosotros exponemos a través de las interfaces basadas en Java (RMI y JMS). Entonces, es muy sencillo con las herramientas adecuadas, generar automáticamente una nueva interfase Web Service, un estándar que permite que el servicio sea consumido desde cualquier tecnología. Muy probablemente, y en especial para este tipo de

consumidores externos, se proveerá un nuevo “Contrato” con ciertas limitaciones, por ejemplo, en cuanto a la confidencialidad de la información brindada y eventualmente limitaciones en cuanto a la funcionalidad expuesta por el servicio.

De este modo, tendremos un servicio básico en la capa de servicios de Acceso a Información y Datos (Obtención de los datos de un empleado) que expone la funcionalidad de nuestro sistema corporativo (backend) de Recursos Humanos, a través de tres interfaces (RMI, JMS y WebServices), con tres contratos distintos según el consumidor.

Si avanzamos en el camino hacia la adopción de SOA, encontraremos que procesos de

negocio completos pueden ser expuestos como servicios para ser consumidos por múltiples aplicaciones. Proyectos y Aplicaciones Es común, en organizaciones de cierto tamaño, encontrarnos con un nivel alarmante de desconocimiento acerca de los proyectos e iniciativas en marcha en los distintos departamentos y áreas. Con el objeto de aprovechar las ventajas de SOA, es importante un cambio radical en este aspecto. En una Arquitectura Orientada a Servicios, el órden de desarrollo e implementación de los proyectos es fundamental para facilitar el reuso de servicios y evitar la duplicación de esfuerzos. Si el desarrollo de una aplicación A involucra la implementación de los servicios 1, 2 y 3; y el desarrollo de una aplicación B exige la implementación de los servicios 1,2,3,4,5,6,7 y 8, seguramente será conveniente dar prioridad a la aplicación A, con el objeto de reducir el costo de desarrollo de la apliación B. O al menos, se deberá dar prioridad a la implementación de los servicios reusables (1,2 y 3), ya que son los que serán aprovechados en ambos desarrollos. Esta coordinación exige de un cambio organizacional (ver dominio de Organización y Gobierno) y la implementación de esquemas de comunicación en relación a proyectos “on the flight” entre las distintas áreas de una empresa. Estrategia de Negocio y Procesos Este dominio dentro del modelo ataca la necesidad de que la línea de negocio y las áreas de IT hablen un mismo lenguaje. Normalmente estamos acostrumbrados, desde las areas de tecnología, a hablar en términos de aplicaciones y funcionalidad y no en términos de procesos o servicios de negocio. Esta es una de las causales que ayudan a que exista lo que se conoce como el “IT Gap”, o la incapacidad de las áreas de tecnología de satisfacer los requerimientos de las líneas de negocio.

En relación a este punto, será necesario desde IT comenzar a implementar “Servicios de Negocio”, y hacerlos conocer como tales a medida que se publican en la capa de “Servicios de Negocio Compartidos” que mencionábamos en un principio.

Los desarrollos deben ser impulsados por necesidades de negocio y de procesos más que centrarse en aplicaciones y sistemas. Pero no sólo los servicios desde IT deben ser implementados según las necesidades del negocio y de los procesos sino que por otro lado, las líneas de negocio deben conocer qué servicios están disponibles para poder expresar sus necesidades en términos de dichos servicios, y definir procesos nuevos basados en procesos y servicios existentes.

Asimismo debe soportarse el modelado visual de procesos de negocio, debe lograrse un

entendimiento conceptual de cómo el flujo de trabajo de estos procesos fluye entre los ditintos servicios, deben incorporarse herramientas que automaticen la creación de estos procesos, al punto en que analistas de negocios puedan participar de estas tareas e incluso sean capaces de incorporar pequeños cambios –al menos inicialmente- a procesos existentes.

Este acercamiento permitirá achicar el “IT Gap”, la perfromance de la Arquitectura

Orientada a Servicios debe estar íntimamente vinculada con la performance del negocio, de modo que las estrategias e iniciativas corporativas deberán verse reflejadas en las áreas de IT. Costos y Beneficios Nada de lo que se haga tendrá sentido si no somos capaces de medir el impacto de la adopción de SOA en la organización desde el punto de vista económico. Es imprescindible contar con mecanismos de evaluación que permitan estimar la inversión y medir los beneficios, no sólo en términos de ahorro sino en términos de mejoras en “time to market”.

Proyecto a proyecto, deben recolectarse los datos que permitan justificar las inversiones

realizadas y proyectar inversiones futuras. Ningún cambio será percibido si no somos capaces de mostrar los resultados, especialmente cuando se requiere de una inversión inicial significativa:

Near Term Mid-Term Long Term

Time

C O S T

low

high

Servicios de negocio reusable comienzan a aparecer, acelerando los tiempos de respuesta.

El punto de quiebre ocurre cuando las áreas debajo de las curvas son iguales.

Organización y Gobierno Es en esta área en la cual se debe producir el cambio organizacional y cultural más importante. Las organizaciones que han implentado SOA con éxito (Nokia, British Telecom, Wells Fargo, UPS, por nombrar algunas) han atacado este punto mediante la creación de un “Comité de SOA” , responsable de cuestiones como:

- Priorizar implementaciones. - Auditar el nivel de disponibiliad de los servicios. - Auditar el cumplimiento de los contratos, tanto por parte de los productores

como por parte de los consumidores de los servicios. - Resolver cuestiones presupuestarias (qué área financia la implementación de un

servicio que va a ser reutilizado por muchas otras áreas en producción, por ejemplo).

- Asegurar e imponer la reusabilidad y evitar la duplicación de esfuerzos - Determinar la exposición o no de servicios sensibles hacia el exterior de la

organización. - Determinar procesos operacionales, herramientas y buenas prácticas. - Definir los mecanismos de versionamiento y control de cambios - Asegurar la adhesión a la Arquitectura e Referencia - Seguir métricas, costos y evaluar y reportar beneficios - Implementar procesos de planeamiento y revisión periódicos

La creación temprana de este tipo de estructuras organizacionales es fundamental en la adopción de SOA. Existen varias alternativas posibles de implementación de estas estructuras; y la elección de la más adecuada dependerá del tipo de compañía de que se trate, de su cultura empresarial, de su distribución geográfica y de su jerarquía organizacional. Las siguientes son cuatro de las más usuales:

El perfil de los integrantes de un Comité de SOA debe tener el equilibrio justo entre el

conocimiento de negocio, funcional y técnico. Finalmente el rol del Arquitecto Corporativo es indispensable y clave en este contexto.

Conclusión SOA está brindando beneficios tangibles en organizaciones de todos los tamaños y en todas las geografías. Sin embargo, y a diferencia de lo que generalmente se tiene como foco, es necesario atacar mútiples aspectos para su adopción, y no solamente el técnológico, si se desea obtener los beneficios prometidos por este Paradigma de Arquitectura Corporativa.

Octavio Duré