Modello informativo cloud

Il Cloud Information Model (CIM) è uno schema aperto e indipendente dall’applicazione per descrivere le entità che si muovono all’interno di un’impresa moderna: parti, prodotti, ordini, pagamenti e le relazioni che li legano tra loro. Invece di inventare un modello di dati su misura per ogni integrazione, CIM offre un vocabolario condiviso in modo che un CRM, un ERP, una piattaforma di commercio e un warehouse di analisi possano concordare su cosa significhi effettivamente un “Sales Order” o un “Product Relationship Type”. Questo articolo esamina i gruppi di entità che compongono il modello, per poi approfondire un’entità rappresentativa — ProductRelationshipType — per mostrare come CIM esprima nella pratica relazioni, ruoli e chiavi.

Punti chiave

• CIM organizza i dati aziendali in gruppi di entità (Party, Product, Sales Order, Payment e altri) che possono essere adottati in modo incrementale anziché tutti in una volta.
• Ogni entità è definita con un Term URI, una descrizione, proprietà scalari e proprietà di collegamento — una struttura che si mappa agevolmente su JSON-LD, RDF e store di property-graph.
• Le entità di relazione come ProductRelationshipType codificano i ruoli (genitore/figlio) in modo che bundle, opzioni e coperture possano essere modellati senza hard-coding della logica aziendale.
• Il modello è deliberatamente indipendente dall’applicazione: descrive il significato dei dati, non il modo in cui un particolare fornitore li archivia.
• L’adozione di CIM è un esercizio di mappatura, non un “rip and replace”: si allineano i sistemi esistenti a termini condivisi e si riconciliano le lacune.

Perché è importante un modello condiviso

L’integrazione aziendale presenta una modalità di fallimento familiare: ogni sistema parla il proprio dialetto. Salesforce lo chiama Account, SAP lo chiama Business Partner e un servizio di fatturazione interno lo chiama Customer. Quando si creano mappature punto a punto tra ogni coppia, il numero di traduzioni cresce con il quadrato dei sistemi coinvolti e ogni nuovo sistema moltiplica il carico di manutenzione.

Un modello canonico risolve questo problema quadratico. Si mappa ogni sistema una volta al modello condiviso, e il modello condiviso diventa l’hub. Questo è lo stesso istinto architetturale alla base di standard come OAGIS (Open Applications Group Integration Specification), il Common Warehouse Metamodel di OMG e il vocabolario per il commercio di schema.org.

CIM si inserisce in questa tradizione, ma è dimensionato per l’interoperabilità dell’era cloud ed è pubblicato come termini aperti con URI dereferenziabili.

Il vantaggio pratico è che un architetto dei dati può rispondere a domande come “quali sistemi detengono il record autorevole per una Party?” o “come rappresentiamo un bundle di prodotti in modo coerente tra il catalogo e l’ordine?” utilizzando un unico punto di riferimento.

Panoramica dei gruppi di entità

CIM non è un unico schema monolitico; è un insieme di gruppi debolmente accoppiati. I gruppi nominati nel modello includono:

Correlato: Fivetran — La pipeline ELT completamente gestita che continua a funzionare.

• Account — il contesto della relazione commerciale per una parte.
• Contact Point — numeri di telefono, indirizzi email e canali di raggiungibilità simili.
• Lead — una parte potenziale non ancora qualificata.
• Party e Party Role — il concetto generale di attore e i ruoli che interpreta (cliente, fornitore, dipendente).
• Payment e Payment Method — come si muove il denaro e gli strumenti utilizzati.
• Product Attribute, Product Catalog e Product — i beni e i servizi vendibili e descrivibili.
• Sales Order e la sua ampia famiglia di sotto-entità — il cuore transazionale del modello.
• Shipment — adempimento e logistica.

Il gruppo Sales Order è di gran lunga il più granulare, ed è utile comprenderne il motivo. Un ordine è il luogo in cui si concentrano le regole aziendali: prezzi, tasse, rettifiche, raggruppamenti di consegna e note per riga sono tutti collegati ad esso.

CIM scompone l’ordine in molte piccole entità — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log e altro ancora — anziché in un’unica tabella ampia. Questa scomposizione è una scelta progettuale deliberata: consente a ogni aspetto di evolversi indipendentemente e permette ai sistemi di sottoscrivere solo le sezioni di loro interesse.

Anatomia di un’entità CIM

Ogni entità in CIM segue la stessa forma, il che rende il modello prevedibile per il consumo programmatico. Consideriamo ProductRelationshipType, l’entità che descrive perché due prodotti sono correlati.

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

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Questo è l’identificatore univoco globale del concetto. Essendo un URI, può essere dereferenziato e utilizzato direttamente in grafi RDF/JSON-LD.
• Description — “Reasons why products are related such as bundle, option or covering.” Questo indica che l’entità è un tipo o una classificazione, non l’istanza della relazione stessa.
• Scalar Properties — i campi primitivi che trasportano i dati.
• Link Properties — riferimenti ad altre entità. ProductRelationshipType non ne ha, il che è di per sé informativo: è un’entità foglia, un vocabolario controllato piuttosto che un hub.

Le proprietà scalari sono:

Proprietà	Term URI	Range	Obbligatorio	Descrizione
id	.../model/id	guid	sì	Chiave primaria
parentProductRole	.../model/parentProductRole	string	sì	Il primo ruolo nella relazione, es. “Consists of”
childProductRole	.../model/childProductRole	string	sì	Il secondo ruolo nella relazione, es. “Component of”

Il fatto che l’ id sia un GUID è una convenzione significativa: significa che gli identificatori sono globalmente univoci senza coordinamento tra i sistemi, che è esattamente ciò che si desidera quando i record vengono creati in cloud diversi e successivamente uniti.

Modellazione delle relazioni con i ruoli

La parte più istruttiva di ProductRelationshipType è la coppia di proprietà del ruolo. Una relazione tra prodotti è direzionale, e CIM cattura tale direzione con due ruoli denominati anziché con una singola stringa di “tipo” opaca.

Pensa a un bundle. Uno “Starter Kit” consiste in un “Router” e un “Cavo”. In termini CIM:

• Il prodotto genitore (parent product) svolge il ruolo descritto da parentProductRole — ad esempio, “Consiste in”.
• Il prodotto figlio (child product) svolge il ruolo descritto da childProductRole — ad esempio, “Componente di”.

Memorizzando entrambi i ruoli come stringhe nel tipo, si ottiene una definizione riutilizzabile. Qualsiasi numero di collegamenti effettivi prodotto-prodotto può fare riferimento alla stessa riga ProductRelationshipType, così il vocabolario rimane ridotto e coerente mentre le istanze di relazione rimangono numerose. Questo è un classico modello di normalizzazione: separare il tipo di relazione dalle sue istanze.

La descrizione nomina esplicitamente tre tipologie — bundle, opzione e covering — che alludono alla gamma di semantica commerciale che il modello intende coprire:

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

• Bundle — prodotti venduti insieme come un’unità (il genitore “consiste in” figli).
• Opzione — una scelta o un add-on associato a un prodotto base.
• Covering — un prodotto che avvolge o protegge un altro, comune nei contesti di assicurazione e garanzia.

Come decidere il vocabolario dei ruoli

Poiché parentProductRole e childProductRole sono stringhe a formato libero, il modello non detta il testo esatto. Questa flessibilità è sia una caratteristica che un rischio. Alcune regole pratiche:

1. Scegli un vocabolario controllato e congelalo. Concorda un piccolo set di frasi di ruolo (“Consiste in” / “Componente di”, “Add-on opzionale di” / “Ha opzione”) e documentale. Il testo libero invita alla deriva.
2. Mantieni i ruoli simmetrici e leggibili in entrambe le direzioni. Un buon test: riesci a leggere la relazione ad alta voce da entrambe le estremità e ha senso?
3. Non sovraccaricare i ruoli con la logica di business. Se un ruolo necessita di un comportamento condizionale, tale logica appartiene all’applicazione consumatrice, non alla stringa.
4. Versiona il tuo vocabolario. Quando aggiungi un ruolo, trattalo come una modifica dello schema con un percorso di migrazione, non come un inserimento ad hoc.

Adottare CIM nella pratica

Adottare un modello canonico è una disciplina di mappatura, non una migrazione. Una sequenza percorribile:

• Inventaria i tuoi sistemi di registrazione (systems of record). Per ogni gruppo di entità, decidi quale sistema sia autorevole. Party potrebbe risiedere nel CRM; Product nel PIM; Sales Order nell’ERP.
• Mappa ogni sorgente ai termini CIM. Costruisci una tabella campo sorgente $\rightarrow$ proprietà CIM. Dove una sorgente non ha un equivalente, annota il gap; dove CIM non ha un equivalente, annota l’estensione.
• Riconcilia gli identificatori. La convenzione GUID di CIM implica che tipicamente manterrai una tabella di crosswalk tra le chiavi native e i valori id di CIM.
• Scegli una serializzazione. I termini basati su URI di CIM si mappano naturalmente su JSON-LD e RDF; si traducono inoltre chiaramente in tabelle relazionali o in un property graph. Il modello non impone una tecnologia di archiviazione.
• Governa il vocabolario. Le stringhe di ruolo, le enumerazioni e le estensioni che aggiungi sono le parti più soggette a deriva, quindi sottoponile a controllo delle modifiche.

Un modello mentale utile è trattare CIM come lo schema di interscambio e i tuoi store operativi come il sistema di registrazione. Non stai chiedendo a ogni applicazione di abbandonare il proprio modello nativo; stai chiedendo loro di pubblicare e consumare un modello condiviso ai confini.

Se stai facendo acquisti: Boomi AtomSphere — Enterprise iPaaS per l'integrazione ibrida da cloud a on-premise.

Avvertenze e compromessi

Nessun modello canonico è privo di costi, e CIM non fa eccezione.

• L’astrazione ha un prezzo. Un modello sufficientemente generale da coprire interi settori non si adatterà perfettamente a nessuno di essi. Aspettati di dover aggiungere estensioni.
• Il gruppo Sales Order è pesante. La sua scomposizione a grana fine è potente, ma comporta più join e più entità da mappare. I team con flussi d’ordine semplici potrebbero adottarne solo un sottoinsieme.
• Le stringhe di ruolo a formato libero necessitano di governance. Come notato, la flessibilità in parentProductRole e childProductRole è valida solo quanto la disciplina che la circonda.
• I modelli aperti evolvono. Poiché CIM è orientato alla comunità, i termini possono essere aggiunti o affinati nel tempo. Vincolati a una versione e rivedi le modifiche deliberatamente.

Il compromesso è essenzialmente quello classico tra fedeltà a un sistema specifico e portabilità tra sistemi. CIM ottimizza per la portabilità, che è la scelta corretta quando l’obiettivo è l’interoperabilità.

Domande frequenti

Cos’è il Cloud Information Model?

Il Cloud Information Model è un modello di dati aperto e indipendente dall’applicazione che definisce entità e termini condivisi per i dati aziendali come party, prodotti, ordini e pagamenti. Fornisce un vocabolario comune affinché diversi sistemi cloud e on-premises possano scambiare dati senza mappature punto-punto ad hoc.

A cosa serve ProductRelationshipType?

ProductRelationshipType definisce i motivi per cui due prodotti sono correlati — ad esempio un bundle, un’opzione o un covering. Memorizza un ruolo genitore e un ruolo figlio in modo che i collegamenti direzionali prodotto-prodotto possano fare riferimento a una definizione condivisa e riutilizzabile, invece di ripetere la semantica su ogni collegamento.

Perché CIM utilizza i GUID per le chiavi primarie?

L’utilizzo di un GUID per la proprietà id significa che gli identificatori sono globalmente univoci senza coordinamento centrale. Ciò è fondamentale in ambienti multi-cloud e multi-vendor dove i record vengono creati in sistemi diversi e successivamente uniti, poiché le collisioni vengono efficacemente evitate.

CIM è uno schema di database o un formato di scambio dati?

È meglio intenderlo come un modello concettuale e di interscambio piuttosto che come uno schema di database fisico. I suoi termini basati su URI si mappano naturalmente su JSON-LD, RDF, tabelle relazionali o property graph, quindi puoi implementarlo con qualsiasi tecnologia di storage già utilizzata dalla tua architettura.

In che modo CIM si relaziona con altri standard come OAGIS o schema.org?

CIM condivide l’obiettivo di tali sforzi – un vocabolario condiviso per l’interoperabilità – ma è progettato per l’integrazione aziendale dell’era del cloud e pubblicato come termini aperti e dereferenziabili. In pratica, è possibile mappare CIM verso altri standard ai margini, laddove i partner li richiedano.

Devo adottare l’intero modello tutto in una volta?

No. CIM è organizzato in gruppi di entità a basso accoppiamento, quindi puoi adottare i gruppi di cui hai bisogno – ad esempio, Party e Product – ed espandere in seguito. La maggior parte dei team inizia con le entità che causano i maggiori problemi di integrazione e cresce a partire da lì.

Ulteriori letture

• Sales order — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — vocabolario condiviso per dati strutturati sul web