EL PROBLEMA DE SaaS

 Ilustración: Sek Leung

 

Las empresas recurren al software como servicio (SaaS) por su sencillez y ahorros en costos, pensando en dejar al proveedor su mantenimiento y actualizaciones. Pero se están dando cuenta de que la labor de integración, que sigue siendo tarea del área IT, dista mucho de resumirse en drag&drop.

 

Sin duda, una prueba del éxito de este modelo es que jamás había habido tanta presión por integrarlo con otros sistemas de negocio porque las herramientas de CRM como servicio, como la de Salesforce.com se van volviendo indispensables, y las compañías desean intercambiar más datos con ellas.
Para que el software en línea de la start-up estadounidense Workday administre los expedientes de decenas de miles de empleados, se necesita una forma segura de conectarlo con los datos exteriores sobre prestaciones, y así sucesivamente…, pero antes de lo que canta un gallo, los ahorros y la sencillez han desaparecido.

Los CIO prevén que en el todavía tierno mundo SaaS los compradores no pueden dar por sentado el papel que el fabricante desempeñará en la integración. Algunos de éstos entregan sus API Web y una lista de integradores (con los que ellos trabajan) para que los usen los clientes; otros han desarrollado plantillas para aplicaciones corrientes de negocio que prometen conducir a los equipos IT paso a paso hacia la integración.

 Además de eso, existe una creciente lista de terceros que venden aplicaciones, software y servicios en línea destinados a la tarea de la integración.

Esto lleva a la cuestión de si las áreas de business technology disponen de los talentos, capacidades y mentalidad requeridos para la integración SaaS, en la que se requiere al menos trabajar con las API Web y estar constantemente encima de los proveedores de SaaS, así como escribir código.

 

APRENDER SOBRE LA MARCHA. Cuando Manjit Singh, CIO de Chiquita Brands, pasó a ser el principal cliente de Workday, a finales del año pasado, aprendió una lección básica: el modelo SaaS está todavía en la fase de “aprender sobre la marcha”, tanto para proveedores como para clientes, y los CIO deben afanarse por que las nuevas reglas se escriban a su favor.

Workday fue fundada hace tres años por el legendario de PeopleSoft, Dave Duffield, y lleva el modelo de suscripción a SaaS al core de las aplicaciones de negocio, incluidos recursos humanos (RH), contabilidad y nómina. Singh escogió el software de RH de Workday para el manejo de rastreo del ausentismo, prestaciones, compensaciones y desarrollo de la profesión de 26,000 empleados del mundo entero, lo cual requería un gran proyecto de integración que vinculara los proveedores exteriores de prestaciones de Chiquita, con sistemas de nóminas de terceros.

Workday siguió el mismo enfoque con Chiquita que el que lleva a cabo con otras organizaciones, y recomendó a Singh instalar software de una empresa socia llamada Cape Clear, que posee un service bus empresarial que vincula aplicaciones usando servicios Web. Pero Singh no había invertido tanto en SaaS sólo para terminar con más software que manejar, así que decidió poner las cosas en claro. “Decidimos hacer que Workday se encargara más de la integración -dice Singh-. Aceptamos la conexión con Cape Clear, pero Workday sería responsable de mantener y manejar esa conexión.” Workday asintió, y poco después adquiriría a Cape Clear. Workday ahora vende esa capa de middleware como servicio, añadiendo un 20% al precio por sitio, dice el analista de Gartner, Benoit Lheureux.

Con ingresos por $749 millones de dólares y 41,000 clientes, Salesforce ha desempeñado un papel notable en definir SaaS para los negocios y ha generado un racimo de firmas con amplia gama de opciones de integración. “Es todo un ecosistema que trata de resolver la integración SaaS de diferentes modos”, afirma Lheureux. En muchos aspectos, las opciones son las convencionales para la integración de aplicaciones.

Para quien desee hacer el trabajo en casa hay conectores de API Web y de ERP en Force.com AppExchange (de Salesforce) que los departamentos IT experimentados pueden descargar para escribir sus propias ligas. Si se prefiere recurrir a consultores hay más de 40 socios de negocio (como IBM, Informatica y Pervasive) que ofrecen distintas formas de integrar los sistemas con Salesforce desde plantillas de software, servicios de integración basados en Web y aplicaciones precargadas con plantillas de integración, hasta servicios completos de consultoría para SaaS.

La opción de “hágalo usted mismo” de Salesforce puede resultar atractiva a clientes que busquen ahorrar dinero, ya que sus desarrolladores pueden tomar herramientas de Force.com (lo que podría resultar mucho menos complicado que un proyecto convencional de integración de aplicaciones). Con todo, Lheureux avisa que esos desarrolladores deberán aprender WSDL (de Salesforce), que describe cómo funcionan en una API los distintos servicios Web.

 Lo peor es que todas las API Web que ofrecen los fabricantes de SaaS son propietarias en algún grado, así que un desarrollador que recurra a múltiples proveedores de este modelo de entrega de software deberá aprender una variedad de lenguajes de descripción.

Chris Pokrana, CIO del Points of Light Institute, se ha hartado del “hágalo usted mismo”. En uno de sus anteriores trabajos en United Way, los desarrolladores tardaron más de un año entre una y otra actividad, y tuvieron que crear primero integraciones usando API de Salesforce que alimentaban la información sobre clientes desde una base de datos de CRM de legado y la transferían a Salesforce, y luego crearon también una liga entre Salesforce y el portal para clientes, el cual extraía de un sistema de legado algunos de los datos de los clientes. “Fue difícil, en buena parte por el tiempo que emplearon los desarrolladores internos para centrarse en el asunto”, dice Pokrana.

Así que cuando este ejecutivo debió ejecutar un proyecto de integración en Points of Light, entidad no lucrativa que organiza voluntarios para causas benéficas en Estados Unidos, contrató a Bluewolf. Se trataba de integrar Salesforce con una base de datos SQL Server (Microsoft) hecha en casa, de modo que todos los cambios y adiciones a los datos que efectúa el personal de ventas en Salesforce fueran respaldados día tras día. “Si Salesforce.com se hunde en el océano, tenemos así una copia local de todos nuestros datos corrientes”, señala Pokrana, quien explica que el sistema de ERP de la firma extrae datos también de la base de datos SQL Server.

El trabajo exigió descargar el software de integración de Bluewolf desde Force.com, cargar algo más de software de integración de Bluewolf a la base de datos y escribir una pequeña cantidad de código customizado para mapearlo a Salesforce. En el proyecto trabajó un consultor de Bluewolf.

 

ORDEN EN LA CASA. La integración de SaaS puede resultar más compleja, en cierto sentido, que la de software hecho en casa, puesto que intervienen más partes para proveer los datos, aun cuando el proyecto sea técnicamente menos complicado. Steven John, CIO de la fábrica de adhesivos H.B. Fuller, dice que un modo de reducir la complejidad es con disciplina IT estándar, como recurrir a un solo proveedor de middleware.

H.B. Fuller contrató a Workday para RH y a Salesforce para CRM y automatización de ventas, pero John está pensando en transferir más aplicaciones a SaaS y espera realizar gran parte de este trabajo ‘en casa’. De paso, busca consolidar en BizTalk (Microsoft) varias plataformas de middleware que H.B. Fuller ha venido usando, como WebSphere y Tibco. “Si se va a seguir en SaaS, se debe procurar tener la casa en orden -subraya-. Con un solo middleware la integración no constituirá ninguna barrera de importancia, pues proporcionará congruencia y rapidez a la integración.”

A los proveedores de SaaS, John les hace montones de preguntas en torno al middleware; por ejemplo, si han desarrollado plug-ins para un paquete específico de middleware y si tienen experiencia directa en implementar ese middleware.” Si me contestan ‘no’ a las dos preguntas, es un punto en su contra”, explica.

John está formando también un equipo con su personal IT que se encargará de desarrollar una estrategia en torno a la integración de SaaS y el middleware. Esto significa un reconocimiento de que la arquitectura SaaS demanda nuevas capacidades y relaciones; no es simplemente una herramienta ya lista. “Si no se tiene esa disciplina interna, las cosas pueden salir mal y esas relaciones SaaS no van a funcionar”, asegura.

Los clientes de SaaS están entusiasmados por la sencillez de las actualizaciones, puesto que las nuevas características pueden activarse en el centro de datos del proveedor. Pero integrar servicios y aplicaciones puede enmarañar ese pulcro paquete. Cuando los proveedores trabajan con otro software y otros fabricantes de SaaS en integración es importante prestar atención a si las versiones han quedado integradas, según ha aprendido John. Por ejemplo, cuando H.B. Fuller contrató a Workday, ésta mostró casos en que otros clientes se habían integrado con los servicios de procesamiento de nóminas de Automatic Data Processing (ADP), que H.B. Fuller también usa. John luego se enteró de que esos clientes usaban una versión más vieja de ADP, no la que estaba usando H.B. Fuller. “Así que donde pensábamos que las cosas serían sencillas hubo algunas complicaciones -comenta-. Si yo estuviera en los zapatos de Workday habría dicho que ADP es uno de los mayores vendedores de nóminas y que esto no se tiene que perder de vista.”

Los clientes también deben contar con el desempeño de la red, puesto que las integraciones SaaS podrían cambiar dramáticamente la cantidad de datos que estarían moviéndose. GreenPages Technology Solutions, que es una integradora de SaaS, lo descubrió por su cuenta hace varios años cuando contrató un servicio de software, afirma su CIO, Michael Healy, quien no quiso nombrar al fabricante. Éste le aseguró que no era necesario más ancho de banda, pero cuando GreenPages integró el servicio de software con su sistema de CRM, tuvo que añadir ancho de banda para la comunicación entre ambos sistemas.

SaaS es todavía muy joven y muchos fabricantes no tienen experiencia para anticipar las actualizaciones en infraestructura de redes necesarias. “Como las aplicaciones se pueden iniciar y poner a funcionar, no piensan en la actuación como algo primordial -señala Healy-. Cuando llegamos al convenio sobre SaaS comenzamos con la pregunta: ‘¿Cuál es la capacidad que ustedes tienen?’.”

 

VERDADEROS CREYENTES. Doug Harr, quien hace tres años fue CIO del proveedor de bases de datos de fuente abierta Ingres, no tiene intención de usar middleware convencional en su ambiente IT, que está basado casi por completo en SaaS.

En cargos anteriores en Portal Software y en Core Technology Group, cuando el middleware de Oracle, Tibico y otros hacían furor, Harr evitó emplearlo, por su alto costo, y optó por integraciones punto a punto construidas a la medida. Ahora intenta trabajar con fabricantes de SaaS que han puesto mucho esfuerzo en integrar su software con productos de otros proveedores.

Ya ha integrado cuentas recibidas del fabricante de SaaS Intacct con el CRM de Salesforce y lo ha logrado con bastante facilidad, ya que esos fabricantes han llevado a cabo una considerable labor de integración. En realidad, una de las razones de que Salesforce ganara el contrato de CRM frente a NetSuite fue precisamente por esa labor, sostiene Harr. Pero hay algo más que le gustaría hacer, como transferir los datos de los empleados sacándolos de ADP, y alimentarlos directamente a Intacct para Cuentas Pagables, eliminando la necesidad de que alguien manualmente manipule los nombres de los empleados hacia Intacct para distribuir los pagos de gastos.

Para resolver algunos de sus problemas de integración, Harr está considerando los ofrecimientos que existen en torno a la emergente categoría de aplicaciones de integración y servicios en línea para SaaS, como los de Bluewolf, Cast Iron y Boomi. Ingres quizá tenga que escribir algo de código, pero dado que la mayoría de aplicaciones SaaS fueron desarrolladas desde el principio teniendo en mente los servicios Web, dice que la codificación será más sencilla que con aplicaciones convencionales que se encuentran en la empresa, incluso aquellas a las que se les ha dado una interfaz Web.

Employers Direct, firma californiana que provee seguros de compensaciones, usa Cast Iron para la integración de SaaS. Cuando su CIO, Joe Cárdenas, cofundó esta firma en 2002, evitó tener un centro de datos en la empresa. Todas las aplicaciones de software que usa son entregadas vía SaaS o bien están hospedadas con un proveedor. Employers Direct tiene 17 empledos IT de tiempo completo cuya principal tarea es manejar SaaS y las relaciones hospedadas, así como procurar una integración entre ellas sin problemas. La mayor inversión en infraestructura IT de la compañía se encuentra en la banda ancha del soporte.

Cast Iron es una aplicación de ‘servidor y software’ que corre en un data center del cliente o se hospeda en Cast Iron, guidando al profesional IT (típicamente, un analista de sistemas) a través de la integración entre un servicio de software y una aplicación de software que se encuentre en la empresa o con otro fabricante de SaaS. Employers Direct lo emplea para integrar su sistema hospedado de procesamiento de reclamaciones con los servicios de procesamiento de cheques y con los departamentos de seguros y el sistema judicial de California, todo vía Web. El personal IT había hecho codificación manual para integraciones anteriores SaaS, pero la meta de Cárdenas es ir eliminando ese procedimiento y basarse más en Cast Iron.

Como aplicación que es, también maneja los ciclos y monitoreo requeridos por las conexiones de software en línea, por lo que tiene sentido hacer que maneje tanta integración de SaaS como sea posible, afirma. “Más adelante procuraremos que todo el mundo esté bien entrenado en el producto -dice Cárdenas-. Entonces comenzaremos a tomar agresivamente esos servicios Web codificados y los convertiremos a Cast Iron.”

Pero más importante que una estrategia técnica disciplinada en un ambiente SaaS integrado, dice Cárdenas, es el talento. “Los colegas de servicios Web son de oro”, dice. Los define como profesionales IT que han pasado de la mentalidad de construir una arquitectura IT en casa a crear un ambiente en línea vinculado, usando Web services.

Pero mientras la moderna filosofía de los servicios Web es importante, no lo es menos tener la mente abierta, sea para evaluar SaaS o alguna opción más convencional. “Hay muchas personas a las que hemos entrevistado que son fanáticos de .Net, pero no me gusta -explica Cárdenas-. Lo que se necesita son personas que conozcan las fortalezas y puntos flacos de las distintas plataformas.”

El tipo de gestión de los fabricantes son también esenciales para el personal IT, añade Cárdenas. Hay que tomar precauciones estándar cuando se recurre a compañías externas para que den soporte al ambiente IT, como pruebas extra de software con el fin de cerciorarse de que funcionan a la perfección. Los miembros del personal se encuentran ocasionalmente con que tienen que estar llamando a menudo a los fabricantes de SaaS y aceptar que los procesos de integración pueden exigir más tiempo del esperado, porque hay menos cosas que están bajo control de Employers Direct.

John, de H.B. Fuller, coincide y llama al ambiente SaaS una forma de subcontratación moderna. Subraya que muchas de las capacidades de gestión de proyectos requeridas para gestionar un contrato de outsourcing se requieren también para lograr buenas integraciones SaaS.

 

DE INTEGRACIÓN A INTEGRACIÓN. Los proveedores de software-as-a-service suelen proporcionar listas de integradores y proveedores de software con los que trabajan, pero es importante entender el nivel de integración, pues podría significar la diferencia entre unos cuantos clics del mouse o que el personal IT se tenga que pasar días codificando. Singh asevera: “Todo cliente tiene que hacerle al vendedor la misma pregunta: ‘¿Qué nivel de integración tiene?’

 

Chiquita, que trabaja con varios proveedores de prestaciones que están en la lista de socios de integración de Workday, encontró que su trabajo iba de superficial a profundo. “Le recomendé a Workday ser cuidadoso cuando pasan al modo de ventas y dicen: ‘Hemos logrado realizar esta integración de prestaciones’.” Desde entonces Singh dice que si no es una integración profunda podría significar una inesperada codificación a la medida con el subsiguiente costo para el cliente.

Otro problema de integración que ha encontrado Singh fue cuando uno de los proveedores de prestaciones de Chiquita se rehusó a alimentar datos directamente a Workday, diciendo que su contrato era con Chiquita. Esto obligó a ésta a establecer un servidor FTP para captar los datos del proveedor de prestaciones y luego transferirlos a Workday. Una vez más, Singh tuvo que pelear para no añadir infraestructura para soportar su operación SaaS.

Cuando Singh le planteó el problema a Workday, éste aceptó que el servidor FTP estuviera en Chiquita y manejar remotamente el flujo de datos. “No era un problema de Workday, sino del proveedor -concede-, pero mi expectativa era no verme atrapado en medio de la situación.”

No hay que entender la franqueza de Singh como insatisfacción. Dice que está feliz con Workday y satisfecho del modo como este proveedor estadounidense ha resuelto los problemas, y confía poder integrar mucho más con la plataforma.

Más aún, Singh desea emplear a Workday como repositorio maestro de los datos de todos los empleados, de forma que cuando alguien deje la compañía o cambie de puesto, tal movimiento desencadene una serie de flujos de trabajo que, por ejemplo, automáticamente eliminen los derechos de acceso a la red o inicien una orden de trabajo de cambio en las líneas de los teléfonos.
Esa funcionalidad significará integración extensiva, incluida una liga de arquitectura orientada a servicios (SOA) entre Workday y varias aplicaciones en la empresa, como el Microsoft Active Directory y Lombardi Business Process Management. Es un gran proyecto que comprende mucho código de legado, y Singh piensa que su equipo podrá realizar buena parte de este trabajo usando el middelware BEA AquaLogic, de Oracle.

Hacia ahí es adonde se dirigen las aplicaciones SaaS. Aún persisten los prejuicios como que SaaS es una producto mal visto, comprado por alguna unidad de negocio que lo pone en funcionamiento sin la ayuda o la bendición del área IT. Pero son tanto más razón para que el departamento IT muestre que tiene su taller de SaaS. Desde luego que algún pequeño grupo puede establecer una herramienta de Salesforce y ponerla a funcionar durante el fin de semana. Cuando el equipo vea lo que se puede hacer conectando Salesforce al ERP o a Exchange, estarán felices de sacarlo a la luz.

Artículos relacionados

1. LA VERDAD DETRÁS DEL SAAS