Llegamos a ustedes gracias a:



Reportajes y análisis

Integración SaaS

Complicada, pero manejable

[01/06/2009] Era demasiado bueno para ser verdad. Cuando Hines Interests Ltd. lanzó su negocio de de bienes raíces seguras llamado Hines Real Estate Securities Inc., como complemento de su negocio de desarrollo inmobiliario,  construyeron la infraestructura de TI en torno a una gran variedad de productos SaaS. Pero la necesidad de intercambiar datos entre las distintas aplicaciones alojadas -el proceso de transacciones, CRM, literature-fulfillment, y el sistema de gasto y pago de proveedores- creó un sinfín de integraciones que unían SaaS con SaaS, y con SaaS a las aplicaciones on-premises.

Es el sello de distinción de SaaS: Incorpore demasiadas aplicaciones, y es factible que se encuentre en aquellas viejas y malas épocas, cuando las múltiples aplicaciones en la infraestructura corporativa no hablaban la una con la otra. "Cuando te vuelves profundamente dependiente de SaaS, debes saber que tu data estará hacinada, una vez más", comenta Benny Lasiter, arquitecto de sistemas de negocio de Hines Real Estate Securities.

Consejos para el éxito de la integración de proyectos
1. Desarrollar una estrategia global de integración que incluya SaaS.

2. Tomarse el tiempo para comprender plenamente los requerimientos de los procesos del negocio, antes de comenzar el trabajo de integración.

3. Contrate a un arquitecto de información, con una profunda comprensión de los requisitos del proceso de negocio, así como las cuestiones relacionadas con la tecnología.

Benny Lasiter al menos contó con un plan. En muchas organizaciones, se infiltran subrepticiamente ofertas de SaaS en las unidades de negocio individuales, a menudo sin el conocimiento del departamento de TI. Los proyectos engañosos se han convertido en "el perfil de SaaS" para la empresa, señala Ron Papas, vicepresidente Senior y gerente general del grupo on-demand de Informatica Corp.

Luego, cuando las aplicaciones se multiplican y crecen, surgen los problemas. "Lo hace, una, dos, y cinco veces más tarde, tiene muchas de estas disparatadas soluciones en la infraestructura de TI. No hay estrategia, no hay coherencia, y eso implica un problema. La mayoría de las empresas ni siquiera saben que deben tener una estrategia de integración de SaaS, y se quedan solamente en la estrategia interna de integración Busines to Business (B2B). Eso es un gran problema", comenta Benoit Lheureux, analista de Gartner Inc. 

Pero es necesario no continuar solo. Así como los ejecutivos de TI están trabajando en la integración de SaaS; están también, a su vez, desarrollando nuevas estrategias de integración y obteniendo ayuda de los especialistas de integración y de nuevas herramientas.

Tres formas en cómo las integraciones pueden complicarse 
Puedes encontrarte en el mal camino, incluso después de que las aplicaciones SaaS estén integradas con el resto de la infraestructura. Según Pervasive Software, los tres retos a superar más comunes son los siguientes:
1. Nuevas funciones que complican más las tareas: El proveedor de SaaS incorpora nuevas características que podría querer usar. Por ejemplo, el proveedor ofrece informes más detallados, sin embargo es necesario cambiar el flujo del proceso previamente construido, de tal forma que se pueda percibir sustancialmente la ventaja de dicho cambio.

2. "Mejoras" a los API de los proveedores para SaaS: Los proveedores pueden revisar las interfaces de programación de aplicaciones varias veces al año, lo que puede provocar problemas con el trabajo de integración personalizada. Por ejemplo: la emisión de mensajes es un mecanismo que notifica a otra aplicación que se ha realizado un cambio en los datos, y que se necesita una actualización en el otro extremo. "Por diversas razones, los proveedores de SaaS han tenido que cambiar la forma en que aparece la señal al mundo exterior. Eso obliga a cambios que pueden parecer pequeños detalles, pero que aún requieren alterar el proceso de integración o de mapeado", comenta David Inbar, director de márketing de Pervasive Software.
Salesforce.com Inc. se esfuerza por garantizar que las actualizaciones no rompan las formas de las transacciones de procesos de los API. "El momento en que podría fallar es cuando cambiamos el comportamiento de las llamadas de la API. Si se comporta de manera diferente, la integración de código del cliente puede no saber qué hacer. Para evitar estos problemas, la empresa mantiene las versiones antiguas API en Internet. Comenta Ariel Kelman, director senior de márketing de producto en Salesforce.com.

3. Lastimarse a sí mismo: Puede realizar cambios en sus procesos de negocio que rompan el sistema. Por ejemplo, construir un sistema de órdenes de compra y, a continuación, decidir dividir el flujo de trabajo para los pequeños y grandes clientes, cambiando el flujo del proceso y de información a través de uno o más SaaS, o en aplicaciones in-house.
La Estrategia: Clave primordial
Para Lasiter, "es esencial disponer de un arquitecto con una visión global de los datos, alguien que entienda la parte del negocio de las cosas y cómo implementarlas técnicamente". En caso contrario, se presentarán problemas inesperados.

Por ejemplo, la mayoría de los proyectos de integración SaaS consideran a las aplicaciones de negocios back-end como sistemas financieros. Dado que estos vínculos se multiplican, abruman el sistema central. "De repente, el rendimiento de la aplicación financiera entra en conflicto, porque se presentan todas estas cosas conectadas a ella. Es como la antigua EAI. Así se finaliza con este código efecto espagueti ", comparte Rick Nucci, jefe de tecnología de Boomi Inc.
La flexibilidad de SaaS, y la capacidad de cambiar rápidamente de proveedor, también representan desafíos, tales como la forma de conciliar las nuevas aplicaciones SaaS con mayores datos. Por ejemplo, Lasiter cambió de proveedor de SaaS en mayo. "Ahora, estamos haciendo el proceso de fines de año y tenemos data de dos proveedores. Todo ello tiene que encajar para la presentación de informes de fin de año. En el mundo del SaaS las cosas cambian constantemente. Todo depende del departamento de TI para la gestión de todas las piezas en movimiento. ", añade.

Los dolores de cabeza pueden evitarse mediante una estrategia de integración que incluya a SaaS. Pero se entra en contradicción con los proyectos ad hoc, la cultura primordial con la que muchas aplicaciones SaaS se venden.

¿Quién se responsabiliza?
¿Cómo está vinculando las aplicaciones SaaS con la data legacy de su empresa?

  • Nuestro departamento de TI está estableciendo los hitos: 29%
  • Nuestro proveedor de SaaS está ayudando con la integración: 29%
  • No estamos integrando con la data legacy: 16%
  • Las unidades de negocio que usan SaaS trabajan la integración: 13%
  • Estamos trabajando con especialistas en integración SaaS: 4%
  • Estamos utilizando una herramienta de integración especializada de SaaS: 2%
  • Otros: 7%
Para Lasiter, la estructura de integración del framework ha evolucionado con el tiempo. Hines optó por SaaS dado que el negocio de bienes raíces presentaba un gran dinamismo y debía implementarse rápidamente. Era necesario un sistema flexible que permitiera cambios rápidos, debido a que los procesos de negocio se encuentran en evolución.

Lasiter también quería todos los datos en un repositorio común para la presentación de informes, razón por la cual decidió crear una base de datos on-premises que sirviera de depósito central y de registro del tráfico del intercambio de datos. Se utilizó una herramienta de Pervasive para crear los vínculos de integración. "construimos una capa aislada de integración que nos permite mantener un centro de datos con el fin de generar reportes ", comenta. Y dicho diseño permite a Hines cambiar de proveedores SaaS con bastante facilidad.

 
¿Quién está a cargo?
  • Departamento de TI: 71%
  • El departamento de usuarios finales: 16%
  • Gestión conjunta: 9%
  • Otros: 2%
  • No sabe: 2%
    Fuente: Encuesta exclusiva para Computerworld, marzo del 2009, Base: 45 encuestados
"Nosotros no tratamos de hacerlo todo a la vez", continúa. Todo lo contario, Hines implementó una por una las integraciones por más de dos años y medio. Aproximadamente el 20% del esfuerzo se codificó. El resto involucró procesos de negocio definidos, análisis de datos y cálculo de los requisitos de presentación de informes.

Mientras Hines utiliza middleware on-premise, cada vez es más popular entre otras empresas, usar la integración como servicio (IAS, por sus siglas en inglés) ofrecidas por los proveedores como Boomi e Informatica. Ellos proporcionan un centro de integración común para todos SaaS-a-SaaS, e intregraciones SaaS-on-premises

"La razón principal para cambiar a las herramientas de integración alojadas es el rápido desarrollo", acota Papas. Si bien el software on-premises tiende a ser actualizado en un rango de cada 12 a 18 meses, los proveedores de SaaS pueden revisar su software tres o más veces cada año. Los proveedores IAS pueden ayudar a asegurar que las personalizaciones para suss clientes sigan trabajando.

Zamil Industrial ITG, un fabricante de productos de construcción en Dammam, Arabia Saudita, no tuvo problemas en la integración de su arquitectura middleware orientada a servicios con la aplicación de gestión de servicios de Service-now.com. "Implementamos una arquitectura middleware orientada a servicios de Oracle Fusion, antes de ir con Service-now.com", cuenta Ahmed Abdrabalnabi, gerente de planificación de los servicios Zamil. Integrar esto con la información de los empleados residente en el Active Directory, y con las aplicaciones de recursos humanos on-premises, fue tan simple y claro "como bebe un vaso de agua. Abdrabalnabi cuenta que el proceso solo tomó unos días, pero eso es porque los requisitos de la integración fueron evaluados por adelantado, para asegurarse de que Servicio-now.com era el adecuado.
A pesar del tiempo que tardó la implementación de Zamil, sería un tiempo demasiado optimista para la mayoría de los proyectos de integración. Annrai O'Toole, vicepresidente de integración en Workday Inc., proveedor de aplicaciones alojadas de Pleasanton, California, menciona que alrededor del 80% de integraciones usan tecnologías básicas tales como transferencia de archivos; y proyectos con aplicaciones SaaS tienden a desarrollarse más rápido que el promedio típico de 12 a 18 meses para las aplicaciones tradicionales on-premises. Sin embargo, un típico proyecto de integración de sistemas de Workday, incluidos la migración y la limpieza de data, especificaciones de los procesos de negocio, y configuración de los sistemas, toma todavía alrededor de 70 días.
Robert L. Mitchell, Computerworld