CIM-model

(CIM) er en åben, applikations-agnostisk datamodel beregnet til at give virksomheder et fælles ordforråd for de enheder, der optræder på tværs af CRM-, ERP-, marketing-, service- og analysesystemer. I stedet for at hver leverandør opfinder sine egne objektnavne og relationer, definerer CIM et fælles sæt af emneområder, entiteter og attributter, som ethvert system kan knytte sig til. Modellen styres som et open source-projekt under The Linux Foundation, som er vært for en bred portefølje af samarbejdsprojekter inden for data og infrastruktur.

Denne artikel forklarer, hvordan CIM er opbygget, hvordan dets komponenter relaterer til hinanden, hvordan supertyper og undertyper fungerer, og hvordan emneområderne er organiseret. Den dækker også de praktiske beslutninger, som en arkitekt står over for, når CIM vedtages — kortlægning, governance, versionering og udvidelse — og hvor modellen passer ind i forhold til andre industristandarder.

Key Takeaways

• CIM organiserer forretningskoncepter i Subject Areas, der hver indeholder Entity Groups, Entities og Attributes — et hierarki, der kortlægges rent til skemaer, tabeller og kolonner.
• Supertyper og undertyper lader modellen udtrykke fælles karakteristika (en Party, der er en person eller en organisation), mens den stadig tillader specialisering.
• Modellen er bevidst applikations-agnostisk: den beskriver forretningskoncepter, ikke en enkelt leverandørs implementering.
• CIM udgives i flere formater med eksempeldiagrammer, så det kan forbruges af både modelleringsværktøjer, kodegeneratorer og dokumentation.
• Antallet og omfanget af emneområder vokser med konsortiets og communityets bidrag, så vedtagelse bør tage højde for versionering og change management.
• CIM er én mulighed blandt flere; det rigtige valg afhænger af, om du har brug for en bred model på tværs af domæner eller en smal, dyb standard for én branche.

Hvordan CIM er opbygget

CIM er organiseret i komponenter, så indholdet lettere kan navigeres og forbruges. Hvert niveau i hierarkiet besvarer et andet spørgsmål, og forståelsen af dette hierarki er det første skridt til at bruge modellen korrekt.

• Subject Area (Emneområde) — Et hovedforretningskoncept identificeret af CIM-konsortiet, såsom Party. Hvert emneområde indeholder en eller flere enhedsgrupper. Tænk på et emneområde som en bounded context: det grupperer alt, hvad virksomheden har brug for at vide om ét bredt tema.
• Entity Group (Enhedsgruppe) — En logisk gruppering af relaterede enheder inden for et emneområde, såsom Account. Enhedsgrupper holder store emneområder navigerbare og giver teams en naturlig enhed til tildeling af ejerskab.
• Entity (Enhed) — Et unikt objekt, som en organisation indsamler oplysninger om, såsom en Account Contact. En enhed er analog med en standard databasetabel.
• Attribute (Attribut) — En unik egenskab ved en enhed, såsom Account Id eller Contact Email. En attribut er analog med et standard databasefelt i en tabel.

Dette fire-niveau hierarki er bevidst velkendt. Dataarkitekter, der har arbejdet med relationel modellering, dimensionsmodellering eller entitets-relationsdiagrammer, vil genkende mønsteret med det samme. Den værdi, CIM tilføjer, er ikke en ny modelleringsteknik, men et delt, forudforhandlet sæt af navne og relationer, som flere organisationer og leverandører kan blive enige om.

En nyttig mental model: et emneområde er groft sagt et skema eller et domæne; en enhedsgruppe er groft sagt et navnerum eller modul; en enhed er en tabel; en attribut er en kolonne. Denne kortlægning er omtrentlig — CIM er en konceptuel og logisk model, ikke en fysisk — men det hjælper, når du oversætter CIM til en fysisk implementering.

Supertyper og undertyper

Ud over de fire kernekomponenter tilpasser og udvider CIM-designet enheder til yderligere grupperinger ved hjælp af supertyper og undertyper. Det er her, modellen får meget af sin udtrykskraft.

Relateret: Fivetran — Den fuldt administrerede ELT-pipeline, der bare bliver ved med at køre.

• Supertype — En enhed, der udvides af undertype-enheder, og som definerer fælles attributter for lignende begreber.
• Undertype — En enhed, der udvider en anden enhed og arver attributterne fra sin supertype-enhed.

Det klassiske eksempel er Party. En party er enhver eller alt, som virksomheden handler med. En person og en organisation er begge parties, og de deler attributter — et navn, identifikatorer, kontaktpunkter — men hver har attributter, som den anden ikke har.

Ved at modellere Party som en supertype med Person og Organization som undertyper undgås duplikering af de delte attributter, og relationer (f.eks. “denne mulighed tilhører denne party”) holdes konsekvente uanset hvilken undertype, der er involveret.

Nedarvning som denne er et veletableret koncept inden for datamodellering og optræder i standarder som Object Management Groups UML og i entity-relationship-konventioner, der anvendes på tværs af industrien. Når du implementerer CIM fysisk, skal du beslutte, hvordan du vil repræsentere nedarvning:

Hvis du handler: Boomi AtomSphere — Enterprise iPaaS til hybrid cloud-to-on-prem integration.

• Single table — gem alle undertyper i én tabel med en diskriminatorkolonne. Enkel at forespørge på, men kan producere mange nullable kolonner.
• Class table inheritance — én tabel for supertypen og én pr. undertype, sammenføjet på en delt nøgle. Normaliseret og ren, men kræver joins.
• Concrete table inheritance — en separat, selvstændig tabel pr. undertype. Hurtig til undertypespecifikke forespørgsler, men duplerer delte attributter.

Der findes ikke ét universelt korrekt svar. Det rigtige valg afhænger af forespørgselsmønstre, antallet af undertyper og hvor ofte de delte attributter læses sammen. Dokumentér beslutningen, da den vil påvirke enhver downstream-integration.

CIM-emneområderne

Fagområderne repræsenterer de vigtigste forretningskoncepter, som konsortiet hidtil har modelleret. Hvert område udgives med sine egne diagrammer og formater, og flere bærer eksplicitte versionsmarkører (for eksempel v1.0 eller v0.1.1), hvilket afspejler, at nogle områder er mere modne end andre.

Setup — Definerer, hvem du handler med, for eksempel kunde, leverandør og sælger. Det dækker også de software- og infrastrukturkoncepter, som en organisation driver: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job og IoT Device.

Data Model — Selve de grundlæggende modelleringskoncepter.

Hire — Aktiviteter relateret til oprettelse af din virksomhed, for eksempel intern forretningsenhed og medarbejder. Enhedsgrupper omfatter Job Application, Employee, Compensation, Training, Location, Work Territory og Work Report.

Biz Process — Koncepter for forretningsprocesser og forretningskontinuitet.

Relateret: Matillion — Push-down ELT bygget til cloud-datavarehuse.

Produce — Håndtering af materiale, som du vil købe, flytte og sælge, for eksempel produkt og lagerprodukt. Enhedsgrupper omfatter Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order og Sales Agreement.

Market — Aktiviteter, der bruges til at promovere dit produkt, for eksempel marketingkampagne og webshop. Enhedsgrupper omfatter Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy og Web Site.

Sell — Aktiviteter, der bruges til at sælge dit produkt, for eksempel oprettelse af tilbud og muligheder. Enhedsgrupper inkluderer Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program og Competitor.

Læsernes favorit: Airbyte — Open source ELT med en administreret cloud-mulighed.

Service — Aktiviteter for at yde support til et produkt, der er solgt eller serviceres, for eksempel en sag eller en undersøgelse. Enhedsgrupper omfatter AI Assistant, Asset, Asset Subscription, Web Content, Case, Task og Event.

Fulfill — Aktiviteter, du udfører for at opfylde en ordre til en kunde, for eksempel forsendelse og returordre. Enhedsgrupper inkluderer Fulfillment Order, Shipment, Return Order, Work Order, Work Resource og Work Forecast.

Interact — Aktiviteter til at spore interaktion med enten slutbrugere eller andre systemer. Enhedsgrupper omfatter Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey og Loyalty.

Finance — Aktiviteter til at spore økonomiske oplysninger i virksomheden, for eksempel betaling, faktura og udgiftsrapport. Enhedsgrupper inkluderer Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar og Tax Policy.

Analyze — Aktiviteter relateret til analyse af data, for eksempel analyse af mønstre, produktbrug, databevægelse, dataændringer og kundetilfredshed. Enhedsgrupper inkluderer AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty og Journal.

Læg mærke til, hvordan fagområderne spænder over både operationelle anliggender (Sell, Fulfill, Service) og analytiske (Analyze, Finance). Den bredde er pointen: En delt model er mest værdifuld, når den kan beskrive den samme kunde, produkt eller ordre konsekvent, uanset om dataene lever i et transaktionssystem eller et datalager.

Valg mellem CIM og andre standarder

CIM er ikke den eneste delte model i virksomheden. Flere etablerede standarder overlapper med dele af dens omfang, og en moden arkitektur bruger ofte mere end én. Beslutningen handler mindre om at vælge en vinder og mere om at matche modellens bredde og styring til dit problem.

Standard	Primært fokus	Typisk styrke	Hvor CIM adskiller sig
CIM	Forretningskoncepter på tværs af domæner	Bred, applikations-agnostisk dækning af CRM/ERP/marketing/service	Designet som en delt paraply på tværs af domæner
OMG Common Core Ontologies / UML-baserede modeller	Konceptuel modelleringsnotation og øvre ontologier	Rigorøs formel semantik	CIM er mere direkte forretningsorienteret
Branchespecifikke modeller (f.eks. detailhandel, sundhedsvæsen, finansielle vertikaler)	Dyb dækning af én sektor	Præcision inden for vertikalen	CIM bytter dybde for bredde
Leverandørdatamodeller (CRM/ERP-platforme)	Et produkts objekter	Tæt integration med det produkt	CIM er leverandørneutral af design

En praktisk tommelfingerregel:

• Hvis du har brug for et delt ordforråd på tværs af mange systemer og leverandører, er en bred model som CIM et stærkt valg.
• Hvis du har brug for dyb, reguleret, branchespecifik semantik, vil en vertikal standard normalt være mere præcis, og du kan mappe den til CIM ved grænserne.
• Hvis du integrerer inden for en enkelt leverandørs økosystem, kan denne leverandørs egen model være tilstrækkelig – men det vil ikke hjælpe dig med at forbinde til den næste leverandør.

Det mest almindelige mønster i den virkelige verden er en hub-and-spoke-tilgang: CIM (eller en anden kanonisk model) sidder i midten, og hvert kildesystem mappes til den. Dette er det samme princip bag kanoniske datamodeller i master data management og bag idéen om “conformed dimension”, som blev populariseret i dimensionel modellering af Ralph Kimball.

Praktisk vejledning til implementering af CIM

At implementere en delt model er lige så meget en organisatorisk øvelse, som det er en teknisk. Nogle få beslutninger afgør, om indsatsen betaler sig.

Start med et afgrænset omfang. Forsøg ikke at mappe hvert system til hvert fagområde på én gang. Vælg ét domæne med høj værdi – Party og Sell er almindelige udgangspunkter, fordi kunde- og mulighedsdata er bredt duplikeret – og bevis mappingen fra ende til anden.

Beslut din udvidelsespolitik tidligt. CIM er designet til at vokse med konsortiet og bidragene, men din organisation vil uundgåeligt få brug for attributter, som modellen endnu ikke definerer. Etabler en konvention for lokale udvidelser (for eksempel et namespaced præfiks), så brugerdefinerede attributter tydeligt kan skelnes fra standardattributter og kan afstemmes senere.

Behandl versionering som en førsteklasses prioritet. Fagområderne bærer versionsmarkører såsom v1.0 og v0.1.1, hvilket signalerer, at modellen udvikler sig. Fastlås den version, du bygger imod, spor ændringer og planlæg migrering. Dette er den samme disciplin, som du ville anvende på enhver afhængighed.

Kortlæg, kopier ikke. CIM er en konceptuel og logisk model. Modstå fristelsen til at generere fysiske skemaer direkte fra den uden at overveje ydeevne, indeksering og adgangsmønstrene for de systemer, der skal forbruge dataene. Brug modellen til at afstemme betydning, og design derefter den fysiske lagring til din arbejdsbyrde.

Styr kortlægningen. Kortlægningen mellem et kildesystem og CIM er i sig selv et aktiv. Versionér den, gennemgå den og tildel ejerskab. Værktøjer inden for dataintegration — ETL- og ELT-platforme, datakataloger og lineage-værktøjer — kan hjælpe dig med at spore, hvor hver attribut stammer fra, og hvordan den flyder, hvilket er præcis den slags metadata, som Analyze-fagområdet forventer med entiteter som Data Lineage.

Engager fællesskabet. Fordi CIM er open source og konsortiumdrevet, er huller, du finder, ofte huller, som andre også har fundet. At bidrage med en foreslået entitet eller attribut tilbage til projektet er både godt medborgerskab og en måde at reducere din langsigtede vedligeholdelsesbyrde på.

Formater, diagrammer og forbrug

CIM-designene er tilgængelige i flere formater for hvert domæne, inklusive eksempeldiagrammer. Dette er vigtigt, fordi forskellige målgrupper forbruger en datamodel forskelligt:

• Arkitekter ønsker diagrammer og relationsvisninger for at kunne ræsonnere om struktur.
• Ingeniører ønsker maskinlæsbare definitioner, som de kan føde ind i kodegenerering, skemavalidering eller kortlægningsværktøjer.
• Analytikere og stewards ønsker dokumentation, der forklarer, hvad hver entitet og attribut betyder i forretningsmæssige termer.

Udgivelse i flere formater er et bevidst designvalg, der sænker barrieren for adoption. Når du evaluerer en delt model, skal du kontrollere, at den leveres i formater, som din værktøjskæde faktisk kan indlæse — en model, der kun eksisterer som en PDF, er langt mindre nyttig end en med strukturerede definitioner.

Ofte stillede spørgsmål

Hvad er Cloud Information Model (CIM)?

Cloud Information Model er en åben, applikations-agnostisk datamodel, der definerer delte forretningskoncepter — såsom Party, Account og Sales Order — så forskellige cloud- og on-premises-systemer kan udveksle data ved hjælp af et fælles ordforråd. Den er organiseret i fagområder, entitetsgrupper, entiteter og attributter og styres som et open source-projekt under The Linux Foundation.

Hvad er forskellen mellem en supertype og en subtype i CIM?

En supertype er en entitet, der udvides af subtype-entiteter, og som definerer de attributter, der er fælles for lignende koncepter. En subtype udvider en anden entitet og arver attributterne fra sin supertype. For eksempel kan Party fungere som en supertype med Person og Organization som subtypes, så delte attributter defineres én gang, og specialiserede attributter findes i subtypen.

Hvordan forholder CIM sig til et databaseskema?

CIM er en konceptuel og logisk model, ikke et fysisk skema. Dens entiteter er analoge med databasetabeller og dens attributter med felter, hvilket gør oversættelsen intuitiv, men du bør stadig designe den fysiske lagring — indeksering, partitionering, denormalisering — omkring dine egne forespørgselsmønstre frem for at kopiere modellen bogstaveligt.

Er CIM en erstatning for branchespecifikke datastandarder?

Nej. CIM er bred og på tværs af domæner, mens vertikale standarder er dybe og sektorspecifikke. Mange organisationer bruger en hub-and-spoke-tilgang, hvor CIM fungerer som den kanoniske model i centrum, og industristandarder eller leverandørmodeller kortlægges til den i kanterne.

Hvorfor har CIM-fagområder versionsnumre?

Versionsmarkører som v1.0 og v0.1.1 indikerer, at modellen udvikler sig, og at nogle fagområder er mere modne end andre. At fastlåse en version, spore ændringer og planlægge migreringer er den samme disciplin for afhængighedsstyring, som du ville anvende på ethvert delt bibliotek eller skema.

Hvordan håndterer jeg attributter, som CIM ikke definerer?

Etabler en dokumenteret udvidelseskonvention, såsom et namespaced præfiks, så brugerdefinerede attributter tydeligt kan skelnes fra standardattributter. Overvej derefter at bidrage med hullet tilbage til projektet, da modellen er designet til at vokse gennem bidrag fra konsortiet og fællesskabet.