Integrando Soluciones y Su Impacto en el Negocio
Integrando Soluciones y Su Impacto en el Negocio
La integración de aplicaciones ha evolucionado, pasando de arquitecturas donde todos los sistemas se comunican entre sí, conocidas como arquitectura de espagueti, a lo que tenemos hoy: el establecimiento de buses de integración, la normalización y modelado de datos para la integración, así como el establecimiento de patrones de integración.
En el mundo tecnológico actual, incluyendo la nube, se han habilitado aún más tecnologías y herramientas, lo que a su vez ha conllevado al desarrollo de mejores prácticas de integración. Han surgido protocolos de integración específicos, tales como:
- SOAP
- HTTP-based REST API
- HTTP-based GraphQL
Si te detienes a pensar en la evolución de este texto desde el primer párrafo hasta estas letras, puedes apreciar que el cambio fundamental es un cambio de paradigma, pasando del desorden y la falta de estandarización (spaghetti) hacia la estandarización organizada. La razón: el orden ahorra tiempo y la estandarización previene la confusión.
Todos estos esfuerzos por estandarizar la integración de aplicaciones implican un gran esfuerzo, incluyendo la importancia de comprender la necesidad de definir y establecer una práctica adecuada para la integración de aplicaciones, y esta idea debe ser entendida por los miembros del equipo del proyecto y el resto de los participantes del proyecto.
En muchas ocasiones, hemos visto que cada equipo de aplicación que participa en una solución más grande se enfoca en cumplir y desarrollar solo los requisitos de su componente. Por lo tanto, la fase de integración se considera como algo genérico, donde las aplicaciones de destino solo necesitan cumplir con un formato de integración estándar y el API propuesto. Todo esto lleva a que se defina superficialmente la siguiente lista de elementos durante las fases de diseño:
- Patrones de integración entre aplicaciones
- Definición de los modelos de datos que rigen la integración
- Análisis detallado de los campos necesarios que deben enviarse de la aplicación A a la B, lo que generalmente causa una gran cantidad de retrabajo, y cuanta menos atención prestes a estos detalles, más retrabajo se genera.
Como se mencionó anteriormente, el punto anterior genera retrabajo en etapas posteriores del proyecto, ya que generalmente aparecen situaciones como las siguientes:
- Campos faltantes, lo que significa información que el sistema A no envía a B. Por ejemplo, información que en la fase de pruebas se identifica que el CRM no está enviando al sistema de facturación, o que el sistema de facturación no envía al ERP, información necesaria posteriormente para la facturación electrónica, la contabilidad, la correcta gestión de cobros, etc.
- Formatos incompatibles, existen muchos de estos, pero el ejemplo más común es el formato de fecha. El Sistema A definió AAAA-MM-DD, y el Sistema B definió AAAA-DD-MM. Esto causa problemas en futuros procesos que dependen de la fecha, como las fechas de corte, por ejemplo. MM/DD no es lo mismo que DD/MM. El primero sería el 3 de enero, el segundo sería el 1 de marzo, casi dos meses de diferencia debido a un error tan simple. Este error incluso podría llegar a producción si las pruebas no son exhaustivas.
Por lo tanto, considerar un espacio en el plan del proyecto y la definición de la solución para la integración de aplicaciones garantiza la minimización de estos y otros errores comunes, además de permitir:
- Estandarizar cómo se comunicarán las aplicaciones en el futuro, simplifica las fases de análisis si el nuevo requisito se adhiere a los estatutos o estándares de integración establecidos. Más importante aún, permite una arquitectura sostenible a lo largo del tiempo que posibilita la adaptación al futuro.
- Asegurar un rendimiento óptimo de la solución desde el inicio del proyecto se logra definiendo patrones de integración apropiados entre los componentes. Hemos visto, por ejemplo, cómo la elección de una comunicación en línea para un sistema que está diseñado para recibir un alto nivel de transacciones provoca que los servicios fallen en los momentos pico del mes, causando una pérdida de continuidad del negocio. Algo que podría haberse evitado simplemente integrando a través de colas y no procesando todo en línea en tiempo real.
En CONGERO, entendemos la importancia y la necesidad de la integración de aplicaciones. Por eso, entre nuestras fortalezas y capacidades se encuentra el área de integración, el desarrollo de la integración de aplicaciones, tanto en aplicaciones on-premises como en soluciones en la nube, así como la implementación de frameworks o herramientas de integración. Entendemos la importancia de definir los patrones de integración correctos para situaciones como:
- Orquestación de órdenes de aprovisionamiento de servicios: Tienes una orden que implica configurar el servicio en varias plataformas o orquestar activaciones y notificaciones en varios sistemas satélite. En estos casos, la estandarización de la información es fundamental, así como entender si el mejor método de integración es en línea (online), disparar y olvidar (fire and forget), colas, pub-subs, etc.
- Mediación de Información: Este es un escenario muy común, donde una fuente de información sirve información a varios destinos, o varias fuentes sirven a un destino. Especialmente en el último escenario, varias fuentes y un solo destino, es una buena práctica estandarizar la información, definir un formato y una capa de integración de normalización para estandarizar conceptos, formatos, etc. Así, por ejemplo, si tienes una telco que tiene varias plataformas y en una plataforma un campo se llama contract, en otra phone number, en otra account, pero todos sirven el mismo y único propósito a nivel de negocio, entonces tu capa de mediación lo llamará, por ejemplo, identificador de contrato, y a partir de ese momento todos los consumidores de información entenderán que ese es el uso que deben dar a ese campo, sin importar de dónde provenga o cómo lo nombre el otro sistema.
- Integración de Aplicaciones en la Nube, ya sea de nube a nube o dentro de una sola nube, cada proveedor, especialmente los más importantes en la industria, ha definido y puesto a disposición de sus clientes herramientas de procesamiento de datos que sirven para diversos propósitos: comunicación en tiempo real (lambda, google functions por ejemplo), streaming (stream analytics, AWS MSK, Kinesis, Google Data Flow, datastream, etc.), procesamiento por lotes (data proc por ejemplo). Entender cuándo usar cada una es fundamental para desarrollar una arquitectura de solución sostenible a lo largo del tiempo.
Con el tiempo, nos hemos convertido en verdaderos maestros de la integración, tanto para nuestras soluciones como para soluciones de terceros. La razón: Entendemos la importancia del orden y la estandarización, y comprendemos la influencia de estos aspectos y su impacto en el negocio.
¿Cómo se traduce todo lo anterior en el negocio?:
El área de TI podrá responder más rápidamente a la evolución natural del negocio, ya que su tecnología y arquitectura están diseñadas para el futuro, para la flexibilidad y el cambio. Imagina una arquitectura donde todo está atado e integrado de tal manera que para cumplir con un nuevo requisito legal, necesitas 5 meses de implementación, y resulta que el cambio es solo agregar un campo más a la factura. ¿Por qué 5 meses?, preguntará el equipo de negocio, y la respuesta, porque nadie entiende el espagueti de comunicación entre los componentes, pero esto es un secreto entre tú (el lector) y yo (el autor).
Responder rápidamente al negocio significa que cada uno de los componentes de la solución o equipos de aplicaciones entiende el negocio y su función, de modo que comprenden qué información deben servir y poner a disposición del negocio, de sus stakeholders y de sus clientes finales. Por lo tanto, la integración debe servir y proporcionar canales estándar para que la información pueda ir del punto A al B de la manera más rápida, comprensible y correcta posible.
La definición de una arquitectura de integración adecuada, así como su implementación, está orientada a buscar el Cero Tiempo de Inactividad (Zero Downtime) (estar siempre en línea), lo cual en muchos casos no se logra debido a errores de sobrecarga del servidor, lentitud del servidor y muchos otros problemas relacionados con el procesamiento de volumen, algo fundamentalmente relacionado con la satisfacción del cliente y la calidad en la entrega del servicio. Cuando se entiende el patrón de carga de trabajo (workload pattern) así como la naturaleza del negocio, se estará capacitado para definir adecuadamente cómo integrar aplicaciones en cada punto de integración requerido.
