CIM-modell

(CIM) er en åpen, applikasjonsagnostisk datamodell beregnet på å gi bedrifter et delt vokabular for enhetene som dukker opp på tvers av CRM-, ERP-, markedsførings-, service- og analysesystemer. I stedet for at hver leverandør finner opp sine egne objektnavn og relasjoner, definerer CIM et felles sett med emneområder, enheter og attributter som ethvert system kan kartlegges til. Modellen forvaltes som et åpen kildekode-prosjekt under The Linux Foundation, som er vert for en bred portefølje av samarbeidsprosjekter innen data og infrastruktur.

Denne artikkelen forklarer hvordan CIM er strukturert, hvordan komponentene relaterer seg til hverandre, hvordan supertyper og undertyper fungerer, og hvordan emneområdene er organisert. Den dekker også de praktiske beslutningene en arkitekt står overfor når man tar i bruk CIM – kartlegging, styring, versjonering og utvidelse – og hvor modellen passer i forhold til andre industristandarder.

Viktige takeaways

• CIM organiserer forretningskonsepter i emneområder (Subject Areas), som hver inneholder enhetsgrupper, enheter og attributter – et hierarki som kartlegges rent til skjemaer, tabeller og kolonner.
• Supertyper og undertyper lar modellen uttrykke delte egenskaper (en part som er en person eller en organisasjon) samtidig som den tillater spesialisering.
• Modellen er bevisst applikasjonsagnostisk: den beskriver forretningskonsepter, ikke implementeringen til en enkelt leverandør.
• CIM er publisert i flere formater med eksempeldiagrammer, slik at den kan brukes av både modelleringsverktøy, kodegeneratorer og dokumentasjon.
• Antallet og omfanget av emneområder vokser med konsortiet og bidrag fra fellesskapet, så adopsjon bør ta hensyn til versjonering og endringshåndtering.
• CIM er ett alternativ blant flere; det riktige valget avhenger av om du trenger en bred modell på tvers av domener eller en smal, dyp standard for én bransje.

Hvordan CIM er strukturert

CIM er organisert i komponenter slik at innholdet kan navigeres og konsumeres lettere. Hvert nivå i hierarkiet svarer på et forskjellig spørsmål, og å forstå dette hierarkiet er det første trinnet for å bruke modellen effektivt.

• Emneområde (Subject Area) — Et hovedforretningskonsept identifisert av CIM-konsortiet, slik som Party. Hvert emneområde inneholder én eller flere enhetsgrupper. Tenk på et emneområde som en avgrenset kontekst (bounded context): det grupperer alt virksomheten trenger å vite om ett bredt tema.
• Enhetsgruppe (Entity Group) — En logisk gruppering av relaterte enheter innenfor et emneområde, slik som Account. Enhetsgrupper holder store emneområder navigerbare og gir teamene en naturlig enhet for tildeling av eierskap.
• Enhet (Entity) — Et unikt objekt som en organisasjon samler informasjon om, slik som en Account Contact. En enhet er analog med en standard databasetabell.
• Attributt (Attribute) — En unik egenskap ved en enhet, slik som Account Id eller Contact Email. Et attributt er analogt med et standard databasefelt i en tabell.

Dette fire-nivå hierarkiet er bevisst kjent. Dataarkitekter som har jobbet med relasjonsmodellering, dimensjonsmodellering eller entitetsrelasjonsdiagrammer vil gjenkjenne mønsteret umiddelbart. Verdien CIM tilfører er ikke en ny modelleringsteknikk, men et delt, forhåndsforhandlet sett med navn og relasjoner som flere organisasjoner og leverandører kan bli enige om.

En nyttig mental modell: et emneområde er grovt sett et skjema eller et domene; en enhetsgruppe er omtrent et navnerom eller en modul; en enhet er en tabell; et attributt er en kolonne. Denne kartleggingen er omtrentlig – CIM er en konseptuell og logisk modell, ikke en fysisk – men den hjelper når du oversetter CIM til en fysisk implementering.

Supertyper og undertyper

Utover de fire kjernekomponentene, tilpasser og utvider CIM-designet enheter til ytterligere grupperinger ved bruk av supertyper og undertyper. Det er her modellen får mye av sin uttrykkskraft.

Relatert: Boomi AtomSphere — Enterprise iPaaS for hybrid sky-til-på-prem-integrasjon.

• Supertype — En enhet som utvides av subtype-enheter, og som definerer felles attributter for lignende konsepter.
• Subtype — En enhet som utvider en annen enhet, og arver attributtene fra sin supertype-enhet.

Det klassiske eksemplet er Party. En part er hvem som helst eller hva som helst virksomheten har å gjøre med. En person og en organisasjon er begge parter, og de deler attributter – et navn, identifikatorer, kontaktpunkter – men hver har attributter den andre ikke har.

Ved å modellere Party som en supertype med Person og Organization som undertyper, unngår man å duplisere de delte attributtene og holder relasjoner (for eksempel “denne muligheten tilhører denne parten”) konsistente uavhengig av hvilken undertype som er involvert.

Arv som dette er et veletablert konsept innen datamodellering og forekommer i standarder som Object Management Groups UML og i entitetsrelasjonskonvensjonene som brukes i bransjen. Når du implementerer CIM fysisk, må du bestemme hvordan arv skal representeres:

Vårt valg: Workato — Automatiseringsledet iPaaS som bedriftsteam faktisk kan bygge på.

• Enkelttabell (Single table) — lagre alle undertyper i én tabell med en diskriminatorkolonne. Enkel å spørre etter, men kan produsere mange nullbare kolonner.
• Klassetabellarv (Class table inheritance) — én tabell for supertypen og én per undertype, koblet sammen via en delt nøkkel. Normalisert og ren, men krever joins.
• Konkret tabellarv (Concrete table inheritance) — en separat, selvstendig tabell per undertype. Rask for undertypespesifikke spørringer, men dupliserer delte attributter.

Det finnes ikke ett universelt riktig svar. Det riktige valget avhenger av spørringsmønstre, antall undertyper og hvor ofte de delte attributtene leses sammen. Dokumenter beslutningen, fordi den vil påvirke enhver nedstrømsintegrasjon.

CIM-emneområdene

Fagområdene representerer de viktigste forretningskonseptene konsortiet har modellert så langt. Hvert område er publisert med egne diagrammer og formater, og flere har eksplisitte versjonsmarkører (for eksempel v1.0 eller v0.1.1), noe som reflekterer at noen områder er mer modne enn andre.

Setup — Definerer hvem du handler med, for eksempel kunde, leverandør og selger. Det dekker også programvare- og infrastrukturkonseptene en organisasjon opererer: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job og IoT Device.

Data Model — Selve de grunnleggende modelleringskonseptene.

Hire — Aktiviteter knyttet til å sette opp virksomheten din, for eksempel intern forretningsenhet og arbeider. Enhetsgrupper inkluderer Job Application, Employee, Compensation, Training, Location, Work Territory og Work Report.

Biz Process — Konsepter for forretningsprosesser og forretningskontinuitet.

Relatert: Matillion — Push-down ELT bygget for skydatavarehus.

Produce — Håndtering av materiale som du skal kjøpe, flytte og selge, for eksempel produkt og lagerprodukt. Enhetsgrupper inkluderer Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order og Sales Agreement.

Market — Aktiviteter som brukes til å markedsføre produktet ditt, for eksempel markedsføringskampanje og nettbutikk. Enhetsgrupper inkluderer Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy og Web Site.

Sell — Aktiviteter som brukes til å selge produktet ditt, for eksempel opprettelse av tilbud og muligheter. Enhetsgrupper inkluderer Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program og Competitor.

Hvor vi skulle begynne: Fivetran — Den fullt administrerte ELT-rørledningen som bare fortsetter å kjøre.

Service — Aktiviteter for å gi støtte til et produkt som er solgt eller servet, for eksempel en sak eller en undersøkelse. Enhetsgrupper inkluderer AI Assistant, Asset, Asset Subscription, Web Content, Case, Task og Event.

Fulfill — Aktiviteter du utfører for å oppfylle en ordre til en kunde, for eksempel forsendelse og returordre. Enhetsgrupper inkluderer Fulfillment Order, Shipment, Return Order, Work Order, Work Resource og Work Forecast.

Interact — Aktiviteter for å spore engasjement med enten sluttbrukere eller andre systemer. Enhetsgrupper inkluderer Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey og Loyalty.

Finance — Aktiviteter for å spore finansiell informasjon i selskapet, for eksempel betaling, faktura og utgiftsrapport. Enhetsgrupper inkluderer Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar og Tax Policy.

Analyze — Aktiviteter knyttet til å analysere data, for eksempel analyse av mønstre, produktbruk, databevegelse, dataendringer og kundetilfredshet. Enhetsgrupper inkluderer AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty og Journal.

Legg merke til hvordan fagområdene spenner over både operasjonelle hensyn (Sell, Fulfill, Service) og analytiske (Analyze, Finance). Den bredden er poenget: en delt modell er mest verdifull når den kan beskrive samme kunde, produkt eller ordre konsekvent, uavhengig av om dataene ligger i et transaksjonssystem eller et datalager.

Velge mellom CIM og andre standarder

CIM er ikke den eneste delte modellen i virksomheten. Flere etablerte standarder overlapper med deler av dens omfang, og en moden arkitektur bruker ofte mer enn én. Avgjørelsen handler mindre om å velge en vinner, og mer om å matche modellens bredde og styring til problemet ditt.

Standard	Primært fokus	Typisk styrke	Hvor CIM skiller seg ut
CIM	Forretningskonsepter på tvers av domener	Bred, applikasjonsagnostisk dekning av CRM/ERP/markedsføring/service	Designet som en delt paraply på tvers av domener
OMG Common Core Ontologies / UML-baserte modeller	Konseptuell modelleringsnotasjon og øvre ontologier	Rigorøs formell semantikk	CIM er mer direkte forretningsorientert
Bransjespesifikke modeller (f.eks. detaljhandel, helsevesen, finansvertikaler)	Dyp dekning av én sektor	Presisjon innenfor vertikalen	CIM bytter dybde mot bredde
Leverandørdatamodeller (CRM/ERP-plattformer)	Ett produkts objekter	Tett integrasjon med det produktet	CIM er leverandørnøytral av design

En praktisk tommelfingerregel:

• Hvis du trenger et delt vokabular på tvers av mange systemer og leverandører, er en bred modell som CIM et godt valg.
• Hvis du trenger dyp, regulert, bransjespesifikk semantikk, vil en vertikal standard vanligvis være mer presis, og du kan mappe den til CIM i grensesnittene.
• Hvis du integrerer innenfor en enkelt leverandørs økosystem, kan den leverandørens egen modell være tilstrekkelig – men den vil ikke hjelpe deg med å koble til neste leverandør.

Det vanligste mønsteret i den virkelige verden er en hub-and-spoke-tilnærming: CIM (eller en annen kanonisk modell) sitter i midten, og hvert kildesystem mappes til denne. Dette er det samme prinsippet bak kanoniske datamodeller i masterdatastyring og bak ideen om «conformed dimension» som ble popularisert i dimensjonsmodellering av Ralph Kimball.

Praktisk veiledning for å ta i bruk CIM

Å ta i bruk en delt modell er like mye en organisatorisk som en teknisk øvelse. Noen få beslutninger avgjør om innsatsen lønner seg.

Start med et avgrenset omfang. Ikke prøv å mappe hvert system til hvert fagområde samtidig. Velg ett domene med høy verdi – Party og Sell er vanlige utgangspunkt fordi kunde- og mulighetsdata er mye duplisert – og bevis mappingen fra ende til annen.

Bestem utvidelsespolicyen tidlig. CIM er designet for å vokse med konsortiet og bidrag, men organisasjonen din vil uunngåelig trenge attributter som modellen ennå ikke definerer. Etabler en konvensjon for lokale utvidelser (for eksempel et prefiks med navnerom) slik at egendefinerte attributter er tydelig skilt fra standardattributter og kan avstemmes senere.

Behandle versjonshåndtering som en førsteklasses prioritet. Fagområdene har versjonsmarkører som v1.0 og v0.1.1, som signaliserer at modellen utvikler seg. Lås versjonen du bygger mot, spor endringer og planlegg migrering. Dette er den samme disiplinen du ville brukt på enhver avhengighet.

Kartlegg, ikke kopier. CIM er en konseptuell og logisk modell. Motstå fristelsen til å generere fysiske skjemaer direkte fra den uten å vurdere ytelse, indeksering og tilgangsmønstrene til systemene som skal konsumere dataene. Bruk modellen til å samkjøre betydning, og utform deretter fysisk lagring for din arbeidsmengde.

Styr kartleggingen. Kartleggingen mellom et kildesystem og CIM er i seg selv en ressurs. Versjoner den, se gjennom den og tildel eierskap. Verktøy innen dataintegrasjon – ETL- og ELT-plattformer, datakataloger og lineage-verktøy – kan hjelpe deg med å spore hvor hvert attributt kommer fra og hvordan det flyter, noe som er akkurat den typen metadata som Analyze-fagområdet forutser med enheter som Data Lineage.

Engasjer fellesskapet. Fordi CIM er åpen kildekode og konsortiumdrevet, er hullene du finner ofte hull andre også har funnet. Å bidra med en foreslått enhet eller et attributt tilbake til prosjektet er både godt medborgerskap og en måte å redusere den langsiktige vedlikeholdsbyrden på.

Formater, diagrammer og konsum

CIM-designene er tilgjengelige i flere formater for hvert domene, inkludert eksempeldiagrammer. Dette er viktig fordi ulike målgrupper konsumerer en datamodell på forskjellige måter:

• Arkitekter ønsker diagrammer og relasjonsvisninger for å resonnere rundt struktur.
• Ingeniører ønsker maskinlesbare definisjoner de kan mate inn i kodegenerering, skjemavalidering eller kartleggingsverktøy.
• Analytikere og forvaltere ønsker dokumentasjon som forklarer hva hver enhet og hvert attributt betyr i forretningsmessige termer.

Publisering i flere formater er et bevisst designvalg som senker barrieren for adopsjon. Når du evaluerer en delt modell, sjekk at den leveres i formater som verktøykjeden din faktisk kan importere – en modell som bare eksisterer som en PDF er langt mindre nyttig enn en med strukturerte definisjoner.

Vanlige spørsmål

Hva er Cloud Information Model (CIM)?

Cloud Information Model er en åpen, applikasjonsagnostisk datamodell som definerer delte forretningskonsepter – som Party, Account og Sales Order – slik at ulike sky- og lokale systemer kan utveksle data ved hjelp av et felles ordforråd. Den er organisert i fagområder, enhetsgrupper, enheter og attributter, og forvaltes som et åpen kildekode-prosjekt under The Linux Foundation.

Hva er forskjellen mellom en supertype og en undertype i CIM?

En supertype er en enhet som utvides av undertype-enheter og definerer attributtene som er felles for lignende konsepter. En undertype utvider en annen enhet og arver attributtene til sin supertype. For eksempel kan Party fungere som en supertype med Person og Organization som undertyper, slik at delte attributter defineres én gang og spesialiserte attributter ligger i undertypen.

Hvordan forholder CIM seg til et databaseskjema?

CIM er en konseptuell og logisk modell, ikke et fysisk skjema. Enhetene er analoge med databasetabeller og attributtene med felt, noe som gjør oversettelsen intuitiv, men du bør fortsatt designe fysisk lagring – indeksering, partisjonering, denormalisering – rundt dine egne spørringsmønstre i stedet for å kopiere modellen bokstavelig.

Er CIM en erstatning for bransjespesifikke datastandarder?

Nei. CIM er bred og tverrfaglig, mens vertikale standarder er dype og sektorspesifikke. Mange organisasjoner bruker en hub-and-spoke-tilnærming der CIM fungerer som den kanoniske modellen i sentrum, og industristandarder eller leverandørmodeller kartlegges mot denne i ytterkantene.

Hvorfor har CIM-fagområder versjonsnummer?

Versjonsmarkører som v1.0 og v0.1.1 indikerer at modellen utvikler seg og at noen fagområder er mer modne enn andre. Å låse en versjon, spore endringer og planlegge migreringer er den samme disiplinen for avhengighetshåndtering som du ville brukt på et hvilket som helst delt bibliotek eller skjema.

Hvordan håndterer jeg attributter som CIM ikke definerer?

Etabler en dokumentert utvidelseskonvensjon, for eksempel et prefiks med navnerom (namespace), slik at egendefinerte attributter klart kan skilles fra standardattributter. Vurder deretter å bidra med gapet tilbake til prosjektet, siden modellen er utformet for å vokse gjennom bidrag fra konsortiet og fellesskapet.