Modelo de Información en la Nube

Bienvenido a CIM, un modelo de datos independiente de las aplicaciones que simplifica la integración y acelera la innovación.

Conclusiones clave

• CIM es un modelo de datos abierto y compartido, no un producto. Define conceptos de negocio comunes y sus relaciones para que diferentes aplicaciones puedan intercambiar datos sin mapeos personalizados y únicos.
• Se rige como un estándar abierto. CIM es de código abierto bajo la Joint Development Foundation, parte de la Linux Foundation, y da la bienvenida a contribuyentes de proveedores, empresas y la comunidad en general.
• El contenido está organizado en Áreas Temáticas (dominios). Cada dominio representa un concepto de negocio importante y se publica en múltiples formatos, incluidos diagramas, para que los arquitectos e ingenieros puedan adoptarlo de forma incremental.
• El valor central es reducir la fragilidad de la integración. Un modelo canónico reemplaza el código de traducción punto a punto con un destino estable al que muchos sistemas pueden mapear hacia y desde.
• La adopción es una decisión de diseño, no un interruptor. Usted elige qué dominios adoptar, cómo mapear sus sistemas de origen y cómo gobernar las extensiones a lo largo del tiempo.

Un nuevo estándar para la interoperabilidad de datos

CIM es producido por un consorcio abierto formado para ofrecer una solución basada en estándares para conectar productos empresariales. Con CIM, puede crear experiencias personales fluidas y personalizadas a través de aplicaciones nativas de la nube.

Para acelerar la transformación digital y ofrecer interacciones personalizadas a los clientes en todos los canales, muchas empresas adoptan múltiples aplicaciones locales y en la nube. Cada una viene con su propio modelo de datos, lo que obliga a los desarrolladores a crear, probar y administrar el código personalizado necesario para mapear y traducir datos entre diferentes sistemas. En lugar de acelerar la transformación digital, este proceso frena la innovación y conduce a integraciones frágiles.

CIM es una especificación moderna y abierta que ayuda a aliviar la dificultad de integrar datos. CIM proporciona un estándar definido para comunicarse fácilmente entre diferentes formatos de datos. De código abierto como parte de la Joint Development Foundation (bajo la Linux Foundation), damos la bienvenida a todos y cada uno de los contribuyentes.

El problema que aborda CIM es estructural, no incidental. Cuando cada sistema habla su propio dialecto —uno llama a un cliente “Contacto”, otro “Parte”, un tercero “Cuenta”— los equipos de integración terminan manteniendo una creciente red de mapeos por pares.

Cada nueva aplicación multiplica la cantidad de traducciones requeridas, y cada cambio de esquema en cualquier sistema puede propagarse y romper los flujos de datos posteriores. Un modelo canónico cambia la forma de ese problema: en lugar de que N sistemas se mapeen entre sí, cada sistema se mapea una sola vez a un vocabulario compartido.

Relacionado: Fivetran — El proceso ELT totalmente gestionado que sigue funcionando.

Por qué falla la integración punto a punto

Es útil ser concreto sobre los modos de falla que motivan un modelo compartido.

• Crecimiento combinatorio. Con mapeos punto a punto, el número de rutas de traducción crece aproximadamente con el cuadrado del número de sistemas. Agregar una décima aplicación es mucho más costoso que agregar la segunda.
• Deriva semántica. Dos equipos pueden “mapear al cliente” y aun así no estar de acuerdo sobre si un cliente es una persona, una organización o una relación de facturación. Los datos fluyen, pero el significado diverge.
• Gestión de cambios frágil. Un cambio de nombre de campo o un nuevo atributo requerido en un sistema de origen obliga a realizar ediciones en cada consumidor que lo utilice.
• Lógica duplicada. Las reglas de validación, deduplicación y resolución de identidad se vuelven a implementar en cada integración en lugar de definirse una sola vez.
• Presión de bloqueo del proveedor (vendor lock-in). Cuando la lógica de integración está entrelazada con el esquema de un proveedor específico, cambiar o agregar proveedores se convierte en un proyecto de replataformado.

Un modelo canónico como CIM no elimina el trabajo de mapeo; cada sistema fuente aún necesita un mapeo al modelo. Lo que elimina es la multiplicación de ese trabajo. Usted crea un mapeo por sistema hacia el modelo compartido, y el modelo en sí proporciona el contrato estable entre ellos.

Cómo está organizado CIM: Áreas Temáticas

El contenido definido de forma colaborativa se organiza en dominios, o Áreas Temáticas. Cada Área Temática representa un concepto de negocio importante. Los diseños de CIM están disponibles en varios formatos para cada dominio, incluidos diagramas de ejemplo. El número y alcance de las Áreas Temáticas crecerán con el consorcio y las contribuciones.

Nuestra elección: Workato — iPaaS basada en automatización que los equipos empresariales pueden aprovechar.

Esta estructura orientada al dominio es importante para la adopción. Rara vez necesitará todo el modelo a la vez. Una empresa típica comienza con los dominios que afectan a su integración más problemática, prueba el enfoque y se expande. Los puntos de partida comunes tienden a ser los conceptos que aparecen en casi todos los sistemas:

• Parte / Cliente — las personas y organizaciones con las que hace negocios, y los roles que desempeñan.
• Producto — lo que vende, ofrece o gestiona, incluidos catálogos y clasificaciones.
• Cuenta y relación — cómo se relacionan las partes con los productos, los contratos y entre sí.
• Interacción y actividad — los eventos, transacciones e interacciones que conectan lo anterior.

Debido a que cada Área Temática se publica con diagramas y múltiples formatos de representación, los arquitectos pueden revisar el modelo conceptual, los ingenieros pueden consumir una forma legible por máquina y las partes interesadas del negocio pueden validar que los conceptos coincidan con la realidad. Ese enfoque multiformato es una elección de diseño deliberada: un modelo que solo los ingenieros pueden leer tiende a desviarse del significado de negocio.

Cómo se compara CIM con otros enfoques

CIM es una opción entre varias para lograr la interoperabilidad. Elegir bien significa comprender las compensaciones.

Enfoque	Qué es	Fortalezas	Trade-offs
Mapeo punto a punto	Traducciones directas entre cada par de sistemas	Sencillo para dos sistemas; no se necesita gobernanza compartida	Crece combinatoriamente; frágil; lógica duplicada
Modelo canónico (estilo CIM)	Un vocabulario compartido e independiente de las aplicaciones al que se mapea cada sistema	Esfuerzo de mapeo lineal; contrato estable; reutilizable en diversos proyectos	Requiere gobernanza y acuerdo; aún se necesita mapeo por sistema
Estándares de datos de la industria	Estándares verticales para un sector específico (p. ej., salud, finanzas)	Cobertura profunda del dominio; alineación regulatoria	Alcance limitado; puede no cubrir conceptos empresariales intersectoriales
Modelos de datos de proveedores	El esquema nativo de una plataforma expuesto como el centro de integración	Estrecha integración de herramientas; rápido dentro del ecosistema de un proveedor	Riesgo de bloqueo (lock-in); otros proveedores deben ajustarse al modelo de una sola parte
API-first / esquema en lectura	Contratos definidos por API; el significado se resuelve en el momento del consumo	Flexible; rápido de iniciar	La coherencia semántica depende de la disciplina; más difícil de gobernar a escala

La guía práctica: utilice un modelo canónico cuando tenga muchos sistemas, conceptos transversales a dominios y un panorama de integración de larga duración. Utilice el mapeo punto a punto cuando el alcance sea genuinamente de dos sistemas y de corta duración. Los estándares de la industria y el CIM son complementarios: un estándar vertical puede informar un dominio, mientras que el CIM proporciona el vocabulario empresarial transversal.

Cómo adoptar CIM en la práctica

La adopción es una secuencia de decisiones deliberadas más que una única migración. Un patrón viable se ve así:

1. Elija una integración con mucho “dolor” y bien delimitada. Elija un dominio donde la dificultad del mapeo sea real y el alcance sea lo suficientemente pequeño como para demostrar el valor rápidamente.
2. Haga un inventario de los sistemas fuente y sus esquemas. Documente cómo llama cada sistema a los conceptos en el Área Temática elegida y en qué puntos discrepan.
3. Mapee cada sistema al dominio CIM. Cree un mapeo por sistema hacia el modelo compartido. Trate estos mapeos como artefactos versionados, no como scripts desechables.
4. Defina su política de extensión desde el principio. Decida cómo manejará los conceptos que el CIM aún no cubre; las extensiones deben documentarse, nombrarse de manera consistente y proponerse al consorcio cuando sean ampliamente útiles.
5. Establezca la gobernanza. Asigne la propiedad de los mapeos, un proceso de revisión de cambios y una cadencia para la sincronización con las actualizaciones ascendentes de CIM.
6. Amplíe dominio por dominio. Reutilice los patrones de mapeo y la gobernanza del primer dominio para reducir el costo del siguiente.

Vale la pena mencionar dos advertencias claramente. Primero, un modelo canónico agrega una capa: no es gratuito, y la recompensa proviene de la reutilización en muchas integraciones, no de una sola. Segundo, el mapeo es donde reside el trabajo real; el modelo le brinda un objetivo estable, pero alguien todavía tiene que decidir cómo corresponde cada campo fuente a este, y esa decisión se beneficia de la aportación del negocio, no solo de la ingeniería.

Relacionado: Matillion — ELT push-down creado para almacenes de datos en la nube.

Gobernanza, Licencias y Contribuciones

CIM es de código abierto como parte de la Joint Development Foundation, que opera bajo la Linux Foundation. Esa estructura es importante para las empresas que la evalúan: la Linux Foundation es un hogar bien establecido para proyectos de código abierto colaborativos y neutrales respecto a los proveedores, y la Joint Development Foundation proporciona un marco legal diseñado específicamente para desarrollar y operar estándares y proyectos de especificaciones.

Para un arquitecto de datos empresariales, las implicaciones prácticas de este modelo de gobernanza son:

• Neutralidad del proveedor. Ningún proveedor controla la especificación, lo que reduce el riesgo de que el modelo esté diseñado para favorecer a una plataforma.
• Contribución abierta. Cualquiera puede proponer cambios, lo que significa que el modelo puede evolucionar para reflejar las necesidades de integración del mundo real en lugar de una única hoja de ruta.
• Proceso orientado a la especificación. El modelo de la Joint Development Foundation se basa en la producción y el mantenimiento de especificaciones, lo que se alinea con la forma en que se adoptan y referencian los estándares en las revisiones de adquisiciones y arquitectura.

Se anima a contribuir y está abierto a todos. Las contribuciones suelen tomar la forma de Áreas Temáticas nuevas o refinadas, correcciones y aclaraciones, diagramas de ejemplo y comentarios de proyectos de integración reales. Las contribuciones más valiosas a menudo provienen de profesionales que se han topado con un problema de mapeo específico y pueden describir el concepto que lo resuelve.

Si estás de compras: Boomi AtomSphere — iPaaS empresarial para la integración híbrida de la nube a las instalaciones.

Cómo involucrarse

¿Está interesado en unirse a la iniciativa CIM? ¡Genial! No dude en enviarnos un correo electrónico para obtener más información.

Más allá del correo electrónico, las formas naturales de participar son revisar las Áreas Temáticas publicadas para su dominio de interés, intentar mapear uno de sus sistemas a un dominio y reportar las brechas que encuentre a la comunidad. Debido a que el número y el alcance de las Áreas Temáticas crecen con el consorcio y las contribuciones, el modelo mejora en proporción a cuántos problemas reales de integración le traigan sus usuarios.

Preguntas frecuentes

¿Qué es exactamente el Cloud Information Model?

CIM es un modelo de datos abierto e independiente de las aplicaciones que define conceptos de negocio comunes y sus relaciones para que diferentes aplicaciones puedan intercambiar datos a través de un vocabulario compartido. Es producido por un consorcio abierto y publicado como una especificación abierta. En lugar de ser un producto que se instala, es un modelo al que se mapean los sistemas.

¿Para quién es CIM?

Está dirigido a arquitectos de datos empresariales, ingenieros de integración y ETL, proveedores de aplicaciones y plataformas, y contribuyentes de código abierto. Cualquier persona que tenga que conectar múltiples sistemas en la nube y locales con diferentes esquemas es un usuario potencial. Los proveedores se benefician porque un modelo compartido reduce el trabajo personalizado necesario para integrarse con sus productos.

¿Cómo se gobierna y bajo qué licencia está CIM?

CIM es de código abierto como parte de la Joint Development Foundation, que opera bajo la Linux Foundation. Esto proporciona un marco de gobernanza orientado a especificaciones y neutral respecto al proveedor. Esa estructura tiene como objetivo mantener el modelo abierto a contribuciones e independiente del control de un solo proveedor.

¿En qué se diferencia CIM del modelo de datos nativo de un proveedor?

El modelo nativo de un proveedor está optimizado para el producto y ecosistema de ese proveedor; adoptarlo como su centro de integración tiende a crear una dependencia del proveedor (lock-in). CIM está diseñado para ser agnóstico a la aplicación, por lo que ninguna plataforma define el vocabulario. La contrapartida es que CIM requiere gobernanza y acuerdo entre los equipos, mientras que un modelo de proveedor está listo para usarse dentro de las herramientas de ese proveedor.

¿Sigo necesitando escribir mapeos si uso CIM?

Sí. Cada sistema fuente sigue necesitando un mapeo al modelo compartido. La ventaja es que se escribe un mapeo por sistema hacia CIM en lugar de una traducción separada para cada par de sistemas. Esto convierte el esfuerzo de mapeo combinatorio en un esfuerzo aproximadamente lineal y le brinda un contrato estable que sobrevive a los cambios en los sistemas individuales.

¿Cómo empiezo a adoptar CIM?

Comience con una única integración de alta criticidad y bien delimitada en un Área Temática (Subject Area). Realice un inventario de los esquemas de origen, mapee cada sistema al dominio CIM, defina una extensión y una política de gobernanza, y trate los mapeos como artefactos versionados. Una vez que el primer dominio demuestre su valor, expanda dominio por dominio, reutilizando los patrones y la gobernanza que estableció.

Lectura adicional

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia