Modello informativo cloud

Benvenuti in CIM, un modello di dati indipendente dall’applicazione che semplifica l’integrazione e accelera l’innovazione.

Punti chiave

• CIM è un modello di dati aperto e condiviso, non un prodotto. Definisce concetti aziendali comuni e le relative relazioni in modo che diverse applicazioni possano scambiare dati senza mappature personalizzate e create ad hoc.
• È governato come uno standard aperto. CIM è open source nell’ambito della Joint Development Foundation, parte della Linux Foundation, e accoglie contributori da fornitori, aziende e dalla comunità più ampia.
• Il contenuto è organizzato in Aree Tematiche (domini). Ogni dominio rappresenta un concetto aziendale principale ed è pubblicato in più formati, inclusi i diagrammi, in modo che architetti e ingegneri possano adottarlo in modo incrementale.
• Il valore fondamentale è ridurre la fragilità dell’integrazione. Un modello canonico sostituisce il codice di traduzione punto-punto con un target stabile verso cui molti sistemi possono mappare i dati e viceversa.
• L’adozione è una decisione progettuale, non un interruttore. Scegliete quali domini adottare, come mappare i vostri sistemi di origine e come governare le estensioni nel tempo.

Un nuovo standard per l’interoperabilità dei dati

CIM è prodotto da un consorzio aperto formato per fornire una soluzione basata su standard per connettere prodotti aziendali. Con CIM, potete creare esperienze personali fluide e su misura attraverso applicazioni cloud-native.

Per accelerare la trasformazione digitale e offrire interazioni personalizzate ai clienti su ogni canale, molte aziende adottano molteplici applicazioni cloud e on-premise. Ciascuna di esse dispone del proprio modello di dati, il che costringe gli sviluppatori a creare, testare e gestire codice personalizzato necessario per mappare e tradurre i dati tra sistemi diversi. Invece di accelerare la trasformazione digitale, questo processo rallenta l’innovazione e porta a integrazioni fragili.

CIM è una specifica moderna e aperta per aiutare ad alleviare le difficoltà dell’integrazione dei dati. CIM fornisce uno standard definito per comunicare facilmente tra diversi formati di dati. Essendo open source come parte della Joint Development Foundation (sotto la Linux Foundation), diamo il benvenuto a qualsiasi contributore.

Il problema che CIM affronta è strutturale, non incidentale. Quando ogni sistema parla il proprio dialetto — uno chiama un cliente “Contact”, un altro “Party”, un terzo “Account” — i team di integrazione finiscono per mantenere una rete crescente di mappature a coppie.

Ogni nuova applicazione moltiplica il numero di traduzioni richieste, e ogni modifica dello schema in un qualsiasi sistema può propagarsi verso l’esterno e interrompere le pipeline a valle. Un modello canonico cambia la natura di questo problema: invece di N sistemi che mappano l’uno verso l’altro, ogni sistema mappa una sola volta verso un vocabolario condiviso.

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

Perché l’integrazione punto-punto fallisce

È utile essere concreti riguardo alle modalità di fallimento che motivano l’uso di un modello condiviso.

• Crescita combinatoria. Con le mappature punto-punto, il numero di percorsi di traduzione cresce all’incirca con il quadrato del numero di sistemi. Aggiungere una decima applicazione è molto più costoso che aggiungere la seconda.
• Deriva semantica. Due team possono entrambi “mappare il cliente” e tuttavia non essere d’accordo sul fatto che un cliente sia una persona, un’organizzazione o un rapporto di fatturazione. I dati fluiscono, ma il significato diverge.
• Gestione fragile delle modifiche. La ridenominazione di un campo o un nuovo attributo obbligatorio in un sistema di origine impone modifiche a ogni consumatore che lo utilizza.
• Logica duplicata. Le regole di convalida, deduplicazione e risoluzione dell’identità vengono reimplementate in ogni integrazione invece di essere definite una sola volta.
• Pressione di vendor lock-in. Quando la logica di integrazione è intrecciata con lo schema di un fornitore specifico, cambiare o aggiungere fornitori diventa un progetto di ri-platforming.

Un modello canonico come CIM non elimina il lavoro di mappatura — ogni sistema sorgente necessita comunque di una mappatura verso il modello. Ciò che elimina è la moltiplicazione di tale lavoro. Si crea una sola mappatura per sistema verso il modello condiviso, e il modello stesso fornisce il contratto stabile tra di essi.

Come è organizzato CIM: Aree Tematiche

Il contenuto definito collaborativamente è organizzato in domini, o Aree Tematiche. Ciascuna Area Tematica rappresenta un concetto aziendale principale. I design di CIM sono disponibili in più formati per ogni dominio, inclusi diagrammi di esempio. Il numero e la portata delle Aree Tematiche cresceranno insieme al consorzio e ai contributi.

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

Questa struttura orientata al dominio è fondamentale per l’adozione. Raramente è necessario l’intero modello tutto in una volta. Un’impresa tipica inizia con i domini che riguardano l’integrazione più problematica, ne prova l’approccio e poi si espande. I punti di partenza comuni tendono a essere i concetti che appaiono in quasi ogni sistema:

• Party / Customer — le persone e le organizzazioni con cui si fanno affari e i ruoli che svolgono.
• Product — ciò che si vende, si offre o si gestisce, inclusi cataloghi e classificazioni.
• Account and relationship — come le parti si relazionano con i prodotti, i contratti e tra di loro.
• Interaction and activity — gli eventi, le transazioni e le interazioni che collegano quanto sopra.

Poiché ogni Area Tematica è pubblicata con diagrammi e molteplici formati di rappresentazione, gli architetti possono rivedere il modello concettuale, gli ingegneri possono consumare una forma leggibile dalla macchina e gli stakeholder aziendali possono validare che i concetti corrispondano alla realtà. Questo approccio multiformato è una scelta progettuale deliberata: un modello che solo gli ingegneri possono leggere tende ad allontanarsi dal significato aziendale.

Come CIM si confronta con altri approcci

CIM è una delle diverse opzioni per raggiungere l’interoperabilità. Scegliere correttamente significa comprenderne i compromessi.

Approccio	Cos’è	Punti di forza	Compromessi
Mappatura punto a punto	Traduzioni dirette tra ogni coppia di sistemi	Semplice per due sistemi; non è necessaria una governance condivisa	Cresce in modo combinatorio; fragile; logica duplicata
Modello canonico (stile CIM)	Un vocabolario condiviso e indipendente dall’applicazione a cui ogni sistema si mappa	Sforzo di mappatura lineare; contratto stabile; riutilizzabile tra i progetti	Richiede governance e accordo; la mappatura è comunque necessaria per ogni sistema
Standard di dati di settore	Standard verticali per un settore specifico (es. sanità, finanza)	Copertura approfondita del dominio; allineamento normativo	Ambito ristretto; potrebbe non coprire concetti aziendali intersettoriali
Modelli di dati del fornitore	Lo schema nativo di una piattaforma esposto come hub di integrazione	Stretta integrazione degli strumenti; veloce all’interno dell’ecosistema di un singolo fornitore	Rischio di lock-in; gli altri fornitori devono conformarsi al modello di una sola parte
API-first / schema-on-read	Contratti definiti per API; significato risolto al momento del consumo	Flessibile; veloce da avviare	La coerenza semantica dipende dalla disciplina; più difficile da governare su larga scala

La guida pratica: utilizzare un modello canonico quando si hanno molti sistemi, concetti cross-dominio e un panorama di integrazione a lungo termine. Utilizzare il punto a punto quando l’ambito è realmente limitato a due sistemi e a breve termine. Gli standard di settore e il CIM sono complementari: uno standard verticale può informare un dominio, mentre il CIM fornisce il vocabolario aziendale trasversale.

Come adottare il CIM nella pratica

L’adozione è una sequenza di decisioni deliberate piuttosto che una singola migrazione. Un modello applicabile è il seguente:

1. Scegliere un’integrazione ad alto impatto (high-pain) e ben delimitata. Scegliere un dominio in cui le difficoltà di mappatura siano reali e l’ambito sia sufficientemente piccolo da dimostrare rapidamente il valore.
2. Inventariare i sistemi di origine e i relativi schemi. Documentare come ogni sistema definisce i concetti nell’Area Tematica scelta e dove vi siano divergenze.
3. Mappare ogni sistema al dominio CIM. Creare una mappatura per sistema verso il modello condiviso. Trattare queste mappature come artefatti versionati, non come script usa e getta.
4. Definire in anticipo la politica di estensione. Decidere come gestire i concetti che il CIM non copre ancora: le estensioni dovrebbero essere documentate, denominate in modo coerente e proposte al consorzio qualora risultino ampiamente utili.
5. Stabilire la governance. Assegnare la responsabilità delle mappature, un processo di revisione per le modifiche e una cadenza per la sincronizzazione con gli aggiornamenti CIM upstream.
6. Espandere dominio per dominio. Riutilizzare i modelli di mappatura e la governance del primo dominio per ridurre i costi del successivo.

Due avvertenze meritano di essere espresse chiaramente. In primo luogo, un modello canonico aggiunge un livello: non è gratuito, e il beneficio deriva dal riutilizzo in molte integrazioni, non da una singola. In secondo luogo, la mappatura è dove risiede il vero lavoro; il modello fornisce un obiettivo stabile, ma qualcuno deve comunque decidere come ogni campo di origine corrisponda ad esso, e tale decisione beneficia dell’input aziendale, non solo di quello tecnico.

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

Governance, Licenze e Contributi

Il CIM è open source come parte della Joint Development Foundation, che opera sotto la Linux Foundation. Questa struttura è fondamentale per le aziende che lo valutano: la Linux Foundation è una sede consolidata per progetti open source collaborativi e vendor-neutral, e la Joint Development Foundation fornisce un quadro legale specificamente progettato per lo sviluppo e la gestione di standard e progetti di specifica.

Per un architetto dei dati aziendali, le implicazioni pratiche di questo modello di governance sono:

• Neutralità del fornitore. Nessun singolo fornitore controlla la specifica, riducendo il rischio che il modello sia plasmato per favorire una piattaforma specifica.
• Contributo aperto. Chiunque può proporre modifiche, il che significa che il modello può evolversi per riflettere le esigenze di integrazione del mondo reale piuttosto che un’unica roadmap.
• Processo orientato alle specifiche. Il modello della Joint Development Foundation è basato sulla produzione e manutenzione di specifiche, il che si allinea al modo in cui gli standard vengono adottati e referenziati negli appalti e nelle revisioni dell’architettura.

Il contributo è incoraggiato e aperto a tutti. I contributi assumono tipicamente la forma di nuove o perfezionate Aree Tematiche, correzioni e chiarimenti, diagrammi di esempio e feedback da progetti di integrazione reali. I contributi più preziosi spesso provengono da professionisti che hanno affrontato un problema di mappatura specifico e sanno descrivere il concetto che lo risolve.

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

Partecipare

Sei interessato a unirti all’iniziativa CIM? Ottimo! Non esitare a scriverci via email per ulteriori informazioni.

Oltre alle email, i modi naturali per partecipare sono rivedere le Aree Tematiche pubblicate per il tuo dominio di interesse, provare a mappare uno dei tuoi sistemi su un dominio e riportare le lacune riscontrate alla comunità. Poiché il numero e l’ambito delle Aree Tematiche crescono con il consorzio e i contributi, il modello migliora in proporzione a quanti problemi di integrazione reali gli utenti gli sottopongono.

Domande Frequenti

Cos’è esattamente il Cloud Information Model?

Il CIM è un modello di dati aperto e indipendente dall’applicazione che definisce concetti aziendali comuni e le loro relazioni, affinché diverse applicazioni possano scambiare dati attraverso un vocabolario condiviso. È prodotto da un consorzio aperto e pubblicato come specifica aperta. Piuttosto che essere un prodotto da installare, è un modello a cui mappare i propri sistemi.

A chi è rivolto il CIM?

Si rivolge ad architetti di dati aziendali, ingegneri di integrazione ed ETL, fornitori di applicazioni e piattaforme e contributori open source. Chiunque debba connettere più sistemi cloud e on-premise con schemi differenti è un potenziale utente. I fornitori ne beneficiano perché un modello condiviso riduce il lavoro di personalizzazione richiesto per l’integrazione con i loro prodotti.

Come è governato e licenziato il CIM?

CIM è open source come parte della Joint Development Foundation, che opera sotto la Linux Foundation. Ciò fornisce un quadro di governance indipendente dal fornitore e orientato alle specifiche. Tale struttura ha lo scopo di mantenere il modello aperto ai contributi e indipendente dal controllo di un singolo fornitore.

In cosa differisce CIM dal modello dati nativo di un fornitore?

Il modello nativo di un fornitore è ottimizzato per il prodotto e l’ecosistema di quel fornitore; adottarlo come hub di integrazione tende a creare un lock-in. CIM è progettato per essere application-agnostic, quindi nessuna singola piattaforma definisce il vocabolario. Il compromesso è che CIM richiede governance e accordo tra i team, mentre un modello di fornitore è pronto per l’uso all’interno degli strumenti di quel fornitore.

Devo comunque scrivere le mappature se utilizzo CIM?

Sì. Ogni sistema sorgente necessita ancora di una mappatura verso il modello condiviso. Il vantaggio è che si scrive una sola mappatura per sistema verso CIM, anziché una traduzione separata per ogni coppia di sistemi. Ciò trasforma lo sforzo di mappatura combinatoria in uno sforzo approssimativamente lineare e fornisce un contratto stabile che sopravvive ai cambiamenti nei singoli sistemi.

Come posso iniziare ad adottare CIM?

Inizia con un’unica integrazione ad alto impatto (high-pain) e ben delimitata in un’unica Area Tematica (Subject Area). Inventaria gli schemi sorgente, mappa ogni sistema al dominio CIM, definisci una policy di estensione e governance e tratta le mappature come artefatti versionati. Una volta che il primo dominio ne ha dimostrato il valore, espandi dominio per dominio, riutilizzando i pattern e la governance stabiliti.

Ulteriori letture

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia