Integrando soluciones y su impacto en el negocio

La integración de aplicaciones ha evolucionado con el paso del tiempo, pasando de arquitecturas donde todos los sistemas hablan con todos, conocida como arquitectura espagueti, hasta lo que tenemos hoy: establecimiento de buses de integración, normalización de datos y modelos de datos para la integración, así como la definición de patrones de integración.

En el mundo tecnológico de hoy, que por supuesto incluye a la nube, se han habilitado incluso aún más tecnologías y herramientas, que a su vez, han implicado el desarrollo de mejores prácticas específicas para el tema de integración de aplicaciones, así han terminado surgiendo protocolos de integración como:

• SOAP
• REST API basado en HTTP
• GraphQL basado en HTTP 

Si se detiene a pensar la evolución de este texto del desde el primer párrafo hasta estas letras, se puede apreciar que, el cambio fundamental es un cambio de paradigma, partiendo del desorden y falta de norma (espagueti) hacia la organización y la normalización, la razón: el orden ahorra tiempo, la normalización evita confusiones.

Todos estos esfuerzos de estandarización de la integración de aplicaciones, implica muchos esfuerzos, que incluye, el entendimiento de parte de los participantes de un equipo/proyecto/solución de la importancia de la definición de una correcta práctica de integración de aplicaciones.

En muchas ocasiones, hemos visto que, el equipo de cada aplicación que forma parte de una solución está enfocado en cumplir con y desarrollar solamente sus requerimientos, por lo que la fase de integración es vista como algo genérico donde las aplicaciones destino solo deben cumplir con un formato estándar de integración y la API propuesta. Todo esto desemboca en que durante las fases de diseño los siguientes puntos quedan definidos muy someramente:

• Patrones de integración entre aplicaciones
• Definición de los modelos de datos que regirán la integración
• Análisis detallado de los campos que se necesitan enviar de una aplicación A a la B, lo que ocasiona generalmente mucho retrabajo y mientras menos atención se coloca en este detalle mayor retrabajo se genera

El punto anterior, como se ha dicho anteriormente genera, en etapas posteriores del proyecto, retrabajos ya que normalmente aparecen el siguiente tipo de situaciones:

• Campos faltantes, es decir información, que el sistema A no envía al B. Por ejemplo información que en fase de pruebas se identifica que el CRM no está enviando al facturador, o el facturador no envía al ERP, información luego necesaria para factura electrónica, contabilidad, cobro correcto de cargos, etc.
• Formatos incompatibles, hay muchos de estos, pero, el ejemplo más común es, formato de fechas, el sistema A definió YYYY-MM-DD, sistema B definió YYYY-DD-MM esto hace que existan luego problemas en procesos futuros que dependen de la fecha, como fechas de corte por ejemplo, no es lo mismo 01/03 MM/DD que DD/MM el primero sería 3 de enero el segundo 1 de marzo, casi dos meses de diferencia por un error tan sencillo corte el servicio dos meses después o dos meses antes, este error incluso podría llegar a producción si las pruebas no son exhaustivas.

Es por lo anterior que contemplar un espacio del proyecto para la integración de aplicaciones asegura la minimización de estos y otros errores comunes, así como permite:

• Normalizar la forma como las aplicaciones se comunicarán en el futuro, simplificando las fases de análisis si se apegan a los estatutos o normas de integración establecidas. Más importante aún, permitiendo tener una arquitectura sostenible en el tiempo que permite adaptarse al futuro.
• Asegurar un desempeño óptimo de la solución desde el inicio del proyecto, esto se logra definiendo patrones de integración adecuados entre los componentes. Hemos visto por ejemplo, donde al escoger comunicación on line para un sistema que está pensado para recibir alto nivel de transacciones provoca que se caigan los servicios en momentos pico del mes ocasionando pérdida de continuidad del negocio, algo que se pudo evitar simplemente integrando a través de colas de espera y no procesando todo en línea en tiempo real.

NOSTROS en CONGERO entendemos la importancia y la necesidad de la integración de aplicaciones, es por eso que entre nuestras fortalezas y capacidades está el área de integración, el desarrollo de integración de aplicaciones, tanto aplicaciones on-prem, como soluciones cloud, así como la implementación de frameworks o herramientas de integración. Entendemos la importancia de la definición correcta de patrones de integración para situaciones como:

• Orquestación de órdenes de aprovisionamiento de servicios, tienes una orden que implica dar de alta el servicio en diversa plataformas u orquestar activaciones y notificaciones en diversos sistemas satélites, en estos casos la normalización de la información es fundamental, así como entender si el mejor modo de integración es on-line, fire and forget, colas, pub-subs, etc.
• Mediación de información, este escenario es muy normal donde una fuente de información sirve la información a varios destinos, o diversas fuentes sirven a un destino, sobre todo en el último escenario, varias fuentes un destino, es una buena práctica normalizar la información, definir un formato y una capa de integración de normalización para homologar conceptos, formatos, etc. Así por ejemplo, 
• Si tienes una telco que tiene diversas plataformas y en una plataforma un campo se llama contrato, en el otro número de teléfono, en el otro, account, en el otro cuenta, pero todos sirven al mismo y único fin a nivel de negocio, entonces tu capa de mediación lo llamará digamos, identificador de contrato y de ahí en adelante todos los que consuman la información entenderán que ese es el uso que le deben dar a ese campo, no importa de donde venga ni como lo llame el otro sistema.
•  Si tienes una distribuidora de agua o energía, y tienes diversas tecnologías de medición de diversos proveedores quienes le colocan un nombre distinto al medidor, ya sea, meterid, medidor, serviceid, servicio único, etc, etc, etc, entonces tu capa de mediación dirá este es el campo que identifica lo que yo como negocio llamo medidor, y entonces mediación lo bautiza de ahí en adelante y para todos los sistemas posteriores consumidores de la información como medidor.
•  Integración de aplicaciones cloud, ya sea cloud to cloud o one cloud, cada proveedor, sobre todos los más importantes de la industria han definido y puesto a disposición de sus clientes herramientas de procesamiento de datos que sirven a diversos fines, comunicación en tiempo real (lambda, google functions por ejemplo), streaming (stream analytics, AWS MSK, Kinesis, Google Data Flow, datastream, etc), procesamiento batch (data proc por ejemplo), entender cuando usar cual es fundamental en el desarrollo de una arquitectura de soluciones sostenible en el tiempo.

Con el paso del tiempo nos hemos convertido en verdaderos maestros de la integración, tanto de nuestras soluciones, como de soluciones de terceros, la razón: Entendemos la importancia del orden y la normalización, entendemos la influencia de estos aspectos y su impacto en el negocio.

Cómo se traduce todo lo anterior hacia el negocio:

El área de TI logrará responder de forma más rápida a la evolución natural del negocio, ya que su tecnología y arquitectura están pensadas para el futuro para la flexibilidad y el cambio. Imagina una arquitectura donde todo está atado, integrado de forma tal, que para hacer que un nuevo requerimiento legal sea cumplido, necesitas 5 meses de implementación y resulta que el cambio es solo agregar un campo más a la factura. Porque 5 meses, porque nadie entiende el espagueti de comunicación entre los componentes.

Responder de forma rápida al negocio implica que cada una de las aplicaciones o componentes de tu solución entienden el negocio y entienden su papel, por lo cual entienden que información servir y disponibilizar, por lo que la integración solo sirve y provee canales estándar para que esa información vaya del punto A al B de la forma más rápida, entendible y correcta posible.

La definición de una arquitectura de integración adecuada, así como la implementación de la misma están orientadas a buscar el Zero Downtime (siempre en línea), que en muchas ocasiones no se logra por errores de sobrecarga de servidores, lentitud de los mismos y otros problemas relacionados al procesamiento de volumen, algo fundamentalmente relacionado con la satisfacción del cliente y la calidad de entrega del servicio. Entender el patrón de carga, entender la naturaleza del negocio permitirá definir la forma de integrar las aplicaciones en cada punto de integración requerido.

¡Únete a nuestra red en LinkedIn y comparte tus ideas!