Incrementando la flexibilidad empresarial a traves de la arquitectura orientada a servicios (SOA)

Edición 1

Impacto en el negocio de la arquitectura orientada a servicios (SOA)

SOA o la flexibilidad que demanda el negocio www.ibm.com En la continua búsqueda de la innovación por parte de las empresas, la tecnología puede ser o no un elemento facilitador. Lo será si está dotada de la flexibilidad necesaria para transformarse y adaptarse al ritmo que requiera el negocio. Pero, ¿qué significa flexibilidad de la tecnología? Significa capacidad de respuesta de la tecnología a las exigencias del negocio, sin “peros”, sin excusas, sin pretextos. Factores como la descomposición de las aplicaciones de negocio en “servicios” individuales, la estandarización tecnológica o la virtualización de la infraestructura representan la esencia de la arquitectura SOA (Service Oriented Architecture), entendida como un nuevo paradigma de los sistemas de información, cuyo principal valor es que permite que el área de TI responda de modo flexible a las necesidades de cambio del negocio y que éste perciba a las TI como una ventaja competitiva sobre la que apoyarse para llegar mejor al mercado. David Soto

Utilizando una analogía sencilla, SOA transforma las aplicaciones empresariales en piezas de lego, capaces de encajar en cualquier configuración posible y reutilizables para diferentes construcciones. Además, la propuesta de valor de SOA para el negocio se completa con la capacidad que tiene de reducir los costes de esta adaptación al cambio. En el mercado existe consenso sobre la necesidad de “fusionar” la tecnología con el negocio. SOA logra esto aportando a la tecnología un componente diferencial: la flexibilidad y agilidad necesarias para responder a las necesidades de negocio en el momento en que se producen. La rapidez, la agilidad e, incluso, la previsión son las ventajas competitivas que llevan a una empresa al éxito.

“SOA transforma las aplicaciones empresariales en piezas de lego, capaces de encajar en cualquier configuración posible y reutilizables para diferentes construcciones.”

Con una arquitectura SOA, las empresas pueden contar con estos atributos. Por todo esto, la adopción de SOA debe plantearse como una iniciativa estratégica, que requiere el liderazgo directo del CIO y que debe contar con el soporte explícito del consejo de dirección.

~ David Soto David Soto Vicepresidente - IBM Global Business Services España, Portugal, Grecia, Israel y Turquía

En esta edición

Atracción de la investigación de

Cómo pueden los CIOs impulsar el negocio a través de un modelo de TI flexible y orientado a servicios Ser flexible para innovar y crecer Flexibilidad del modelo TI La importancia de los estándares Orientar una Organización a servicios ¿Cómo empezar? Escenarios de valor para la adopción de SOA Conclusión Gartner: El impacto que tiene en el negocio la arquitectura orientada a servicios

2 2 2 3 4 5 6 7 8

Cómo pueden los CIOs impulsar el negocio a través de un modelo de TI flexible y orientado a servicios

Ser flexible para innovar y crecer Las empresas saben que la flexibilidad es uno de los principales impulsores del crecimiento empresarial y es fundamental para habilitar la innovación en las compañías. La capacidad de crear ideas mediante la colaboración debe ser acompañada por las capacidades necesarias para hacer realidad los nuevos conceptos. En este sentido, la flexibilidad es necesaria para habilitar una respuesta más ágil a las tendencias del mercado, una mayor satisfacción de los clientes y una reducción de los costes de desarrollo de productos y servicios. En un entorno en que la actividad de las empresas y sus procesos de negocio están fuertemente vinculados a la tecnología, la consecución de una flexibilidad “tecnológica” se convierte en un tema fundamental en las estrategias empresariales. Flexibilidad del modelo TI Pero, ¿Qué significa flexibilidad de la tecnología? Es su capacidad para transformarse y adaptarse al ritmo que requiere el negocio, de un modo ágil y con el menor coste posible. Significa capacidad de respuesta de la tecnología a las exigencias del negocio, sin “peros”, sin excusas, sin pretextos. Para ilustrar cómo la tecnología puede ser más flexible, piénsese en un juego de construcciones. Imagínese que el modelo de negocio objetivo es representado por un coche real, con todos los detalles y elementos diferenciadores visibles, y que las capacidades que una organización dispone para implementar este modelo es un juego de construcciones con piezas encajables. Cuanto más se asemeje la construcción al coche, mejor se estará sustentando el modelo de negocio objetivo.

2

Si el juego dispone de unas pocas piezas grandes (como los juegos de construcción para niños de primera infancia) podremos modelar algo que tendrá cierto parecido con el coche real, pero apenas podrá mostrar la riqueza de detalles del coche, y dará igual si éste es un deportivo o una berlina, porque el juego de construcciones no permitirá diferenciarlos. Si el juego es más avanzado y ofrece un número mayor de piezas mucho más pequeñas (como los juegos de construcción para adolescentes o adultos), el modelo que se podrá construir va a parecerse mucho al coche real; se podrán apreciar los detalles y se podrá reconocer si el tipo de coche que se ha modelado es un deportivo o una berlina, e incluso si tiene tres o cinco puertas. Del mismo modo, si el modelo de TI se basa en aplicaciones más o menos monolíticas (piezas grandes), la flexibilidad para adaptarse a los cambios del modelo

de negocio y la capacidad para sustentar rápidamente matices diferenciadores del negocio en los sistemas nuevos, va a estar comprometida. Podría decirse que el negocio percibe la función TI como un “mal necesario” y no se espera esta que proporcione capacidades competitivas, más allá de las necesarias funciones de soporte del negocio: no importa si el coche es un deportivo o una berlina. Sin embargo, si el modelo de TI puede asemejarse al juego avanzado, con muchas piezas pequeñas que pueden recombinarse según cambia el modelo de coche, el negocio tendrá la capacidad de adaptarse al mercado y la función TI responderá de un modo flexible. El negocio percibirá a la TI como una ventaja competitiva y se apoyará en ella para llegar mejor al mercado. Cuando el modelo de TI se basa en servicios (piezas pequeñas) se tiene un modelo TI flexible.

...continuado

Es justo aquí donde SOA entra en juego. Con toda seguridad, a estas alturas, habrá oído hablar de SOA. Además seguramente se habrá dado cuenta de que el término SOA se utiliza en distintos, quizás demasiados, contextos. Se habla de infraestructuras SOA, de aplicaciones SOA, de productos SOA, y están bien, pero muestran una visión incompleta de lo que SOA realmente significa para el modelo de TI y, por extensión, para una organización. Lo que SOA realmente significa en este contexto, es la orientación a servicios, el poder pasar progresivamente del juego de piezas grandes al de piezas pequeñas. No obstante, para llegar a modelar algo con piezas pequeñas se requieren muchas más piezas que para modelar algo con piezas grandes. Y el juego de muchas piezas es un juego avanzado, y requiere que el jugador, la organización TI, esté preparado para gestionar un mayor número de piezas pequeñas. Posiblemente necesitará un

manual de instrucciones, mayor destreza, manos más expertas, mayor capacidad espacial…

Es en este contexto donde los estándares, tecnológicos o de sector aportan su verdadero valor.

Así pues, cambiar de juego, orientarse a servicios, va a permitir una mayor flexibilidad al disponer de piezas más pequeñas, pero va a requerir una mayor habilidad para combinar tantas piezas con la mayor fidelidad al modelo y en el menor tiempo posible.

De este modo, cuando la tecnología se estandariza se fomenta la interoperabilidad técnica de componentes. Por ejemplo, sin estandarización las telecomunicaciones, tal como hoy las entendemos, jamás habrían sido posibles.

La importancia de los estándares La flexibilidad que proporciona la recombinación de servicios para crear nuevas capacidades, puede verse comprometida si existen dificultades técnicas, o de cualquier otro tipo, para combinar efectivamente los diversos servicios requeridos. Sería el caso de encontrar dos piezas adecuadas que no encajan entre sí, la combinación no es posible o requiere costosas adaptaciones.

En el mercado actual de los sistemas de información, bajo las siglas SOA, existe un modelo de estándares para la definición de servicios que permite una interoperabilidad de los mismos más allá de implementaciones y plataformas tecnológicas concretas. Estos estándares permiten “encajar” con facilidad servicios implementados internamente en la organización con servicios proporcionados por colaboradores de negocio u otros proveedores externos. Por si fuera poco, la interoperabilidad tecnológica se ve reforzada por los estándares del sector que homogenizan una misma semántica de negocio dentro de una industria o estandarizan protocolos de intercambio de datos de negocio. De hecho, algunos sectores han llegado al punto de publicar versiones SOA de sus estándares (por ejemplo, el sector de banca y el financiero con “Interactive Financial Exchange”, y el sanitario con “Health Level 7”). La flexibilidad que proporciona el modelo de orientación a servicios junto con la doble estandarización, técnica y sectorial, conforman la base de un nuevo mercado de servicios de negocio, bien como productos de software (Service Oriented Business Applications, Composite Business Services, …), bien como servicios online (Software as a Service), que a su vez proporcionan aún mayor flexibilidad y agilidad en los modelos TI de las organizaciones que estén orientadas a servicios.

3

Cómo pueden los CIOs impulsar el negocio a través de un modelo de TI flexible y orientado a servicios

Orientar una Organización a servicios Típicamente, una organización TI dentro de una empresa desarrolla, mantiene y opera sistemas de información, entendidos como aplicaciones que se ejecutan sobre una infraestructura determinada. Las aplicaciones son pues el eje vertebrador de los procesos y actividades de la organización, tanto los procesos operativos como los de control y gobierno: • Gestión de la cartera de aplicaciones • Persona o unidad de negocio responsable de cada aplicación • Proveedores del desarrollo/ mantenimiento de tal o cuál aplicación • Modelo de costes asociado a las aplicaciones • Metodologías de desarrollo de aplicaciones • Arquitectura de aplicaciones y de integración de aplicaciones • Gestión del ciclo de vida de las aplicaciones • Monitorización de aplicaciones y de su infraestructura • Seguridad de las aplicaciones y de su infraestructura

La orientación a servicios implica llegar a cambiar “aplicación” por “servicio” en la lista anterior. Este cambio aparentemente inocente representa una auténtica revolución para una organización TI. Exige ajustarlo todo para poder gestionar un mayor número de elementos más simples: los servicios de negocio. La orientación a servicios de los sistemas de información busca, además de la flexibilidad, la reducción del coste del cambio, entendido no sólo como el coste TI de implementar el cambio requerido, sino también el coste de oportunidad implícito al no poder disponer de un cambio en el momento en que se necesita, y que se reduce al acortar el tiempo requerido para implementar los cambios. La característica de la orientación a servicios que más claramente ilustra esta reducción de costes es la reutilización de los servicios de negocio.

Pero poder reutilizar servicios presenta nuevos retos a la organización TI, y por tanto requiere políticas y procesos de gobierno específicos, prácticamente inexistentes en las actuales organizaciones TI vertebradas sobre aplicaciones. El ejemplo más claro es el modelo de costes asociado a un servicio: ¿Cómo se paga el mantenimiento de un servicio utilizado por diversas unidades de negocio? ¿Quién paga los costes de implementación de un nuevo servicio con elevado potencial de reutilización? Rápidamente puede entenderse que estos nuevos retos reclaman modificaciones en los procesos de gobierno de TI y, posiblemente, ajustes organizativos: nuevas funciones, nuevos roles, consolidación horizontal de funciones… En consecuencia, la orientación a servicios de una organización TI debe plantearse como una iniciativa estratégica, que requiere el liderazgo directo del CIO y que debe contar con el soporte explícito del Comité de Dirección. Cuando no es así, la orientación a servicios de la organización TI o bien nunca llega a abordarse o bien fracasa en el intento. En el primer caso, el asunto SOA se quedará en la implantación de alguna infraestructura moderna o en la modernización de alguna aplicación tecnológicamente obsoleta, lo que, ciertamente, podrá aportar valor para la TI pero no para el negocio. En los casos en que se abordan iniciativas de mayor calado, con mayor impacto en el negocio, pero sin la correcta planificación y sin un adecuado modelo de gobierno, se habrá perdido gran cantidad de tiempo y dinero con el riesgo añadido de acabar manteniendo un nuevo entorno tecnológico que elevará los costes de TI sin apenas aportar valor.

4

...continuado

¿Cómo empezar? Debe empezarse con el convencimiento de que la orientación a servicios del modelo de TI es una transformación estratégica, que abarca la tecnología, los procesos TI y las personas de la organización, y por consiguiente, requiere una cuidadosa planificación. Se trata de recorrer un camino, lo más recto posible, donde cada paso aporta valor, pues cada paso nos acerca a la meta deseada. Debe conocerse la situación de partida, donde será especialmente crítico el estado de salud de la organización TI que determinará cuán rápidamente se podrá recorrer el camino y cuál es la meta realista que se puede alcanzar en tres o cuatro años. Es fácil introducir cambios en la tecnología, lo realmente difícil es introducirlos en el modo de trabajar de las personas, cargar con el lastre cultural. Es como evaluar si el actual juego de construcción de piezas grandes se controla suficientemente bien como para pasar al juego de mayor nivel, con numerosas piezas muy pequeñas o quedarse en el siguiente nivel, con algunas piezas más y algo más pequeñas.

Tan importante como determinar la situación de partida es definir la situación deseada, la meta, a tres o cuatro años. El modelo TI objetivo debe estar alineado con el modelo de negocio objetivo que dicta el plan estratégico de negocio de la organización. Deberá ser realista, en base a la cantidad de cambios que la organización es capaz de asumir, y, además, deberá estar orientado a servicios, de modo que asegure la flexibilidad necesaria para mantener siempre la alineación con el negocio. Con los puntos inicial y final determinados, la línea recta puede ser el camino más corto pero quizás no sea el mejor. Es preciso diseñar una hoja de ruta adecuada, aceptable desde el punto de vista tecnológico, organizativo y financiero, que maximice la aportación de valor, pondere los riesgos y permita medir el progreso de cada etapa. A partir del conocimiento de la situación actual y de una visión compartida y validada del modelo futuro, es factible identificar, cualificar y cuantificar las distintas iniciativas del plan de transformación que, en el caso de la orientación a servicios, de la adopción de SOA, deberán contemplar los siguientes ámbitos.

•

Conjunto de iniciativas de transformación de las aplicaciones en servicios y/o implantación de nuevos servicios. Estas son las iniciativas que verdaderamente aportarán al negocio el valor de la orientación a servicios. Por esta razón, es importante cualificarlas y planificarlas adecuadamente, empezando por iniciativas tácticas, de valor moderado pero con menor complejidad, para, progresivamente, abordar las de carácter estratégico (alto valor).

•

Iniciativas de adecuación de la arquitectura e infraestructura, para que puedan sustentar la orientación a servicios y todos los principios arquitectónicos asociados. Aquí es imprescindible basarse en modelos de referencia y mejores prácticas. También se enmarcan en este ámbito las actividades de selección de tecnología y productos SOA y la ejecución de pruebas tecnológicas. Es habitual que los departamentos de arquitectura de las organizaciones TI hayan empezado su aproximación a SOA con iniciativas de este tipo. Por otro lado, también es preciso disponer de una infraestructura TI flexible, una infraestructura menos estática y que se ofrezca también como servicio. Deben contemplarse aspectos como la virtualización o la automatización de la provisión de componentes y recursos, ya que cada vez más las ventanas de tiempo no operativo serán más escasas y las operaciones de mantenimiento coexistirán con la operativa del negocio.

•

Iniciativas de gestión del cambio, tales como el desarrollo y puesta en funcionamiento de nuevas políticas, procesos de gobierno y herramientas de soporte adecuados para la gestión del ciclo de vida de los servicios (identificación, especificación, realización, operación); la puesta en marcha de áreas organizativas de

5

Cómo pueden los CIOs impulsar el negocio a través de un modelo de TI flexible y orientado a servicios

soporte al cambio y la transformación de determinados órganos de gobierno TI para adaptarlos progresivamente a la nueva orientación a servicios del modelo TI; y, finalmente, el ajuste de las operaciones TI, que deberán, también de modo progresivo, orientarse a servicios. Los tres ámbitos son interdependientes y deberán organizarse temporalmente de modo coordinado. En general, habrá una primera fase de preparación básica que deberá permitir implementar una primera experiencia que, además de presentar una mejora en algún aspecto del negocio, deberá servir para validar muchas de las decisiones y principios definidos. Esta primera fase, por si sola, no suele ser rentable, desde un punto de vista puramente financiero de retorno de la inversión, pero representa el sólido fundamento sobre el que se puede edificar. A partir de esta primera fase, la hoja de ruta debe abordar las demás iniciativas de valor que permitirán recorrer el camino de la orientación a servicios hacia la meta definida en el plan estratégico. Puesto que las siguientes iniciativas van a construirse sobre el fundamento de la primera fase, la inversión requerida será mucho menor y los beneficios mucho más evidentes a medida que se reutilicen los servicios de negocio existentes como resultado de las fases anteriores.

Escenarios de valor para la adopción de SOA. Las preguntas siguientes pueden servir de ayuda para identificar escenarios ideales en los que la adopción de la SOA proporciona la flexibilidad y agilidad necesarias para reducir los tiempos y costes de introducción de cambios, convirtiendo en favorable una situación o condición del entorno que, a priori, se presenta como un reto • ¿Dispone de un número grande o variable de colaboradores de negocio? SOA puede rebajar drásticamente la cantidad de tiempo necesario para empezar a colaborar con nuevos socios. SOA brinda la oportunidad de crear una interfaz sencilla para funciones concretas, reutilizables por múltiples colaboradores, independientemente de la tecnología que utilicen. •

•

Es por esta razón que, junto con la hoja de ruta, es crítico cuantificar el ROI de cada iniciativa, de modo que pueda llevarse a cabo el business case de todo el plan. Los resultados de este ejercicio de planificación estratégica y business case de la orientación a servicios del modelo TI deberían ser suficientes para convencer a la empresa de la conveniencia de abordar el plan definido.

6

•

¿Ha realizado una inversión en un gran número de aplicaciones e interfaces TI creadas a medida? Adopte como punto de partida los servicios web para dar un aire nuevo a estas antiguas aplicaciones, lo que normalmente prolongará su vida útil. Este “aire nuevo” también facilitará que las empresas migren sus aplicaciones básicas sin interrumpir el servicio prestado a los usuarios. ¿Resulta excesivamente amplia o heterogénea su cartera de aplicaciones TI? El tamaño y complejidad evidentes de la cartera de aplicaciones TI de algunas empresas hacen financieramente atractiva la arquitectura de integración SOA, incluso en el caso de que la empresa nunca se plantee aplicarla a la colaboración externa. ¿Introduce regularmente productos y servicios nuevos que contengan un componente TI? Aquellas empresas que dispongan de un inventario de servicios considerable en la actualidad tendrán más probabilidades de contar con las

piezas necesarias para componer el soporte TI de sus nuevas ofertas. •

¿Cuántas aplicaciones TI respaldan procesos de negocio sujetos a frecuentes variaciones? De nuevo, disponer de una infraestructura SOA, y de su correspondiente colección de servicios, contribuye a que TI responda con mayor rapidez a los cambios de negocio.

•

¿Compite en un sector cuyo acceso tiene como obstáculo principal contar con una mayor capacidad en TI? A medida que los servicios constituyan la norma y vayan evolucionando los estándares sectoriales, irán desapareciendo muchos de estos obstáculos. Quienes carezcan de la capacidad y experiencia en SOA quedarán en desventaja.

•

Y al contrario, ¿se desenvuelve en un sector donde la complejidad TI resulta desmesurada? En ciertos sectores, el

De los archivos de Gartner: El impacto que tiene en el negocio la arquitectura orientada a servicios

•

entorno TI se ha vuelto tan complejo que cualquier cambio relativamente sencillo comporta cierto riesgo y suele ser financieramente inviable. Más que para no perder posiciones en el mercado frente a otros competidores más ágiles, las empresas aquí referidas pueden servirse de SOA para escapar a la rigidez de sus sistemas.

Conclusión Si bien a primera vista podría resultar normal que los directores ejecutivos ignoren los debates sobre arquitectura TI, sí merece la pena que presten atención a SOA y su propuesta de orientar a servicios el modelo de TI. En su esencia, la inversión en SOA no consiste en adquirir tecnología informática sino en invertir en flexibilidad de negocio.

¿Forma parte de un entorno de negocio dominado por una entidad principal? Si así fuera, puede adoptar la arquitectura SOA para mantener dicha relación. ¿Cuánto sabe de la estrategia SOA de dicha organización?

En cualquier caso, la industria de las TIC está adoptando, de un modo generalizado, la orientación a servicios en su oferta de productos y servicios. SOA entrará de un modo u otro en las empresas. Es responsabilidad de los CIOs adaptar sus organizaciones para que esta adopción

de SOA se lleve a cabo de un modo tal que proporcione valor para el negocio y no se quede en una mera modernización tecnológica basada en productos preparados para SOA. Por esa razón, ahora es el momento de abordar la definición de un planteamiento estratégico para la orientación a servicios del modelo TI de la organización: analizar, definir y planificar; convencer a la dirección, obtener su apoyo e iniciar el camino de la orientación a servicios, con paso firme y seguro, aportando valor real al negocio en cada etapa del camino. Source: IBM

7

De los archivos de Gartner: El impacto que tiene en el negocio la arquitectura orientada a servicios

En este estudio se analiza el impacto de la arquitectura orientada a servicios (SOA, service-oriented architecture) desde la perspectiva de un analista de empresas o directivo ajeno al departamento de TI. Los profesionales de TI necesitan un modo de explicar las ventajas y las limitaciones de SOA a quienes no pertenecen a la TI, con el fin de mejorar las decisiones que se toman respecto al uso de dicha arquitectura. Principales conclusiones • La principal ventaja de SOA que es permite a los directivos y analistas desarrollar nuevos procesos de negocio y modificar los existentes con mayor rapidez y a menor coste. Por lo tanto, SOA da lugar a nuevos modelos de negocio que implican la introducción de nuevos productos y servicios, en especial lo que requiere la cooperación on-line de varias unidades de negocio. • El mayor inconveniente de SOA es que puede dificultar la gestión de las aplicaciones. En muchos casos, las unidades de negocio y sus sistemas de aplicaciones de TI son más interdependientes y vulnerables a sus problemas respectivos. • Un usuario final no puede determinar a partir de la interfaz de usuario si una aplicación se ha implementado utilizando SOA, gestión de procesos de negocio (BPM) o ambas. El impacto que ejercen en el negocio es indirecto y no se manifiesta en el exterior, pero es importante. • Cualquier gran sistema heterogéneo y distribuido, en especial si tiene muchos propietarios, presenta dificultades de gestión. SOA ayuda a resolver esos retos, aunque hace que sea más probable toparse con ellos.

8

Recomendaciones • Utilice SOA al diseñar las aplicaciones y procesos nuevos y más grandes, o al integrar alguna combinación de paquetes adquiridos, o aplicaciones y servicios heredados de otras unidades de negocio. • Implemente un centro de excelencia SOA o una organización similar para coordinar el desarrollo y el mantenimiento de las aplicaciones SOA entre unidades de negocio y grupos de TI dispares. • No utilice SOA para aplicaciones pequeñas o sencillas, ni cuando realice ligeras modificaciones a aplicaciones que no son SOA y que ya se encuentran en producción. ANÁLISIS El uso de SOA tiene dos grandes implicaciones para los directivos del negocio: • Mejora el desarrollo y la adaptabilidad de los procesos de negocio. Permite implementar o modificar procesos con mayor rapidez y menor coste. • Complica la gestión. Es necesario resolver los problemas que pueden derivarse de la mayor dependencia de otras unidades de negocio y sus sistemas. Estos factores se analizan en las dos secciones siguientes de este estudio. Mejora del desarrollo y la adaptabilidad de los procesos de negocio La principal ventaja de SOA es que puede reducir el tiempo, el esfuerzo y el coste necesarios para implementar o cambiar los sistemas de aplicación distribuidos en comparación con otros enfoques de las aplicaciones distribuidas. A su vez, esto agiliza y hace menos costosa la implementación o el cambio de los procesos de negocio que utilizan dichas aplicaciones.

Sin embargo, los sistemas SOA requieren a veces más tiempo y esfuerzo iniciales que las aplicaciones monolíticas (no distribuidas). Los sistemas basados en SOA se montan con componentes de aplicaciones creados por clientes, aplicaciones comerciales (aplicaciones de negocio orientadas al servicio) o servicios con alojamiento externo (también llamados “cloud computing” o nube de información, porque son “software como servicio” situados en cualquier punto de la nube de la red). Las aplicaciones SOA suelen ser una combinación de componentes procedentes de dos de esas fuentes o de las tres. Los componentes de aplicaciones previas a SOA se pueden adaptar con interfaces SOA utilizando “envoltorios” de software para que puedan incluirse. SOA difiere de enfoques anteriores a las aplicaciones distribuidas porque sus desarrolladores documentan formalmente las interfaces de componentes y utilizan protocolos de comunicación estándar para simplificar el intercambio de mensajes entre los componentes. SOA es útil aunque todos los componentes se ejecuten dentro de un solo departamento de TI de una unidad de negocio. Los desarrolladores pueden llevar el control de las interacciones entre los componentes y gestionar la implementación de componentes nuevos o modificados con mayor facilidad, gracias a la documentación de la interfaz. A medida que cambian las necesidades del negocio, las aplicaciones SOA se pueden cambiar en incrementos, sin afectar a otras partes del sistema. SOA es aún más valiosa cuando participan varias unidades de negocio y componentes procedentes de sus sistemas de TI respectivos. SOA se puede aplicar en sistemas que abarcan componentes ejecutados en sistemas de socios del negocio, fuera de la empresa.

...continuado

Téngase en cuenta que SOA no es directamente visible en el tiempo de ejecución. El usuario final de un terminal no tiene manera de determinar si una aplicación es orientada al servicio. SOA queda oculta tras los procesos. Sin embargo, la gente del negocio observará cambios en la manera en que los analistas de negocio recopilan requisitos para las aplicaciones SOA durante el proceso de desarrollo: • La gente del negocio puede entender algunos aspectos del diseño de la aplicación SOA con más facilidad que las aplicaciones tradicionales. Un servicio de software SOA se suele diseñar en correspondencia a un concepto de negocio. Una función de negocio lógica (un servicio de negocio), como la de “buscar el historial de crédito del cliente”, con frecuencia tendrá un equivalente directo en un servicio de software y una interfaz de componente (los desarrolladores suelen documentar esas interfaces utilizando WSDL). También puede existir correlación entre un formulario de negocio o una página web y uno o más documentos de software de los que se envían en mensajes SOA entre componentes. Estas relaciones entre elementos de negocio y de software hacen que algunos aspectos de las aplicaciones SOA se expliquen por sí solos y faciliten la comunicación entre usuarios finales, analistas de negocio e ingenieros de software. Por el contrario, la mayoría de las descripciones de interfaz de componentes y de los formatos de mensaje en aplicaciones que no son SOA se hallaban en un nivel de abstracción técnica que no era adecuado para las conversaciones de negocios. •

Los analistas de negocio, en el papel de modeladores de procesos, suelen utilizar herramientas gráficas de modelado de procesos durante el desarrollo para

documentar los flujos del sistema SOA. Si bien el modelado de procesos se puede llevar a cabo sin SOA, y SOA se puede implementar sin modelado de procesos, cada vez es más frecuente el uso de los dos de manera conjunta. La gente del negocio también debería estar al tanto de los cambios en el funcionamiento de las aplicaciones SOA en el tiempo de ejecución. A diferencia de las aplicaciones más tradicionales, muchas aplicaciones SOA utilizan motores BPM para articular el flujo de trabajo a través de una secuencia de actividades. El motor BPM activa una secuencia de servicios SOA (cada uno ejecutado por un componente distinto) en el orden especificado por reglas de distribución. Al igual que sucede con SOA, los usuarios finales no pueden determinar, sólo con el uso de la aplicación, si se está utilizando un motor BPM detrás de las bambalinas en el tiempo de ejecución. Si no se utiliza motor BPM, el flujo de trabajo se controla en el código de la aplicación utilizando un lenguaje de programación estándar. Las herramientas de modelado de procesos para desarrollo a veces se emplean sin utilizar motores BPM en tiempo de ejecución, si bien la tendencia es utilizar ambas cosas. Las interfaces bien documentadas y de naturaleza modular de SOA facilitan la implementación de modelado de procesos y de motores BPM. A su vez, esto facilita el cambio de los procesos de negocio, ya que las reglas de distribución se definen gráficamente y se mantienen separadas de otras partes de los sistemas de aplicación. En unos pocos casos, el flujo de procesos puede ser modificado directamente por un analista de negocio en lugar de un ingeniero de software, por la relativa sencillez del software BPM en comparación con la implementación de reglas de distribución en un lenguaje de programación.

Mayor dificultad de gestión Casi todo tiene un precio, y también lo tiene SOA. Cualquier aplicación distribuida (SOA o no) es más difícil de diseñar, programar, probar y gestionar que una equivalente monolítica, sencillamente por el número de componentes y la dificultad de hacer que funcionen juntas en una red. Las aplicaciones heterogéneas distribuidas, cuyos componentes utilicen sistemas operativos, lenguajes de programación y servidores de aplicación distintos, presentan aún más dificultades que las aplicaciones homogéneas y distribuidas. Mediante el esfuerzo necesario, los departamentos de TI pueden superar esas dificultades técnicas utilizando herramientas de integración. Sin embargo, un departamento de TI no puede resolver por sí solo los problemas de gestión que se presentan cuando un sistema de aplicación SOA abarca varias unidades de negocio. Cuando los componentes son propiedad de las distintas unidades de negocio que los utilizan, suelen surgir problemas de fiabilidad y calidad de datos. Por ejemplo, si un componente no funciona debido a problemas de hardware, software o del operador, tampoco lo hará ninguna de las aplicaciones compuestas de SOA que utilicen dicho componente. De igual manera, si los datos de un componente son defectuosos, los problemas se pueden trasladar con rapidez a otros departamentos que utilizan esos datos on-line. Esos problemas son más graves que los que se producen en sistemas tradicionales de procesos aislados, que sólo intercambian datos en transferencias nocturnas de archivos en lote.

9

De los archivos de Gartner: El impacto que tiene en el negocio la arquitectura orientada a servicios

También pueden surgir conflictos de propiedad de servicios, prioridades de cambio y otros aspectos administrativos, como: • La manera de financiar el desarrollo inicial y el mantenimiento posterior de los componentes. •

El contracargo por el uso de componentes de servicio, como el uso de ordenadores y de almacenamiento, y la administración del sistema y de la red.

•

La responsabilidad de la comprobación, la configuración, el ajuste del rendimiento, la seguridad y los problemas de calidad de servicio de cada componente y del sistema en su conjunto.

Una aplicación SOA que se ejecuta exclusivamente dentro de una unidad de negocio, sin interactuar jamás con componentes de servicio que se ejecuten en otros puntos, puede quedar a salvo de dichos problemas a la vez que proporciona muchas de las ventajas de SOA. Sin embargo, un número creciente de aplicaciones SOA abarca muchas aplicaciones de negocio. La capacidad de conectar componentes gestionados por separado es una de las ventajas que se pregonan de SOA, y algo que cada vez se utiliza más. El deseo de compartir un servicio SOA (y sus datos) entre diversas unidades de negocio y varios procesos es algo que a veces impone a la gente del negocio la necesidad de hacer concesiones respecto a sus necesidades. Si un servicio ya está implementado para otro proceso, será menos costoso compartirlo (“reutilizarlo”) que desarrollar una nueva versión del servicio, aunque el existente no sea óptimo para los nuevos fines. Los analistas y administradores de negocio deben

10

saber cuándo solicitar la implementación de una nueva versión del servicio y cuándo “darse por satisfechos con lo que se tiene”. SOA no genera por sí sola ninguna de estas dificultades técnicas o de administración. Cualquier sistema heterogéneo y distribuido con varios propietarios presenta esos problemas. No obstante, con SOA aumenta el número de situaciones en las que surgen dichos problemas, debido a que los sistemas pre-SOA eran monolíticos o al menos solían tener menos componentes y propietarios, eran más homogéneos en el aspecto técnico y se modificaban con menor frecuencia. Los departamentos de TI carecen de atribuciones para tomar decisiones respecto al diseño y la gestión de SOA. Son los responsables de negocio quienes deben fijar las prioridades y resolver los problemas de metodología derivados de la

interdependencia entre diversos propietarios de aplicaciones. Una técnica que se aplica con éxito para resolver dichos problemas es implementar un centro de competencia o de excelencia SOA. Un grupo de ese tipo actúa como una cámara central de compensaciones que coordina las actividades SOA de todas las unidades de negocio de una compañía o de una gran división, de modo que cada departamento no deba actuar de manera individual con cada uno de los demás grupos. Impacto neto en el negocio En conclusión, los responsables del negocio pueden contar con que el desarrollo y la implementación de grandes sistemas de aplicación distribuidos se pueden realizar en menor tiempo con la utilización de SOA que sin ella. Si la aplicación comparte componentes desarrollados previamente, SOA puede ser aún más ventajosa.

...continuado

Aunque algunas técnicas más antiguas ya consiguieron el uso compartido de código y de datos, SOA está ampliando el número de lugares en los que resulta práctico compartir recursos, gracias a la definición de interfaces y mecanismos de comunicación estándar. Sin embargo, la implementación de la primera aplicación SOA en una compañía será en general más complicada que crear una aplicación de capacidad similar utilizando un diseño monolítico. Si los componentes que se pueden reaprovechar (compartir) son pocos o ninguno, el desarrollo inicial de una aplicación SOA puede requerir fácilmente más esfuerzo que crear la misma aplicación con una arquitectura de sistema monolítica (no distribuida). La decisión de implementar una actividad o proceso de negocio como una aplicación distribuida en lugar de monolítica, suele estar determinada por las necesidades del negocio. Si los datos y la lógica de la nueva aplicación se alojarán en sistemas de aplicación distintos (tal vez incluso en departamentos distintos), el diseño monolítico no es una opción viable. La mayoría de los nuevos sistemas de aplicación son distribuidos. Los costes iniciales de desarrollo suelen ser sólo el 20% del coste de ciclo de vida de una aplicación, en tanto que el 80% restante se gasta en el mantenimiento del sistema durante el resto de su vida. SOA será más beneficiosa en las últimas etapas de la vida de una aplicación debido a su modularidad (conectividad) inherente. Una vez que la primera aplicación SOA se encuentra en producción, las siguientes aplicaciones SOA y los cambios de la inicial son más sencillos, rápidos y económicos, ya que dichos cambios se pueden reducir a unos pocos componentes de software. Las aplicaciones SOA se pueden mantener y mejorar con mayor facilidad

que los sistemas monolíticos o los sistemas distribuidos que no son SOA, aunque los datos de reintegro sigan siendo escasos en cuanto al grado de dichas ventajas. Sin embargo, hay disponible un creciente cuerpo de datos en el impacto inicial de SOA. Por ejemplo, Gartner realizó una encuesta entre 254 compañías usuarias en 2006 para evaluar su experiencia con SOA. El estudio demostró que SOA tenía un efecto ligeramente negativo en los costes en el periodo analizado. Del total de encuestados, el 32% indicó que había experimentado un incremento en los gastos netos debido a SOA, el 47% no advirtió cambios en los gastos y el 21% informó de ahorros. Como es lógico, la mayoría de las compañías llevaban poco tiempo utilizando SOA. Los desarrolladores de aplicaciones todavía estaban aprendiendo a utilizar los patrones y herramientas de diseño SOA, y los expertos en software intermedio estaban instalando la estructura de software necesaria para sustentar aplicaciones SOA actuales y futuras. En todo caso, las ventajas de SOA en cuanto a agilidad ya eran visibles. Más del 55% de las compañías encuestadas indicó que SOA tenía un impacto positivo en la agilidad del negocio, sólo el 36% reconoció que no había advertido cambios, y el 9% informó de una disminución de la agilidad. Si la solución de un problema de negocio requiere específicamente una aplicación distribuida, SOA es claramente preferible a otros estilos de arquitectura. Las aplicaciones que utilizan SOA a nivel de TI abren el camino a un incremento en el uso del concepto de servicio en el ámbito del negocio. Las compañías pueden adoptar nuevos modelos de negocio y

desarrollar nuevos productos, ofertas de servicios y canales de venta mediante el aprovechamiento de los sistemas de aplicación basados en SOA. Ésta ayuda a las organizaciones a implementar aplicaciones on-line más sofisticadas y mejor definidas, enfocadas a mercados verticales o procesos horizontales específicos. Los procesos preparados para SOA ofrecen valor de negocio en los siguientes aspectos: •

Una perspectiva única del cliente, que permite ofrecerle mejor servicio.

•

Una venta complementaria (cross-selling) mejor definida.

•

Interfaces de usuario final de mayor capacidad mediante aplicaciones híbridas que combinan elementos de datos diversos (por ejemplo, mapas y otros datos).

Por último, Gartner estima que hasta el 40% de las aplicaciones CRM (gestión de relaciones con el cliente) y ERP (planificación de recursos empresariales) típicas de las organizaciones, no están efectivamente integradas con otras aplicaciones más antiguas debido a las dificultades para implementar la integración. Por razones antes descritas, con SOA es más práctico aplicar algunos tipos de integración, en especial de aplicaciones compuestas on-line. SOA facilita el uso compartido de datos y de la lógica de programas de aplicación, lo cual representa una gran ventaja en sistemas a gran escala, de tipo corporativo o global. Gartner Número de ID: G00153828, Roy W. Schulte, Charles Abrams, Fecha de publicación: 24 de diciembre de 2007.

11

IBM y el logo de IBM son marcas registradas de International Business Machines Corporation. Los otros nombres de sociedades, productos o servicios pueden ser marcas registradas o marcas de servicios de terceros. Esta publicación está destinada únicamente a ser una guía general. Las fotografías pueden mostrar modelos de diseño. © Copyright IBM Corporation 2008 Incrementando la flexibilidad empresarial a traves de la arquitectura orientada a servicios (SOA) is published by IBM. Editorial supplied by IBM is independent of Gartner analysis. All Gartner research is © 2008 by Gartner, Inc. and/or its Affiliates. All rights reserved. All Gartner materials are used with Gartner’s permission and in no way does the use or publication of Gartner research indicate Gartner’s endorsement of IBM’s products and/or strategies. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. CN02012009

12