fue realizado por el (f)

Transcripción

1 REPÚBLICA DEL ECUADOR UNIVERSIDAD CATÓLICA DE CUENCA UNIDAD ACADÉMICA DE INGENIERÍA DE SISTEMAS, ELÉCTRICA Y ELECTRÓNICA SOA Y SU APLICACIÓN EN LATINOAMÉRICA Trabajo de Investigación, previa a la obtención del Título de Ingeniero, especialidad de Ingeniería de Sistemas AUTOR: Tnlg. Mario V. Domínguez Cárdenas DIRECTOR: Ing. Isael Sañay Cuenca Ecuador

2 Certifico que bajo mi dirección, el proyecto fue realizado por el Egresado. Tnlg. Mario V. Domínguez Cárdenas (f) Ing. Isael Sañay

3 CERTIFICA: Luego de haber dirigido y revisado correctamente cada uno de los capítulos tratados en este trabajo de investigación, desarrollado por el Tnlg. Mario V. Domínguez C. y por cumplir los requisitos autoriza su presentación. Cuenca, Octubre 13 del 2008 Ing. Isael Sañay. Director

4 DEDICATORIA Este trabajo de investigación está dirigido a mis queridos padres y amigos que con su esfuerzo y sacrificio me han encaminado a conseguir este título el cual me servirá en un futuro no muy lejano para poder ejercer mi profesión. Tnlg. Mario V. Domínguez Cárdenas.

5 AGRADECIMIENTO Antes de todo el más grande de los agradecimientos va dirigido a aquella persona que nos ha permitido ser lo que somos... DIOS. Un agradecimiento muy sincero y de todo corazón a mis padres y profesores por haber permanecido junto a mí durante esta etapa de mi vida estudiantil y de manera muy especial al Ing. Isael Sañay por haberme dirigido en el desarrollo de este trabajo de investigación. Tnlg. Mario V. Domínguez Cárdenas.

6 INTRODUCCIÓN Una nueva sigla está inundando el mensaje de marketing de los principales vendedores de soluciones de tecnología de la información: SOA. Detrás de las tres letras se esconde un concepto: Service Oriented Architecture, o, en español, Arquitectura Orientada a Servicios. Este trabajo de investigación revela las principales características de este nuevo paradigma basado en estándares de mercado, que amenaza con haber llegado para quedarse y que requiere de un cambio cultural profundo: las aplicaciones dejan de ser tales y se convierten en servicios. soluciones. En el desarrollo de grandes aplicaciones distribuidas se aportan Estas soluciones logran abstraer los sistemas de sus requerimientos físicos y permiten su modelado independiente de las plataformas e implementación. Estas soluciones son válidas en otros campos (IT Insight, 2008).

7 ii Arquitecturas Orientadas a Servicios (SOA). Puede aplicarse en otros entornos con problemas similares. Aporta la misma capacidad de abstracción. Campo en continuo desarrollo. Durante los 70 sufrió un auge agotado pocos años después al no satisfacer las aspiraciones iníciales (Alicante, 2005). Impulsores auge: Robótica + IA Retención: sistemas de gran complejidad que no lograban cubrir expectativas. Actualmente. Introducida en sectores como los entornos industriales, medicina, servicios y energía nuclear. Suponen una fuerte inversión y compromiso. Reticencia al cambio de sistemas implantados.

8 iii El flujo de conocimiento que dirige una empresa u organización en cualquier sector de negocio cambia de forma constante como respuesta a influencias externas e internas. Desde el punto de vista Tecnologías de Información IT, cada área de negocio de la empresa origina unos requisitos de negocio que son implementados en procesos documentados, al que nos referimos como capa de negocio. Por otro lado existe un conjunto de aplicaciones que automatizan dichos procesos de negocio basándose en distintas soluciones tecnológicas. La capa de aplicación se caracteriza por utilizar tecnologías heterogéneas, por tener un origen diverso (bien desarrolladas por la propia organización o suministrada por distintos proveedores) y por tener restricciones técnicas y de seguridad. manera: Este trabajo de investigación se encuentra organizada de la siguiente El Capítulo I trata del análisis de la Arquitectura SOA. El Capítulo II trata de las cuatro P y el SOA. El Capítulo III trata de la era de la M.

9 iv El Capítulo IV trata del análisis del Ciclo de Gobierno de SOA según IBM. El Capítulo V trata del análisis del Market Share.

10 ÍNDICE DE CONTENIDOS INTRODUCCIÓN... I GLOSARIO DE TÉRMINOS... 8 CAPITULO 1: SOA QUÉ ES SOA? DE QUÉ HABLAMOS CUANDO HABLAMOS DE SOA LAS CLAVES DIFERENCIADORAS DE SOA IMPACTO DE SOA EN EL DESARROLLO DE APLICACIONES IMPLICACIONES SOA SOA PUEDE GENERAR BENEFICIOS DE NEGOCIO SIGNIFICATIVOS MODELADO DE SERVICIOS Y SU RELACIÓN CON SOA PRINCIPIOS DE LA ORIENTACIÓN A SERVICIOS SOA Y LOS SERVICIOS WEB SOA Y LOS SERVICIOS WEB: LA SINGULARIDAD DEL RENDIMIENTO SERVICIOS WEB Y EL PROBLEMA DE LA COMPLEJIDAD DE SOA EL CAMINO DE LA INTEGRACIÓN QUE TIENE DE BUENO LATINOAMÉRICA UN LARGO CAMINO A SOA

11 MIGRAR HACIA SOA PASO A PASO EN AMÉRICA LATINA CAPITULO 2: LAS CUATRO P Y EL SOA UN IMENZO MARKET MINDSHARE TODOS SOMOS PARTE QUIÉN SOY? DÓNDE ESTOY? LO NUEVO DENTRO DE LO NUEVO CAPITULO 3: LA ERA DE LA M IBM ARGENTINA Y SUS "10 AÑOS" CON SOA LAS EMPRESAS ARGENTINAS ESTÁN ADOPTANDO POCO A POCO SOA IBM SUGIERE EXPLICAR LA RAPIDEZ DE ACTIVAR LOS NEGOCIOS CON SOA BEA ARGUMENTA QUE LA INDUSTRIA YA APLICA SOA SIN SABERLO SUN: SOA AHORRA AL NO GASTAR MÁS EN REPARAR REPARACIONES CAPITULO 4: CICLO DE GOBIERNO DE SOA SEGÚN IBM EL CASO DE UNA TELCO QUE COMENZÓ SOA POR EL CALL CENTER, CON IBM BEA SUGIERE LOS PASOS PARA INICIAR UN PROYECTO GRADUAL SOA POR EL BUS SUN OPINA QUE SOA COMIENZA AL APLICAR MEJORES PRÁCTICAS SISTEMÁTICAMENTE SOA BUSCA CONDUCIR LA IT DESDE EL NEGOCIO, SEGÚN IBM BEA Y LOS LAZOS DE REALIMENTACIÓN EN CADA PASO DE SOA AL APLICAR SOA, SEGÚN IBM, LAS TELCO EVITARÍAN COMPRAR COSTOSOS PAQUETES BEA EXPLICA CÓMO ARMAR DE A POCO UN ENTORNO SOA DESDE EL LEGACY IBM PLANTEA CÓMO CONVIVE EN SOA CON LAS TELCOS QUE USAN SAP... 81

12 7 4.9 POLÉMICA ENTRE BEA, SAP Y ORACLE SOBRE CONVIVENCIA EN SOA LA CONSIDERACIÓN DE SOA COMO DE ALTA PRIORIDAD PASÓ DE 28% EN 2005 A 36% EN CAPITULO 5: MARKET SHARE ENCUESTA CUALITATIVA SOBRE LIDERAZGO A LA HORA DE PENSAR EN SOA RÉPLICA DE SUN AL SHARE QUE UBICA A BEA AL TOPE DE SOA CONCEPTOS BÁSICOS PARA COMENZAR A ENTENDER SOA, SEGÚN IBM COMPLEMENTO DE BEA AL MODELO DE TRES CAPAS PARA SOA DE IBM SUN RESALTA LA INTEGRACIÓN DE LA GENTE EN SOA Y APORTA SU MODELO GARTNER VATICINA RESPECTO A SOA LOS TRES NIVELES DE MADUREZ DE SOA CREANDO EMPRESAS FLEXIBLES CON SOA BARRERAS PARA SOA CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA

13 GLOSARIO DE TÉRMINOS Término Significado SOA Arquitectura Orientada a Servicios. WSDL Lenguaje de Definición de Servicios Web. CORBA Common Object Request Broker Architecture. EAI Integración de Aplicaciones Corporativas. Web Services Servicios Web. SLA Acuerdos de Nivel de Servicio. UDDI Descripción, Descubrimiento e Integración Universal. SOAP Protocolo Simple de Acceso a Objetos XML extensible Markup Language. IT Tecnologías de Información.

14 9 ROI Mejora del Retorno de la Inversión. WS-BPEL Servicios Web de Lenguaje de Ejecución del Proceso de Negocios. WS-CDL Servicios Web de Lenguaje de de Descripción de Coreografía. WS-Security Seguridad de Servicios Web. WS-Manageability Gestión de Servicios Web. WS-Transaction Transacción de Servicios Web. WS-Coordination Coordinación de Servicios Web. JMS Servicio de mensajería Java. WSRP Web Services Remote Portlets. ESB Enterprise Service Bus. HTTP Protocolo de Transferencia de Hyper Texto. ERP Enterprise Resource Planning. CRM Administración de la Relación con los Clientes.

15 10 SPM Software Practice Manager. BPIC Business Partner Innovation Center. SOM Administración Orientada a Servicios. CPIO Chief Process Innovation Officer. SQL Lenguaje de Consulta Estructurado. BPM Administración de Procesos de Negocio. KPI Indicadores Clave de Procesos. WH WareHouse. ESB Enterprise Service Bus.

16 ÍNDICE DE FIGURAS ILUSTRACIÓN 1.1 EVOLUCIÓN HISTÓRICA DE LOS SISTEMAS ILUSTRACIÓN 1.2 IMPLICACIONES SOA ILUSTRACIÓN 1.3 CAPAS DEL SOA ILUSTRACIÓN 1.4 PRINCIPIOS DE LA ORIENTACIÓN A SERVICIOS ILUSTRACIÓN 1.5 SOA TRADICIONAL ILUSTRACIÓN 1.6 ESQUEMA BÁSICO DEL SOA ILUSTRACIÓN 1.7 ARQUITECTURA ORIENTADA A SERVICIOS ILUSTRACIÓN 1.8 EXPERTOS EMPRESARIALES ILUSTRACIÓN 2.1 MARKET MINDSHARE ILUSTRACIÓN 3.1 SILVIA LÓPEZ GRANDÍO, GERENTE DE SOFTWARE DE IBM ARGENTINA ILUSTRACIÓN 4.1 EVOLUCIÓN SOA EN 2005 Y ILUSTRACIÓN 4.2 PROTAGONISTAS ILUSTRACIÓN 5.1 INNOVACIÓN Y DEMANDA POR TI ILUSTRACIÓN 5.2 REVISIÓN RETROSPECTIVA Y PROYECTADA DEL DESARROLLO DE TI

17 CAPITULO 1: SOA 1.1 Qué es SOA? Para comprender cabalmente el significado de SOA, hay que partir señalando que no se trata de una tecnología, sino más bien de un enfoque, como dicen algunos, o una "filosofía", como dicen otros. Este enfoque provee una metodología y un marco de trabajo para diseñar una arquitectura de software basada en servicios, los cuales pueden ser expuestos interna o externamente a través de un conjunto de tecnologías estándares para su uso por otras aplicaciones, propias o de terceros. Sin embargo, una arquitectura orientada al servicio no es algo 100% nuevo. De hecho, las organizaciones de TI han estado construyendo y desplegando exitosamente aplicaciones SOA desde hace años, antes incluso de que existiera el estándar XML (extensible Markup Language) o los servicios Web. Sólo que entonces se hacía referencia a ella a través de términos como "modularidad", "programación orientada a objetos", "componentes

18 13 reutilizables" o "interfaces de programación de aplicaciones". Y, aunque ninguno de dichos conceptos es idéntico a SOA, sí involucran algunos aspectos de ella. SOA es un método para diseñar, desarrollar, desplegar y administrar partes de lógica computacional (servicios) al interior de una red. Se trata de una manera de estructurar las aplicaciones, de organizar la infraestructura de TI y de estandarizar las funcionalidades de negocios. Aunque suele asociarse a SOA con XML y los Servicios Web (utilizando SOAP - Protocolo Simple de Acceso a Objetos y WSDL - Lenguaje de Definición de Servicios Web), se trata en ambos casos de referencias a las implementaciones más recientes y reconocidas. 1.2 De qué hablamos cuando hablamos de SOA Se trata de un nuevo concepto de IT que invita a convertir los procesos de negocios en servicios disponibles para los usuarios de equipos informáticos. Es un gran cambio de paradigma, y no una mera implementación de software. En algún momento de la historia, las empresas debieron dejar el mainframe y mudar su infraestructura de IT a un esquema cliente-servidor para bajar los costos, distribuir la carga de trabajo y aumentar la performance

19 14 general de las terminales, entre otros beneficios. Luego, llegó el turno del modelo Web, para, también entre diversos objetivos, hacer que las aplicaciones sean accesibles desde cualquier punto del planeta. Un nuevo paradigma asoma ahora en el universo de IT. El de la Arquitectura Orientada a los Servicios, que propone convertir a los recursos de software en servicios disponibles para quien los requiera. Conceptualmente, la idea es crear componentes reutilizables, fáciles de emplear y de mantener, en lugar de aplicaciones monstruosas y complejas. Estos componentes son los que reciben el nombre de servicios. Algunos ejemplos obvios de servicios podrían ser consulta de saldo, control de stock, abrir una cuenta o desarrollo de factura. Cada uno de estos servicios representa una función de negocios claramente definida con toda su lógica, que puede ser invocada desde cualquier punto (no sólo desde las computadoras corporativas) mediante protocolos de comunicación estándar. La interfaz del servicio es independiente, por lo que no está relacionada con su implementación.

20 Las claves diferenciadoras de SOA Las claves diferenciadoras de SOA son las siguientes: Fijar la atención en mostrar los procesos de negocio. Los servicios ejecutan transacciones de negocio completas, más que funciones de aplicaciones. La atención está en los servicios a proveer más que en su propia implementación. Potenciar la interoperabilidad. A través del ensamblaje o la encapsulación de las funciones de negocio. A través de Acuerdos de Nivel de Servicio (SLA), o una operación de servicio correctamente definida. Transparencia en la localización de los servicios (Separación de servicios de clientes y proveedores). Implementación de estándares a través de Servicios Web.

21 Impacto de SOA en el desarrollo de aplicaciones La Ilustración 1.1 Muestra la evolución histórica de los sistemas. Ilustración 1.1 Evolución histórica de los sistemas. SOA representa uno de los mayores paradigmas de cambio en el desarrollo de aplicaciones comparable al paso de desarrollos procedimentales a orientación de objetos. 1.5 Implicaciones SOA El cambio de paradigma de SOA tiene implicaciones en: Gestión, planificación, desarrollo y operación como se presenta en la Ilustración 1.2

22 17 Ilustración 1.2 Implicaciones SOA. 1.6 SOA puede generar beneficios de negocio significativos Distintos tipos de beneficios de negocio: Mejora del Retorno de la Inversión (ROI). Aumento de la vida de las funcionalidades existentes, por ejemplo exponiendo los sistemas legacy. Posibilidad de conexión con nuevas tecnologías a través de envoltorios basados en estándares. Incrementando el foco en los Servicios de negocio.

23 18 Disponibilidad de herramientas y funcionalidades existentes. Facilita el proceso de integración basado en estándares. Mejor Interoperabilidad. Localización transparente. Independencia de plataforma (comunicación basada en mensajes a través de la capa de servicios). Comunicaciones basadas en un acuerdo. Mayor escalabilidad y control de fallos. Incremento de servicios para soportar mayor uso o mayor seguridad sin necesidad de modificación. Mejora del Time to Market. Posibilidad de desarrollos concurrentes. Facilidad de publicar servicios para ser probados. 1.7 Modelado de servicios y su relación con SOA. Una aplicación SOA está formada por un conjunto de servicios interconectados cuyo objetivo es automatizar uno o varios procesos de

24 19 negocio. Por tanto, a la hora de construir una aplicación SOA, el elemento sobre el que debemos enfocar nuestros esfuerzos es el concepto de servicio. En este punto surgen una serie de preguntas: Qué tipos de servicios existen? Esta pregunta se la hace todo desarrollador a la hora de enfrentarse a una aplicación SOA. Existen varias clasificaciones dependiendo de su autor. Existen básicamente tres tipos de servicios, divididos en base a sus funcionalidades: Servicios controladores: Son los encargados de recibir las peticiones de los clientes y realizar las llamadas necesarias a otros servicios (en la secuencia adecuada) para devolver una respuesta. Es decir, son los servicios encargados de coordinar al resto de servicios. Si analizamos bien este tipo de servicios, nos daremos cuenta de que representan a los procesos de negocio que queremos implementar, ya que un proceso de negocio no es más que un conjunto de tareas ejecutadas en una determinada secuencia para obtener un objetivo.

25 20 Servicios de negocio: Son los servicios que representan una tarea de negocio, y que forman parte de un proceso de negocio. Este tipo de servicios suelen ser poco reutilizables porque están orientados a resolver una tarea muy puntual. Servicios de utilidad: Son aquellos servicios que se caracterizan por representar una tarea altamente reutilizable. Existen dos tipos, los servicios orientados al negocio que representan una tarea de negocio altamente reutilizable entre aplicaciones y los servicios tecnológicos encargados de encapsular una determinada tecnología y por tanto altamente reutilizables (ej: servicio de acceso a bases de datos relacionales). Así, una aplicación SOA la podemos dividir en tres capas como muestra la Ilustración 1.3

26 21 Ilustración 1.3 Capas del SOA. 1.8 Principios de la orientación a servicios. Un problema con el que nos podemos encontrar a la hora de construir una aplicación SOA es si la aplicación construida realmente es una aplicación "SOA Compliant". Para comprobar si una aplicación lo es, la mejor forma de hacerlo es chequeando que la aplicación cumpla con los Principios de la Orientación a Servicios. No existe una definición estándar de cuáles son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es

27 22 un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl son: Los Servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo. Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, esto se logrará mediante la definición de interfaces con WSDL. Los Servicios deben tener bajo acoplamiento: Es decir, que los

28 23 servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables. Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación Servicios Web de Lenguaje de Ejecución del Proceso de Negocios (WS-BPEL) y Servicios Web de Lenguaje de de Descripción de Coreografía (WS-CDL). Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos

29 24 podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución. Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea. Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros de Universal Description, Discovery and Integration (UDDI). Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta siempre estos principios, ya que nos van a dar las pautas

30 25 necesarias para tomar ciertas decisiones de diseño complejas. Como se habrá podido observar, una característica muy importante de los Principios de la Orientación a Servicios, es que todos ellos se interrelacionan. La Ilustración 1.4, muestra la inter-relación de los diferentes principios: Ilustración 1.4 Principios de la orientación a servicios. Como se puede observar en la ilustración, el objetivo de la Orientación a Servicios es obtener software totalmente reutilizable a través de un conjunto de técnicas y principios como los descritos anteriormente.

31 SOA y los servicios web. En la actualidad el concepto de SOA ha resurgido, gracias al auge y madurez de una nueva tecnología: los Servicios Web. Los Servicios Web se han convertido en el estandarte de SOA, ya que esta tecnología posee un conjunto de características que permiten cubrir todos los principios de la orientación a servicios, no como otras posibles tecnologías de implementación como colas de mensajes o CORBA. Centrándonos en los Servicios Web, podemos decir que con ellos se pueden generar dos tipos de Arquitecturas Orientadas a Servicios: Arquitectura Orientada a Servicios Tradicional. Arquitectura Orientada a Servicios de Segunda generación. La SOA Tradicional es aquella que utiliza los principios y tecnologías básicos de los Servicios Web. Esto significa utilizar SOAP como lenguaje de intercambio, WSDL como lenguaje para la descripción de los servicios y UDDI para la publicación o registro de los mismos. En la ilustración 1.5 que se muestra a continuación, se puede ver la

32 27 estructura básica de funcionamiento de una SOA tradicional. Ilustración 1.5 SOA Tradicional. En la ilustración anterior, se puede observar la existencia de tres roles claramente diferenciados: Cliente del servicio: Es el que solicita la ejecución del servicio web, y por lo tanto el que lo consume. Proveedor del servicio: Es el encargado de implementar el Servicio Web y ofrecerlo a los clientes. Registro del servicio: Es un repositorio donde se almacenan las descripciones de los servicios, para que así los clientes puedan buscar el Servicio Web que mejor se adapte a sus necesidades. La secuencia de ejecución es la siguiente:

33 28 El proveedor del servicio da de alta el Servicio Web en el registro. Para realizar esto, el proveedor almacena en el registro el documento de descripción de este. El solicitante del servicio busca en el registro un Servicio Web que pueda adaptarse a sus necesidades. Una vez seleccionado el servicio, el solicitante lo invoca mediante el envío de un mensaje SOAP, en el cual se indica la acción a realizar y los datos de entrada. El Servicio Web recibe la petición y ejecuta la funcionalidad. Para finalizar envía un mensaje SOAP al solicitante con los resultados obtenidos. Por lo tanto, una SOA tradicional estará compuesta por un conjunto de servicios que reciben y envían mensajes SOAP en base a una descripción WSDL. Este tipo de arquitecturas hoy en día es muy utilizado, pero no es el más óptimo debido a que no proporciona una serie de características esenciales a la hora de crear una Arquitectura profesional. Estas características son:

34 29 Seguridad. Transaccionabilidad. Garantía de entrega. Orquestación. Coreografía. Direccionamiento ( ) Estas características las ofrecen las SOA de segunda generación. SOA de segunda generación es el tipo utilizado actualmente, porque está basado en el SOA tradicional, añadiendo lo necesario para cubrir sus carencias. Es decir, proporciona los elementos necesarios para cumplir con todos los principios de la orientación a objetos. El esquema básico de una SOA de segunda generación es el mostrado en la ilustración 1.6

35 30 Ilustración 1.6 Esquema básico del SOA. Como se puede observar, una SOA de segunda generación está formada por un conjunto de Funciones y por la Calidad del Servicio. Las funciones están formadas por: Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente, hasta el proveedor del servicio, y viceversa. Protocolo de comunicación: Es el sistema de comunicación entre el cliente y el proveedor de servicios. Descripción del servicio: Es un esquema utilizado para describir qué servicio es, como se le puede invocar, y cuáles son los datos

36 31 necesarios para realizar su invocación. Servicio: Es la implementación del servicio. Proceso de negocio: Es una colección de servicios, invocados en una determinada secuencia, con un conjunto particular de reglas para satisfaces un requisito de negocio. Registro de servicios: Es un repositorio de servicios y datos, usado por los proveedores de servicio y publicar los servicios, y para los clientes, donde buscarlos. La calidad del servicio por: Política: Son un conjunto de reglas bajo las cuales, un proveedor de servicio hace que el servicio esté disponible para los clientes (WS- Policy). Seguridad: Son un conjunto de reglas que podrían ser aplicadas en la identificación, autorización y control de acceso a los servicios, por parte del cliente (WS-Security). Transacción: Conjunto de atributos que podrían ser aplicados sobre un grupo de servicios para devolver un conjunto de datos consistentes (WS-Transaction, WS-Coordination).

37 32 Gestión: Conjunto de atributos que podrían ser aplicados para gestionar los servicios proporcionados (WS-Manageability). Es decir, las SOA de segunda generación se basan en ampliar su funcionalidad mediante el uso de los estándares WS, que proporcionan funcionalidades como gestión de transacciones, seguridad, etc SOA y los Servicios Web: la singularidad del rendimiento Los entornos de servicios débilmente acoplados proporcionan a las empresas la flexibilidad que necesitan para adaptarse rápidamente a las demandas empresariales cambiantes. Pero a pesar de todas las ventajas que ofrecen, los Servicios Web y el SOA introducen una nueva paradoja: la comunicación entre sistemas dispares se simplifica si el entorno en el que se despliegan estos servicios es más complejo. servicios. Esta complejidad agrava la tarea de gestionar la calidad de los Considerando el número de servicios disponibles y los muchos puntos en los que intersectan, donde cualquiera de ellos podría hacer caer una aplicación, cómo es posible garantizar la salud y disponibilidad de estos

38 33 servicios en un entorno de producción en tiempo real? Ya no es suficiente tratar el rendimiento de las tecnologías de servicios como Servicios Web sin considerar su impacto en el entorno en el que se despliegan. Las empresas deben adoptar una propuesta de gestión del rendimiento de extremo a extremo que mire en los puntos de integración así como en los propios sistemas conectados: servicios, aplicaciones Web y sistemas back-end conectados. Así, cualquier solución para gestionar aplicaciones habilitadas para Servicios Web sólo será efectiva si se puede ver en toda la ruta de la transacción y en cada intersección crítica a lo largo del camino Dentro de una Arquitectura Orientada a Servicios Una Arquitectura Orientada a Servicios es esencialmente una colección de servicios que se comunican entre sí. La comunicación puede implicar un sencillo traspaso de datos o dos o más servicios coordinando alguna actividad. La tecnología que habilita SOA puede tomar muchas formas.

39 34 Por ejemplo, una aplicación típica como un sistema de gestión de inventarios podría estar compuesta por múltiples servicios (como búsqueda, índices de precios y generación de facturas) que se exponen a través de un servicio Web. Desde otro punto de vista, las peticiones HTTP deberían transformarse en mensajes JMS (Java Messaging Service, Servicio de mensajería Java) a través de un Bus de servicios empresariales. O los servicios remotos podrían exponerse a través de portlets en aplicaciones de cara al cliente a través de Portlets remotos de Servicios Web (WSRP, Web Services Remote Portlets). Para complicar aún más las cosas, en cualquier punto de conexión se podría usar un broker de integración para interrelacionar las interacciones de servicios. diferente. Cada una de estas tecnologías se adapta a una SOA de forma Brokers de mensajes El broker de mensajes, una capa de comunicación responsable de garantizar la entrega de los mensajes, se utiliza para desacoplar las

40 35 aplicaciones entre sí. Como ejemplos se pueden citar WebSphere MQ, JMS, Sonic MQ y TIBCO Rendezvous. En una SOA, el broker de mensajes actúa como el canal sobre el que los servicios pueden editar mensajes a una lista de abonados y, de ese modo, habilitar la interrelación débil de los servicios Brokers de integración Históricamente, los brokers de integración han proporcionado una amplia gama de funcionalidades que abarca la intermediación de mensajes, la conectividad back end (a través de adaptadores) y la interrelación de procesos. Los brokers de integración continúan ofreciendo el servicio vital de la interrelación de procesos. Al coordinar y gestionar las transacciones a través de servicios, los desarrolladores tienen la capacidad de construir rápidamente aplicaciones habilitadas para servicios que reflejen los procesos empresariales establecidos. Los brokers de integración proporcionan la interrelación de los

41 36 procesos empresariales, dedicando los brokers de mensajes donde se precisan interacciones asincrónicas (Cabrera, 2006) Buses de servicios empresariales Los Buses de servicios empresariales (ESB, Enterprise Service Bus) inyectan dinamismo en una SOA. Actuando como intermediarios entre varios consumidores y proveedores de servicios, los ESB proporcionan autenticación, transformación y encaminamiento de servicios que se pueden configurar y desplegar en tiempo de ejecución. Coordinan la comunicación entre los recursos de TI (incluidas aplicaciones, servicios, información y plataformas) Servidores de portal Los equipos de TI empresariales reconocen cada vez más los servidores de portal como un componente integral de un entorno SOA. De hecho, Gartner recomienda los portales como un primer paso para construir una arquitectura orientada a servicios. Los servidores de portal proporcionan una estructura de presentación que tradicionalmente ha actuado como un consumidor de servicios Web.

42 37 No obstante, con la introducción y adopción de WSRP, los portales han comenzado a actuar también como proveedores de servicios Servicios Web Un servicio Web es el bloque de construcción básico para la informática distribuida basada en Internet y, probablemente, la más ampliamente reconocida (e implementada) de las tecnologías de servicios. Se pueden crear aplicaciones habilitadas para SOA a través de la interrelación de múltiples servicios Web, independientemente de la implementación o ubicación del servicio. Como objetos empresarial auto descriptivo, se puede acceder a estas interfaces mediante el protocolo SOAP sobre una variedad de canales: HTTP, JMS, WebSphereMQ, etc. La mayoría de ellos se alojan en un servidor de aplicaciones J2EE o Microsoft.NET. Los Servicios Web facilitan la comunicación entre los sistemas de información a través de WSDL (Lenguaje de Definición de Servicios Web).

43 38 WSDL es responsable de describir cómo comunicar con un servicio (qué transportes y tipos de mensaje utilizar) así como las operaciones que expone el servicio. Los Servicios Web se editan en un UDDI. Se trata de un registro que aloja información acerca del servicio Web: cómo acceder a él, quién lo aloja, etc. Es una tecnología que sólo ahora se ha hecho más popular debido a que las empresas necesitan gestionar sus inventarios de servicios Web. Esta representación de un entorno orientado a servicios muestra a un banco comercial que utiliza un servicio de notificación de créditos centralizado. El banco puede utilizar este servicio para garantizar que ofrece una experiencia de cliente uniforme a través de todos los canales del banco (por ejemplo, no desean que se deniegue una tarjeta de crédito a un cliente cuando ya le han extendido una línea de crédito en su cuenta corriente). Editada como un servicio Web por una agencia de notificación externa, la aplicación de informes de crédito está lista para proporcionar información relevante de los clientes a todas y cada una de las aplicaciones que la

44 39 necesiten. A medida que las SOA y sus tecnologías facilitadoras maduran, las soluciones de gestión del rendimiento deben ser capaces de afrontarlas. Portales, buses ESB, brokers de mensajes y brokers de integración pueden tener sus propias utilidades de gestión pero son sólo un punto de inicio para diagnosticar caídas y problemas de servicio en el entorno de aplicación de los servicios Web. Sigue siendo necesario proporcionar una vista más integral y centrada en el negocio a través de toda la infraestructura. Unas soluciones de gestión del rendimiento eficaces para aplicaciones desplegadas en arquitecturas orientadas a servicios deben ser capaces de gestionar tecnologías de Servicios Web heterogéneas, integrarse con todo el conjunto de tecnologías de TI e identificar dependencias entre servidores de aplicaciones, servicios Web, sistemas backend y redes. servicios: La Ilustración 1.7, muestra un ejemplo de Arquitectura orientada a los

45 40 Ilustración 1.7 Arquitectura orientada a servicios Servicios Web y el problema de la complejidad de SOA La complejidad de las TI continúa siendo una enorme carga para la mayoría de las empresas. Mientras que los sistemas de información como los Servicios Web prometen agilizar el negocio, según Gartner, la complejidad fuera de control de las TI a menudo convierte estos sistemas en el principal obstáculo para la agilidad empresarial. Diversos factores han conducido a esta complejidad.

46 41 La historia de las arquitecturas empresariales se puede ver como evolución en vez de cómo revolución. En lugar de eliminar y cambiar los sistemas existentes, la mayoría de empresas han injertado nuevas capacidades sobre las que ya tenían, dejando un entorno heterogéneo compuesto de aplicaciones ya disponibles y recientes, tecnologías basadas en servicios. El cambio de los paradigmas arquitectónicos continúa introduciendo complejidad. Cuando se producían caídas en las arquitecturas clásicas cliente-servidor, era fácil señalar un fallo y las posibles causas estaban limitadas a unos pocos sistemas. En los entornos de aplicaciones compuestos habilitados para servicios, el servidor de aplicaciones Web es un punto central de coordinación a través de múltiples sistemas cliente-servidor y puede ocurrir un fallo en cualquier parte de la ruta de transacción. La capacidad de desplegar rápidamente nuevos servicios, o versiones de los mismos, dificulta la planificación precisa de la arquitectura de la aplicación. Casi tan pronto como se dibuja, el diagrama queda

47 42 desactualizado. En este tipo de entorno de evolución rápida. Cómo se puede saber el servicio que estaba desplegado en el momento del error? Factores empresariales como cambios en la estructura organizativa, fusiones o adquisiciones también pueden aumentar la complejidad de una arquitectura empresarial. Personas que previamente eran expertas en áreas específicas de funcionalidad empresarial pueden encontrarse trabajando en nuevos departamentos, lo que deja atrás un vacío de conocimiento institucional. Como consecuencia, las funcionalidades adicionales de las aplicaciones tienden a estar aglutinadas, lo que hace el servicio más complejo. Los Servicios Web fueron diseñados, en parte, para permitir inter operar transparentemente a los sistemas de una empresa con los de otra. Tradicionalmente, los sistemas de información han operado de forma independiente, gestionando sus propios datos y permaneciendo felizmente inconscientes de los demás sistemas dentro del entorno. La llegada de la tecnología basada en la Web y la necesidad

48 43 resultante de compartir datos de fuentes dispares condujo a la creación de enlaces de comunicación punto a punto entre las aplicaciones. SOA reemplaza los enlaces explícitos en el código con un enfoque de débil acoplamiento, aunque esto implica que, desde la perspectiva de gestión del rendimiento, debe ponerse más atención en los propios puntos de integración. La gestión del tiempo de respuesta también se hace más difícil cuando varias aplicaciones comparten un componente o servicio específico. Las diversas aplicaciones tienen diferentes requisitos de carga, se pueden desplegar nuevas aplicaciones en cualquier momento, y el administrador de servicios puede no ser alertado de un incremento en la utilización. El variante uso de la aplicación hace difícil planificar y predecir las características de la carga de servicio. Normalmente, los desarrolladores de un servicio no saben mucho sobre otro servicio, aparte de la información expresada en WSDL. Por tanto, normalmente no tienen medios para diagnosticar los problemas causados por un servicio Web concreto ni pueden identificar qué

49 44 servicio Web ha originado el problema. Esta falta de visibilidad es el mayor desafío en la mayoría de implementaciones de SOA y es uno de los retos que debe resolver una solución de gestión de servicios. A medida que las SOA se convierten en entornos de aplicaciones Web empresariales, la dificultad de gestionarlas y la necesidad de visibilidad de extremo a extremo de las transacciones crecen exponencialmente. El hecho principal es que SOA facilita la integración de los sistemas basados en estándares y los ya disponibles, sean internos o externos, lo que implica que las herramientas de gestión deben poder llegar a todos estos sistemas para redescubrir las relaciones y dependencias internas Integridad de las transacciones y conformidad de nivel de servicio Como las transacciones de cliente son el corazón del negocio, garantizar su integridad debe ser uno de los objetivos principales de la gestión del rendimiento de los servicios. En este extremo, los equipos de TI deben adoptar una propuesta integrada para hacer cumplir los acuerdos de nivel de servicio (SLA).

50 45 Esto incluye la supervisión del uso y actividad, así como la capacidad de proporcionar un sistema de alerta temprana que pueda predecir y evitar los problemas antes de que falle una transacción. Para garantizar adecuadamente la compatibilidad de los servicios Web con los SLA, una empresa debe definir primero los requisitos empresariales específicos y luego disponer los procesos y herramientas para supervisar y medir el rendimiento de los servicios. No es suficiente decir que quiero que mi servicio Web sea rápido. Se necesitan objetivos medibles específicos que se relacionen con el negocio, como tiempos de respuesta exactos o el número de usuarios simultáneos que pueden acceder a un servicio Web antes de que se ralentice. Para poder garantizar la integridad de las transacciones y el logro de los SLA, una solución de gestión de servicios efectiva debe notificar todas las transacciones de Servicios Web (peticiones y respuestas) y emitir alertas cuando cualquier condición de rendimiento se encuentre fuera de especificaciones. Mientras que la gestión de los niveles de servicio es crítica, la

51 46 naturaleza distribuida de los servicios hace que sea más difícil que nunca alcanzarla. Ya no es relevante expresar una métrica SLA como el rendimiento de un componente individual situado solo en un servidor aislado. Las SOA están diseñadas para permitir la interrelación de múltiples Servicios Web en un único proceso empresarial o transacción (por ejemplo cumplimiento de pedidos, índice de precios, ajuste de inventarios). Las soluciones de gestión del rendimiento de los Servicios Web deben ser capaces de proporcionar visibilidad a través de toda la transacción hasta su conclusión, desde el navegador a los sistemas back-end, garantizando que no se producen problemas a lo largo de todo el camino. Cómo obtener el control sobre los entornos de Servicios Web Una gestión efectiva del rendimiento de los Servicios Web debe ir más allá de proporcionar las capacidades disponibles con las soluciones de gestión de sistemas más tradicionales: supervisión y alertas, auditoría y notificación, gestión de SLA y análisis de las causas raíz. Según la discusión anterior, al elegir una solución de gestión para un entorno de Servicios Web deberán tenerse en cuenta diversas consideraciones especiales:

52 47 Los Servicios Web introducen una nueva capa de coordinación y, con ello, una nueva capa de complejidad. Los servicios se pueden cambiar de forma improvisada puntualmente. Es más flexible aunque más difícil de gestionar. Tanto los consumidores como los proveedores de Servicios Web deben contar con algún medio de medir y gestionar los niveles de estos servicios. Si varias aplicaciones comparten un componente de servicio particular, todas se verán afectadas si falla dicho componente. Unas herramientas de gestión efectivas deben poder llegar a todos los sistemas conectados El camino de la integración SOA es, en realidad, el final de un recorrido que debería comenzar con la integración de procesos corporativos. La visión de aplicaciones que han tenido durante las últimas décadas las empresas ha hecho, por ejemplo, que la gestión de negocios reflejada en el Enterprise Resource Planning (ERP) vaya por un canal diferente a la atención al cliente representada en la Administración de la Relación con los

53 48 Clientes (CRM). El concepto de EAI (Integración de Aplicaciones Corporativas) y los Servicios Web (servicios concretos que pueden ser accedidos a través de Internet) proponen una forma de acceder por una vía única hacia las diferentes fuentes de información y unificar los procesos internos de forma tal que denoten con precisión el flujo de negocios. Esta infraestructura de integración es la que provee la base real para poder extraer los servicios sobre los que se apoyará SOA, ya que es la única manera de poder lograr la lógica completa de negocios para cada tarea o actividad que se necesite realizar. Desde el punto de vista tecnológico, mencionábamos que SOA está basado en estándares y en mensajes. Esto le da a cada servicio una serie de ventajas, tales como son visibles independientemente del equipo cliente que los requiere o que son accesibles con altísima performance sin importar el ancho de banda que une al que dispara el requisito del lugar físico donde el servicio está alojado. El mensaje contiene toda la información relacionada con el proceso de negocios que atiende ese servicio. Por lo tanto, un simple intercambio de estos mensajes es suficiente para completar el servicio de manera

54 49 satisfactoria. En los siguientes artículos se explora la oferta existente de SOA, se analizan sus facilitadores y sus barreras y se estima para cuándo puede esperarse que este concepto explote en el país Que tiene de bueno Entre los principales beneficios de SOA se cuentan: Capacidad de reutilización de los servicios, lo que permite un time-tomarket más rápido y menores costos de desarrollo e implementación. Flexibilidad para lograr la integración de los diferentes procesos de negocios, gracias al uso de los mencionados estándares. Facilidad y agilidad para adaptar la funcionalidad de IT a los nuevos requisitos de negocios, porque sólo hay que modificar un servicio que se comporta de manera independiente, sin el riesgo inherente de generar modificaciones en otras áreas de la aplicación que afecten el rendimiento general o el resultado de otro proceso de negocios. Del mismo modo, provee una alta escalabilidad ligada a que el crecimiento relacionado con un proceso de negocios puede reflejarse de manera inmediata en el servicio.

55 50 El entorno de IT se comporta verdaderamente en tiempo real Latinoamérica un largo camino a SOA. La realidad de SOA en el mercado latinoamericano dice que recién se comenzó a andar el camino (expertos empresariales Ilustración 1.8). Algunas estrategias y enfoques clave para agilizar su desarrollo o, al menos, para no arrebatar a su empresa en el trayecto hacia la arquitectura orientada a servicios: cruda por dentro, quemada hacia fuera. Ilustración 1.8 Expertos Empresariales. Si se analiza el torrente de publicidades, seminarios, eventos de capacitación, encuentros y lanzamientos relacionados con SOA, la primera conclusión es que las empresas lo están adoptando a diestra y siniestra. Sin embargo, las cosas no siempre son lo que parecen. La sensación es que son pocos los proyectos concretos. Los vendedores hablan y se alinean en el discurso de SOA, pero representa un

56 51 cambio de filosofía muy grande y el mercado aún está inmaduro, afirma Juan José Argibay, Analista de Software y Servicios de IDC. La consultora llevó a cabo, a principios de año, un estudio de demanda entre 400 empresas. El 70% destacó tener una estrategia de EAI, estar implementando un middleware de integración u otras similares, pero lo cierto es que sólo el 12 por ciento mencionó que estaba adquiriendo software empaquetado para llevar a cabo esas transformaciones. Eso marca que SOA todavía no ha llegado, concluye Argibay. Para reforzar sus dichos, el analista indica que entre las grandes empresas, la integración de aplicaciones alcanza apenas el noveno lugar entre las máximas prioridades de IT. Marcelo Fernández, Software Practice Manager de Sun Microsystems para Latinoamérica Sur, indica que creo que existe un gran interés en el tema, a raíz del empuje que se ha realizado por los medios, que se nutre de la emergencia de estándares en torno a los Servicios Web y de los fundamentos que brinda el legado de los años de disciplina de EAI. Para Fernández, SOA viene a plantear la convergencia de estos campos y plantea nuevamente la promesa de la interoperabilidad.

57 Migrar hacia SOA paso a paso en América Latina Alejandro Cavaliere, Regional Manager para América Latina de BEA Systems, afirma que no existe un mandato tecnológico para migrar hacia SOA, sino una racionalidad estructural. Para explicar sus dichos, apela a una comparación: Por qué una ciudad debe tener autopistas y sistemas de transporte masivo? Una arquitectura orientada a servicios es análoga a la forma de solucionar los problemas de infraestructura de una ciudad: movilidad, flexibilidad, interoperabilidad, seguridad, retorno de inversión.... Néstor Camilo, SOA Program Director Strategic Account para América Latina de Oracle, afirma que Estamos trabajando hace unos cinco años con muchos clientes en este tema y, de esa experiencia, rescatamos éxitos y fracasos que nos han ayudado a desarrollar mejores prácticas en la implementación. Para Camilo, no puede hacerse cualquier proyecto en cualquier estadío de la organización. Oracle desarrolló un modelo de madurez con Accenture, en el cual se definen diferentes proyectos para distintos estadíos de la empresa. No se puede correr si no se ha gateado antes, sentencia (Daffra, 2007).

58 53 El primer paso, según este modelo, es desarrollar un Servicio Web para que lo pruebe el área de IT. Tal vez no sirva para nada, pero me permite avanzar hacia otros más complejos y que sí tengan sentido, como poner saldos en la web para que los consulten los proveedores, explica Camilo. empresa. Estos proyectos ayudan a descubrir el valor de la tecnología en la El siguiente paso es la integración. En el mundo de SOA, uno puede exponer los aplicativos a integrar como servicios. Y como se utilizan estándares, existe competencia con los adaptadores de integración, no como ocurría con EAI, que los adaptadores eran propietarios, remarca el directivo de Oracle. El tercer nivel sería el de orquestación de procesos: tomar los servicios de integración y armar un workflow de pasos para hacer, para tomar un ejemplo de una empresa de seguros, desde la cotización hasta la emisión de la póliza. BEA, por su parte, ha definido como estrategia de adopción el llamado Camino a SOA, que es un conjunto de programas formales de entrenamiento, adopción, migración y soporte.

59 54 En general, las empresas comienzan de una de dos maneras: por proyectos o por redefinición de arquitectura, define Cavaliere, para luego explicar que en cualquiera de los dos casos, BEA tiene un esquema de servicios para asegurar el máximo ROI en el Camino a SOA con el objetivo de que el cliente se independice tecnológicamente de los proveedores y pueda continuar construyendo sobre la nueva arquitectura en forma autónoma.

60 CAPITULO 2: LAS CUATRO P Y EL SOA SUN entiende que para lograr que el concepto funcione son necesarias las 4P : Personas, Prácticas, Procesos y Productos. Debido a la flexibilidad que se obtiene a través de SOA, es necesario contar con personas capacitadas que utilicen las mejores prácticas para la construcción de los niveles o capas que expongan los servicios de negocios que luego puedan formar parte de los nuevos procesos optimizados, indica Fernández, para luego agregar que toda esta actividad deberá estar soportada por productos que reflejen bien estos conceptos y eliminen las barreras de complejidad (Daffra, 2007). Uno de los principales temores que tienen las empresas que comienzan a andar este camino es el de tener que tirar a la basura las inversiones realizadas previamente. Fernández desmiente esta situación.

61 56 La plataforma contempla la integración de lo existente, recubriendo y reusando sus interfaces como una evolución de lo ya implementado. Mediante nuestros conectores es posible integrar en la nueva plataforma lo existente y plantear planes de convergencia de IT según conveniencia y con una estrategia balanceada que en todo momento permita la obtención de valor en plazos cortos, asegura. Qué tan profundo es el cambio de arquitectura? Depende de dónde esté para la empresa, indica Fernández, aunque aclara de inmediato que si bien pueden obtenerse beneficios inmediatos con la adopción de prácticas y herramientas de SOA, el refactoring de IT de la empresa será en el mediano o largo plazo, y será profundo, concluye. 2.1 Un Imenzo Market Mindshare Qué nivel de iniciativas tiene en curso o planea tener su empresa? Solución basada en Servicios Web (uso explícito de SOAP y/o WSDL) Iniciativa SOA a nivel de

62 57 aplicación o proyecto. Iniciativa SOA a nível departamental o regional. Iniciativa SOA a nivel corporativo Sólo mantenimiento En desarrollo Planificado en 12 meses Planificado en 24 meses Ilustración 2.1 Market Mindshare 2.2 Todos somos parte Corina Arostegui, del área de Global Architecture & Core Technologies de la consultora Accenture, afirma que la principal barrera en el avance de este nuevo concepto es que se necesita una nueva forma de pensar los sistemas, que impacta todos los roles: arquitectos, diseñadores, implementadores y ejecutivos de áreas de negocio (Daffra, 2007).

63 58 Aquellos que necesitan ver para creer pueden contar con el BPIC (Business Partner Innovation Center) de Itecsa, un laboratorio destinado a la exhibición, la demostración y la capacitación en soluciones de IT. Las empresas que quieren ser competitivas en el mercado actual necesitan innovar e implementar herramientas que le permitan un retorno sobre sus inversiones a partir de la resolución de los problemas de negocio. En este sentido, la tecnología SOA es una de las herramientas que más éxito ha tenido entre las empresas que han realizado migraciones en el último tiempo, en donde se integran personas, procesos e información, señala Mariano Di Rocco, Gerente Comercial de Software de Itecsa, mayorista monomarca de las soluciones de IBM. La versatilidad de las soluciones basadas en tecnología SOA se fundamenta en el hecho de que se trata de un concepto que es universal para todas las empresas y tiene que ver con la simplificación de los procesos de negocio, más allá del tamaño de la compañía, sostiene Di Rocco. 2.3 Quién soy? Dónde estoy? Otra de las principales barreras a atravesar para comenzar a implementar SOA es la confusión que enfrentan las empresas.

64 59 Es que, como casi siempre que aparece un nuevo concepto tecnológico, muchos vendedores aprovechan para llamar SOA a cualquier producto o servicio que estén vendiendo. Mollo afirma que si bien el interés es alto, también se detecta bastante confusión. En la actualidad, SOA es un término de moda que se utiliza para denominar muchísimas cosas, que van desde un portal hasta una integración sencilla. La capacidad de diferenciar la paja del trigo es, según el directivo de Consist, un buen punto para acercarse a la realidad SOA. El real interés es puesto a prueba cuando el propio interesado comprende que SOA no es un conjunto de tecnologías sino una estrategia en sí misma, asegura. Según Arostegui las empresas locales están tratando de entender cuál es la propuesta de valor detrás del concepto SOA (Daffra, 2007). Entre los temas que están en la agenda de los directivos, aparecen temas como interoperabilidad y reutilización hasta posicionamiento estratégico que le permitan un time-to-market acorde a las necesidades del

65 60 negocio. Están comenzando a realizar workshops de entendimiento, estudios de diagnósticos de su actuales arquitecturas (procesos, técnicas, aplicativos), identificación de drivers y elaboración de roadmaps para alcanzar los objetivos definidos a través de las iniciativas de negocio. Las barreras son, entonces, fundamentalmente de tipo cultural y están relacionadas con el desconocimiento del mercado respecto del concepto, de las herramientas disponibles y de la falta de madurez de SOA en casos de éxito en empresas. Nada que no pueda resolverse con una receta que ya ha dado resultados en el pasado entre los departamentos de IT: varios kilos de tiempo, una pizca de ganas, bastante compromiso de las áreas de negocios y mucha capacitación. Y, desde luego, el presupuesto para poder llevar el proyecto a cabo. 2.4 Lo nuevo dentro de lo nuevo Nunca hay una gran demora entre que aparece un nuevo concepto tecnológico y que los vendedores lo hacen evolucionar para buscar una diferenciación de mercado.

66 61 SAP propone una aproximación más de negocios con Enterprise SOA, mientras que Altiris apuesta a la administración de todo el proceso desde SOM (Administración Orientada a Servicios). Universo decididamente inquieto este de IT. Mientras el concepto de SOA busca echar raíces en las mentes de los directores ejecutivos de TI (CIOs) y de los ejecutivos de negocios, ya empiezan a florecer sucesores y mejoras. Detectamos que el concepto tradicional de SOA es necesario, pero no suficiente, dispara Gustavo Trivelli, Strategic Solutions Director para América Latina de SAP. La empresa diseñó el concepto de Enterprise SOA, que utiliza la plataforma NetWeaver y el concepto de arquitectura orientada a servicios para facilitar su adopción. Lo que hacemos es transformar los Servicios Web en Enterprise Services, que implica que son servicios con mucha mayor semántica de negocios apunta Trivelli. Esto hace que una persona que tenga los procesos de negocios de la empresa en mente pueda acceder a estos servicios, modelarlos y adaptarlos a nuevas necesidades sin necesidad de que sepa de tecnología. Según Trivelli, las empresas que inician su recorrido en el mundo de

67 62 SOA con la aproximación tradicional, deben comenzar a trabajar desde cero, mientras que aquellas que optan por el approach de SAP tienen entre un 50 y un 60 por ciento del camino resuelto. Por otra parte, y siempre según el ejecutivo de SAP, las tarjetas que dicen CIO parecen tener el destino de ir a parar al mismo cajón que las que decían Gerente de Sistemas. Creemos que tiene que surgir un cambio radical en el área de IT, con la aparición del CPIO, Chief Process Innovation Officer, indica Trivelli, quien asegura que pueden esperarse casos interesantes en el corto plazo, no a nivel masivo, pero sí entre los early adopters.

68 CAPITULO 3: LA ERA DE LA M El gran esfuerzo de los proyectos SOA está puesto en lo que son las aplicaciones de negocios, pero eso necesita de una gestión eficaz y adecuada, cuenta Marcelo Lava, Regional Director de Altiris, empresa especializada en soluciones de administración del ciclo de vida de IT. La propuesta de la compañía, entonces, es SOM, Administración Orientada a Servicios. Así como las distintas funcionalidades del ERP o del CRM pueden exponerse como servicios, nuestra propuesta es que las necesidades de administración de IT y de infraestructura también puedan seguir ese mismo camino, agrega Lava. Gestión de archivos, distribución de nuevas versiones y desarrollo de backups son sólo algunos de los servicios que ingresarían en esta categoría. El objetivo de Altiris, entonces, es convertirse en un facilitador a la hora de alinear todos los proyectos de IT de la empresa de cara a SOA.

69 64 Nuestro horizonte es que recién en 2007 se comience a trabajar en estos proyectos, estima Maxi Jacoboski, Systems Engineer de la compañía. SOA dejó de ser una teoría lejana para convertirse en la nueva preocupación de corto plazo que ronda en las cabezas de los ejecutivos de IT de todo el mundo. Las empresas tienen la posibilidad histórica de dejar de lado las aplicaciones cada vez más complejas y decidirse a que, por primera vez, la informática se ponga, de verdad, a su servicio. 3.1 IBM Argentina y sus "10 años" con SOA Silvia López Grandío, gerente de Software de IBM Argentina (Ilustración 3.1), afirma en esta entrevista que la Gigante Azul es pionera en el mundo de las arquitecturas orientadas a servicios, concepto con el que la empresa estaría trabajando desde hace diez años, aunque no lo llamábamos SOA, sostiene la ejecutiva. Además, Grandío afirma que si bien el cambio es importante, puede hacerse de manera escalonada.

70 65 Ilustración 3.1 Silvia López Grandío, gerente de Software de IBM Argentina. Muchas veces, el marketing impone ciertas reglas para posicionar un producto (una solución en este caso), y la verdad es que lo que principalmente está haciendo es reagrupar lo existente bajo otro nombre para accionarlo en algo nuevo, original, más llamativo. Algo similar es lo que piensan en IBM con respecto al SOA. En el edificio de la Big Blue, se atribuyen ser SOA desde hace una década, aunque en este caso el concepto que trae el marketing también imponga ciertas pautas que sí son nuevas. La verdad es que en IBM manejamos el concepto de SOA desde hace diez años, aunque no lo

71 66 llamábamos así. Son ideas como la de adaptabilidad on demand. Esto hizo que hoy seamos de las pocas empresas del mercado que tienen herramientas concretas para ofrecer para este segmento y, entre otras cosas, que el market share de IBM a nivel global en SOA sea del 46 por ciento, afirma Silvia López Grandío, gerente de Software de IBM Argentina. - En estos diez años... cuánto ha avanzado la cultura del cliente para incorporar SOA? - Una de las cosas logradas es que la idea está en la cabeza del CIO. El mercado está abierto a escuchar. Hasta ahora hay pocos clientes, pero son muchos los que están en camino. - Cómo se establece el cambio hacia SOA? Qué tan grande es el abismo que una empresa tiene que saltar para implementar esta arquitectura? - No necesariamente tiene que ser un cambio radical. Puede empezarse con poco. Muchas empresas están volcando sólo los procesos críticos a este nuevo modelo, hacia allí están dirigidos la mayoría de los pilotos con los que estamos trabajando. Igualmente, no se trata de tirar a la basura lo que se tiene, sino de tomar las mejores cosas y adaptarlas. - Cuál es el plazo para que empecemos a ver empresas

72 67 argentinas SOA? - Lo cierto es que cambiar toda la arquitectura es algo que requiere tiempo, por lo que tenemos que pensar en algo más de un año. Estamos en la primera etapa, que es la que requiere una dedicación más prolongada: la organización, la detección del conocimiento... Sin embargo, una vez que se atraviese este momento, los resultados se obtendrán de manera muy rápida. - Y entre las pymes? - Hoy podemos decir que no. De todas formas, las pymes ya deberían estar trabajando en la integración de sus aplicaciones, que es, de cierta manera, un paso necesario para llegar a SOA. 3.2 Las empresas argentinas están adoptando poco a poco SOA Las primeras implementaciones en el país se registran en bancos y cadenas de retail. Es una estrategia que permite bajar los costos de una empresa, generar nuevos ingresos y salir a responder con más rapidez a las oportunidades que plantea el mercado.

73 68 Desde hace un par de años comenzó a difundirse en el mercado de la Tecnología de la Información (TI) un concepto con mucha fuerza de marketing pero débil en la cantidad de casos concretos de implementación: La Arquitectura Orientada a Servicios. De qué se trata? Es una forma de ver los procesos de negocio como un conjunto de servicios vinculados. El objetivo que se busca es las operaciones de la empresa sean más eficientes, eficaces y fluidas. Cuando los procesos de negocios se construyen sobre una base de SOA, una empresa puede lograr que sus datos y aplicaciones de software, que permanecían aisladas, pueda interoperar mejor entre las distintas unidades de la compañía y también con terceros externos (Reynoso, 2005). Este enfoque de SOA funciona como una palanca para los recursos existentes, para que puedan contribuir a mejorar la productividad, reaccionar con rapidez a las condiciones cambiantes del mercado y aprovechar las oportunidades que se presentan. SOA no es un software nuevo sino un cambio en la forma de ver los

74 69 sistemas de TI de una empresa, porque los convierte en servicios disponibles para quien los pida. A que se le llama servicios? Reciben este nombre los componentes del sistema que gracias a SOA se pueden reutilizar, emplear y mantener con facilidad. Pero hay una condición necesaria para implementar SOA en una empresa, y por la cual se retrasa la adopción de esta estrategia en el mercado: la integración de los procesos corporativos. Y para conseguirla hay que recorrer un largo camino. Argentina dentro de su transformación de una empresa de productos de TI a otra de servicios, IBM le presta mucha atención a SOA, al punto de dedicarle el año pasado unos mil millones dólares en inversión y a entrenar a más de 100 mil personas en esta estrategia y a tener unos 3 mil socios de negocio, siete de ellos radicados en la Argentina. En una entrevista exclusiva con infobaeprofesional.com durante su última visita a la Argentina, Rafael Gallegos, gerente de Ventas de WebSphere para la región sur de Sudamérica y responsable de liderar las tareas de marketing y ventas de SOA para la región, informó que en la

75 70 Argentina ya hay clientes del Gigante Azul con implementaciones de SOA, aunque admitió que continúa en ritmo lento la adopción de esta visión. En la Argentina hay más de 20 y en la región latinoamericana, alrededor de 190. Las empresas están poco a poco adoptando esta estrategia. En la Argentina ya estamos en proceso de implementaciones. Dónde? Gallegos dijo que en el mercado financiero y también en ciertas empresas del sector retail y en el industrial. A partir de esos contratos, IBM ayuda a los clientes a definir sus prioridades y luego colabora en el diseño del proyecto para su ejecución. Hemos arrancado con empresas de rango medio y alto, porque son las que tienen un punto de entrada más sencillo para esta estrategia, reconoció. Sin embargo, informó que en 2007 intentarán bajar las barreras para las empresas mucho más pequeñas, porque también son candidatas a adoptar este tipo de estrategias. Cuáles son los beneficios que promete SOA para las empresas? Primero, la reducción de costos: El segundo, el incremento de sus ingresos. Y el tercero, se maximiza el poder de innovar y generar nuevas

76 71 soluciones mucho más rápidas, enumeró el ejecutivo. En 2004, IBM hizo un estudio entre los principales 150 CIOs del mundo acerca de sus diferentes prioridades. Otra investigación de IBM señala que un 90% de las empresas que arrancaron este proceso lo hicieron por reducción de costos pero 50% de ellas se dieron cuenta que luego de implementarlo hubo un incremento de sus ingresos. Implementación.- La implementación de SOA requiere un proceso que obligó a IBM a relanzar en dos ocasiones en el último año su paquete de servicios, debido al propio aprendizaje que debió realizar la multinacional. IBM habla de SOA desde hace dos años. Durante el primer año empezó a ver prácticas y conocimientos y a estudiar las necesidades. En abril de 2006 se hizo el primer cambio de estrategia, pero después hubo otros nuevos ciclos de aprendizaje, y el último relanzamiento se hizo el 20 de octubre. Las causas de tantos cambios fueron que los servicios básicos que

77 72 teníamos no eran lo suficientemente adaptados a la necesidades de los clientes. El análisis previo a SOA comienza por considerar las necesidades del negocio, porque son las que van a determinar cómo se debe adaptar la estructura de TI de la empresa. Luego hay que determinar la arquitectura y la infraestructura que la compañía tiene disponible para poder darle esos servicios al negocio. prioridad. Una vez cumplida esta etapa, la empresa debe determinar su Gallegos explicó que los puntos de entrada a un proceso de SOA se refieren a las personas y sus herramientas de trabajo; a la información para la toma de decisiones; y a BPM (Administración de Procesos de Negocio). La principal barrera que tenemos es entender claramente el negocio de nuestros clientes y que ellos entiendan que el valor que le aporta la tecnología. Es el reto que tenemos. La otra barrera es ayudar a definir las prioridades del negocio de TI del cliente.

78 IBM sugiere explicar la rapidez de activar los negocios con SOA Para poder aplicar SOA el problema de integración es básico. Hoy las empresas, en general, son más cuidadosas en el budget de IT. Así que IT necesita las justificaciones de negocio. Con SOA la tiene: poder decirle al budget que integrando los servicios va a poder activar los negocios en forma más rápida. Rafael Gallegos, gerente de Ventas de Websphere IBM Software Group (SSA Spanish South America). 3.4 BEA argumenta que la industria ya aplica SOA sin saberlo SOA es una evolución, no una revolución, pero debe realizarse correctamente. En la práctica, la gente hace SOA sin saber que lo está haciendo: cuando integra dos aplicaciones, cuando unifica el bus de datos interconectándolo con SQL o cuando utiliza CORBA (Common Object Request Broker Architecture). BEA dispone de un departamento para difundir esto y facilitar la tarea

79 74 de explicarlo al responsable del presupuesto. Rob Levy Executive Vice President Chief Technology Officer de BEA. 3.5 Sun: SOA ahorra al no gastar más en reparar reparaciones La inversión en tiempo, dinero y recursos para SOA es importante. Pero hay que mirar el otro lado, el costo que significa para el departamento de IT vivir reparando incidentes y problemas que terminan generando cambios anárquicos que al solucionarse generan diez más. Yo digo que esto a las empresas las lleva a dedicar el 200% de sus horas hombre a solucionar problemas generados por las soluciones a problemas. Porque con las horas normales no alcanza, la gente propia tampoco y se termina pagando consultoría y contratando recursos adicionales. Nada de eso genera valor. Arreglar un incidente no genera valor.

80 CAPITULO 4: CICLO DE GOBIERNO DE SOA SEGÚN IBM El ciclo de gobierno de SOA con el que IBM esquematiza el procedimiento de funcionamiento SOA se divide en cuatro pasos que se realimentan: Modelaje, Construcción, Implantación y Monitoreo. 4.1 El caso de una telco que comenzó SOA por el call center, con IBM Tenemos una telco que tiene 4 millones de líneas fijas, con un promedio de llamadas diarias al helpdesk y el operador debía navegar por 15 pantallas. Ahí, el puerto de entrada a SOA fue bajar el tiempo de atención de un reclamo, que pasó de 3 o 4 minutos a 1,5. Bajamos el tiempo del proceso.

81 76 Actuamos contra la aplicaciones de CRM, y la forma en que se consultaban las aplicaciones con un mainframe de por medio. Fue un trabajo de síntesis de pantalla. Con esto justificamos la integración de IT. Rafael Gallegos, gerente de Ventas de Websphere IBM Software Group (SSA Spanish South America). 4.2 BEA sugiere los pasos para iniciar un proyecto gradual SOA por el bus Creo que lo más lógico es comenzar por el bus. Hay un data bus y un message bus. En el primero caso, la conexión es por las fuentes de datos, mientras que el segundo es transformación de middleware. Luego comienza a escribir el bus para conectar en Servicios Web. Cuando ya lo hizo puede comenzar a realizar BPM o portal para la visualización y la conformación de metadata.

82 77 dispersas. El bus de data está orientado a cuando hay muchas bases de datos componerlo. Si se quiere sacar un perfil de cliente, debe ir a cada una y El de mensajes a que las aplicaciones hablen unas con otras. A partir de que se tienen todos los componentes unidos pueden hacer aplicaciones compuestas. Rob Levy, Executive Vice President Chief Technology Officer de BEA Systems. 4.3 Sun opina que SOA comienza al aplicar mejores prácticas sistemáticamente No es algo que se haga en 24 horas y verlo desde el punto de vista tecnológico es un error. No es tajante la respuesta, habría que ver cada caso en particular. Para iniciar un proyecto SOA sería conveniente acompañarlo de modelos como Itil, SunTone u otro de buenas prácticas. La aplicación de buenas prácticas permite definir etapas intermedias en las que se logran beneficios porque se van escalando el tiempo.

83 78 Sun, además de productos específicos, cuenta con la especificación SunTone, un conjunto de mejores prácticas para llevar a una implementación de SOA exitosa. Fernando Villalba, consultor senior de Servicios Educacionales Sun Latinoamérica Sur. 4.4 SOA busca conducir la IT desde el negocio, según IBM El Websphere Business Monitor tiene un tablero de control que le da al cliente la posibilidad de ver los procesos en tiempo real, si tiene cuellos de botella, cómo se están cumpliendo los KPI (Indicadores Clave de Procesos). También permite poner alarmas. Y como negocio, no como IT, tomar acciones en los procesos. Las reglas de negocio se cambian en línea. Ese es el valor de monitorear el proceso. Rafael Gallegos, gerente de Ventas de Websphere IBM Software Group (SSA Spanish South America). 4.5 BEA y los lazos de realimentación en cada paso de SOA Se tiene los productos pero falta cerrar el ciclo de monitoreo. Una de las limitaciones del modelaje es que no hay un lazo de realimentación. Lo que se quiere hacer es que cada proceso sea un loop.

84 79 El modelaje cumple un ciclo de Requerimientos de negocios, Arquitectura, Diseño, Codificación y Testing. Cada uno de ellos, a su vez, tiene un loop. En función de un requerimiento de negocios, uno va a poder ir hacia abajo, hasta que encuentra la capa en que realiza un cambio. Luego sube hasta cambiar el modelo. Hoy el resultado no se ve en cada estado sino cumplido el ciclo completo. Actualmente, las aplicaciones son millones de líneas de código. Si quiere hacer un cambio, toma un pedazo, hace el cambio, lo reintroduce y testea todo. En SOA no hay más aplicaciones sino pedazos conectados por procesos de negocios. Un mismo componente puede estar en varias aplicaciones y si se cambia un componente cambia en todas las aplicaciones. Esto se vuelve más atómico, más pequeño. Antes el ciclo de vida correspondía a toda una aplicación, ahora a un simple Servicio Web.

85 80 La evolución de cada una de las partes hace evolucionar el conjunto. Rob Levy, Executive Vice President Chief Technology Officer de BEA Systems. 4.6 Al aplicar SOA, según IBM, las telco evitarían comprar costosos paquetes Si como telco descubro que me falta una pieza del rompecabezas, al trabajar con SOA no necesito salir a buscar el gran paquete. Salgo a buscar el componente que necesito. Además, quizás los pueda desarrollar y no me veo obligado a pagar US$ 50M o US$100M que es lo que cuesta un feature para agregar al sistema de billing. Rafael Gallegos, gerente de Ventas de Websphere IBM Software Group (SSA Spanish South America). 4.7 BEA explica cómo armar de a poco un entorno SOA desde el legacy de catalogo. Retire una pieza de legacy o del CRM y vaya armando un repositorio

86 81 Cuando tiene suficientes, puede construir composite apps y composite elements, un catálogo de apps y elementos. Luego, habrá que mudarlos a una nueva plataforma. Hay dos caminos. No hacer nada y siempre serán cerrados o ir tomando pedacitos de los legacy, encapsularlos, de modo que dentro del aplicativo original luzcan como siempre, pero vistos desde afuera tengan la apariencia de un Servicio Web. Ese componente pasa a jugar en el cuadro de SOA. Así, se sigue con todos, hasta que los legacy no se usen más. costoso. La ventaja es que no hay que cambiar todo de golpe, algo que es muy 4.8 IBM plantea cómo convive en SOA con las telcos que usan SAP Con SAP tenemos diferenciadores fuertes, así como también ellos tienen otros con nosotros. Pero nuestra ventaja más fuerte es el tiempo, la experiencia de más de 15 años en este negocio.

87 82 Los analistas dicen que llevamos dos o tres años sobre los demás y seguimos invirtiendo. Creo que esa diferencia es algo que vamos a mantener. Para un cliente en el que el 90% de su entorno es SAP es lógico que su alternativa hoy sea Netweaver. Pero en tanto empieza a cambiar, y la mayoría de las telcos con que trabajamos usan SAP y la decisión no fue Netweaver. Netweaver para SAP, pero para el backbone Websphere. Rafael Gallegos, gerente de Ventas de Websphere IBM Software Group (SSA Spanish South America). 4.9 Polémica entre BEA, SAP y Oracle sobre convivencia en SOA Oracle y SAP creen en una solución integrada, todo en una única caja. Microsoft, BEA e IBM creen en muchas soluciones integradas por SOA, incluso con las anteriores. Ellos prefieren la base de datos, las aplicaciones, los procesos de negocios y la administración en una caja. El otro grupo dice SOA es lo que usted debe implementar.

88 83 Es tomar una pieza de Oracle, SAP, un in house o legacy, o algo nuevo, con Servicios Web. Creemos que esto es heterogéneo y lo otro homogéneo. Está la gente OR y la AND. No es Java o.net sino Java y.net. (Rob Levy, Executive Vice President Chief Technology Officer de BEA Systems) La consideración de SOA como de alta prioridad pasó de 28% en 2005 a 36% en 2006 Más allá de la fuerte presión de marketing para imponer productos, la Arquitectura Orientada a Servicios resulta una salida para los sistemas informáticos en consonancia con que tienen que ser comandados desde las necesidades de negocios. En esta primera entrega sobre el tema, Telcos IT refleja los puntos de vista básicos señalados por tres de los principales protagonistas de este mercado: IBM, BEA Systems y Sun Microsystems. Según InfoWorld, mientras que en 2005 SOA fue considerado una "prioridad crítica" para los próximos doce meses por 14% de sus consultados, en 2006, la misma muestra lo elevó a 17%.

89 84 En la categoría "alta prioridad", el indicador subió de 28% a 36% y en el de "prioridad moderada", de 28% a 32%. Esto muestra que SOA gana consenso a paso firme (Ilustración 4.1). Ilustración 4.1 Evolución SOA en 2005 y PROTAGONISTAS (Ilustración 4. 2)

90 85 Rafael Gallegos Gerente de Ventas de Websphere Software Group (SSA Spanish South America) IBM Rob Levy Executive Vice President Chief Technology Officer BEA Systems. Fernando Villalba Consultor senior de Servicios Educacionales Latinoamérica Sur Sun Microsystems. Ilustración 4.2 Protagonistas.

91 CAPITULO 5: MARKET SHARE 5.1 Encuesta cualitativa sobre liderazgo a la hora de pensar en SOA En una encuesta realizada por InfoWorld, proporcionada a TelcosIT por BEA Systems, se le pregunta (a una cantidad no especificada de gerentes de sistemas) qué compañías piensan que son las líderes en SOA. Las respuestas, de tipo múltiple, arrojan que BEA fue mencionada en 74% de los casos. Los resultados completos son los que siguen: BEA 62%. IBM 62%. Microsoft 40%. Oracle 38%.

92 87 Sun 33%. Tibco 24%. Sonic 20%. WebMethods 20%. SAP 15%. Systinet 14%. 5.2 Réplica de Sun al Share que ubica a BEA al tope de SOA Esta encuesta está relacionada con la percepción. Alguien que ataca sólo al nicho de SOA no es lo mismo que otro con una cartera más amplia. A estas últimas les cuesta más posicionarlas para que se las asocie con SOA. Fernando Villalba, consultor senior de Servicios Educacionales Sun Latinoamérica Sur.

93 Conceptos básicos para comenzar a entender SOA, según IBM Simplificado al máximo, un modelo de tres capas que aplicamos en IBM permite estructurar a SOA en un primer nivel denominado BUS, para el intercambio de información entre las diferentes aplicaciones (ERP, CRM, Billing -para el caso de las telcos-, sistemas de marketing, provisionamiento y demás). Un segundo nivel de PROCESOS, donde se definen los servicios. Y un último, NEGOCIOS, que se ubica sobre los demás y es el lugar donde se modelan los procesos. 5.4 Complemento de BEA al modelo de tres capas para SOA de IBM. capas. En líneas generales, el esquema coincide con un modelo de tres partes. Pero las aplicaciones rumbo a SOA deben fragmentarse en pequeñas

94 89 La capa de BUS debe dividirse en Datos, Mensajes y otras prestaciones, como Seguridad. La intermedia, la definimos como de VISUALIZACIÓN y comprende Gestión de Procesos de Negocios y Portales. Finalmente, a la superior y principal la denominamos de COMPOSICIÓN y sus funcionalidades son las de modelado y creación. 5.5 Sun resalta la integración de la gente en SOA y aporta su modelo. En Sun agregamos que es necesario tomar en cuenta que entre las capas mencionadas debe intercalarse la participación de personas que interactúen con servicios y con procesos. Porque todo ello forma parte de la arquitectura empresarial. Fernando Villalba, consultor senior de Servicios Educacionales Sun Latinoamérica Sur. 5.6 Gartner Vaticina respecto a SOA Dentro del marco de su VIII Conferencia Anual Future of IT: la Justificación Económica de la TI, celebrada en la Ciudad de México, Gartner

95 90 presentó las principales tendencias de crecimiento de este mercado en Latinoamérica. Durante su exposición, Donald Feinberg, Vicepresidente y Analista Distinguido de Gartner, explicó los aspectos que influyen en la madurez tecnológica de la región, así como la tendencia de crecimiento que América Latina tendrá en los próximos años. La industria de T.I. en América Latina crece a un ritmo cercano al 7%, lo cual la convierte en la segunda región en ritmo de crecimiento de T.I. en el mundo, detrás de Europa del Este. Entre las tendencias de T.I. que Gartner ve con mayor proyección hacia los próximos años, está SOA. A veces, una tecnología o producto sólo necesita un pequeño disparador para catapultarse hacia la fama. Pero otras veces nunca logra la aceptación del mercado. Para saber de antemano qué tendrá futuro y qué no, Gartner desarrolló su Hype Cycle, o ciclo de promoción exagerada, para predecir si determinadas tecnologías irán a parar a nuestros bolsillos, oficinas o livings o al cementerio donde ya descansan varios proyectos fallidos. Según un vicepresidente de investigación de Gartner, David Cearly, la Arquitectura de Próxima Generación constituirá la tercera gran era de la

96 91 historia de la industria IT (la primera fue la del hardware y la segunda la del software), la tecnología SOA sería uno de los pilares. SOA usa componentes interactivos de negocios diseñados para ser significativos, usables y útiles a lo largo de los límites de la empresa y de las aplicaciones. A pesar de una temporal desilusión con SOA, Gartner dice que crecerá y madurará en los próximos diez años, aunque eso requerirá muchos cambios tanto en los usuarios como en los vendedores. Asimismo de acuerdo con otros estudios realizados por Garter la próxima ola masiva de innovación y demanda por TI comienza en el 2007, como se puede observar en la Ilustración 5.1:

97 92 Ilustración 5.1 Innovación y demanda por TI. Los avances de tecnología, la agilidad en los negocios, procesos adaptativos impulsados por eventos, requieren un modelo de entrega de servicios para las aplicaciones. De acuerdo a los estudios realizados por Gartner, en el año 2007 se inicia el desarrollo de aplicaciones de próxima generación, nuevas aplicaciones y servicios ampliamente disponibles para configurar procesos compuestos, fusionados. Asimismo, prevé que hasta el año 2011 existirá una amplia disponibilidad de aplicaciones tradicionales envueltas en SOBA-enabled, y nuevas capacidades de las aplicaciones impulsaran la innovación de proceso. Asimismo, Gartner vaticina que la Arquitectura Orientada al Servicio (SOA), hacia 2008 "proporcionará la base del 80% de todos los nuevos proyectos de desarrollo, y permitirá a las empresas aumentar la reutilización de código en más del 100%". La ilustración 5.2 presenta una revisión retrospectiva y proyectada del desarrollo de la Tecnología de la información desde el año 2003 hasta el año 2011 realizado por Gartner.

98 93 Ilustración 5.2 Revisión retrospectiva y proyectada del desarrollo de TI. Según un reciente estudio de Gartner, la nueva iniciativa de SAP, Red de Valor para la Industria Bancaria, impulsará la adopción de Arquitecturas Orientadas a Servicios (SOA) en la Banca. El informe indica que los bancos que busquen la agilidad corporativa que puede ofrecer una Arquitectura Orientada a Servicios pueden considerar esta iniciativa como un buen primer paso. Gartner recomienda a los bancos con una política agresiva en materia de tecnología, considerar seriamente ser parte de la Red de Valor para la