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 e independiente de las aplicaciones: un vocabulario compartido de conceptos de negocio (clientes, pedidos, productos, etc.) que permite que diferentes sistemas locales y en la nube intercambien datos sin un mapeo personalizado punto a punto.
• Existe para resolver un problema específico y costoso: cada aplicación incluye su propio modelo de datos, por lo que los equipos de integración terminan escribiendo y manteniendo un código de traducción personalizado que es frágil y ralentiza la innovación.
• Se rige como un estándar abierto, producido por un consorcio y distribuido como código abierto bajo la Joint Development Foundation, parte de la Linux Foundation, por lo que cualquiera puede contribuir, revisarlo y adoptarlo.
• El contenido está organizado en Áreas Temáticas (dominios), cada una de las cuales representa un concepto de negocio importante, con diseños publicados en múltiples formatos, incluidos diagramas de ejemplo.
• CIM es un modelo, no un producto. Define el significado y la estructura; usted sigue eligiendo cómo mapear, almacenar y mover los datos en sus propios sistemas.

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 a medida 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. Al ser 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.

Por qué fallan los modelos de datos específicos de aplicaciones

El problema principal que aborda CIM no es que una sola aplicación tenga un modelo de datos incorrecto. La mayoría son perfectamente razonables dentro de sus propios límites. El problema es la explosión combinatoria que ocurre cuando se conectan muchas de ellas.

Considere una pila empresarial típica: un CRM, un ERP, una plataforma de automatización de marketing, un centro de soporte, un almacén de datos y un puñado de herramientas SaaS de línea de negocio. Si cada sistema tiene su propia noción de “cliente”, “cuenta”, “pedido” y “producto”, entonces cada par de sistemas que necesita compartir datos requiere su propio mapeo. El número de integraciones crece aproximadamente con el cuadrado del número de sistemas, y cada mapeo es una pequeña pieza de lógica, indocumentada y sin dueño, que alguien debe mantener para siempre.

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

Los síntomas son familiares para cualquiera que haya dirigido una práctica de integración:

• Deriva semántica. “Cliente” en el CRM significa una entidad de facturación; en el centro de soporte significa una persona que abre tickets. La misma palabra, dos significados, reconciliados silenciosamente por un mapeo que nadie recuerda haber escrito.
• Canalizaciones frágiles. Un proveedor cambia el nombre de un campo o modifica una enumeración, y un trabajo de ETL falla a las 2 a. m. porque el mapeo estaba codificado rígidamente según la estructura anterior.
• Esfuerzo duplicado. Dos equipos crean de forma independiente traducciones casi idénticas entre los mismos dos sistemas porque no hay una referencia compartida a la cual remitirse.
• Dependencia del proveedor por los datos (Vendor lock-in). Migrar fuera de una plataforma es costoso no por el software, sino por la lógica de traducción acumulada ligada a su esquema.

Un modelo compartido e independiente de la aplicación ataca la causa raíz: en lugar de mapeos N a N, cada sistema se mapea una sola vez a un modelo común, y el modelo común es el que porta el significado.

Qué significa realmente “independiente de la aplicación”

Vale la pena ser precisos sobre la filosofía de diseño, porque el término “agnóstico” a menudo se usa de manera vaga.

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

Un modelo independiente de la aplicación no es propiedad de ningún producto de un proveedor específico ni está optimizado para él. Describe conceptos de negocio en términos que serían reconocibles para un experto en el dominio —un cliente, un pedido, un producto, una ubicación— en lugar de términos que reflejen las tablas internas de una aplicación. Esa neutralidad es lo que lo convierte en un hub útil: ningún participante tiene que adoptar la visión del mundo de un competidor para interoperar.

Este es el mismo instinto arquitectónico detrás de otros estándares de intercambio neutrales. Así como el Resource Description Framework (RDF) y schema.org le dan a la web un vocabulario compartido para describir cosas, y así como EDI y más tarde UBL (Universal Business Language, un estándar de OASIS) dieron a las cadenas de suministro un formato compartido para las transacciones, CIM aspira a brindar a las aplicaciones empresariales un vocabulario compartido para sus entidades de negocio principales. La diferencia es el alcance y la modernidad: CIM se dirige al mundo conectado, impulsado por API, tanto en la nube como local, en lugar del intercambio de archivos por lotes.

Un modelo mental útil es el patrón de modelo de datos canónico de la integración empresarial, popularizado en Enterprise Integration Patterns de Gregor Hohpe y Bobby Woolf. CIM es, en efecto, un modelo canónico mantenido colaborativamente —el “hub” en una topología de integración de estrella (hub-and-spoke)— pero uno que es abierto, versionado y compartido entre organizaciones en lugar de ser inventado privadamente dentro de una sola empresa.

Cómo se organiza CIM: Áreas Temáticas y dominios

El contenido definido colaborativamente 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 múltiples formatos para cada dominio, incluidos diagramas de ejemplo. El número y el alcance de las Áreas Temáticas crecerán junto con el consorcio y las contribuciones.

En la práctica, esto significa que debería pensar en CIM como una biblioteca de modelos relacionados en lugar de un único esquema monolítico. Las áreas temáticas típicas se agrupan en torno a preocupaciones comerciales reconocibles; por ejemplo, partes y cuentas, productos y catálogos, pedidos y transacciones, y las relaciones que los unen. Debido a que cada área se publica con diagramas y definiciones legibles por máquina, diferentes equipos pueden adoptar diferentes áreas en diferentes momentos sin esperar a que se complete todo el modelo.

De esta estructura se desprenden algunas implicaciones prácticas:

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

• Adopte de forma incremental. No es necesario mapear toda su empresa a CIM desde el primer día. Comience con el área temática que cause más problemas —generalmente el dominio del cliente o del pedido— y amplíe.
• Extienda en lugar de bifurcar. Cuando CIM carece de un concepto que usted necesita, el modelo abierto está diseñado para ser extendido. Es preferible aportar una extensión que mantener una bifurcación (fork) privada, porque una bifurcación se desvía y pierde el beneficio de la interoperabilidad.
• Trate los diagramas como documentación, no como la fuente de verdad. Los diagramas de ejemplo son para humanos; las definiciones legibles por máquina son lo que sus herramientas deben consumir.

CIM en el panorama de la integración: cómo decidir

CIM es una opción entre varias para domar la complejidad de la integración. Elegir bien requiere adaptar la herramienta al problema. La siguiente tabla contrasta los principales enfoques que suele sopesar un arquitecto de datos empresariales.

Enfoque	Qué es	Mejor cuando	Principal compensación
Mapeo punto a punto	Código personalizado que traduce directamente entre dos sistemas	Solo dos sistemas, esquemas estables, horizonte corto	No escala; explosión N-a-N; frágil
Modelo canónico (p. ej., CIM)	Un modelo compartido y neutral al que cada sistema se mapea una sola vez	Muchos sistemas, entre distintos proveedores, integración de larga duración	Esfuerzo inicial de modelado; requiere gobernanza
Conectores iPaaS del proveedor	Conectores preconstruidos de una plataforma de integración	Pares de SaaS comunes, prioridad de velocidad sobre control	Semántica específica del conector; potencial bloqueo (lock-in)
Estándares de intercambio de la industria (EDI, UBL, HL7, etc.)	Formatos de mensajes específicos de un dominio	Verticales regulados o bien establecidos	Alcance limitado; a menudo orientado a lotes
Virtualización / federación de datos	Consultas entre fuentes sin centralizar	Analítica, acceso mayoritariamente de lectura	No resuelve los conflictos semánticos por sí solo

La heurística de decisión es sencilla: si tiene más de un puñado de sistemas que deben estar de acuerdo en el significado de entidades compartidas, y esos sistemas provienen de diferentes proveedores, un modelo canónico se amortiza solo. Si tiene dos sistemas y no planea agregar más, el mapeo punto a punto está bien. Si su necesidad es puramente analítica y de solo lectura, la federación puede ser suficiente, pero tenga en cuenta que la federación desplaza el problema semántico en lugar de resolverlo.

CIM es complementario, no un reemplazo, de las herramientas que lo rodean. Un pipeline de ETL o ELT (construido con algo como Apache Airflow, dbt o una plataforma comercial) sigue encargándose del movimiento; CIM define lo que significan los datos una vez que llegan. Un bróker de mensajes como Apache Kafka sigue encargándose del transporte; CIM define la forma de los eventos. El modelo es el contrato; las herramientas son la plomería.

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

Gobernanza, licencias y por qué la fundación es importante

CIM es de código abierto como parte de la Joint Development Foundation, que opera bajo la Linux Foundation. Este no es un detalle trivial: es fundamental para que una empresa pueda construir sobre CIM de manera segura.

La Linux Foundation es un hogar neutral bien establecido para proyectos colaborativos de código abierto, y la Joint Development Foundation proporciona una estructura legal ligera para desarrollar estándares y especificaciones de forma colaborativa. Alojar CIM allí significa:

• Administración neutral. Ningún proveedor controla el modelo, por lo que adoptarlo no significa adoptar la hoja de ruta de un competidor.
• Contribución abierta. Cualquiera —proveedores, empresas, contribuyentes individuales— puede proponer cambios, y el proceso es transparente.
• Licencias predecibles. Las especificaciones alojadas por la Fundación generalmente llevan términos diseñados para una adopción amplia y libre de regalías, lo cual es de gran importancia para los equipos legales y de adquisiciones que evalúan un estándar.

Para un arquitecto que defiende el caso internamente, esta historia de gobernanza suele ser tan importante como el contenido técnico. “Es un estándar abierto bajo la Linux Foundation” responde a las preguntas que matan la adopción de estándares: ¿Quién lo controla? ¿Qué sucede si un proveedor se retira? ¿Podemos contribuir con nuestras extensiones?

Primeros pasos: un camino práctico de adopción

Adoptar un modelo compartido es tanto un ejercicio organizativo como técnico. Una secuencia pragmática sería la siguiente:

1. Haga un inventario de sus entidades compartidas. Identifique los conceptos de negocio que aparecen en más de un sistema; generalmente cliente, producto, pedido y ubicación. Estos son sus candidatos.
2. Elija un área temática y una integración. Elija la integración con mayor problema y menor radio de impacto para probar el modelo. Un único pipeline de informes o la incorporación de una nueva aplicación es lo ideal.
3. Mapee cada sistema a CIM una sola vez. Construya la traducción de cada sistema de origen a la representación de CIM, y de CIM a cada destino. Resista la tentación de mapear sistema a sistema directamente.
4. Documente sus extensiones. Cuando CIM no cubra un concepto, registre la extensión explícitamente y considere contribuir con ella.
5. Establezca la propiedad. Un modelo canónico sin un responsable decae. Asigne un equipo o rol responsable de los mapeos y del seguimiento de los cambios ascendentes (upstream).
6. Versione y pruebe. Trate el modelo y sus mapeos como artefactos versionados con pruebas, exactamente como lo haría con el código de una aplicación.

El modo de falla más común es tratar al CIM como un ejercicio de modelado único en lugar de un contrato vivo. Las organizaciones que tienen éxito tratan el modelo de la misma manera que tratan una API: versionada, probada, con un propietario y evolucionada deliberadamente.

Socios que contribuyen al CIM

CIM es un esfuerzo de consorcio y su valor crece con la participación. Los socios aportan contenido de Áreas Temáticas, revisan propuestas y ayudan a dar forma a la dirección del modelo. Debido a que el trabajo es abierto, las contribuciones no se limitan a los grandes proveedores: las empresas con dificultades reales de integración y los profesionales individuales con experiencia en el dominio son igualmente bienvenidos.

Ponte en contacto

¿Estás interesado en unirte a la iniciativa CIM? ¡Genial! No dudes en enviarnos un correo electrónico para obtener más información. Envíenos un correo electrónico.

Preguntas frecuentes

¿Qué es el Cloud Information Model (CIM)?

CIM es un modelo de datos de código abierto e independiente de la aplicación que proporciona un vocabulario compartido basado en estándares para los conceptos de negocio que las empresas necesitan intercambiar entre aplicaciones en la nube y locales (on-premises). Es producido por un consorcio abierto y alojado bajo la Joint Development Foundation, parte de la Linux Foundation. Su propósito es reducir el código de mapeo personalizado que requieren las frágiles integraciones punto a punto.

¿Es CIM un producto o una especificación?

CIM es una especificación —un modelo y un conjunto de definiciones—, no un producto ejecutable. Define el significado y la estructura de las entidades compartidas; usted sigue eligiendo sus propias herramientas de ETL/ELT, brokers de mensajes y almacenamiento. Piense en ello como el contrato que implementa su infraestructura de integración, en lugar de la infraestructura en sí.

¿En qué se diferencia CIM de la plataforma de integración de un proveedor?

Una plataforma de integración (una iPaaS o una biblioteca de conectores) mueve datos y a menudo incluye conectores preconstruidos, pero esos conectores codifican semánticas específicas del proveedor. CIM es neutral e independiente del proveedor, por lo que no lo ata a la visión del mundo de una sola plataforma. Ambos son complementarios: puede utilizar CIM como el modelo canónico dentro de cualquier plataforma de integración.

¿Qué son las Áreas Temáticas (Subject Areas) en CIM?

Las Áreas Temáticas (también llamadas dominios) son las unidades organizativas del modelo, y cada una representa un concepto de negocio principal, como clientes, productos o pedidos. Los diseños se publican en múltiples formatos, incluidos diagramas de ejemplo, y se espera que el conjunto de Áreas Temáticas crezca a medida que el consorcio y la comunidad aporten más contenido.

¿Podemos extender CIM si no cubre nuestros conceptos?

Sí. CIM está diseñado para ser extendido y, debido a que es de código abierto bajo una fundación neutral, puede proponer adiciones a través del proceso de contribución. Extender el modelo compartido y contribuir de vuelta es muy preferible a mantener un fork privado, que se desvía con el tiempo y pierde el beneficio de interoperabilidad que motivó la adopción de CIM en primer lugar.

¿Quién debería adoptar CIM?

Es más valioso para las organizaciones que ejecutan muchas aplicaciones de diferentes proveedores que deben acordar el significado de entidades compartidas: la situación clásica para los arquitectos de datos empresariales y los ingenieros de integración. Los proveedores de aplicaciones y plataformas también se benefician al alinear sus esquemas con un modelo neutral, lo que facilita la integración de sus productos para los clientes. Si solo tiene dos sistemas estables, un mapeo punto a punto más simple puede ser suficiente.

Lectura adicional

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia