Planificar la integración B2B
XML como eje
Si se está trazando una arquitectura para ayudar a la empresa a participar en uno o más de los mercados de empresa-a-empresa o business-to-business (B2B) que los observadores del sector pronostican que florecerán durante este año, habrá que prepararse para aprender algunos de los puntos más específicos del middleware y del lenguaje XML.
Una vez que se haya creado una “rampa de acceso” a un mercado, uno de los retos clave será integrar los datos en las aplicaciones back-end que necesitarán utilizarlos. Es aquí donde el middleware puede ofrecer una ayuda crucial para convertir, dirigir y suministrar de forma segura los datos, y donde los mensajes basados en XML pueden facilitar el manejo de esos datos en formatos muy variables. Sin embargo, la tecnología es sólo una parte de la ecuación, advierten los analistas. Antes de comenzar a pensar sobre el software, la compañía deberá examinar sus procesos comerciales y las relaciones con sus firmas colaboradoras para determinar cuáles serán afectadas y cuáles serán mejoradas por el mercado. A continuación, deberán identificarse todas las aplicaciones y bases de datos que intervienen, porque esa información afectará a las decisiones que habrá que adoptar respecto a la arquitectura.
Aunque todo esto puede parecer simple y directo, el trabajo puede complicarse, en particular en las empresas grandes. Por ejemplo, algunos departamentos podrían tener sus propios sistemas. Y la situación podría hacerse incluso más compleja si han tenido lugar fusiones entre empresas.
Un reciente estudio de la consultora Forrester Research destacaba el caso de una compañía grande que tenía en marcha varios proyectos de integración compitiendo en diferentes unidades comerciales, Y se trataba en esencia de una carrera para ver quién podía terminar antes el proyecto. La estrategia consistía en “alimentar a la fuerza” a las otras unidades la solución ganadora.
Formar un equipo multidisciplinar
Podrá organizarse mejor ese esfuerzo formando un equipo central a tiempo completo, con alcance en toda la empresa y en todas sus divisiones, para desarrollar, desplegar y mantener la infraestructura de integración. El equipo tendrá que evaluar cuidadosamente la infraestructura actual, planificando y teniendo en cuenta cualquier software adicional que pudiera ser necesario. Se obtendrá una ventaja de salida si existe ya instalada una arquitectura flexible de múltiples niveles: presentación, lógica comercial y base de datos.
El trabajo más complejo y difícil es la integración back-end. Las empresas abordan generalmente la integración de aplicaciones en las formas siguientes:
• Creando y diseñando un sistema de integración punto-a-punto para una “conexión fija” o “hard-wired” de las aplicaciones, para que puedan comunicarse entre sí; un entorno muy complejo de gestionar.
• Adoptando middleware orientado a mensajes. En este caso, se conecta una aplicación a un bus de mensajes que gestiona la comunicación entre programas, que pueden estar funcionando bajo diferentes sistemas operativos. El inconveniente es que continúa siendo necesario realizar la conversión de datos entre aplicaciones y la gestión de las transacciones.
• Utilizando herramientas de integración de aplicaciones de empresa o EAI (Enterprise Integration Applications), muchas de las cuales habrán sido mejoradas para manejar una amplia variedad de funciones, incluyendo el envío garantizado de mensajes entre aplicaciones, gestión de transacciones, conversión de datos y seguridad.
Este tipo de middleware ayuda en la integración business-to-business externa y en la integración aplicación-con-aplicación interna. Con este enfoque, cada aplicación y sus características de integración son definidas una vez en un repositorio de meta-datos.
Entre los vendedores de middleware de integración están Tibco, Extricity, Neon Systems, Vitria Technology y webMethods. Microsoft tiene previsto competir mediante su BizTalk Server, y IBM ofrece el MQSeries Integrator. Aunque estos productos eliminan una buena parte del trabajo de diseño y creación que solían realizar los desarrolladores a partir de cero, no son soluciones mágicas. Hay que estar preparado para mucho trabajo de análisis y diseño. Algunas compañías podrían optar por no utilizar todas las capacidades de un producto EAI, optando por utilizar codificación de adaptación a fin de conectar con middleware que ya tuvieran instalado.
Evaluar los Estándares XML
Aunque la mayoría de las empresas coinciden en destacar los beneficios de XML para manejar un contenido de mensajes rico y variado, también reconocen la gran exigencia en potencia de proceso y ancho de banda que se requiere para los ficheros XML, que puede ser entre cinco y diez veces mayor que para EDI. Algunos analistas afirman que esas preocupaciones son infundadas, porque hay suficiente ancho de banda y espacio de disco disponibles. Pero ese no es el único obstáculo potencial respecto a XML. Debido a la ausencia de estándares XML, los vendedores y los grupos de sectores verticales han intentado establecer definiciones de pedidos, facturas y otros documentos comerciales importantes, lo cual ha obligado a muchas compañías a soportar muchos tipos de documentos XML diferentes.
Las claves para 2001
----------------------------
• Analizar los procesos comerciales actuales y las relaciones entre firmas colaboradoras con el fin de mejorarlas.
• Crear una infraestructura de propósito general en toda la compañía y elegir vendedores cuyo software sea adaptable a las necesidades futuras.
• Formar un equipo para desarrollar, desplegar y mantener la infraestructura de integración.
Una vez que se haya creado una “rampa de acceso” a un mercado, uno de los retos clave será integrar los datos en las aplicaciones back-end que necesitarán utilizarlos. Es aquí donde el middleware puede ofrecer una ayuda crucial para convertir, dirigir y suministrar de forma segura los datos, y donde los mensajes basados en XML pueden facilitar el manejo de esos datos en formatos muy variables. Sin embargo, la tecnología es sólo una parte de la ecuación, advierten los analistas. Antes de comenzar a pensar sobre el software, la compañía deberá examinar sus procesos comerciales y las relaciones con sus firmas colaboradoras para determinar cuáles serán afectadas y cuáles serán mejoradas por el mercado. A continuación, deberán identificarse todas las aplicaciones y bases de datos que intervienen, porque esa información afectará a las decisiones que habrá que adoptar respecto a la arquitectura.
Aunque todo esto puede parecer simple y directo, el trabajo puede complicarse, en particular en las empresas grandes. Por ejemplo, algunos departamentos podrían tener sus propios sistemas. Y la situación podría hacerse incluso más compleja si han tenido lugar fusiones entre empresas.
Un reciente estudio de la consultora Forrester Research destacaba el caso de una compañía grande que tenía en marcha varios proyectos de integración compitiendo en diferentes unidades comerciales, Y se trataba en esencia de una carrera para ver quién podía terminar antes el proyecto. La estrategia consistía en “alimentar a la fuerza” a las otras unidades la solución ganadora.
Formar un equipo multidisciplinar
Podrá organizarse mejor ese esfuerzo formando un equipo central a tiempo completo, con alcance en toda la empresa y en todas sus divisiones, para desarrollar, desplegar y mantener la infraestructura de integración. El equipo tendrá que evaluar cuidadosamente la infraestructura actual, planificando y teniendo en cuenta cualquier software adicional que pudiera ser necesario. Se obtendrá una ventaja de salida si existe ya instalada una arquitectura flexible de múltiples niveles: presentación, lógica comercial y base de datos.
El trabajo más complejo y difícil es la integración back-end. Las empresas abordan generalmente la integración de aplicaciones en las formas siguientes:
• Creando y diseñando un sistema de integración punto-a-punto para una “conexión fija” o “hard-wired” de las aplicaciones, para que puedan comunicarse entre sí; un entorno muy complejo de gestionar.
• Adoptando middleware orientado a mensajes. En este caso, se conecta una aplicación a un bus de mensajes que gestiona la comunicación entre programas, que pueden estar funcionando bajo diferentes sistemas operativos. El inconveniente es que continúa siendo necesario realizar la conversión de datos entre aplicaciones y la gestión de las transacciones.
• Utilizando herramientas de integración de aplicaciones de empresa o EAI (Enterprise Integration Applications), muchas de las cuales habrán sido mejoradas para manejar una amplia variedad de funciones, incluyendo el envío garantizado de mensajes entre aplicaciones, gestión de transacciones, conversión de datos y seguridad.
Este tipo de middleware ayuda en la integración business-to-business externa y en la integración aplicación-con-aplicación interna. Con este enfoque, cada aplicación y sus características de integración son definidas una vez en un repositorio de meta-datos.
Entre los vendedores de middleware de integración están Tibco, Extricity, Neon Systems, Vitria Technology y webMethods. Microsoft tiene previsto competir mediante su BizTalk Server, y IBM ofrece el MQSeries Integrator. Aunque estos productos eliminan una buena parte del trabajo de diseño y creación que solían realizar los desarrolladores a partir de cero, no son soluciones mágicas. Hay que estar preparado para mucho trabajo de análisis y diseño. Algunas compañías podrían optar por no utilizar todas las capacidades de un producto EAI, optando por utilizar codificación de adaptación a fin de conectar con middleware que ya tuvieran instalado.
Evaluar los Estándares XML
Aunque la mayoría de las empresas coinciden en destacar los beneficios de XML para manejar un contenido de mensajes rico y variado, también reconocen la gran exigencia en potencia de proceso y ancho de banda que se requiere para los ficheros XML, que puede ser entre cinco y diez veces mayor que para EDI. Algunos analistas afirman que esas preocupaciones son infundadas, porque hay suficiente ancho de banda y espacio de disco disponibles. Pero ese no es el único obstáculo potencial respecto a XML. Debido a la ausencia de estándares XML, los vendedores y los grupos de sectores verticales han intentado establecer definiciones de pedidos, facturas y otros documentos comerciales importantes, lo cual ha obligado a muchas compañías a soportar muchos tipos de documentos XML diferentes.
Las claves para 2001
----------------------------
• Analizar los procesos comerciales actuales y las relaciones entre firmas colaboradoras con el fin de mejorarlas.
• Crear una infraestructura de propósito general en toda la compañía y elegir vendedores cuyo software sea adaptable a las necesidades futuras.
• Formar un equipo para desarrollar, desplegar y mantener la infraestructura de integración.
