Partecipa

Fondato nel 2019 sotto l’egida della Linux Foundation, il Cloud Information Model (CIM) è sia un’alleanza di membri che una comunità. Insieme, collaborando in Working Group, i membri definiscono e utilizzano un modello di dati aperto comune, influenzano gli standard esistenti e futuri e creano soluzioni aperte per risolvere problemi comuni.

CIM esiste perché i dati aziendali sono frammentati in decine di applicazioni, ciascuna con il proprio schema proprietario, convenzioni di denominazione e semantica. Un cliente in Salesforce, un cliente in SAP e un cliente in un sistema di fatturazione interno sono tutti “clienti”, ma raramente concordano su cosa sia un cliente, quali attributi siano autorevoli o come debbano essere espresse le relazioni tra clienti, ordini e prodotti. La risposta di CIM è un modello condiviso e indipendente dall’applicazione a cui qualsiasi sistema può mappare, così che il lavoro di integrazione diventi un esercizio di mappatura piuttosto che un progetto di traduzione su misura.

Punti chiave

• CIM è un progetto della Linux Foundation (fondato nel 2019) che pubblica un modello di dati aperto e basato su standard, tradotto in più formati affinché sistemi eterogenei possano adottarlo.
• La partecipazione è suddivisa in livelli: Steering Members, Contributor Members e la più ampia comunità CIM, con diritti progressivamente più ampi man mano che si sale di livello.
• L’unico attuale Working Group definisce nuove Subject Area, mappature e requisiti API: è qui che avviene il lavoro tecnico sostanziale.
• Il contributo non è solo codice: proporre Subject Area, partecipare a sondaggi di consenso e unirsi ai Working Group sono tutti modi di primo piano per dare forma allo standard.
• Il modello è deliberatamente neutro rispetto al formato, il che consente a consumatori relazionali, a grafo e orientati alle API di condividere un’unica definizione canonica.

Perché è importante un modello di dati condiviso

La maggior parte delle difficoltà di integrazione è semantica, non tecnica. Le pipeline ETL, le piattaforme iPaaS e i gateway API sono maturi; ciò che si rompe è lo strato di significato. Quando due sistemi non concordano sul fatto che “account” significhi un’entità di fatturazione o una gerarchia aziendale, ogni report, join e riconciliazione a valle eredita tale ambiguità.

Un modello canonico come CIM affronta questo problema fornendo un punto di riferimento neutrale. Invece di mappare N sistemi tra loro (un problema N×N), ogni sistema mappa una volta sola al modello canonico (un problema N×1). Questo è lo stesso principio architetturale alla base di standard come il Common Information Model utilizzato nel settore energetico (IEC 61970/61968) e le risorse HL7 FHIR utilizzate nell’assistenza sanitaria: modelli canonici specifici per dominio che consentono l’interoperabilità di sistemi costruiti indipendentemente.

L’ambito di CIM è più ampio e orizzontale: si rivolge alle entità aziendali comuni — clienti, prodotti, ordini, fornitori e le relazioni tra loro — che compaiono nei sistemi CRM, ERP, di commercio e della supply chain. L’obiettivo non è sostituire i modelli nativi di questi sistemi, ma posizionarsi al di sopra di essi come vocabolario condiviso.

Ambito del Working Group

Abbiamo sviluppato il Cloud Information Model (CIM) con un approccio basato su standard e lo abbiamo tradotto in più formati. Questo approccio consente alle aziende con tecnologie diverse di adottare CIM. Inoltre, potenzia i contributori e favorisce la crescita di un ecosistema CIM più ampio.

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

Concretamente, “più formati” significa che lo stesso modello sottostante può essere consumato da diverse toolchain — ad esempio, come definizione di schema per archivi relazionali o documentali, come grafo di entità e relazioni e come base per contratti API. Un team che utilizza un warehouse relazionale, un team che utilizza un database a grafo e un team che sviluppa servizi REST o GraphQL possono tutti lavorare partendo da un’unica fonte di verità anziché da tre definizioni divergenti.

Questa neutralità del formato è una scelta progettuale deliberata con reali compromessi:

• Pro: Nessuno strumento di un singolo fornitore è privilegiato, quindi l’adozione non è vincolata all’acquisto di una particolare piattaforma.
• Pro: Il modello può evolversi indipendentemente da qualsiasi formato di serializzazione.
• Contro: I contributori devono riflettere attentamente su quali costrutti siano veramente canonici rispetto agli artefatti di un formato particolare.
• Contro: Gli strumenti per la traduzione tra formati devono essere mantenuti e il round-tripping non è sempre privo di perdite.

Per gli architetti che valutano se adottare CIM, la questione pratica è se la superficie di integrazione sia dominata da entità aziendali condivise. Se la maggior parte delle mappature sono una tantum e specifiche per dominio, un modello canonico aggiunge overhead. Se si mappano ripetutamente le stesse poche entità su molti sistemi, la riduzione N×1 si ripaga da sola.

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

Cloud Information Model Working Group

Attualmente, CIM ha un unico Working Group che lavora alla definizione di nuove Subject Area, mappature e requisiti API.

Una Subject Area è una sezione coerente del modello — ad esempio, un raggruppamento di entità e relazioni attorno a un dominio aziendale. Proporre una Subject Area è uno dei contributi di maggior impatto che un membro possa dare, perché determina cosa coprirà lo standard in seguito. Le mappature collegano le Subject Area a sistemi e formati del mondo reale; i requisiti API catturano ciò di cui i consumatori hanno bisogno dai servizi costruiti sul modello.

Se state considerando di unirvi al Working Group, un modo utile per decidere dove contribuire è chiedersi:

1. Quali entità causano la maggior parte delle rielaborazioni di integrazione nella vostra organizzazione? Queste sono candidate per proposte di Subject Area.
2. Dove i vostri sistemi concordano già e dove divergono silenziosamente? La divergenza è dove le mappature aggiungono più valore.
3. Di cosa hanno effettivamente bisogno i vostri consumatori a valle da un’API? Questo definisce i requisiti API.

Poiché attualmente esiste un unico Gruppo di Lavoro, il percorso pratico per un nuovo contributore è solitamente quello di unirsi ad esso e proporre un’Area Tematica, piuttosto che creare un nuovo gruppo. Proporre un nuovo Gruppo di Lavoro è un diritto riservato ai livelli più alti ed è preferibile riservarlo ad aree di lavoro genuinamente distinte che altrimenti sovraccaricherebbero il gruppo esistente.

Livelli di Membership e Vantaggi

La partecipazione a CIM è strutturata in livelli, ciascuno con diritti progressivamente più ampi. La tabella seguente riassume i vantaggi così come pubblicati da CIM.

Vantaggio	Membro Direttivo	Contributore	Comunità CIM
Utilizzo dei rilasci del Modello CIM	✓	✓	✓
Rimanere aggiornati sui progressi e sulle innovazioni CIM	✓	✓	✓
Contribuire con idee al Consorzio CIM	✓	✓	✓
Possibilità di proporre un’Area Tematica	✓	✓	✓
Accesso a risorse riservate e private	✓	✓
Idoneità a unirsi a un Gruppo di Lavoro	✓	✓
Contribuire ai Gruppi di Lavoro	✓	✓
Proporre nuovi Gruppi di Lavoro	✓	✓
Conteggio ai fini del quorum minimo di supporto di un’Area Tematica	✓	✓
Partecipare ai sondaggi di consenso	✓	✓
Contribuire alla Roadmap CIM	✓	✓
Guidare la direzione strategica generale di CIM	✓
Idoneità a far parte del Comitato Direttivo	✓
Idoneità per una posizione di Chair di un Gruppo di Lavoro	✓
Idoneità a votare per l’adozione di contenuti come parte dello Standard CIM	✓
Possibilità di presentare ricorso su questioni tecniche	✓
Possibilità di presentare ricorso su questioni procedurali	✓

*Domanda di Membro Direttivo — I Membri Contributori possono richiedere l’adesione come Membri Direttivi.

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

Come leggere i livelli

I livelli si basano su un modello di governance open source familiare, utilizzato in tutti i progetti della Linux Foundation: un’ampia comunità che può utilizzare l’output e contribuire con idee, un livello di contributore che svolge il lavoro pratico e un livello direttivo che gestisce la strategia e l’adozione formale. La distinzione che conta di più nella pratica:

• CIM Community è il punto di ingresso. È possibile adottare i modelli rilasciati e contribuire con idee senza un ruolo operativo formale. Questo è appropriato se si sta valutando CIM per un progetto o si desidera influenzare la direzione in modo informale.
• Contributor è dove risiede l’influenza tecnica. Unirsi a un Gruppo di Lavoro, contribuire ad esso, proporre Aree Tematiche e partecipare ai sondaggi di consenso rientrano in questo livello. Se l’obiettivo è dare forma allo standard piuttosto che limitarsi a consumarlo, questo è il livello a cui puntare.
• Steering Member detiene i diritti di governance: direzione strategica, idoneità al Comitato Direttivo, idoneità alla carica di Chair di un Gruppo di Lavoro e il voto formale per l’adozione di contenuti come parte dello Standard CIM. I Membri Contributori possono richiedere l’adesione come Membri Direttivi.

Un dettaglio sottile ma importante: essere “conteggiati ai fini del quorum minimo di supporto di un’Area Tematica” è un diritto riservato ai Contributori e ai livelli superiori. Le regole sul quorum esistono affinché un’Area Tematica non venga adottata sulla base del solo sostegno di un singolo partecipante — una salvaguardia di governance comune agli organismi di standardizzazione basati sul consenso. Se alla propria organizzazione interessa che una particolare Area Tematica raggiunga l’adozione, la partecipazione a livello di Contributore è ciò che permette di contare per tale soglia.

Come partecipare: un percorso pratico

Se sei nuovo in CIM, una sequenza sensata è:

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

1. Inizia come CIM Community. Esamina i modelli rilasciati e le FAQ, e identifica dove le entità dei tuoi sistemi si sovrappongono alle Aree Tematiche di CIM.
2. Contribuisci con idee. Anche a livello di community puoi proporre idee al Consorzio CIM — un modo a basso impegno per testare se il tuo caso d’uso ha risonanza.
3. Passa a Contributor se desideri svolgere il lavoro. Ciò sblocca la partecipazione ai Gruppi di Lavoro, le proposte di Aree Tematiche e i sondaggi di consenso.
4. Richiedi l’adesione come Membro Direttivo se la tua organizzazione desidera aiutare a definire la direzione e partecipare ai voti formali di adozione.

Per i contributori open source nello specifico, la neutralità del formato del modello significa che c’è spazio per contribuire con strumenti — traduttori di formato, validatori, generatori di mapping — insieme al contenuto del modello stesso. Per i fornitori di piattaforme e applicazioni, mappare lo schema del proprio prodotto su CIM è un modo per ridurre i costi di integrazione a carico dei clienti, il che spesso rappresenta un differenziatore competitivo.

Governance, Standard e Ricorsi

CIM segue un approccio basato sugli standard, che implica un processo definito per la proposta, la revisione e l’adozione dei contenuti. La presenza di diritti formali di “ricorso” — tecnico e procedurale — al livello Direttivo è un segno distintivo di una governance degli standard matura. Ciò significa che le controversie hanno un percorso di risoluzione definito invece di essere risolte informalmente.

Questo rispecchia il modo in cui operano le organizzazioni di standardizzazione consolidate. La Linux Foundation ospita molti di questi progetti e fornisce l’impalcatura legale e di governance — politiche su marchi, IP e antitrust — che consente ai concorrenti di collaborare su un’infrastruttura condivisa. Se si sta valutando l’adozione di CIM a livello aziendale, l’affiliazione alla Linux Foundation è un segnale significativo: significa che il modello è governato da una fondazione neutrale piuttosto che essere di proprietà di un singolo fornitore, riducendo il rischio di futuri cambiamenti di licenza o di direzione.

Informazioni correlate

• Domande frequenti
• Quote di adesione
• Elenco degli attuali membri dello SteerCo
• Modulo Web per i contributori
• Risorse del modello CIM
• Presentazione CIM
• Formati CIM
• CIM nelle notizie
• Repository GitHub
• Blog di notizie
• Contatti

Domande frequenti

Cos’è il Cloud Information Model?

Il Cloud Information Model (CIM) è un modello di dati aperto e una comunità di membri fondata nel 2019 sotto la Linux Foundation. Definisce un modello comune di entità aziendali, indipendente dall’applicazione, in modo che i sistemi cloud e on-premises possano interoperare attraverso una semantica condivisa anziché mappature punto-punto personalizzate.

Chi può aderire al CIM e quanto costa?

CIM ha tre livelli di partecipazione: Steering Member, Contributor e CIM Community. Il livello community è il punto di ingresso più ampio, mentre i membri Contributor possono richiedere l’adesione come Steering Member. Le quote di adesione sono pubblicate separatamente da CIM, pertanto si prega di consultare la pagina Quote di adesione per le cifre attuali invece di presumere un costo.

Cos’è una Subject Area in CIM?

Una Subject Area è una porzione coerente del modello che copre un insieme di entità e relazioni correlate. Proporre una Subject Area è un diritto a livello di Contributor e uno dei modi più diretti per influenzare ciò che lo standard copre. Le Subject Area sono inoltre soggette a un quorum minimo di supporto, che impedisce l’adozione sulla base di un singolo partecipante.

Devo essere uno Steering Member per contribuire?

No. I membri Contributor possono unirsi ai gruppi di lavoro, contribuire ad essi, proporre Subject Area e partecipare ai sondaggi di consenso. L’adesione come Steering Member aggiunge diritti di governance quali la direzione strategica, l’idoneità al Comitato Direttivo (Steering Committee) e il voto formale per l’adozione di contenuti come parte dello Standard CIM.

In che modo CIM si relaziona con altri standard di dati?

CIM è un modello orizzontale e intersettoriale incentrato su entità aziendali comuni, in contrasto con i modelli canonici specifici di dominio come il Common Information Model del settore energetico (IEC 61970/61968) o l’HL7 FHIR del settore sanitario. Il suo design neutrale rispetto al formato gli consente di integrare, anziché sostituire, i modelli nativi dei sistemi già in uso.

Perché la neutralità del formato è importante per l’adozione?

Perché consente a team con stack tecnologici diversi — warehouse relazionali, database a grafo e servizi API — di consumare un’unica definizione canonica invece di mantenere schemi divergenti. Il compromesso è che gli strumenti di traduzione devono essere mantenuti e il round-tripping tra i formati non è sempre privo di perdite, pertanto i team dovrebbero convalidare le mappature rispetto alle loro effettive esigenze di integrazione.

Ulteriori letture

• Gruppo di lavoro — Wikipedia
• Linux Foundation — Wikipedia