Enterprise Application Integration. Mucho más que productos de moda.

Imaginemos el caso de una compañía petrolera, cuyos procesos de negocio van desde el descubrimiento de nuevas fuentes de hidrocarburos hasta su explotación, pasando por varios procesos intermedios. Todos estos procesos son soportados por diferentes aplicaciones, en un ambiente heterogéneo con distintos proveedores, plataformas y productos. Supongamos ahora que necesitamos una ficha completa de un pozo petrolero en una ubicación geográfica particular. Dicha información podría estar diseminada entre una decena de aplicaciones distintas, ¿cómo podemos obtener la información integrada?

Situémonos ahora en la mesa de dinero de un importante banco que ha pasado por una fusión con otro banco de envergadura similar. Algunos productos financieros son manejados por una aplicación perteneciente al banco adquirido, y otros por aquella que tenía ya el banco comprador. Sin embargo, debemos consolidar ambas fuentes para poder calcular ganancias y pérdidas... ¿Volcamos reportes de ambas aplicaciones y los consolidamos manualmente? ¿Qué costo tendría eso? Y, ¿Cuál es la posibilidad e impacto de un error?

Situaciones como la anterior son vividas a diario por grandes empresas de diferentes mercados, desde hace más de una década. Estas situaciones surgen de fenómenos naturales en la empresa... aplicaciones que nacieron y crecieron aisladas... aplicaciones de diversos fabricantes... fusiones y adquisiciones... y, sin duda, otras razones particulares. Sin embargo, algo queda claro: en la empresa actual, cuyas estrategias están cada vez más apoyadas desde las TIs, la integración de las aplicaciones siguiendo las necesidades del negocio es una realidad. Pero la solución no está en SOA, Enterprise Service Bus, message-oriented middleware ni algún otro buzzword tecnológico, sino en una estrategia de integración claramente alineada, planeada y ejecutada según las necesidades del negocio. De eso trata este artículo, de cómo abordar la Integración de Aplicaciones Empresariales con un marco de trabajo en el cual la tecnología está “al servicio” del negocio.

¿Qué es “Enterprise Application Integration” (EAI)?
Se llama EAI al uso de medios de software para conectar a un conjunto de aplicaciones empresariales. En la definición anterior, “medios de software” es cualquier mecanismo que permita realizar tal conectividad, desde archivos planos hasta servicios de mensajería. Por otro lado, una “aplicación empresarial” es cualquier aplicación que da servicios a la empresa, desde una aplicación propia del mercado en el cual opera (petróleo, banca, etc.) hasta las aplicaciones administrativas típicas (CRM, ERP, etc.).

La forma más simple de EAI, como para ilustrar este concepto, es el intercambio de datos entre dos aplicaciones a través de algún medio como un archivo plano o una base de datos. Es muy común en una empresa, por ejemplo, la existencia de “interfaces” consistentes en archivos planos depositados temporalmente por un proceso en un directorio compartido, que luego son tomados por otro proceso. Otra forma muy común es a través de bases de datos accedidas por diferentes sistemas. Finalmente, las formas más modernas de EAI hacen uso normalmente de servicios de mensajería, desde ad-hoc hasta basados en estándares de la industria.

Una Necesidad de Hoy y Siempre
El concepto de EAI no es para nada nuevo. Es tan antiguo como la necesidad de intercambiar datos entre dos aplicaciones separadas, y las empresas han tenido este problema casi desde el mismo momento en que empezaron a usar sistemas de software.

¿Por qué EAI es una necesidad “de hoy y de siempre”? Porque es una realidad que una empresa es un ecosistema de aplicaciones diferentes en naturaleza, que requieren comunicarse entre sí, pero que no fueron destinadas a comunicarse entre sí. La necesidad de integración es estratégica y está para quedarse. La integración no debe entenderse como un problema del “hoy”, heredado de los sistemas legacy que no tuvieron en cuenta la necesidad de integrarse. Muy por el contrario, la integración es una realidad de siempre, ya que siempre tendremos sistemas diferentes en diferentes sectores del negocio, cuyas realidades siempre serán diferentes.

Las Dificultades del EAI
Las dificultades más inmediatamente visibles, aunque no necesariamente las más importantes, son principalmente técnicas. Dado que muchos de los sistemas son pensados para ser utilizados en forma aislada (para un departamento o pequeño grupo de usuarios), raramente están preparados para soportar la seguridad y escalabilidad requeridas para hacerlos disponibles hacia otros usuarios y sistemas.

Por otro lado, existen problemas del estilo organizacional o de gestión, entre los cuáles distinguimos los siguientes: • Integración “miope” y no planificada. Las interfaces pensadas para resolver la necesidad inmediata a veces crean acoplamientos indeseables, que se suman a la pila de sistemas legacy poco mantenibles. Se resuelve un problema y se crea otro. • Carencia de un análisis de impacto en la forma de trabajar de los usuarios. Es decir, “luego de la integración de A y B... ¿cómo se ve afectado el trabajo de los usuarios de A y B?”.

Los anteriores no son más que manifiestos evidentes de los siguientes problemas de fondo, aún más graves:
• Mapa de aplicaciones no definido, desconocido o “spaghetti”. Esto dificulta de sobremanera detectar si una nueva integración no está causando un acoplamiento indeseable, o si se está integrando en forma consistente en diferentes sectores de la empresa.
• Relación entre aplicaciones y procesos de negocio no definida, poco clara o desordenada. Esto impide discernir qué aplicaciones son responsables de cada proceso o flujo de información y, por lo tanto, impide discernir la forma de integración más adecuada para el negocio.

Mientras que los problemas técnicos son generalmente visibles, los problemas organizacionales no son tan evidentes y, por lo tanto, son mucho más riesgosos. Y no sólo eso, sino que en general son también más difíciles y caros de solucionar. Por otro lado, la mayoría de los proyectos de EAI son conducidos por informáticos bien capacitados para resolver el aspecto técnico de la integración, pero quizás no tan duchos en la detección y resolución de los problemas organizacionales.

Finalmente, es importante pesar las dificultades en términos de los riesgos que las mismas suponen para el negocio. Una dificultad técnica normalmente puede solucionarse, eventualmente con costo adicional. Sin embargo, una integración (posiblemente costosa) que no fue pensada claramente desde el punto de vista del negocio, puede no acarrear beneficios para el mismo, redundando en un gasto necesario (y tal vez problemas adicionales). Dejando a un lado el peso relativo de tales problemas, es claro que un proyecto de EAI es tanto informático como organizacional, ya que tanto las necesidades como las dificultades están de ambos lados.

Más adelante en este artículo revisaremos un enfoque estructurado y alineado al negocio, que busca encontrar y resolver problemas organizacionales para un proyecto EAI. Pero antes, conozcamos los diferentes tipos de integración.

Tipos de Integración
No existe una forma única de integración adecuada a todas las situaciones, por el contrario, a lo largo de los años se han desarrollado diferentes formas de integración, adecuadas a diferentes necesidades. Si bien no hay una taxonomía estándar, los siguientes son tipos de integración generalmente aceptados:
1. Integración Orientada a la Información. Consiste en el pasaje de información de un sistema a otro. Casos típicos: el envío de transacciones comerciales, y las bases de datos integradas (por ejemplo, bases de datos que reúnen los datos de todos los clientes de una compañía, en forma sincronizada con las demás aplicaciones que usan tales clientes).

Figura 1. Integración Orientada a la Información.

Típicamente, la integración orientada a la información no requiere modificaciones en las aplicaciones integradas, sino solamente la implementación del mecanismo de pasaje de información entre los repositorios de datos de las aplicaciones respectivas; esto hace que sea la forma de integración más simple y de menor impacto.

Si bien la integración orientada a la información consiste en el pasaje de datos entre los repositorios de las aplicaciones, no necesariamente esto implica que tal integración se realice pura y exclusivamente usando tecnología de base de datos. También podría realizarse mediante archivos planos, APIs de las aplicaciones, o incluso servicios de mensajería. La clave de este tipo de integración no está en el medio técnico, sino en el hecho de que lo que se integra es información y no procesos o servicios.

2. Integración Orientada a Procesos. Subiendo en el nivel de abstracción, nos encontramos con la integración orientada a los procesos de negocio. Esta integración consiste en la automatización de los diferentes pasos de un proceso de negocio a través de una o más aplicaciones. Si bien esto muchas veces implica intercambio de información entre aplicaciones, esto es simplemente un medio para lograr el fin en cuestión. Además de información, en la integración orientada a procesos de negocio también se integra el control. Típicamente, este tipo de integración se lleva a cabo mediante un flujo de trabajo (workflow).

Figura 2. Integración Orientada a los Procesos de Negocio.

3. Integración Orientada a Servicios. Otro tipo de integración, muy en boga en estos días, es la integración orientada a servicios. En este modelo, una aplicación expone una serie de servicios de negocio que pueden ser usados por otras aplicaciones. Se busca no solamente el reuso, sino también el hacer que cierta lógica de negocio sea implementada una única vez en la empresa, y reutilizada el resto de las veces.

Figura 3. Integración Orientada a los Servicios.

La orientación a servicios también permite la creación de las llamadas “aplicaciones compuestas”. Nuevas aplicaciones que surgen a partir de la unificación de diferentes servicios preexistentes en la organización. En el diagrama anterior, la Aplicación de Trading Web podría ser una aplicación compuesta, si toda su lógica partiera de invocación a servicios de otras aplicaciones.

La orientación a servicios y la orientación a procesos no son excluyentes, sino complementarias. De hecho, el caso ideal de la integración es aquel en el cual los procesos de negocio pueden ensamblarse a partir de la invocación ordenada y coordinada de diferentes servicios, que satisfacen las necesidades de los distintos subprocesos.

4. Integración Orientada a los Portales. Finalmente, algunos autores distinguen la integración orientada a los portales como un tipo separado. El aspecto distintivo de esta forma de integración es la agrupación de varios aplicaciones bajo una interfaz visual común, normalmente un portal web.

Figura 4. Integración Orientada a los Portales.

La integración mediante portales tampoco es necesariamente excluyente de los otros tipos de integración. De hecho, el portal puede alimentarse a través de servicios, y el mismo portal puede también soportar la participación de actores humanos en procesos de negocio.

Eligiendo un Tipo de Integración
No existe una receta mágica acerca de qué tipo (o tipos) de integración se puede aplicar en cada situación. Sin embargo, los siguientes puntos pueden proveer una guía básica:
• Si la necesidad es centralizar el origen de un cierto tipo de dato (por ejemplo, centralizar una base de clientes), entonces en principio nos es suficiente con una integración orientada a la información. En este caso es crucial revisarlo con todos los actores importantes (los representantes de TI y negocio relacionados con las aplicaciones a integrar) y acordar universalmente el flujo resultante de la integración. Esto para evitar futuras integraciones inconsistentes con esta (por ejemplo, que si se acordó una base única de clientes, no surja de pronto una base alternativa de clientes).
• Si la necesidad es centralizar cierta función de negocio (por ejemplo, el cálculo de precios de los productos de la compañía), entonces es conveniente pensar en términos de servicios. Una aplicación debe ser elegida como la oficial para realizar tal función (podrían ser varias, en caso de que se determine en qué casos se invoca a una y en qué casos a otra).
• El caso de la integración orientada a procesos normalmente está asociada a una decisión más estratégica. Si la necesidad va más allá de un dato o función, y tiene que ver con formalizar o automatizar procesos de negocio completos, ésta es la opción adecuada.

• La integración orientada a portales generalmente es un caso más particular, y tiene que ver con la necesidad de facilitar la llegada de la información a quiénes la deben utilizar. Por ejemplo, si un operador debe consultar cinco aplicaciones al comenzar el día, claramente pierde bastante tiempo al tener que abrir las cinco y navegar hasta los datos que necesita; un portal personalizado puede hacerle llegar todos esos datos en una única pantalla. El portal puede servirse de integraciones de información, servicios, e incluso facilitar la automatización del proceso de negocio. Por esto, la orientación orientada a portales puede convivir perfectamente con los otros tipos de integración. En cualquiera de los casos, es importante ver cómo juega el negocio en la decisión del tipo o tipos de integración a utilizar. En los primeros casos, más simples, veamos que rescatamos la necesidad de consensuar la integración con los actores. En el caso de los procesos, es claro que tales procesos deben ser definidos por el negocio, y soportados por la TI. En el caso de los portales, hablamos de que la integración está motivada por las necesidades de información de un actor del negocio. Es fundamental, entonces, siempre tener en cuenta las necesidades de la organización antes de elegir productos que nos fuercen a un tipo de integración que no es el que necesitamos.

Un Mapa de Ruta para la Integración
Tras haber conocido la necesidad, las dificultades inherentes y las diferentes formas que puede tomar la integración, nos resta hilar esos componentes en un mapa de ruta que podamos usar para guiar nuestros proyectos de EAI. Veamos una metodología que nos puede servir como checklist básico.

En primer lugar, reconozcamos una realidad de la empresa, y es que no todos los emprendimientos del día a día responden a planes estratégicos claramente orquestados. Es por eso que muchas necesidades de integración a las cuáles nos enfrentamos puedan no responder a una estrategia mayor, y aún así requerir llevarse a cabo para responder a necesidades bien reales. En cualquiera de los casos, un enfoque cuidadoso y estructurado nos ayudará a evitar que la respuesta a necesidades tácticas de hoy entorpezca la integración estratégica que busquemos mañana. Por esto, dividimos nuestro mapa en dos “rutas”: una táctica y una estratégica.

La Ruta Táctica
La ruta táctica es aquella que seguiremos para responder a las necesidades de hoy, pero sin ir en detrimento de aquellas que podamos tener mañana. Recurrimos a ella cuando tenemos una necesidad a corto plazo que debemos suplir. Los pasos recomendados son los siguientes:
1. Identificar la necesidad a cubrir. Determinar si debemos integrar información, funcionalidad y/o procesos. En el caso de tratarse de un proceso, deberá ser un proceso sencillo y aislado; en caso contrario, raramente podrá ser tratado a nivel táctico, y requerirá un enfoque estratégico. El caso de los portales raramente puede ser tratado a nivel táctico, a no ser que se trate de un prototipo inicial restringido a un grupo limitado de usuarios.
2. Identificar el alcance e impacto organizacional.Determinar las unidades organizacionales, procesos, aplicaciones y usuarios afectados. Una necesidad táctica no debería ser, por lo general, muy abarcativa a nivel organizacional. En caso contrario, se recomienda nuevamente revalidar si el rumbo no debería ser la ruta estratégica.
3. Identificar concesiones para hoy y acciones para mañana. Es posible que la naturaleza táctica de la solución requiera hacer algunas concesiones, como por ejemplo, realizar una integración que resulta en un acoplamiento no del todo deseable. En tal caso, es muy importante identificar tales concesiones y establecer algunas reglas de juego para evitar que los riesgos subyacentes se potencien con el tiempo. Por ejemplo, acordar que un acoplamiento indeseable no será explotado más allá de este proyecto particular. Adicionalmente, pueden programarse acciones a futuro para remover tal acoplamiento.
4. Definir el tipo de integración a utilizar. Una necesidad táctica normalmente podrá ser resuelta con una integración de información o servicios.
5. Seleccionar tecnología de integración. Elegir la forma de implementar el tipo de integración seleccionado. Si la necesidad es táctica, es conveniente que sea resuelta con alguna de las tecnologías ya probadas en la organización.
6. Planear la integración.Como todo proyecto, una integración requiere cuidadosa planificación. En especial, debe realizarse un cuidadoso análisis de riesgos.
7. Planear la transición. ¿Qué debe hacerse para que el negocio siga funcionando correctamente tras implantarse la integración? Esto normalmente incluye comunicación y capacitación a usuarios de las aplicaciones afectadas, y eventualmente la baja de alguna función de alguna en las aplicaciones utilizadas anteriormente.
8. Implementar la integración y la transición. Llevar a cabo la integración y la transición siguiendo los planes establecidos.

La Ruta Estratégica
La ruta estratégica es aquella abordada por la organización más allá de un proyecto particular, y responde no sólo a necesidades de hoy, sino que adelanta las de mañana. Se utiliza cuando la necesidad está guiada por optimizar procesos de negocio en forma integral. Los pasos recomendados son los siguientes: 1. Identificar la necesidad a cubrir. Un proyecto estratégico normalmente estará asociado a formalizar la manera en que uno o más procesos de negocio son soportados por las aplicaciones, y optimizar la forma en que tales aplicaciones se relacionan para soportarlos. 2. Identificar el alcance e impacto organizacional. Determinar las unidades organizacionales, procesos, aplicaciones y usuarios afectados. 3. Identificar el mapa actual de procesos y aplicaciones. Es muy probable que aunque se conozca qué procesos se desea automatizar, los detalles de los mismos no sean completamente conocidos, ni tampoco la forma en que se mapean a las aplicaciones. Es fundamental, antes de iniciar un enfoque de integración estratégico, documentar los procesos afectados, las unidades a las que pertenecen, los roles que participan y las aplicaciones requeridas para llevarlos a cabo. De otra manera, no se tendrá el mapa actual requerido para trazar el mapa futuro. 4. Trazar el mapa futuro de procesos y aplicaciones. Una vez detectado el mapa actual, determinar como el mismo se verá afectado tras la integración. Puntos clave a considerar son los procesos que sufrirán modificaciones, las aplicaciones que sufrirán modificaciones o serán retiradas, y cómo los diferentes roles de la organización deberán cambiar su forma de trabajar en un aspecto u otro. 5. Establecer la ruta de transición a seguir. Un proyecto estratégico raramente se ejecuta de una sola vez, dado su alcance y magnitud. En cambio, el mapa futuro se alcanzará siguiendo una ruta consistente a través de varios proyectos que acercarán paulatinamente la situación actual a la futura. 6. Implementar la ruta de transición establecida. Siguiendo lo ya mencionado, la ruta se ejecuta a través de varios proyectos de índole táctica.

Conclusión
La Integración de Aplicaciones Empresariales es un tema de gran importancia. Sin embargo, muchas veces los conceptos centrales del EAI se pierden en la complejidad de la oferta tecnológica y las promesas de los proveedores. EAI es un concepto que debe entenderse desde las necesidades del negocio, la arquitectura de las aplicaciones, y el valor que estas últimas proveen al negocio... y no solamente desde la perspectiva puramente tecnológica.

En definitiva, ¡EAI es mucho más que un conjunto de productos de moda!