Modello CIM

Il Cloud Information Model (CIM) è un modello di dati aperto e indipendente dall’applicazione, destinato a fornire alle aziende un vocabolario condiviso per le entità che compaiono nei sistemi CRM, ERP, marketing, service e analytics. Invece di lasciare che ogni fornitore inventi i propri nomi di oggetti e relazioni, il CIM definisce un insieme comune di aree tematiche, entità e attributi a cui qualsiasi sistema può mappare. Il modello è gestito come progetto open source sotto The Linux Foundation, che ospita un ampio portafoglio di progetti collaborativi di dati e infrastrutture.

Questo articolo spiega come è strutturato il CIM, come i suoi componenti si relazionano tra loro, come funzionano i supertipi e i sottotipi e come sono organizzate le aree tematiche. Copre inoltre le decisioni pratiche che un architetto deve affrontare quando adotta il CIM — mappatura, governance, versioning ed estensione — e dove il modello si colloca rispetto ad altri standard di settore.

Punti chiave

• Il CIM organizza i concetti aziendali in Aree tematiche, ciascuna contenente Gruppi di entità, Entità e Attributi — una gerarchia che si mappa chiaramente su schemi, tabelle e colonne.
• Supertipi e sottotipi consentono al modello di esprimere caratteristiche condivise (un Party che è una persona o un’organizzazione) pur consentendo la specializzazione.
• Il modello è deliberatamente indipendente dall’applicazione: descrive i concetti di business, non l’implementazione di un singolo fornitore.
• Il CIM è pubblicato in più formati con diagrammi di esempio, così da poter essere consumato sia da strumenti di modellazione e generatori di codice, sia dalla documentazione.
• Il numero e la portata delle aree tematiche crescono con i contributi del consorzio e della comunità, quindi l’adozione dovrebbe tenere conto del versioning e della gestione del cambiamento.
• Il CIM è un’opzione tra diverse; la scelta giusta dipende dal fatto che sia necessario un ampio modello cross-dominio o uno standard ristretto e approfondito per un singolo settore.

Come è strutturato il CIM

Il CIM è organizzato in componenti in modo che il contenuto possa essere navigato e consumato più facilmente. Ogni livello della gerarchia risponde a una domanda diversa, e comprendere tale gerarchia è il primo passo per utilizzare bene il modello.

• Area tematica (Subject Area) — Un importante concetto di business identificato dal consorzio CIM, come Party. Ciascuna area tematica contiene uno o più gruppi di entità. Pensa a un’area tematica come a un bounded context: raggruppa tutto ciò che l’azienda deve sapere su un tema ampio.
• Gruppo di entità (Entity Group) — Un raggruppamento logico di entità correlate all’interno di un’area tematica, come Account. I gruppi di entità mantengono navigabili le aree tematiche di grandi dimensioni e forniscono ai team un’unità naturale per l’assegnazione della proprietà.
• Entità (Entity) — Un oggetto univoco su cui un’organizzazione raccoglie informazioni, come un Account Contact. Un’entità è analoga a una tabella di database standard.
• Attributo (Attribute) — Una caratteristica univoca di un’entità, come Account Id o Contact Email. Un attributo è analogo a un campo di database standard all’interno di una tabella.

Questa gerarchia a quattro livelli è intenzionalmente familiare. Gli architetti dei dati che hanno lavorato con la modellazione relazionale, la modellazione dimensionale o i diagrammi entità-relazione riconosceranno immediatamente il pattern. Il valore che il CIM aggiunge non è una nuova tecnica di modellazione, ma un insieme condiviso e pre-negoziato di nomi e relazioni su cui più organizzazioni e fornitori possono concordare.

Un modello mentale utile: un’area tematica è approssimativamente uno schema o un dominio; un gruppo di entità è approssimativamente un namespace o un modulo; un’entità è una tabella; un attributo è una colonna. Questa mappatura è approssimativa — il CIM è un modello concettuale e logico, non fisico — ma è utile quando si traduce il CIM in un’implementazione fisica.

Supertipi e sottotipi

Oltre ai quattro componenti principali, il design del CIM personalizza ed estende le entità in ulteriori raggruppamenti utilizzando supertipi e sottotipi. È qui che il modello acquisisce gran parte della sua forza espressiva.

Correlato: Boomi AtomSphere — Enterprise iPaaS per l'integrazione ibrida da cloud a on-premise.

• Supertipo — Un’entità che viene estesa da entità di sottotipo e definisce attributi comuni per concetti simili.
• Sottotipo — Un’entità che estende un’altra entità ed eredita gli attributi dalla sua entità supertipo.

L’esempio classico è Party. Un party è chiunque o qualsiasi cosa con cui l’azienda interagisce. Una persona e un’organizzazione sono entrambi party e condividono attributi — un nome, identificativi, punti di contatto — ma ciascuno ha attributi che l’altro non ha.

Modellare Party come supertipo con Person e Organization come sottotipi evita di duplicare gli attributi condivisi e mantiene le relazioni (ad esempio, “questa opportunità appartiene a questo party”) coerenti indipendentemente dal sottotipo coinvolto.

L’ereditarietà di questo tipo è un concetto ben consolidato nella modellazione dei dati e appare in standard come l’UML dell’Object Management Group e nelle convenzioni entità-relazione utilizzate in tutto il settore. Quando implementi il CIM fisicamente, devi decidere come rappresentare l’ereditarietà:

La nostra scelta: Workato — IPaaS basato sull'automazione su cui i team aziendali possono effettivamente basarsi.

• Tabella singola (Single table) — memorizza tutti i sottotipi in una tabella con una colonna discriminatore. Semplice da interrogare, ma può produrre molte colonne nullable.
• Ereditarietà della tabella delle classi (Class table inheritance) — una tabella per il supertipo e una per ogni sottotipo, unite su una chiave condivisa. Normalizzata e pulita, ma richiede join.
• Ereditarietà della tabella concreta (Concrete table inheritance) — una tabella separata e autonoma per ogni sottotipo. Veloce per query specifiche del sottotipo, ma duplica gli attributi condivisi.

Non esiste una risposta universalmente corretta. La scelta giusta dipende dai pattern di query, dal numero di sottotipi e dalla frequenza con cui gli attributi condivisi vengono letti insieme. Documenta la decisione, perché influenzerà ogni integrazione a valle.

Le aree tematiche del CIM

Le aree tematiche rappresentano i principali concetti aziendali che il consorzio ha modellato finora. Ciascuna viene pubblicata con i propri diagrammi e formati, e diverse riportano indicatori di versione espliciti (ad esempio, v1.0 o v0.1.1), riflettendo il fatto che alcune aree sono più mature di altre.

Setup — Definisce con chi hai a che fare, ad esempio cliente, fornitore e venditore. Copre inoltre i concetti di software e infrastruttura gestiti da un’organizzazione: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job e IoT Device.

Data Model — I concetti fondamentali di modellazione stessi.

Hire — Attività relative alla configurazione della tua attività, ad esempio unità aziendale interna e lavoratore. I gruppi di entità includono Job Application, Employee, Compensation, Training, Location, Work Territory e Work Report.

Biz Process — Concetti di processo aziendale e continuità aziendale.

Correlato: Matillion — ELT push-down creato per data warehouse su cloud.

Produce — Gestione del materiale che acquisterai, sposterai e venderai, ad esempio prodotto e prodotto di inventario. I gruppi di entità includono Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order e Sales Agreement.

Market — Attività utilizzate per promuovere il tuo prodotto, ad esempio campagna di marketing e negozio web. I gruppi di entità includono Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy e Web Site.

Sell — Attività utilizzate per vendere il tuo prodotto, ad esempio la creazione di preventivi e opportunità. I gruppi di entità includono Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program e Competitor.

Da dove inizieremmo: Fivetran — La pipeline ELT completamente gestita che continua a funzionare.

Service — Attività per fornire supporto a un prodotto venduto o assistito, ad esempio un caso o un sondaggio. I gruppi di entità includono AI Assistant, Asset, Asset Subscription, Web Content, Case, Task ed Event.

Fulfill — Attività eseguite per evadere un ordine per un cliente, ad esempio spedizione e ordine di reso. I gruppi di entità includono Fulfillment Order, Shipment, Return Order, Work Order, Work Resource e Work Forecast.

Interact — Attività per monitorare l’interazione con gli utenti finali o con altri sistemi. I gruppi di entità includono Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey e Loyalty.

Finance — Attività per tracciare le informazioni finanziarie nell’azienda, ad esempio pagamento, fattura e nota spese. I gruppi di entità includono Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar e Tax Policy.

Analyze — Attività relative all’analisi dei dati, ad esempio l’analisi di pattern, l’uso del prodotto, lo spostamento dei dati, le modifiche dei dati e la soddisfazione del cliente. I gruppi di entità includono AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty e Journal.

Si noti come le aree tematiche abbraccino sia preoccupazioni operative (Sell, Fulfill, Service) che analitiche (Analyze, Finance). Il punto è proprio questa ampiezza: un modello condiviso è più prezioso quando può descrivere lo stesso cliente, prodotto o ordine in modo coerente, indipendentemente dal fatto che i dati risiedano in un sistema transazionale o in un warehouse.

Scegliere tra CIM e altri standard

CIM non è l’unico modello condiviso in azienda. Diversi standard consolidati si sovrappongono a parti del suo ambito e un’architettura matura spesso ne utilizza più di uno. La decisione non riguarda tanto la scelta di un vincitore quanto l’adattamento dell’ampiezza e della governance del modello al problema.

Standard	Focus primario	Forza tipica	Differenze di CIM
CIM	Concetti aziendali cross-dominio	Copertura ampia e indipendente dall’applicazione di CRM/ERP/marketing/service	Progettato come un ombrello condiviso tra i domini
OMG Common Core Ontologies / modelli basati su UML	Notazione di modellazione concettuale e ontologie superiori	Semantica formale rigorosa	CIM è più direttamente orientato al business
Modelli specifici del settore (es. verticali retail, sanità, finanza)	Copertura approfondita di un singolo settore	Precisione all’interno della verticale	CIM scambia la profondità con l’ampiezza
Modelli di dati dei vendor (piattaforme CRM/ERP)	Oggetti di un singolo prodotto	Stretta integrazione con quel prodotto	CIM è neutrale rispetto al vendor per progettazione

Una regola pratica:

• Se hai bisogno di un vocabolario condiviso tra molti sistemi e vendor, un modello ampio come CIM è una soluzione ideale.
• Se hai bisogno di una semantica approfondita, regolamentata e specifica del settore, uno standard verticale sarà solitamente più preciso, e potrai mapparlo su CIM ai confini.
• Se stai integrando all’interno dell’ecosistema di un singolo vendor, il modello di quel vendor potrebbe essere sufficiente, ma non ti aiuterà a connetterti al vendor successivo.

Il pattern più comune nel mondo reale è l’approccio hub-and-spoke: CIM (o un altro modello canonico) si trova al centro e ogni sistema sorgente viene mappato su di esso. È lo stesso principio alla base dei modelli di dati canonici nel master data management e dell’idea di “dimensione conforme” resa popolare nella modellazione dimensionale da Ralph Kimball.

Guida pratica per l’adozione di CIM

Adottare un modello condiviso è un esercizio tanto organizzativo quanto tecnico. Alcune decisioni determinano se lo sforzo ripagherà.

Inizia con un ambito limitato. Non tentare di mappare ogni sistema su ogni area tematica contemporaneamente. Scegli un dominio di alto valore — Party e Sell sono punti di partenza comuni perché i dati sui clienti e sulle opportunità sono ampiamente duplicati — e dimostra la mappatura end-to-end.

Decidi in anticipo la tua politica di estensione. CIM è progettato per crescere con il consorzio e i contributi, ma la tua organizzazione avrà inevitabilmente bisogno di attributi che il modello non definisce ancora. Stabilisci una convenzione per le estensioni locali (ad esempio, un prefisso con namespace) in modo che gli attributi personalizzati siano chiaramente distinguibili da quelli standard e possano essere riconciliati in seguito.

Tratta il versionamento come una priorità assoluta. Le aree tematiche riportano indicatori di versione come v1.0 e v0.1.1, che segnalano l’evoluzione del modello. Blocca la versione su cui sviluppi, tieni traccia delle modifiche e pianifica la migrazione. Questa è la stessa disciplina che applicheresti a qualsiasi dipendenza.

Mappa, non copiare. CIM è un modello concettuale e logico. Resisti alla tentazione di generare schemi fisici direttamente da esso senza considerare le prestazioni, l’indicizzazione e i modelli di accesso dei sistemi che consumeranno i dati. Utilizza il modello per allineare il significato, quindi progetta l’archiviazione fisica per il tuo carico di lavoro.

Governa la mappatura. La mappatura tra un sistema di origine e CIM è di per sé una risorsa. Versionala, rivedila e assegnane la proprietà. Gli strumenti nel campo dell’integrazione dei dati — piattaforme ETL ed ELT, cataloghi di dati e strumenti di lineage — possono aiutarti a tenere traccia dell’origine di ciascun attributo e del modo in cui fluisce, che è esattamente il tipo di metadati che l’area tematica Analyze anticipa con entità come Data Lineage.

Coinvolgi la community. Poiché CIM è open source e guidato da un consorzio, le lacune che riscontri sono spesso lacune che altri hanno già trovato. Contribuire al progetto proponendo un’entità o un attributo è sia un atto di buona cittadinanza che un modo per ridurre l’onere di manutenzione a lungo termine.

Formati, diagrammi e consumo

I progetti CIM sono disponibili in più formati per ciascun dominio, inclusi diagrammi di esempio. Ciò è importante perché diversi segmenti di pubblico consumano un modello di dati in modo differente:

• Gli architetti desiderano diagrammi e viste delle relazioni per ragionare sulla struttura.
• Gli ingegneri desiderano definizioni leggibili a macchina da poter inserire in strumenti di generazione di codice, convalida dello schema o mappatura.
• Analisti e steward desiderano una documentazione che spieghi il significato di ciascuna entità e attributo in termini aziendali.

La pubblicazione in più formati è una scelta progettuale deliberata che riduce le barriere all’adozione. Quando valuti qualsiasi modello condiviso, verifica che venga fornito in formati che la tua toolchain possa effettivamente acquisire: un modello che esiste solo come PDF è molto meno utile di uno con definizioni strutturate.

Domande frequenti

Cos’è il Cloud Information Model (CIM)?

Il Cloud Information Model è un modello di dati aperto e indipendente dall’applicazione che definisce concetti aziendali condivisi — come Party, Account e Sales Order — in modo che diversi sistemi cloud e on-premises possano scambiare dati utilizzando un vocabolario comune. È organizzato in aree tematiche, gruppi di entità, entità e attributi, ed è gestito come progetto open source sotto The Linux Foundation.

Qual è la differenza tra un supertipo e un sottotipo in CIM?

Un supertipo è un’entità che viene estesa da entità sottotipo e definisce gli attributi comuni a concetti simili. Un sottotipo estende un’altra entità ed eredita gli attributi del suo supertipo. Per esempio, Party può fungere da supertipo con Person e Organization come sottotipi, così gli attributi condivisi vengono definiti una sola volta e gli attributi specializzati risiedono nel sottotipo.

In che modo CIM si relaziona allo schema di un database?

CIM è un modello concettuale e logico, non uno schema fisico. Le sue entità sono analoghe alle tabelle di un database e i suoi attributi ai campi, il che rende la traduzione intuitiva, ma dovresti comunque progettare l’archiviazione fisica — indicizzazione, partizionamento, denormalizzazione — in base ai tuoi modelli di query piuttosto che copiare letteralmente il modello.

CIM sostituisce gli standard di dati specifici del settore?

No. CIM è ampio e cross-dominio, mentre gli standard verticali sono approfonditi e specifici per settore. Molte organizzazioni utilizzano un approccio hub-and-spoke in cui CIM funge da modello canonico al centro e gli standard di settore o i modelli dei fornitori vengono mappati verso di esso ai margini.

Perché le aree tematiche CIM hanno numeri di versione?

Indicatori di versione come v1.0 e v0.1.1 indicano che il modello evolve e che alcune aree tematiche sono più mature di altre. Bloccare una versione, tenere traccia delle modifiche e pianificare le migrazioni è la stessa disciplina di gestione delle dipendenze che applicheresti a qualsiasi libreria o schema condiviso.

Come gestisco gli attributi che CIM non definisce?

Stabilisci una convenzione di estensione documentata, come un prefisso con namespace, in modo che gli attributi personalizzati siano chiaramente distinguibili da quelli standard. Quindi valuta la possibilità di contribuire al progetto colmando la lacuna, poiché il modello è progettato per crescere grazie ai contributi del consorzio e della community.