Modelo CIM

El Cloud Information Model (CIM) es un modelo de datos abierto e independiente de las aplicaciones destinado a brindar a las empresas un vocabulario compartido para las entidades que aparecen en los sistemas de CRM, ERP, marketing, servicio y análisis. En lugar de que cada proveedor invente sus propios nombres de objetos y relaciones, el CIM define un conjunto común de áreas temáticas, entidades y atributos a los que cualquier sistema puede mapearse. El modelo se administra como un proyecto de código abierto bajo The Linux Foundation, que alberga una amplia cartera de proyectos colaborativos de datos e infraestructura.

Este artículo explica cómo está estructurado el CIM, cómo se relacionan sus componentes entre sí, cómo funcionan los supertipos y subtipos y cómo se organizan las áreas temáticas. También cubre las decisiones prácticas que enfrenta un arquitecto al adoptar el CIM —mapeo, gobernanza, control de versiones y extensión— y dónde encaja el modelo en relación con otros estándares de la industria.

Conclusiones clave

• El CIM organiza los conceptos de negocio en Áreas temáticas, cada una de las cuales contiene Grupos de entidades, Entidades y Atributos, una jerarquía que se mapea claramente en esquemas, tablas y columnas.
• Los supertipos y subtipos permiten que el modelo exprese características compartidas (una Parte que es una persona o una organización) mientras siguen permitiendo la especialización.
• El modelo es deliberadamente independiente de la aplicación: describe conceptos de negocio, no la implementación de un solo proveedor.
• El CIM se publica en múltiples formatos con diagramas de ejemplo, por lo que puede ser consumido por herramientas de modelado, generadores de código y documentación por igual.
• El número y alcance de las áreas temáticas crece con las contribuciones del consorcio y la comunidad, por lo que la adopción debe tener en cuenta el control de versiones y la gestión de cambios.
• El CIM es una opción entre varias; la elección correcta depende de si necesita un modelo amplio y transversal a varios dominios o un estándar estrecho y profundo para una sola industria.

Cómo está estructurado el CIM

El CIM está organizado en componentes para que el contenido pueda navegarse y consumirse más fácilmente. Cada nivel de la jerarquía responde a una pregunta diferente, y comprender esa jerarquía es el primer paso para utilizar bien el modelo.

• Área temática — Un concepto de negocio importante identificado por el consorcio CIM, como Party (Parte). Cada área temática contiene uno o más grupos de entidades. Piense en un área temática como un contexto acotado: agrupa todo lo que la empresa necesita saber sobre un tema amplio.
• Grupo de entidades — Una agrupación lógica de entidades relacionadas dentro de un área temática, como Account (Cuenta). Los grupos de entidades mantienen las áreas temáticas extensas navegables y brindan a los equipos una unidad natural para asignar la propiedad.
• Entidad — Un objeto único sobre el cual una organización recopila información, como un Account Contact (Contacto de cuenta). Una entidad es análoga a una tabla de base de datos estándar.
• Atributo — Una característica única de una entidad, como Account Id (ID de cuenta) o Contact Email (Correo electrónico de contacto). Un atributo es análogo a un campo de base de datos estándar dentro de una tabla.

Esta jerarquía de cuatro niveles es intencionalmente familiar. Los arquitectos de datos que han trabajado con modelado relacional, modelado dimensional o diagramas entidad-relación reconocerán el patrón inmediatamente. El valor que agrega el CIM no es una técnica de modelado novedosa, sino un conjunto de nombres y relaciones compartidos y prenegociados en los que múltiples organizaciones y proveedores pueden ponerse de acuerdo.

Un modelo mental útil: un área temática es aproximadamente un esquema o un dominio; un grupo de entidades es aproximadamente un espacio de nombres o módulo; una entidad es una tabla; un atributo es una columna. Ese mapeo es aproximado —el CIM es un modelo conceptual y lógico, no uno físico— pero ayuda cuando se traduce el CIM a una implementación física.

Supertipos y subtipos

Más allá de los cuatro componentes principales, el diseño del CIM personaliza y extiende las entidades en agrupaciones adicionales utilizando supertipos y subtipos. Aquí es donde el modelo adquiere gran parte de su poder expresivo.

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

• Supertipo — Una entidad que es extendida por entidades de subtipo y define atributos comunes para conceptos similares.
• Subtipo — Una entidad que extiende otra entidad y hereda los atributos de su entidad supertipo.

El ejemplo clásico es Party. Una parte es cualquier persona o cosa con la que trata la empresa. Una persona y una organización son ambas partes y comparten atributos —un nombre, identificadores, puntos de contacto— pero cada una tiene atributos que la otra no tiene.

Modelar Party como un supertipo con Person (Persona) y Organization (Organización) como subtipos evita duplicar los atributos compartidos y mantiene las relaciones (por ejemplo, “esta oportunidad pertenece a esta parte”) consistentes independientemente del subtipo involucrado.

La herencia de este tipo es un concepto bien establecido en el modelado de datos y aparece en estándares como el UML del Object Management Group y en las convenciones entidad-relación utilizadas en toda la industria. Cuando implemente el CIM físicamente, deberá decidir cómo representar la herencia:

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

• Tabla única — almacenar todos los subtipos en una sola tabla con una columna discriminadora. Simple de consultar, pero puede producir muchas columnas que aceptan valores nulos.
• Herencia de tabla de clase — una tabla para el supertipo y una por subtipo, unidas mediante una clave compartida. Normalizado y limpio, pero requiere uniones (joins).
• Herencia de tabla concreta — una tabla separada y autónoma por subtipo. Rápido para consultas específicas de subtipos, pero duplica los atributos compartidos.

No hay una respuesta universalmente correcta. La elección adecuada depende de los patrones de consulta, el número de subtipos y la frecuencia con la que se lean juntos los atributos compartidos. Documente la decisión, ya que afectará a todas las integraciones posteriores.

Las áreas temáticas del CIM

Las áreas temáticas representan los principales conceptos de negocio que el consorcio ha modelado hasta ahora. Cada una se publica con sus propios diagramas y formatos, y varias llevan marcadores de versión explícitos (por ejemplo, v1.0 o v0.1.1), lo que refleja que algunas áreas son más maduras que otras.

Setup — Define con quién trata, por ejemplo, cliente, proveedor y vendedor. También cubre los conceptos de software e infraestructura que opera una organización: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job y IoT Device.

Data Model — Los conceptos fundamentales de modelado en sí mismos.

Hire — Actividades relacionadas con la configuración de su negocio, por ejemplo, unidad de negocio interna y trabajador. Los grupos de entidades incluyen Job Application, Employee, Compensation, Training, Location, Work Territory y Work Report.

Biz Process — Conceptos de procesos de negocio y continuidad del negocio.

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

Produce — Manejo del material que comprará, moverá y venderá, por ejemplo, producto y producto de inventario. Los grupos de entidades incluyen Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order y Sales Agreement.

Market — Actividades utilizadas para promocionar su producto, por ejemplo, campaña de marketing y tienda web. Los grupos de entidades incluyen Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy y Web Site.

Sell — Actividades utilizadas para vender su producto, por ejemplo, la creación de cotizaciones y oportunidades. Los grupos de entidades incluyen Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program y Competitor.

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

Service — Actividades para brindar soporte a un producto vendido o mantenido, por ejemplo, un caso o una encuesta. Los grupos de entidades incluyen AI Assistant, Asset, Asset Subscription, Web Content, Case, Task y Event.

Fulfill — Actividades que realiza para cumplir con un pedido de un cliente, por ejemplo, envío y pedido de devolución. Los grupos de entidades incluyen Fulfillment Order, Shipment, Return Order, Work Order, Work Resource y Work Forecast.

Interact — Actividades para rastrear la interacción con usuarios finales u otros sistemas. Los grupos de entidades incluyen Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey y Loyalty.

Finance — Actividades para rastrear información financiera en la empresa, por ejemplo, pago, factura e informe de gastos. Los grupos de entidades incluyen Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar y Tax Policy.

Analyze — Actividades relacionadas con el análisis de datos, por ejemplo, análisis de patrones, uso de productos, movimiento de datos, cambios de datos y satisfacción del cliente. Los grupos de entidades incluyen AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty y Journal.

Observe cómo las áreas temáticas abarcan tanto preocupaciones operativas (Sell, Fulfill, Service) como analíticas (Analyze, Finance). Esa amplitud es el punto: un modelo compartido es más valioso cuando puede describir al mismo cliente, producto o pedido de manera consistente, ya sea que los datos residan en un sistema transaccional o en un almacén de datos.

Elegir entre CIM y otros estándares

CIM no es el único modelo compartido en la empresa. Varios estándares establecidos se superponen con partes de su alcance, y una arquitectura madura a menudo utiliza más de uno. La decisión consiste menos en elegir un ganador y más en hacer coincidir la amplitud y la gobernanza del modelo con su problema.

Estándar	Enfoque primario	Fortaleza típica	En qué se diferencia CIM
CIM	Conceptos de negocio transversales a dominios	Cobertura amplia e independiente de la aplicación de CRM/ERP/marketing/servicio	Diseñado como un paraguas compartido entre dominios
OMG Common Core Ontologies / modelos basados en UML	Notación de modelado conceptual y ontologías superiores	Semántica formal rigurosa	CIM está más directamente orientado al negocio
Modelos específicos de la industria (por ejemplo, verticales de retail, salud, finanzas)	Cobertura profunda de un sector	Precisión dentro de la vertical	CIM sacrifica profundidad por amplitud
Modelos de datos de proveedores (plataformas CRM/ERP)	Objetos de un solo producto	Integración estrecha con ese producto	CIM es neutral respecto al proveedor por diseño

Una regla práctica:

• Si necesita un vocabulario compartido entre muchos sistemas y proveedores, un modelo amplio como CIM es una opción sólida.
• Si necesita semántica profunda, regulada y específica de la industria, un estándar vertical generalmente será más preciso, y puede mapearlo a CIM en los límites.
• Si se está integrando dentro del ecosistema de un único proveedor, el modelo propio de ese proveedor puede ser suficiente, pero no le ayudará a conectarse con el siguiente proveedor.

El patrón más común en el mundo real es un enfoque de hub-and-spoke: CIM (u otro modelo canónico) se sitúa en el centro, y cada sistema fuente se mapea hacia él. Este es el mismo principio detrás de los modelos de datos canónicos en la gestión de datos maestros y detrás de la idea de “dimensión conformada” popularizada en el modelado dimensional por Ralph Kimball.

Guía práctica para adoptar CIM

Adoptar un modelo compartido es tanto un ejercicio organizativo como técnico. Unas pocas decisiones determinan si el esfuerzo rinde frutos.

Comience con un alcance delimitado. No intente mapear cada sistema a cada área temática a la vez. Elija un dominio de alto valor —Party y Sell son puntos de partida comunes porque los datos de clientes y oportunidades están ampliamente duplicados— y demuestre el mapeo de principio a fin.

Decida su política de extensión pronto. CIM está diseñado para crecer con el consorcio y las contribuciones, pero su organización inevitablemente necesitará atributos que el modelo aún no define. Establezca una convención para las extensiones locales (por ejemplo, un prefijo de espacio de nombres) para que los atributos personalizados se distingan claramente de los estándar y puedan conciliarse más adelante.

Trate el control de versiones como una preocupación de primera clase. Las áreas temáticas contienen marcadores de versión como v1.0 y v0.1.1, lo que indica que el modelo evoluciona. Fije la versión sobre la cual construya, realice un seguimiento de los cambios y planifique la migración. Esta es la misma disciplina que aplicaría a cualquier dependencia.

Mapee, no copie. CIM es un modelo conceptual y lógico. Resista la tentación de generar esquemas físicos directamente a partir de él sin considerar el rendimiento, la indexación y los patrones de acceso de los sistemas que consumirán los datos. Utilice el modelo para alinear el significado y luego diseñe el almacenamiento físico para su carga de trabajo.

Goberne el mapeo. El mapeo entre un sistema fuente y CIM es en sí mismo un activo. Versiónelo, revíselo y asigne una propiedad. Las herramientas en el espacio de integración de datos —plataformas ETL y ELT, catálogos de datos y herramientas de linaje— pueden ayudarlo a rastrear dónde se origina cada atributo y cómo fluye, que es exactamente el tipo de metadatos que el área temática Analyze anticipa con entidades como Data Lineage.

Involucre a la comunidad. Debido a que CIM es de código abierto y está impulsado por un consorcio, las brechas que usted encuentre a menudo son brechas que otros también han encontrado. Contribuir con una entidad o atributo propuesto al proyecto es tanto un acto de buena ciudadanía como una forma de reducir su carga de mantenimiento a largo plazo.

Formatos, Diagramas y Consumo

Los diseños de CIM están disponibles en múltiples formatos para cada dominio, incluidos diagramas de ejemplo. Esto es importante porque diferentes audiencias consumen un modelo de datos de manera diferente:

• Los arquitectos quieren diagramas y vistas de relaciones para razonar sobre la estructura.
• Los ingenieros quieren definiciones legibles por máquina que puedan alimentar la generación de código, la validación de esquemas o las herramientas de mapeo.
• Los analistas y administradores (stewards) quieren documentación que explique qué significa cada entidad y atributo en términos de negocio.

Publicar en múltiples formatos es una elección de diseño deliberada que reduce la barrera para la adopción. Al evaluar cualquier modelo compartido, verifique que se entregue en formatos que su cadena de herramientas realmente pueda ingerir; un modelo que solo existe como PDF es mucho menos útil que uno con definiciones estructuradas.

Preguntas frecuentes

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

El Cloud Information Model es un modelo de datos abierto e independiente de las aplicaciones que define conceptos de negocio compartidos —como Party, Account y Sales Order— para que diferentes sistemas locales y en la nube puedan intercambiar datos utilizando un vocabulario común. Está organizado en áreas temáticas, grupos de entidades, entidades y atributos, y es administrado como un proyecto de código abierto bajo The Linux Foundation.

¿Cuál es la diferencia entre un supertipo y un subtipo en CIM?

Un supertipo es una entidad que es extendida por entidades de subtipo y define los atributos comunes a conceptos similares. Un subtipo extiende otra entidad y hereda los atributos de su supertipo. Por ejemplo, Party puede actuar como un supertipo con Person y Organization como subtipos, de modo que los atributos compartidos se definen una vez y los atributos especializados residen en el subtipo.

¿Cómo se relaciona CIM con un esquema de base de datos?

CIM es un modelo conceptual y lógico, no un esquema físico. Sus entidades son análogas a las tablas de bases de datos y sus atributos a los campos, lo que hace que la traducción sea intuitiva, pero aun así debe diseñar el almacenamiento físico —indexación, particionamiento, desnormalización— en torno a sus propios patrones de consulta en lugar de copiar el modelo literalmente.

¿Es CIM un sustituto de los estándares de datos específicos de la industria?

No. CIM es amplio y transversal a los dominios, mientras que los estándares verticales son profundos y específicos de un sector. Muchas organizaciones utilizan un enfoque de “hub-and-spoke” en el que CIM sirve como el modelo canónico en el centro y los estándares de la industria o los modelos de proveedores se mapean hacia él en los extremos.

¿Por qué las áreas temáticas de CIM tienen números de versión?

Los marcadores de versión como v1.0 y v0.1.1 indican que el modelo evoluciona y que algunas áreas temáticas son más maduras que otras. Fijar una versión, rastrear los cambios y planificar las migraciones es la misma disciplina de gestión de dependencias que aplicaría a cualquier biblioteca o esquema compartido.

¿Cómo manejo los atributos que CIM no define?

Establezca una convención de extensión documentada, como un prefijo de espacio de nombres (namespace), para que los atributos personalizados se distingan claramente de los estándar. Luego, considere contribuir con dicha brecha al proyecto, ya que el modelo está diseñado para crecer con las contribuciones del consorcio y la comunidad.