Llegamos a ustedes gracias a:



Reportajes y análisis

SOA crece (y se multiplica)

[15/01/2010] Hace no mucho tiempo, las organizaciones de TI empezaron a volcarse hacia la arquitectura orientada a servicios (SOA, por sus siglas en inglés) buscando, en principio, una manera de integrar las aplicaciones corporativas. Pero ahora, las compañías grandes usan SOA para crear componentes que se pueden combinar y volver a usar como servicios en diversas aplicaciones.

Esto no solo agiliza y simplifica la actualización de aplicaciones, sino que también reduce el tiempo de desarrollo, mejora la atención a clientes y socios y permite ahorrar dinero.
Sigue siendo SOA, solo que corregida y aumentada.
"En estos tiempos nadie te da un premio por escribir envoltorios de servicios web alrededor de aplicaciones ya existentes", señala Hamesh Yadav, arquitecto principal de sistemas de Wells Fargo (WFC) & Co., con sede en San Francisco, y codirector del grupo de trabajo orientado a infraestructura de servicios de The Open Group. "Ahora la SOA se concentra más en los problemas".
Si bien esta ampliación del uso de SOA ha dado lugar a una serie de desafíos de gestión, la necesidad de construir un gobierno interno que permita registrar y compartir servicios", agrega Yadav, "también ha reducido la complejidad pues todos los elementos son más interoperables.
En la empresa Massachusetts Mutual Life Insurance Co. (Springfield, Massachusetts), el proyecto SOA incorpora actualmente cerca de 40 servicios, incluyendo los de gestión de distribución, colecciones premium, gestión de atención al cliente, nuevos negocios y aprobación de pólizas.
Estos servicios integran aplicaciones a través de las unidades de negocios, cada una de las cuales comercializa productos diferentes. En vez de reemplazar integralmente una aplicación existente, las unidades de negocio escogen una combinación adecuada entre la gama de servicios compartidos de la compañía", precisa Kinam-Peter Kim, gerente de SOA corporativo de MassMutual.
"Para nosotros, SOA no es una tecnología. Es un enfoque para modernizar nuestro negocio, para crear una empresa adaptable", afirma Kim.
Un servicio SOA bien diseñado se puede reutilizar tanto para automatización de procesos de negocios como para integración de sistemas. Por ejemplo, las funciones compartidas de MassMutual, tales como la seguridad, se colocan en repositorios y forman lo que se conoce como el departamento de normas de gobierno, que a su vez determina qué aplicaciones usan los servicios compartidos. 
En el 2007, cuando la compañía empezó a evaluar la renovación de su modelo de SOA, el equipo de TI se percató de que en lugar de cambiar el modelo de arquitectura, podían usar un modelo para todas las unidades de negocios.
"Planteamos preguntas como ¿qué significa SOA para nuestro negocio?" recuerda Don Carten, vicepresidente asistente de tecnología corporativa de MassMutual. "Reflexionamos en torno al enfoque, qué centro de costos utilizar, qué servicios, qué tipo de asesoría. Luego formamos un equipo para dirigir el programa, y construimos los servicios usando estándares que ya conocíamos bien".
SOA: Más amplio, más profundo
"SOA está ingresando al mainstream, y una vez ahí se convertirá en parte de un todo", adelanta Mike Gilpin, analista de Forrester Research Inc. "Las compañías definen los servicios web, escriben el código y luego entregan el servicio (de aplicación)", añade.
Para ilustrar el concepto, Gilpin recurre a la industria de telecomunicaciones: SOA es la lengua común que comunica todos los servicios de telecomunicaciones - línea a tierra, Internet, móviles, televisión y demás- de forma tal que se pueden entregar de manera unificada desde el sitio web de un operador. Este modelo podría inclusive extenderse a los vendedores minoristas, quienes a su vez podrían ver en un monitor los detalles de varios paquetes. 
Todo este contexto podría integrarse más estrechamente usando SOA, de manera que una compañía pudiera ser capaz de comercializar, ofrecer suministros y facturar servicios combinados o en paquete de todas las fuentes.
Cada uno de estos sistemas podría correr en diferentes tecnologías subyacentes, explica Gilpin. "Las líneas a tierra estarían en un mainframe, mientras que los servicios móviles corren en una plataforma Java. SOA es el facilitador, y así se reducen costos."
De igual manera, en la industria de servicios financieros, SOA podría permitir que los bancos procesen más rápidamente los préstamos o que ofrezcan servicios más veloces y menos engorrosos.
SOA en todas las aplicaciones
En la empresa Cigna Corp. (CI), la evolución de SOA fue distinta a la de MassMutual, pero los resultados fueron similares. Hacia el 2001, esta aseguradora de salud con sede en Filadelfia empezó a trabajar con SOA de manera integral. Mientras otras organizaciones evaluaban los servicios web a nivel departamental, Cigna ya implementaba SOA a gran escala, con sistemas de envergadura corporativa. El proceso incluyó un nuevo software de call center y una aplicación de gestión de contabilidad de clientes. 
"Reutilizamos la infraestructura de hardware y software existente, así que ahora hay piezas de SOA en casi todas las aplicaciones de misión crítica", señala Stephen Bergeron, director principal de arquitectura de Cigna.
Nuevos usos de SOA
Aunque, en líneas generales, actualmente las compañías usan más SOA, un reciente sondeo sugiere que no todos están contentos con esta tendencia. 
  • Empresas de todo tamaño que ya están usando SOA o que lo harán hacia fines de año: 68%
  • Empresas de todo tamaño que están aumentando el uso de SOA: 52%
  • Empresas de todo tamaño que reducen el uso de SOA: 1%
  • Empresas que luchan por obtener los beneficios de SOA que habían previsto: 18%
  • Empresas que no planean usar SOA: 32%

Forrester Research, Inc., de acuerdo a 2,227 entrevistados en el cuarto trimestre de 2009.

De acuerdo a estos datos, las compañías recurren a SOA para orquestación, servicios de información y servicios de negocios, entre otros.
Replantear la entrega de servicios
Cigna ha replanteado la manera en que las diferentes unidades de negocios accederán y usarán las aplicaciones compartidas, Tanto desde una perspectiva de negocios como de TI, explica Bergeron.
Dado que muchas aplicaciones de negocios tienen atributos redundantes -subraya Bergeron-, es importante definir con claridad la función que le corresponde a cada servicio y manejar el uso de cada uno de manera consecuente, a fin garantizar que la tecnología se utilice apropiadamente. Este paso es especialmente crucial cuando toda la empresa se dispone a adoptar SOA", agrega.
Actualmente, tanto el repositorio como el registro de servicios compartidos de Cigna permiten compartir mejor la información. El registro contiene información sobre las aplicaciones que están integradas con el SOA, y qué código reutilizable usa cada una. El repositorio almacena el código reusable.
El uso de servicios para aplicaciones de misión crítica representa un gran cambio. Es distinto de una aplicación creada a partir de servicios, o de una aplicación que usa servicios que no están integrados al SOA, explica Gilpin, de Forrester.
Por lo general, la expansión del uso de SOA se produce de la siguiente manera: las compañías empiezan utilizando los servicios web para proyectos pequeños y cuando estos experimentos salen bien, comienzan a desplegar SOA en toda la empresa.
Para tener éxito, esta expansión debe venir acompañada de un cambio en precepción de los requerimientos de SOA desde un punto de vista de proceso de negocios.
Otras preguntas  
El incremento de complejidad que ha significado la transformación de los servicios web -de integradores de aplicaciones a SOA de nivel corporativo- ha generado una serie de desafíos, uno los cuales es definir qué aplicaciones deberían consumir servicios y cómo tendrían que hacerlo. Para que este cambio se produzca exitosamente, los gerentes de TI tienen que responder preguntas distintas a las que solían encontrar durante las primeras épocas de esta tecnología.
"En este enfoque más amplio, SOA es una aplicación y un entorno de diseño de sistema" que puede aportar una gran agilidad al negocio, sostiene Sandra Rogers, analista de IDC. Pero este nuevo rol necesita que los servicios estén bien diseñados y bien concebidos, no solo como elementos representativos del negocio sino también como componentes de procesos de negocios.
Una alternativa consiste en usar como base del SOA servicios "dinámicos" que se puedan reutilizar y construir para trabajar con diferentes aplicaciones de negocios. Pero para que esto funcione, el equipo de TI tiene que prestar mucha atención a la administración del código. Las herramientas de administración y los repositorios son claves.
Sea cuál sea la opción que escoja, no es aconsejable que se salte la etapa de planificación. Las más exitosas implementaciones de SOA han ocurrido en compañías que cambiaron su manera de pensar para ver a SOA como una tecnología viable, indica Anne Thomas Manes, analista de Burton Group (Midvale, Utah).
Thomas Manes propone una interesante manera de proceder: "Las discusiones sobre SOA deben ser subterráneas. Los grupos de TI deben dejar de intentar vender el concepto de 'SOA' al negocio; simplemente tienen que proceder a aplicar los principios de SOA a los proyectos específicos que ejecutan".
En otras palabras, los grupos de TI tienen que apostar por los beneficios más sutiles del SOA: "garantizar que el software sea más manejable, que el mantenimiento sea más sencillo" y que facilite la integración, todo lo cual, a la larga, le da a las TI mayor agilidad y efectividad de costos, sostiene Thomas.
Su consejo final: No se limiten a hablar del SOA, demuestren que funciona. Y Kim, de MassMutual, le da la razón: "Uno de los factores de nuestro éxito fue que estandarizamos el proceso arquitectural cinco o seis años antes. Los arquitectos también tienen que comprender el negocio, y nuestra compañía tenía esos cimientos, tanto a nivel tecnológico como de negocio. El comité de dirección se interesó y tuvimos apoyo de los ejecutivos".
El desafío: calcular el ROI
A las compañías todavía les resulta difícil calcular el ROI (retorno de inversión por sus siglas en inglés) para una SOA. En muchos casos esto se debe a que como las implementaciones de servicios a gran escala tienen poco tiempo de funcionamiento, es imposible demostrar los beneficios que han reportado en términos presupuestales. Al respecto, Manes aconseja adoptar diferentes tipos de medidas de ROI. Por ejemplo, podríamos demostrar que las iniciativas de SOA requieren menos personal para desarrollo o ciclos de desarrollo más cortos; o que la SOA reduce los riesgos o los tiempos de llegada al mercado, precisa.
"Hay que pensar en las aplicaciones como si estuviéramos en la bolsa de valores. Si no hay retorno de dividendos, no sirven", explica. Es importante demostrar que este servicio puede disminuir los periodos de inactividad en el taller, acelerar el proceso de facturación, recortar el tiempo que el personal de soporte al cliente pasa resolviendo problemas por teléfono, rebajar la cantidad de ítems del inventario.
Teniendo en cuenta la rigidez de los presupuestos actuales, es muy probable que las organizaciones se muestren más propensas a destinar fondos para proyectos específicos con oportunidades de ROI concretas que a iniciativas arquitecturales más abstractas, agrega.
En MassMutual, recuerda Carten, para justificar la implementación general de SOA hubo que buscar nuevas maneras de presentar la tecnología: había que hablar de la manera en que SOA podía estandarizar el negocio, señala.
El proceso puede ser difícil porque primero hay que estar de acuerdo en torno a los estándares y luego desarrollar algunos que funcionen en formato reutilizable.
Pese a todo esto, dice Carten, "nunca tuvimos que hacer el caso del negocio per se; fue algo que se hizo a través de la transformación". En otras palabras, el éxito se logró en la práctica, no solo con palabras. "Hay que dar un paso al frente y ejecutar una serie de servicios", afirma Carten.
La importancia del governancy
Mientras más se use SOA en una empresa, más necesidad habrá de identificar que servicios se ejecutan en qué partes de la organización, qué componentes usa cada servicio y qué componentes están disponibles para reutilización. Un gobierno fuerte se hace indispensable tanto al momento del diseño, cuando se aplican las reglas, y durante la ejecución, "que es cuando resulta más difícil, porque en ese momento los servicios están en pleno funcionamiento", explica Carten de MassMutual.
Una posibilidad es definir qué parámetros se pueden aplicar en todas las unidades de negocios. 
El concepto de "federación" también ha ganado importancia debido a la creciente expansión de SOA en la empresa. "En un enfoque federado de autenticación y autorización, es posible que un usuario de un dominio llame a otro y que sus credenciales atraviesen ambos dominios, aunque uno esté construido en Active Directory de Microsoft y el otro en Identity Manager de Sun," asegura Gilpin.
Por supuesto, el concepto de federación no es ninguna novedad, pero conforme SOA gana terreno en la empresa de TI, su aplicación se vuelve más necesaria. Ciertos estándares, como Security Assertion Markup Language (SAML), establecen la interoperabilidad, aclara Gilpin.
Pero los gerentes de TI deben ser muy cuidadosos. "En el proceso de construcción de SOA, uno tiene que repetirse constantemente que SOA no es simplemente un asunto de tecnología", advierte Bergeron, de Cigna. "Muy a menudo, la gente de TI se concentra tanto en la tecnología que pierde de vista los objetivos del negocio  que deben guiar todo trabajo. Con todos los productos, tecnologías y estándares que existen para darle soporte a SOA, es difícil no caer en la tentación".
John S. Webster, Computerworld