¿Cómo describiría la posición que toma Information Builders con el lanzamiento de iWay Middleware SOA?
Tradicionalmente iWay Software ha jugado en el área de la principal tecnología de integración, conocida como broker de integración, es decir, la codificación de componentes de integración para permitir la comunicación entre, por ejemplo, SAP y PeopleSoft. Esa integración exige codificar dentro del broker y con el tiempo ha evolucionado hacia el denominado workflow de orquestación.
El nuevo rol del broker de integración en el mundo SOA se denomina Enterprise Services Bus y constituye una forma más ligera, amplia y sencilla de utilizar el broker de integración en base a nuevos estándares como servicios web. Esto permite crear procesos y exponerlos para que sean consumidos por otros procesos. Nosotros nos posicionamos ahora como una solución de integración basada en servicios web y facilitamos tanto conectores, así como todo el software subyacente para implementar una aplicación de integración SOA.
¿No supone entrar a competir con vuestros clientes en tanto que el 70 por ciento del negocio de iWay procede de la venta de conectores a otros proveedores?
En primer lugar ese porcentaje sólo es del 20 por ciento ya que el 80 por ciento del negocio de iWay se genera directamente. Es cierto que ese 20 por ciento podría verse afectado, pero también es cierto que empresas como SAP o Microsoft no ofrecen Web Services Buses, sino implementaciones de integración más pesadas del tipo EAI. Por otra parte, EAI todavía realiza cosas que el Services Bus aún no puede hacer, como diseñar procesos transaccionales. La razón es que los servicios web todavía no hablan un lenguaje transaccional. Los servicios web son ideales para procesos cortos o procesos premisa, pero cuando tienes que hacer transacciones es necesario incorporar un producto EAI. Algún día podrán hacerlo, pero no por el momento; y por ese motivo la mayoría de los proveedores ofrecen herramientas tradicionales EAI para crear las mejores aplicaciones de integración.
¿Cuáles son las mejoras que aporta iWay SOA Middleware con respecto a iWay Adaptive FrameWork?
La diferencia con Adaptive FrameWork empieza por el hecho de que hemos incorporado capacidades para la creación y el despliegue de servicios web. Hemos añadido una completa e integrada herramienta de diseño en el entorno de despliegue, de modo que la experiencia de diseño ahora te permite crear el proceso y desplegarlo como un servicio, garantizando el cumplimiento de las políticas y la seguridad.
También hemos añadido la capacidad de monitorización que permite monitorizar los servicios desplegados en distintos entornos; y se puede llegar hasta el nivel más elevado de los procesos o lo que denominamos BPM, incorporando la intervención humana o aspectos de tipo humano.
¿En qué medida este avance es comparable al concepto plataforma de los proveedores de aplicaciones?
Una plataforma incorpora dos importantes capacidades que nosotros no ofrecemos: un servidor de aplicaciones web y el sistema de mensajería. Lo que nosotros si somos capaces de hacer es conectarnos con los sistemas de mensajería que utilizan los negocios, y hay desde luego bastantes; y además somos capaces de correr sobre cualquier plataforma de aplicaciones. Podemos conectarnos a WebSphere, WebLogic, Oracle, Sun, JBox, SAP. No queremos forzar las decisiones y no ofrecemos herramientas que obligan al usuario a escribir y reemplazar. Hay decisiones estratégicas que las organizaciones ya han tomado y no forzamos el cambio de las plataformas de aplicaciones o el sistema de mensajería entre aplicaciones. Nuestro caso no es como el de IBM, que ata a un sistema de transporte propietario.
El transporte de la mensajería es la parte más compleja de la integración, es decir, reconocer de qué tipo de mensaje se trata y proceder a su adecuada conversión. Lo que nosotros ofrecemos es lo que denominamos transporte abierto, soportamos 25 protocolos diferentes y posibilitamos la mezcla de estos protocolos en lo que llamamos una arquitectura de canales de servicio. IBM, SAP o Tibco no tienen la habilidad de facilitar la mezcla de todos los protocolos que conviven en una interacción sofisticada. Las organizaciones nos compran porque pueden situarnos por encima de su arquitectura de transporte existente, pero no se ven obligados a escribir y reemplazar.
¿Qué factores han motivado esta evolución?
Los proveedores cada vez comercializan menos productos puros EAI y su demanda de adaptadores ha descendido. Se está produciendo un declive del negocio EAI y nuestro objetivo es continuar creciendo, de manera que tenemos que entrar en un nuevo mercado.
¿Cree que la adopción de SOA va a ser tan rápida como se espera?
SOA constituye una transición. El alcance de SOA es mucho mayor que el de la tradicional integración. El significado de SOA para la integración está al nivel de lo que Internet significó para el BI. Y queremos estar en la primera fila de esa revolución.
¿A qué empresas mira iWay Software como rivales?
Se trata de jugadores puros como Cape Clear o Sonic, que tampoco ofrecen una plataforma completa. Desde luego, también existe un solapamiento con IBM. Pero lo que sin ninguna duda nosotros podemos hacer mejor que nadie es el transporte y transmisión abiertos.
La necesidad está ahí si pensamos en las empresas tradicionales, donde la mayoría de los datos que se tratan no está originalmente en XML; hablamos de EDI, HTL7, Swift, etc. En ese tipo de entornos, normalmente el primer paso del proceso cuando se quiere hacer una integración es convertirlo en XML, e incluso entonces no es posible empezar con la integración. En nuestra arquitectura las posibilidades son mayores. SAP no habla con el sistema de mensajería de Tibco; mientras que iWay puede hacer esas conversiones de mensajería de forma rápida y escalable. Podemos ser el services bus de los services buses.
¿Qué supone este avance en materia de BI?
Con este nuevo avance, ofrecemos la posibilidad de diseñar un proceso con iWay y automáticamente imbricar informes BI. Es lo que denominamos BI basado en procesos.
Ciertamente Web Focus puede utilizar servicios web pero en el back-end. Ahora es posible crear procesos y embeber informes desde el mismo momento del diseño. Hemos dado respuesta a una pregunta clave: ¿por qué no integrar el BI en el proceso y anticiparse?, ¿por qué no embeber un informe WebFocus en el proceso?.
