Integración “a la carte”

 Aquí  comienza una serie que trata sobre alternativas disponibles a la hora de conectar aplicaciones. Sobre los distintos niveles de integración, sobre las estrategias comunes. También trata sobre riesgos a contemplar y otras consideraciones para asegurar el éxito de la integración. Finalmente, se destacan productos que aceleran el proceso y le dan robustez

En esta primera entrega de la serie, voy a hacer un análisis de las motivaciones por integrar aplicaciones. Luego repasaré dos modelos comunes de integración y los principales contextos en que la integración se presenta. A continuación sigue una distinción del concepto de interoperabilidad, como un caso particular (y deseable) de integración. Finalmente, cierro detallando los niveles en los cuales los sistemas pueden integrarse. Estos niveles serán cubiertos en profundidad en el resto de la serie

Por qué integramos
La primera motivación a integrar aplicaciones viene dada por el deseo de mejorar la productividad. Cuando tenemos sistemas desconectados, los usuarios deben

  • Mantener información en dos o más lugares distintos, con la consiguiente pérdida de tiempo y riesgo de inconsistencia
  • Operar en forma manual ciertas instancias de transacciones comerciales que podrían automatizarse, incluso a efectos de coordinar esfuerzos, anticipar riesgos a fin de evitar perjuicios comerciales y evitar errores humanos
  • Conmutar entre diferentes aplicaciones para cumplir con etapas de un mismo proceso de negocio, tarea que sólo aporta mayor complejidad al proceso
  • Dar aviso a terceros, sea por mail, a través de un Excel, teléfono o algún otro mecanismo acordado, respecto de cambios introducidos de modo de mantener sincronismo en operaciones de nivel de negocio. El seguimiento de estos workflows sólo aporta un stress que atenta contra la efectividad
  • Dejar operaciones pendientes de confirmación, sobre todo si hay pasos ejecutables por terceros (el despacho de una compra, por citar un ejemplo). Aquí no sólo hay sobrecarga de actividades, controles cruzados y seguimientos que hacer sino que además el cliente en más de un caso se ve perjudicado porque no tiene certeza de si la transacción que realizó (y por la que posiblemente ya pagó) será concretada o no

La gerencia de TI también se ve afecta frente a sistemas desconectados, en la medida en que debe

  • Duplicar (o multiplicar) lógica, tanto aquella relacionada con el negocio como la lógica de nivel inferior para acceso a recursos (propios o externos). Esto acarréa pérdida de productividad grupal, incremento de costos y riesgo de que el impacto de cambios es esa lógica duplicada obligue a extremar esfuerzos para mantener todos los sistemas sincronizados
    • Consideremos el riesgo si la lógica de cálculo de la cuota de amortización de un crédito (un algoritmo generalmente complejo) estuviera replicada en varios sistemas. Qué pasa si, por alguna iniciativa comercial, esa fórmula cambia? Sería posible mudar el cambio rápido a todos los sistemas que la llevan incorporada? Qué pasa si algunos de esos sistemas son mantenidos por terceros? Es posible coordinar todas las partes para aplicar el cambio juntos al mismo tiempo? No sería ideal tener toda esa lógica en un solo lugar, nutrir desde allí al resto de los sistemas de modo que un cambio esté inmediatamente disponible?
  • La alternativa a no lidiar con las complejidades de una integración implica migrar un sistema entero a otra plataforma. De este modo se reúne la máxima cantidad posible de bloques de lógica. Eso es integración "por amalgama", pero es carísimo ya que inversiones ya realizadas se desvanecen. Y no necesariamente en software: el hardware también existe
    • Qué pasa si lo que hay que "amalgamar" es un viejo sistema COBOL CICS?). Aún si migrar fuera la respuesta, porque todos los sistemas tienen una vida útil, el proceso no dura una noche sino quizás un par de años: en el durante de una migración, debemos integrar la vieja aplicación con la que está naciendo

Otras motivaciones que el área de Tecnología puede tener para integrar aplicaciones

  • Aprovechar, en los nuevos desarrollos, las mejoras en productividad de nuevas plataformas como el futuro J2EE v5 o .NET 2.0, en tanto que para el portfolio de aplicaciones existentes se conservan los entornos originales dada la necesidad de alcanzar el ROI sobre inversiones previas
    • El clásico ejemplo del mainframe vuelve una y otra vez: organizaciones tradicionales tienen uno y es su plataforma transaccional de misión crítica; será obsoleto, los programadores serán viejos pero es lo que hay y es lo que ya se pagó
  • La decisión de adquirir soluciones cerradas a fin de evitar desarrollar una solución en casa. Estas soluciones pueden estar disponibles en plataformas extras a las estándares de la organización, por lo que se deberán considerar mecanismos de integración desde aplicaciones de línea de negocio (line-of-business o LOB)
    • El ejemplo típico es el de la contabilidad mediante SAP u Oracle Financials, o la relación con clientes (CRM) a través de sistemas maduros como Siebel
  • Similar al anterior, pero tercerizando (outsourcing) un servicio a una empresa externa
    • Es normal en las empresas financieras contar con apoyo en línea de calificadoras de riesgo (como puede ser Veraz en Argentina o Dicom en Chile)

Modelos de Integración
Existen dos modelos de integración: el punto a punto (peer-to-peer) y el basado en un tubo (hub)

En el primer caso, el esquema es descentralizado. Las partes se hablan directamente, sin intermediarios. En la figura se ven dos ejemplos: uno donde las partes son tres y otro donde son diez


Figura 1. Comunicaciones punto a punto entre aplicaciones

En cualquier caso, en este modelo la cantidad de conexiones que hay que mantener, siendo n el número de partes, es equivalente a

Del mismo modo, las interfaces se deben mantener a ambas márgenes de cada conexión entre partes. Por consiguiente la cantidad de interfaces es equivalente al doble de la ecuación anterior

De este modo, si las partes son 3, por consiguiente, hablamos de 3 conexiones a cubrir y 6 interfaces a mantener. Si las partes son 10, todas relacionadas con todas, las conexiones suman 45 y las interfaces 90

Un poco mucho, no? Por supuesto que la clausura del grafo de conexiones es algo que podría llegar a darse algún día, no necesariamente se va a dar en el primer momento. Este esquema punto a punto es útil y sustentable cuando las conexiones efectivamente necesarias son limitadas. En otras palabras, cuando la necesidad de interacción es moderada. Si esa necesidad aumenta, este modelo puede volverse un infierno. La respuesta en ese caso está en el otro modelo de integración. Veamoslo


Figura 2. Aplicaciones conectadas por un caño (hub) de integración

El hub de integración es una pieza que centraliza las interacciones entre los diversos sistemas, de modo que cada parte hable sólo con el hub. Como sugería recién, este modelo se justifica cuando son varias las partes a integrar ya que, en el peor caso, la cantidad de conexiones asciende a n (el número de partes a integrar). La cantidad de interfaces es siempre el doble de las conexiones

Así, con 3 partes seguimos teniendo 3 conexiones y 6 interfaces, en tanto que con 10 partes, hablamos de 10 conexiones (frente a las 45 del modelo peer-to-peer) y 20 las interfaces (frente a las potenciales 90 del modelo previo)

Contextos de Integración
Se distinguen mayoritariamente dos: Integración de Aplicaciones Empresariales (Enterprise Application Integration o EAI) e Integración de Negocio a Negocio (Business to Business o B2B)

El primer caso tiene la particularidad de que la integración está supeditada a los objetivos de un único negocio. Por ende, en este contexto normalmente el proceso de toma de decisiones, en lo pertinente a integración, suele ser más rápido y los esfuerzos coordinables en una forma más cohesiva

El contexto de la integración B2B presenta la particularidad de que tiende a ser habilitador de nuevos canales por donde hacer fluir más oportunidades. No obstante, acá la integración está supeditada ya no a uno sino a varios negocios, con diferentes prioridades, políticas, culturas empresariales, etc. Por consiguiente, el proceso de toma de decisiones podría ser más complejo, con más instancias de negociación. Posiblemente con penalizaciones por incumplimiento del nivel de servicio acordado (Service Level Agreement o SLA). También, es vulnerable a los cambios de rumbo que las compañías con frecuencia puedan tomar

Integración e Interoperabilidad
Se pueden compartir operaciones o se pueden compartir datos. En el primer caso, decimos que estamos "interoperando". Interoperabilidad es integración pero en un orden de magnitud mayor que permite construir sistemas por agregación de otros sistemas. La integración es activa

Cuando la integración es sólo a nivel de datos, no hay agregación para concebir sistemas nuevos sino transformación de información. La integración en este caso es pasiva

Integración y Orientación a Servicios (SO)
Hablar de Integración, en sentido amplio, implica buscar caminos para poder conectar aplicaciones de toda índole y origen. Aplicaciones existentes (posiblemente legadas), aplicaciones nuevas. Un posible acercamiento al problema pasa por diseñar las aplicaciones con la premisa de que se puedan integrar entre sí en cuanto se disponga; más que hacer aplicaciones aisladas sin considerar, si el día de mañana surje la necesidad de conectarlas, el impacto en sus arquitecturas. Un enfoque que toma la característica de integración como premisa puede ser el Orientado a Servicios (SO), del que hago referencia aquí a un excelente artículo de su ventaja estratégica

Niveles de Integración
La integración de una o más aplicaciones puede darse en varios niveles, cada uno con sus ventajas y contextos que lo tornan favorable frente a los restantes. Los niveles son

  • Presentación, cuando lo que se comparte es la misma interfaz de usuario
  • Proceso, cuando se exponen funcionalidades (tanto de negocio como de nivel medio o inferior)
  • Dato, la metáfora típica del o los procesos que producen información para que otro u otros la consuman
  • Comunicación, nivel más bajo y básico de todos que sólo ofrece transporte. Los niveles anteriores normalmente son una versión enriquecida del mismo

En el resto de la serie desarrollaremos en profundidad cada nivel, enunciando las estrategias disponibles, las consideraciones y riesgos presentes, y finalmente los productos que implementan cada estrategia

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s