Framework de Integración Omnicanal — Caso de Estudio Laboral

Problema

Cada canal de chat empresarial — Slack, Microsoft Teams, Google Chat, Webex — comenzó como una integración personalizada. Cuando el código de fulfillment hace bifurcaciones según el canal, estás manteniendo N productos que se van separando bajo presión de tiempo.

Mi rol

Diseñé e implementé el framework de integración basado en el Método de Fábrica y las utilerías compartidas de pruebas sobre las que se construye cada adaptador de canal. Esta es la columna vertebral contra la que se escribe cada canal en la plataforma, incluyendo voz. El objetivo de diseño fue una interfaz que no diga nada sobre cuándo llega una respuesta: los canales de chat son asincrónicos, una llamada telefónica es sincrónica y bloqueante, y ambos son adaptadores detrás de la misma fábrica. Una abstracción que solo funciona para canales que comparten un modelo de tiempo no es un framework de integración, es un framework de chat.

Restricciones

• Los canales difieren en modelos de autenticación, formatos de payload y límites de tasa — las diferencias tenían que permanecer dentro de los adaptadores.
• Las integraciones existentes en producción tenían que seguir funcionando mientras el framework las reemplazaba por debajo.
• Los patrones seguros por defecto (autenticación, MFA, manejo de secretos) eran requisitos indispensables para clientes empresariales.

Arquitectura

Los adaptadores de canal normalizan cada mensaje entrante en un sobre común; un Método de Fábrica instancia el adaptador correcto por canal; el código de fulfillment opera sobre intenciones y entidades y nunca hace bifurcaciones según el canal. Las utilerías compartidas de pruebas le dan a cada nuevo adaptador la misma suite de conformidad desde el primer día.

Resultado

Slack, Microsoft Teams, Google Chat y Webex corren todos sobre una sola columna vertebral, y cada nuevo canal cuesta menos que el anterior. Cero vulnerabilidades críticas mantenidas en estas integraciones empresariales durante dos años.

Lo que haría diferente

Definir el esquema de intenciones compartido desde el día uno y versionarlo como una API — fusionar definiciones divergentes de intenciones después es el camino costoso. Construir el adaptador al final: primero lograr el sobre compartido y la historia de pruebas bien definidos.