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 indipendente dall’applicazione — un vocabolario condiviso di concetti aziendali (clienti, ordini, prodotti e così via) che consente a diversi sistemi cloud e on-premises di scambiare dati senza mappature punto-punto personalizzate.
• Esiste per risolvere un problema specifico e costoso: ogni applicazione fornisce il proprio modello di dati, quindi i team di integrazione finiscono per scrivere e mantenere un codice di traduzione personalizzato che è fragile e rallenta l’innovazione.
• È governato come uno standard aperto, prodotto da un consorzio e reso open source sotto la Joint Development Foundation, parte della Linux Foundation — quindi chiunque può contribuire, rivederlo e adottarlo.
• Il contenuto è organizzato in Aree Tematiche (domini), ciascuna delle quali rappresenta un concetto aziendale principale, con progetti pubblicati in più formati, inclusi diagrammi di esempio.
• CIM è un modello, non un prodotto. Definisce significato e struttura; spetta a voi scegliere come mappare, archiviare e spostare i dati nei vostri sistemi.

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, è possibile 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-premises. Ognuna di esse include il proprio modello di dati, il che costringe gli sviluppatori a creare, testare e gestire il 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.

Perché i modelli di dati specifici per applicazione falliscono

Il problema principale che CIM affronta non è che una singola applicazione abbia un modello di dati errato. La maggior parte è perfettamente ragionevole all’interno dei propri confini. Il problema è l’esplosione combinatoria che si verifica quando se ne collegano molte.

Considerate un tipico stack aziendale: un CRM, un ERP, una piattaforma di marketing automation, un help desk, un data warehouse e una manciata di strumenti SaaS line-of-business. Se ogni sistema ha la propria nozione di “cliente”, “account”, “ordine” e “prodotto”, allora ogni coppia di sistemi che deve condividere dati richiede la propria mappatura. Il numero di integrazioni cresce all’incirca con il quadrato del numero di sistemi, e ogni mappatura è un piccolo pezzo di logica non documentato e senza un proprietario che qualcuno deve mantenere per sempre.

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

I sintomi sono familiari a chiunque abbia gestito un’attività di integrazione:

• Deriva semantica. “Cliente” nel CRM significa un’entità di fatturazione; nell’help desk significa una persona che apre ticket. La stessa parola, due significati, riconciliati silenziosamente da una mappatura che nessuno ricorda di aver scritto.
• Pipeline fragili. Un fornitore rinomina un campo o modifica un’enumerazione, e un job ETL fallisce alle 2 del mattino perché la mappatura era codificata rigidamente rispetto alla vecchia struttura.
• Sforzi duplicati. Due team creano indipendentemente traduzioni quasi identiche tra gli stessi due sistemi perché non esiste un riferimento condiviso a cui fare affidamento.
• Vendor lock-in tramite i dati. Migrare da una piattaforma è costoso non a causa del software, ma a causa della logica di traduzione accumulata e legata al suo schema.

Un modello condiviso e indipendente dall’applicazione attacca la causa alla radice: invece di mappature N-a-N, ogni sistema si mappa una sola volta su un modello comune, e il modello comune ne veicola il significato.

Cosa significa realmente “indipendente dall’applicazione”

Vale la pena essere precisi riguardo alla filosofia di progettazione, perché il termine “agnostico” viene spesso usato in modo approssimativo.

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

Un modello indipendente dall’applicazione non è di proprietà di, né ottimizzato per, il prodotto di un singolo fornitore. Descrive i concetti aziendali in termini che sarebbero riconoscibili per un esperto di dominio — un cliente, un ordine, un prodotto, una posizione — piuttosto che in termini che rispecchiano le tabelle interne di una singola applicazione. Questa neutralità è ciò che lo rende un hub utile: nessun partecipante deve adottare la visione del mondo di un concorrente per interoperare.

Questo è lo stesso istinto architettonico alla base di altri standard di interscambio neutrali. Proprio come il Resource Description Framework (RDF) e schema.org forniscono al web un vocabolario condiviso per descrivere le cose, e proprio come l’EDI e successivamente l’UBL (Universal Business Language, uno standard OASIS) hanno fornito alle supply chain un formato condiviso per le transazioni, CIM mira a fornire alle applicazioni aziendali un vocabolario condiviso per le loro entità aziendali principali. La differenza è l’ambito e la modernità: CIM si rivolge al mondo connesso, basato su API, cloud e on-premises, piuttosto che allo scambio di file batch.

Un modello mentale utile è il pattern del modello di dati canonico dell’integrazione aziendale, reso popolare in Enterprise Integration Patterns di Gregor Hohpe e Bobby Woolf. CIM è, di fatto, un modello canonico mantenuto collaborativamente — l‘“hub” in una topologia di integrazione hub-and-spoke — ma che è aperto, versionato e condiviso tra organizzazioni, piuttosto che inventato privatamente all’interno di una singola azienda.

Come è organizzato CIM: Aree Tematiche e Domini

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

In pratica, ciò significa che dovresti pensare a CIM come a una libreria di modelli correlati piuttosto che a un singolo schema monolitico. Le aree tematiche tipiche si concentrano attorno a esigenze aziendali riconoscibili — ad esempio, parti e conti, prodotti e cataloghi, ordini e transazioni, e le relazioni che li legano tra loro. Poiché ogni area è pubblicata con diagrammi e definizioni leggibili dalla macchina, team diversi possono adottare aree diverse in momenti diversi senza attendere il completamento dell’intero modello.

Da questa struttura derivano alcune implicazioni pratiche:

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

• Adotta in modo incrementale. Non è necessario mappare l’intera azienda su CIM fin dal primo giorno. Inizia con l’Area Tematica che crea più problemi — di solito il dominio del cliente o dell’ordine — ed espandi.
• Estendi anziché biforcare. Quando a CIM manca un concetto di cui hai bisogno, il modello aperto è progettato per essere esteso. Contribuire con un’estensione è preferibile piuttosto che mantenere un fork privato, perché un fork diverge e perde il vantaggio dell’interoperabilità.
• Tratta i diagrammi come documentazione, non come fonte di verità. I diagrammi di esempio sono per gli esseri umani; le definizioni leggibili dalla macchina sono ciò che i tuoi strumenti dovrebbero consumare.

CIM nel panorama dell’integrazione: come decidere

CIM è un’opzione tra le tante per domare la complessità dell’integrazione. Per scegliere bene è necessario abbinare lo strumento al problema. La tabella seguente mette a confronto gli approcci principali che un architetto dei dati aziendali solitamente valuta.

Approccio	Cos’è	Meglio quando	Principale compromesso
Mappatura punto-punto	Codice personalizzato che traduce direttamente tra due sistemi	Solo due sistemi, schemi stabili, orizzonte breve	Non scala; esplosione N-a-N; fragile
Modello canonico (es. CIM)	Un modello condiviso e neutrale a cui ogni sistema si mappa una sola volta	Molti sistemi, cross-vendor, integrazione a lungo termine	Sforzo di modellazione iniziale; governance necessaria
Connettori iPaaS del fornitore	Connettori precostruiti di una piattaforma di integrazione	Coppie SaaS comuni, velocità preferita al controllo	Semantica specifica del connettore; potenziale lock-in
Standard di interscambio di settore (EDI, UBL, HL7, ecc.)	Formati di messaggio specifici del dominio	Verticali regolamentati o ben consolidati	Ambito ristretto; spesso orientato al batch
Virtualizzazione / federazione dei dati	Query tra le fonti senza centralizzare	Analytics, accesso prevalentemente in lettura	Non risolve da solo i conflitti semantici

L’euristica decisionale è semplice: se hai più di una manciata di sistemi che devono concordare sul significato di entità condivise, e tali sistemi provengono da fornitori diversi, un modello canonico si ripaga da solo. Se hai due sistemi e non hai intenzione di aggiungerne altri, il punto-punto va bene. Se la tua esigenza è puramente analitica e di sola lettura, la federazione può essere sufficiente — ma nota che la federazione sposta il problema semantico anziché risolverlo.

CIM è complementare, e non un sostituto, degli strumenti che lo circondano. Una pipeline ETL o ELT (costruita con strumenti come Apache Airflow, dbt o una piattaforma commerciale) si occupa ancora del movimento; CIM definisce cosa significano i dati una volta arrivati. Un broker di messaggi come Apache Kafka si occupa comunque del trasporto; CIM definisce la forma degli eventi. Il modello è il contratto; il tooling è l’impianto idraulico.

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

Governance, licenze e perché la Fondazione è importante

CIM è open source come parte della Joint Development Foundation, che opera sotto la Linux Foundation. Questo non è un dettaglio banale: è fondamentale per spiegare perché un’azienda può basarsi in sicurezza su CIM.

La Linux Foundation è una sede neutrale ben consolidata per progetti open source collaborativi, e la Joint Development Foundation fornisce una struttura legale leggera per lo sviluppo collaborativo di standard e specifiche. Ospitare CIM lì significa:

• Gestione neutrale. Nessun singolo fornitore controlla il modello, quindi adottarlo non significa adottare la roadmap di un concorrente.
• Contributo aperto. Chiunque — fornitori, aziende, singoli contributori — può proporre modifiche, e il processo è trasparente.
• Licenze prevedibili. Le specifiche ospitate dalla Fondazione in genere prevedono termini progettati per un’adozione ampia e favorevole alle royalty, il che è estremamente importante per i team legali e di procurement che valutano uno standard.

Per un architetto che deve sostenere la scelta internamente, questa storia di governance è spesso importante quanto il contenuto tecnico. “È uno standard aperto sotto la Linux Foundation” risponde alle domande che bloccano l’adozione degli standard: chi lo controlla? Cosa succede se un fornitore esce? Possiamo contribuire con le nostre estensioni?

Per iniziare: un percorso pratico di adozione

Adottare un modello condiviso è un esercizio tanto organizzativo quanto tecnico. Una sequenza pragmatica è la seguente:

1. Inventaria le tue entità condivise. Identifica i concetti aziendali che compaiono in più di un sistema — in genere cliente, prodotto, ordine e ubicazione. Questi sono i tuoi candidati.
2. Scegli un’Area Tematica e un’integrazione. Scegli l’integrazione con il maggiore disagio e il raggio di impatto più basso per testare il modello. L’ideale è una singola pipeline di reporting o l’onboarding di una nuova applicazione.
3. Mappa ogni sistema su CIM una sola volta. Costruisci la traduzione da ciascun sistema di origine alla rappresentazione CIM, e da CIM a ciascun target. Resisti alla tentazione di mappare direttamente da sistema a sistema.
4. Documenta le tue estensioni. Laddove CIM non copra un concetto, registra l’estensione esplicitamente e valuta la possibilità di contribuire nuovamente.
5. Stabilisci la proprietà. Un modello canonico senza un responsabile decade. Assegna un team o un ruolo responsabile delle mappature e del monitoraggio delle modifiche a monte.
6. Versiona e testa. Tratta il modello e le sue mappature come artefatti versionati con test, esattamente come faresti con il codice di un’applicazione.

La modalità di fallimento più comune è quella di considerare il CIM come un esercizio di modellazione una tantum piuttosto che come un contratto vivo. Le organizzazioni che hanno successo trattano il modello nello stesso modo in cui trattano un’API: versionato, testato, gestito ed evoluto deliberatamente.

Partner che contribuiscono al CIM

CIM è uno sforzo consortile e il suo valore cresce con la partecipazione. I partner contribuiscono ai contenuti delle Subject Area, esaminano le proposte e aiutano a definire la direzione del modello. Poiché il lavoro è aperto, i contributi non sono limitati ai grandi fornitori: le imprese con reali difficoltà di integrazione e i singoli professionisti con esperienza nel settore sono ugualmente benvenuti.

Mettiti in contatto

Sei interessato ad aderire all’iniziativa CIM? Ottimo! Non esitare a contattarci via email per ulteriori informazioni. Inviaci un’e-mail.

Domande frequenti

Cos’è il Cloud Information Model (CIM)?

CIM è un modello di dati open source, indipendente dalle applicazioni, che fornisce un vocabolario condiviso e basato su standard per i concetti di business che le aziende devono scambiare tra applicazioni cloud e on-premises. È prodotto da un consorzio aperto e ospitato dalla Joint Development Foundation, parte della Linux Foundation. Il suo scopo è ridurre il codice di mappatura personalizzato richiesto dalle fragili integrazioni punto a punto.

CIM è un prodotto o una specifica?

CIM è una specifica — un modello e un insieme di definizioni — non un prodotto eseguibile. Definisce il significato e la struttura delle entità condivise; puoi comunque scegliere i tuoi strumenti ETL/ELT, i broker di messaggi e l’archiviazione. Consideralo come il contratto che la tua infrastruttura di integrazione implementa, piuttosto che l’infrastruttura stessa.

In cosa differisce CIM dalla piattaforma di integrazione di un fornitore?

Una piattaforma di integrazione (un iPaaS o una libreria di connettori) sposta i dati e spesso fornisce connettori precostruiti, ma tali connettori codificano la semantica specifica del fornitore. CIM è neutrale e indipendente dal fornitore, quindi non ti vincola alla visione del mondo di un’unica piattaforma. I due sono complementari: puoi utilizzare CIM come modello canonico all’interno di qualsiasi piattaforma di integrazione.

Cosa sono le Subject Area in CIM?

Le Subject Area (chiamate anche domini) sono le unità organizzative del modello, ciascuna delle quali rappresenta un concetto aziendale importante come clienti, prodotti o ordini. I progetti vengono pubblicati in più formati, inclusi diagrammi di esempio, e si prevede che l’insieme delle Subject Area cresca man mano che il consorzio e la comunità contribuiscono con più contenuti.

Possiamo estendere CIM se non copre i nostri concetti?

Sì. CIM è progettato per essere esteso e, poiché è open source sotto una fondazione neutrale, è possibile proporre aggiunte attraverso il processo di contribuzione. Estendere il modello condiviso e contribuire a sua volta è fortemente preferibile al mantenimento di un fork privato, che tende a divergere nel tempo e annulla il vantaggio di interoperabilità che ha motivato l’adozione di CIM in primo luogo.

Chi dovrebbe adottare il CIM?

È estremamente prezioso per le organizzazioni che utilizzano molte applicazioni di fornitori diversi che devono concordare il significato di entità condivise: la situazione classica per gli architetti di dati aziendali e gli ingegneri dell’integrazione. Anche i fornitori di applicazioni e piattaforme traggono vantaggio dall’allineare i propri schemi a un modello neutrale, rendendo i loro prodotti più facili da integrare per i clienti. Se si hanno solo due sistemi stabili, una mappatura punto a punto più semplice potrebbe essere sufficiente.

Ulteriori letture

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia