Las empresas que triunfan en la era digital son a menudo las que han mejorado su integración de datos, yendo más allá de simplemente recolectar y extraer datos.

Estas empresas están integrando datos de varios silos aislados para aprovechar los datos en la inteligencia de negocios que puede impulsar la toma de decisiones vitales y mejora los procesos internos.

Sin embargo, la integración de datos no es fácil, especialmente cuanto más grande sea su empresa y más sistemas de software de los que dependa. Luego, considera la realidad de la mayoría de las arquitecturas empresariales: con menor frecuencia es una arquitectura intencional y, con mucha mayor frecuencia, un mosaico de diversas aplicaciones y ecosistemas, desde sistemas heredados hasta nuevas herramientas.

Algunos están construidos y son de propiedad interna, mientras que otros dependen de proveedores externos. Cada vez más, las empresas necesitan compartir datos en todos estos sistemas.

El problema es qué tan difícil es compartir datos cuando cada sistema tiene diferentes lenguajes, requisitos y protocolos, y usted considera las muchas iteraciones de un sistema hablando con otro.

Una solución podría ser el modelo de datos canónicos (CDM), que estamos explorando en este artículo.

 

Definiendo CDM

Los modelos de datos canónicos son un tipo de modelo de datos que tiene como objetivo presentar las entidades de datos y las relaciones en la forma más simple posible para integrar los procesos en varios sistemas y bases de datos. La mayoría de las veces, los datos intercambiados a través de varios sistemas se basan en diferentes lenguajes, sintaxis y protocolos.

Un CDM también se conoce como un modelo de datos común.

El propósito de un CDM es permitir que una empresa cree y distribuya una definición común de toda su unidad de datos. Esto permite una integración más suave entre los sistemas, lo que puede mejorar los procesos y también facilita la extracción de datos.

Es importante destacar que un modelo de datos canónicos no es una fusión de todos los modelos de datos. En cambio, es una nueva forma de modelar datos que es diferente de los sistemas conectados. Este modelo debe poder contener y traducir los otros tipos de datos.

Un enfoque CMD puede y debe incluir cualquier tecnología que la empresa utilice, incluidas las plataformas ESB (bus de servicio empresarial) y BPM (gestión del rendimiento / proceso empresarial), otras SOA (arquitectura orientada a servicios) y cualquier rango de herramientas y aplicaciones más específicas.

Esta estandarización es buena: todos en la empresa, incluido el personal no técnico, pueden ver que el tiempo que se tarda en traducir los datos entre los sistemas a tiempo se gasta mejor en otros proyectos.

Construyendo un modelo de datos canónico

Puede sentir la tentación de utilizar un modelo de datos existente de un sistema de conexión como base de su CMD.

Los expertos advierten contra este aparente atajo. Si el sistema que es la base de su modelo cambia alguna vez, incluso a una versión más nueva, es posible que se quede atrapado utilizando viejos modelos de datos y un sistema desactualizado, lo que anula el beneficio de la flexibilidad para la que están diseñados los CDM. También puede tener problemas con las licencias.

Los desarrolladores que tratan de manejar varios modelos de datos similares también pueden dedicar más tiempo a tratar de descifrar las diferencias, lo que puede generar más errores de los usuarios. Si opta por un modelo de datos canónicos, probablemente sea su mejor opción crear su modelo desde cero. Concéntrese en la flexibilidad para que pueda obtener el propósito del CDM: cambios fáciles a medida que la arquitectura de su empresa cambia necesariamente.

Beneficios de emplear un MDL

Las empresas que pueden emplear con éxito un MDL se benefician de las siguientes situaciones:

  • Realizar menos traducciones.

Sin un CDM, cuantos más sistemas tenga, más traducciones de datos debe hacer manualmente. Con un CDM en su lugar, reduce el trabajo manual que requiere la integración de datos y limita las posibilidades de error del usuario.

  • Mejora el mantenimiento de la traducción.

A nivel empresarial, los sistemas serán inevitablemente reemplazados por otros sistemas, ya sean nuevas versiones o SOA de proveedores que reemplacen los sistemas heredados. Cuando solo cambia un sistema, solo necesita verificar las traducciones hacia y desde el CDM. Si no está empleando un MDL, puede pasar mucho más tiempo verificando las traducciones en cualquier otro sistema.

  • Mejora el mantenimiento de la lógica.

En un MDL, la lógica se escribe dentro del modelo canónico, por lo que no hay dependencia de ningún otro sistema. Al igual que el mantenimiento de la traducción, cuando cambia un sistema, solo necesita verificar la lógica del nuevo sistema dentro de la lógica del CDM, no con cualquier otro sistema con el que su nuevo sistema pueda necesitar comunicarse.

Construir un único modelo de datos que pueda acomodar múltiples protocolos de datos e idiomas requiere un enfoque de toda la empresa que puede tomar mucho tiempo y recursos. Desde una perspectiva ejecutiva, la inversión de tiempo y dinero puede ser demasiado significativa como para asumirla a menos que haya un cambio real tangible para el usuario final, que puede no ser el caso cuando se construye un CDM.

Otros críticos de emplear CDM argumentan que es un enfoque teórico que no funciona cuando se aplica de manera práctica. Un proyecto tan grande como este a menudo requiere mucho tiempo y recursos, precisamente porque es difícil de manejar.

 

La inflexibilidad de hacer que cada servicio se ajuste a un modelo de datos específico significa que puede perder los mejores usos de casos para algunos sistemas. De hecho, estos sistemas pueden beneficiarse de especificaciones menos estrictas, no del objetivo único de un enfoque canónico.

 

Estos expertos recomiendan que un arquitecto empresarial aborde la idea de un CDM de forma diferente: si le gusta el objetivo de la coherencia de los datos, considere estandarizar formatos y fragmentos de estos modelos de datos, como pequeñas piezas XML o JSON que ayudan a estandarizar pequeñas agrupaciones de atributos. Una menor centralización permitirá que las partes independientes determinen qué es lo mejor: los equipos deberían optar por un enfoque CDM, en lugar de una decisión descendente en la que todos se vean obligados a crear un modelo de datos canónico.

 

Los CDM pueden beneficiar a su compañía dependiendo del tamaño y las necesidades de sus datos. Si puede dedicar tiempo a un proyecto de ese tipo, cuantos más sistemas y aplicaciones necesiten compartir datos, más esquivo será el modelo canónico de un solo tamaño.

 

Noticia: BMC