Hoy en día, muchas empresas -especialmente las globales- tienen múltiples aplicaciones y sistemas separados, donde los datos que cruzan los departamentos o divisiones de la organización pueden fragmentarse, duplicarse y quedar desfasados rápidamente. La situación se complica aún más cuando estas empresas adquieren otras organizaciones y añaden nuevos sistemas a su ecosistema existente.
Como se puede imaginar, es un reto entender qué datos son «correctos» y cómo utilizarlos para construir una visión de 360 grados del cliente. Este es un reto común con una solución conocida: la gestión de datos maestros o MDM.
Un aspecto clave del MDM es la conexión técnica entre todos los sistemas. Si no se planifica bien, esto puede resultar muy complejo e inmanejable. MuleSoft ofrece una forma eficaz de abordar esta complejidad con la conectividad basada en API, que se construye hacia una red de aplicaciones.
Un escenario de ejemplo: Analicemos la situación en el escenario que se muestra en la imagen 1 a continuación:
Hay dos aplicaciones, un portal web para clientes (CWP) y una aplicación de servicio interna (ISA), que operan con datos almacenados en los sistemas A, B y C.
Sin MDM, el CWP tendría que encargarse de mantener sincronizados los datos de la entidad E01 en los sistemas A y B y utilizar la entidad E02 sólo del sistema A. Por otro lado, la ISA utiliza los datos E01 y E02 de los tres sistemas y necesita asegurarse de que tiene la información correcta y también necesita mantener los datos sincronizados.
Esta complejidad en el procesamiento suele provocar conflictos en la coherencia de los datos, lo que a su vez provoca errores en las aplicaciones CWP e ISA. Estos errores pueden confundir a los usuarios, disminuir su confianza en la integridad del sistema y poner en peligro la adopción de ambas aplicaciones.
En una arquitectura basada en API, CWP e ISA han definido puntos de entrada a través de APIs de experiencia designadas, cada una de las cuales se rige por políticas para controlar y proteger los datos.
Este escenario de arquitectura desvincula las aplicaciones de los repositorios de datos. No es necesario que sepan dónde residen los datos, lo que simplifica el proceso de desarrollo de estas aplicaciones.
¿Cómo obtienen las APIs de experiencia los datos «correctos»? Aquí es donde entra en juego la gestión de datos maestros. Utilicemos los patrones comunes de MDM para discutir esto en detalle:
- Estilo de registro
- Consolidación
- Centralización
- Coexistencia
#1 Estilo de registro
Con un enfoque de estilo de registro para MDM, todos los datos de un sistema se almacenan y gestionan dentro de ese sistema en particular utilizando su estructura propietaria.
La solución de registro de MDM es el «maestro»: mantiene un directorio de los registros y la ubicación de cada conjunto de datos dentro de los distintos sistemas utilizando los ID de registro específicos del sistema. El registro también define las prioridades para las operaciones de lectura y escritura. En un enfoque MDM de estilo de registro, una arquitectura dirigida por la API tendría el aspecto del diagrama siguiente:
En este diseño, las APIs de proceso orquestan el acceso para las operaciones de lectura y escritura. Como primer paso, las APIs de proceso obtienen metadatos del registro sobre cualquier registro específico que esté conectado a la solicitud original de las APIs de experiencia. Esta información indica a las APIs de proceso, qué sistemas de registro alojan los datos en cuestión, y qué reglas deben aplicarse al satisfacer este tipo de solicitud.
Para las operaciones de lectura, el flujo es el siguiente:
- Las APIs de experiencia solicitan datos a las APIs de proceso
- Las APIs de proceso se conectan con el registro como se ha descrito
- Las APIs de proceso solicitan a las APIs de sistema los datos basados en la información del registro
- A continuación, las APIs de proceso crean la respuesta a la API de experiencia utilizando las reglas recibidas del registro
Para las operaciones de escritura, por otro lado, es necesario utilizar un enfoque mejorado para manejar los posibles errores de escritura en los sistemas. El flujo es el siguiente:
- Las APIs de experiencia envían los datos a las APIs de proceso
- Las APIs de proceso se conectan con el registro como se ha descrito anteriormente
- Las APIs de procesos envían los datos mediante una orquestación segura de transacciones a las APIs del sistema, de acuerdo con las reglas devueltas por el registro
- Las APIs de proceso actualizan el registro con un nuevo estado de los datos y luego responden a las APIs de experiencia con el estado de ejecución
# 2 Consolidación
Un modelo MDM de consolidación proporciona una solución especializada con almacenamiento dedicado y suficiente para albergar los «registros de oro» de cada información. Los registros de oro son datos de alta calidad que añaden valor a todos los procesos empresariales que los utilizan y ayudan a formar una visión de 360 grados.
La solución MDM de estilo de consolidación recibe las actualizaciones de los sistemas de cada entidad gestionada. A continuación, siguiendo procesos técnicos y humanos, esta información se consolida en el registro de oro; de hecho, esta capacidad es nativa de una solución MDM.
Todas las aplicaciones que utilizan los datos los recuperan desde un único punto de almacenamiento, sin embargo, los sistemas no se actualizan desde el sistema MDM.
Así es como fluirían los datos utilizando las API:
Para las operaciones de lectura, el flujo es el siguiente:
- Las APIs de experiencia solicitan datos a las APIs de proceso
- Las API de procesos recuperan el «registro de oro» del almacenamiento MDM a través de la API del sistema MDM
- Las APIs de experiencia reciben la respuesta de las APIs de proceso
Para las operaciones de escritura:
- Las APIs de experiencia envían los datos a las APIs de proceso
- Las API de procesos envían los datos a la API del sistema MDM, que actualiza el sistema MDM
- Las APIs de proceso actualizan entonces el sistema de origen respectivo (y sólo esto)
Si los datos se actualizan en el Sistema A, B o C directamente, entonces se empujan a través de las APIs de Sistema y Proceso al MDM.
#3 Centralizado
Centralizado significa que todos los datos se sincronizan entre los sistemas, manteniendo una solución centralizada que almacena el «registro de oro». Al igual que en el modelo anterior, la solución MDM es responsable de la calidad y el almacenamiento del registro de oro. Lo que hace único a este modelo es que todos los sistemas se sincronizan con la versión más actual. Un aspecto clave aquí es que los modelos de datos del sistema A, B y C deben modificarse para poder almacenar todo el ancho de datos.
Las API tienen un aspecto similar al de la imagen 6, y el proceso de lectura es idéntico al comentado para el modelo de consolidación:
El proceso de Escritura actualiza el registro de oro en el sistema MDM central, también idéntico al modelo de consolidación – actualiza el registro en el MDM central primero.
Y luego, sí se ejecuta un proceso de consolidación de datos:
- La API del sistema MDM se invoca desde el sistema MDM con los datos actualizados
- A continuación, se invoca un flujo de la API de procesos para la distribución de datos. Éste enviará las respectivas actualizaciones a los sistemas A, B y C (a través de sus API) y responderá a la solución MDM con el estado
Cualquier cambio de datos en el sistema A, B, C también invoca la API del sistema enviando la actualización al MDM. A continuación, se redistribuirá mediante el proceso de consolidación.
Mientras que las APIs para el estilo centralizado se parecen al estilo de consolidación en el nivel esquemático, la lógica interna es más compleja para acomodar la sincronización completa de datos.
#4 Coexistencia
Este patrón es una combinación de enfoques de consolidación y centralizados. Esto significa que puede haber sistemas que requieran el registro de datos completo y consistente, pero que no estén necesariamente habilitados para la sincronización en tiempo real.
Los componentes principales son muy similares a los de las imágenes 6 y 8, con dos cambios: El sistema C no permite la actualización de datos en tiempo real. Por lo tanto, para mantenerlo sincronizado, la API de sincronización por lotes gestiona el flujo de datos desde la solución MDM central hasta el sistema C.
Hacer MDM plug-n-play con API-led
¿Cuál es la ventaja de un enfoque basado en API en el contexto de MDM? Imagínese que su organización ha configurado su solución utilizando este paradigma. Entonces API-led ayuda a que MDM se acerque más a plug-n-play para incluir un nuevo sistema D en el panorama, como puede ver en la Imagen 11.
Introduce el nuevo Sistema API D y lo conecta con una nueva versión del Proceso API E02. Y, sin olvidar, la necesaria mejora de la configuración en la solución MDM.
Obtenga más información sobre cómo un enfoque basado en API puede resolver los retos de la gestión de datos poniéndose en contacto con nuestros especialistas de MuleSoft que se lo explicarán y demostrarán.
Esto es una adaptación al castellano del interesante post publicado por Mulesoft en su blog en inglés: «API-led connectivity vs. MDM: How to use them together«
