La integración de software entre productos o aplicaciones es un aspecto determinante sobre su futuro y utilidad. Gracias a la integración podremos extender la funcionalidad disponible, acceder a información nativa de otros sistemas e, incluso, aspirar a la eternidad (o casi :-).

Las técnicas que podemos utilizar para solucionar nuestras necesidades de conexión entre aplicaciones son conocidas y numerosas, sin embargo, resulta crítico elegir adecuadamente la ESTRATEGIA de INTEGRACIÓN sobre la que apoyaremos nuestros esfuerzos.

Multitud de conexiones

Dado el estado de cambio permanente
que caracteriza a los sistemas informáticos,
las actividades de integración entre aplicaciones software
pueden ser un auténtico pozo sin fondo.

Para el análisis de esta toma de decisión (DAR en términos CMMI) encontraremos condicionantes relacionados con exigencias en cuanto a prestaciones, facilidades para nuevas integraciones o portabilidad, por ejemplo. Como orientación,  a continuación resumimos las principales cuestiones a considerar:

• Conexiones una a una: Para cada pareja de aplicaciones defino e implemento una forma de conectarlas.
• Conexiones mediante servicios de mensajes: Cada aplicación se conecta a los canales de comunicación que le interesan e interactúa con ellos (lee / escribe). Los conocemos como «Bus de integración» o «Bus de servicios de empresa».
• Conexiones en una sola dirección (la información solo se propaga de la aplicación Origen a la aplicación Destino) frente a conexiones bidirecciones (información de ida y vuelta).
• Las conexiones síncronas (los cambios se propagan al momento) o, por contra, conexiones asíncronas (propago el cambio y ya llegará).
• Conexiones en las que «se empuja la información» (Push) o conexiones en las que «se tira de la información» (Pull).
• Las conexiones con estado (recibo confirmación cuando el cambio llega al destino) o conexiones sin estado (no hay confirmación).
• Publico mi interfaz de conexión (API – Application Programming Interface) y a verlas venir, o me adapto a cada aplicación Destino.
• Utilización de estándares (protocolos de comunicación, estructuras de datos) frente a la utilización de formatos propietarios.
• Me amparo en arquitecuras orientadas a servicios: Desde los frankensteins basados en CORBA o sus primos de ciudad, «los SOA«, hasta las vaporosas aplicaciones basadas en microservicios.

¿Habéis hecho este ejercicio con vuestras integraciones?
¿Echas en falta alguna cuestión relevante?

Y, para rematarlo, mis preguntas favoritas: ¿Lo hacemos desde cero? o ¿nos apoyamos en algún producto (de libre distribución, comercial)?.

Hacernos estas preguntas lo antes posible nos permite aspirar a producir integración de software con calidad y a bajo precio. Así, con todo ello construiremos nuestra estrategia de integración.

Estaremos de acuerdo en que no se trata de un paso trivial. Sin embargo, resulta extremadamente tentador iniciar el camino con objetivos humildes («conectamos rapidito estas dos aplicaciones, salimos del paso y ya lo vamos viendo.»). Válido, solo si estamos absolutamente dispuestos a tirar a la basura este esfuerzo en cuanto cambien las condiciones de contorno.

Transportes dudosos

Aunque no hay un camino garantizado, me parecen reseñables los dos casos de éxito que brevemente os quiero compartir. El caso de la plataforma Jazz de IBM y el caso de la empresa Tasktop.

•   Caso de la Plataforma Jazz Foundations de IBM

Se trata de un conjunto de marcos de trabajo (frameworks) que facilitan la construcción e integración de productos relacionados con el desarrollo colaborativo de aplicaciones. Resulta de especial importancia entender los antecedentes de esta iniciativa: a finales del 2010, IBM culmina un intenso periodo de compras corporativas con un catálogo de productos comerciales reduntantes, inconexos y heterogéneos. Es decir, tienen un problema de integración de sus productos tamaño XXXL.

Para salir de este aprieto, la estrategia de IBM tuvo dos componentes:

1. Inspirar una comunidad abierta dedicada a elaborar especificaciones prácticas para la integración de aplicaciones o productos software. ¿Lo pillas?. Esta comunidad es la Open Services for Lifecycle Collaboration (But you can call us “OSLC” ) y distribuye sus especificaciones de forma gratuita (free).
2. Implementar una plataforma de integración de aplicaciones o productos software, la plataforma Jazz Foundations de IBM. En esencia, se trata de una plataforma distribuida de forma gratuita por IBM (en sus componentes base) a la que podemos conectarnos desarrollando un adaptador que cumpla con  la especificación OSLC.

El componente base, propietario y disponible de forma gratuita es el Jazz Team Server (JTS). Cada Jazz Team Server proporciona los servicios básicos que permiten que un grupo de herramientas trabaje conjuntamente como un único servidor lógico.

Dejaré a vuestra imaginación o curiosidad averigüar cuál es la empresa con más productos interconectados mediante esta plataforma. Os incluyo una pequeña pista 🙂

Integraciones con Jazz.net

 ¡Visto!

• Caso de la empresa Tasktop.

La estrategia de Tasktop para posicionarse como fabricante de pasarelas de integración de productos ha sido:

1. Elaborar y distribuir como código abierto el marco de trabajo Eclipse Mylyn, que se ha convertido es un estandar de facto para extensiones que integran Eclipse con productos de Gestión del Ciclo de Vida del software (ALM). Resultado: Prestigio.
2. Trabajar en estrecha colaboración con fabricantes de software para generar una gama de productos de integración muy satisfactorios (Tasktop Sync, Tasktop Data, Tasktop Dev). Resultado: Negocio.

We don’t just connect systems. We connect knowledge workers.
(Tasktop web)

Como corolario, podemos concluir que cuando hablamos de integración entre aplicaciones software estamos hablando de colaboración entre productos para conseguir que el valor entregado de forma satisfactoria por el conjunto supere a la suma del valor de cada parte.