CIM-modell

(CIM) är en öppen, applikationsagnostisk datamodell avsedd att ge företag ett delat ordförråd för de entiteter som förekommer i CRM-, ERP-, marknadsförings-, service- och analyssystem. I stället för att varje leverantör uppfinner sina egna objektnamn och relationer, definierar CIM en gemensam uppsättning ämnesområden, entiteter och attribut som alla system kan mappa till. Modellen förvaltas som ett projekt med öppen källkod under The Linux Foundation, som är värd för en bred portfölj av samarbetsbaserade data- och infrastrukturprojekt.

Den här artikeln förklarar hur CIM är uppbyggd, hur dess komponenter relaterar till varandra, hur supertyper och undertyper fungerar och hur ämnesområdena är organiserade. Den täcker också de praktiska beslut som en arkitekt står inför när CIM införs – mappning, styrning, versionshantering och utökning – och var modellen passar i förhållande till andra industristandarder.

Viktiga slutsatser

• CIM organiserar affärskoncept i ämnesområden, som var och en innehåller entitetsgrupper, entiteter och attribut — en hierarki som mappar rent mot scheman, tabeller och kolumner.
• Supertyper och undertyper låter modellen uttrycka gemensamma egenskaper (en part som är en person eller en organisation) samtidigt som den tillåter specialisering.
• Modellen är medvetet applikationsagnostisk: den beskriver affärskoncept, inte någon enskild leverantörs implementering.
• CIM publiceras i flera format med exempeldiagram, så att den kan konsumeras av modelleringsverktyg, kodgeneratorer och dokumentation.
• Antalet och omfattningen av ämnesområden växer med konsortiets och communityns bidrag, så införandet bör ta hänsyn till versionshantering och ändringshantering.
• CIM är ett alternativ bland flera; det rätta valet beror på om du behöver en bred domänöverskridande modell eller en smal, djup standard för en specifik bransch.

Hur CIM är uppbyggd

CIM är organiserad i komponenter så att innehållet lättare kan navigeras och konsumeras. Varje nivå i hierarkin svarar på en olika fråga, och att förstå denna hierarki är det första steget för att använda modellen på ett effektivt sätt.

• Ämnesområde (Subject Area) — Ett övergripande affärskoncept identifierat av CIM-konsortiet, såsom Party. Varje ämnesområde innehåller en eller flera entitetsgrupper. Tänk på ett ämnesområde som ett avgränsat sammanhang (bounded context): det grupperar allt företaget behöver veta om ett brett tema.
• Entitetsgrupp (Entity Group) — En logisk gruppering av relaterade entiteter inom ett ämnesområde, till exempel Account. Entitetsgrupper håller stora ämnesområden navigerbara och ger team en naturlig enhet för att tilldela ägarskap.
• Entitet (Entity) — Ett unikt objekt som en organisation samlar in information om, till exempel en Account Contact. En entitet är analog med en standarddatabastabell.
• Attribut (Attribute) — En unik egenskap hos en entitet, till exempel Account Id eller Contact Email. Ett attribut är analogt med ett standarddatabasfält i en tabell.

Denna fyrnivåhierarki är avsiktligt bekant. Dataarkitekter som har arbetat med relationsmodellering, dimensionsmodellering eller entitetsrelationsdiagram kommer att känna igen mönstret omedelbart. Värdet som CIM tillför är inte en ny modelleringsteknik utan en delad, förförhandlad uppsättning namn och relationer som flera organisationer och leverantörer kan enas om.

En användbar mental modell: ett ämnesområde är ungefär ett schema eller en domän; en entitetsgrupp är ungefär en namnrymd eller modul; en entitet är en tabell; ett attribut är en kolumn. Denna mappning är ungefärlig — CIM är en konceptuell och logisk modell, inte en fysisk — men den hjälper när du översätter CIM till en fysisk implementering.

Supertyper och undertyper

Utöver de fyra kärnkomponenterna anpassar och utökar CIM-designen entiteter till ytterligare grupperingar med hjälp av supertyper och undertyper. Det är här modellen får mycket av sin uttryckskraft.

Relaterat: Boomi AtomSphere — Enterprise iPaaS för hybrid moln-till-på-prem-integration.

• Supertyp — En entitet som utökas av subtyp-entiteter och definierar gemensamma attribut för liknande koncept.
• Undertyp (Subtype) — En entitet som utökar en annan entitet och ärver attributen från sin supertyp-entitet.

Det klassiska exemplet är Party. En part är vem som helst eller vad som helst som verksamheten interagerar med. En person och en organisation är båda parter och de delar attribut — namn, identifierare, kontaktpunkter — men var och en har attribut som den andra inte har.

Genom att modellera Party som en supertyp med Person och Organisation som undertyper undviker man att duplicera de delade attributen och håller relationerna (till exempel “den här möjligheten tillhör denna part”) konsekventa oavsett vilken undertyp som är involverad.

Arv som detta är ett väletablerat koncept inom datamodellering och förekommer i standarder som Object Management Groups UML och i de entitetsrelationskonventioner som används inom branschen. När du implementerar CIM fysiskt måste du bestämma hur du ska representera arv:

Vårt val: Workato — Automationsledd iPaaS som affärsteam faktiskt kan bygga på.

• Enkel tabell (Single table) — lagra alla undertyper i en tabell med en diskriminatorkolumn. Enkel att fråga, men kan resultera i många nullbara kolumner.
• Klasstabellsarv (Class table inheritance) — en tabell för supertypen och en per undertyp, sammanfogade via en delad nyckel. Normaliserad och ren, men kräver joins.
• Konkret tabellsarv (Concrete table inheritance) — en separat, fristående tabell per undertyp. Snabb för subtypsspecifika frågor, men duplicerar delade attribut.

Det finns inget universellt korrekt svar. Rätt val beror på frågemönster, antalet undertyper och hur ofta de delade attributen läses tillsammans. Dokumentera beslutet, eftersom det kommer att påverka varje nedströms integration.

CIM-ämnesområdena

Ämnesområdena representerar de stora affärskoncept som konsortiet har modellerat hittills. Var och en publiceras med egna diagram och format, och flera har explicita versionsmarkörer (till exempel v1.0 eller v0.1.1), vilket återspeglar att vissa områden är mer mogna än andra.

Setup — Definierar vem du har att göra med, till exempel kund, leverantör och säljare. Den täcker också mjukvaru- och infrastrukturkoncepten som en organisation driver: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job och IoT Device.

Data Model — Själva de grundläggande modelleringskoncepten.

Hire — Aktiviteter relaterade till att sätta upp din verksamhet, till exempel intern affärsenhet och arbetare. Entitetsgrupper inkluderar Job Application, Employee, Compensation, Training, Location, Work Territory och Work Report.

Biz Process — Affärsprocess- och affärskontinuitetskoncept.

Relaterat: Matillion — Push-down ELT byggd för molndatalager.

Produce — Hantering av material som du ska köpa, flytta och sälja, till exempel produkt och lagerprodukt. Entitetsgrupper inkluderar Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order och Sales Agreement.

Market — Aktiviteter som används för att marknadsföra din produkt, till exempel marknadsföringskampanj och webbshop. Entitetsgrupper inkluderar Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy och Web Site.

Sell — Aktiviteter som används för att sälja din produkt, till exempel skapande av offerter och möjligheter. Entitetsgrupper inkluderar Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program och Competitor.

Var skulle vi börja: Fivetran — Den fullt hanterade ELT-pipelinen som bara fortsätter att köras.

Service — Aktiviteter för att ge support för en produkt som säljs eller servas, till exempel ett ärende eller en undersökning. Entitetsgrupper inkluderar AI Assistant, Asset, Asset Subscription, Web Content, Case, Task och Event.

Fulfill — Aktiviteter du utför för att fullgöra en order till en kund, till exempel leverans och returorder. Entitetsgrupper inkluderar Fulfillment Order, Shipment, Return Order, Work Order, Work Resource och Work Forecast.

Interact — Aktiviteter för att spåra interaktion med antingen slutanvändare eller andra system. Entitetsgrupper inkluderar Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey och Loyalty.

Finance — Aktiviteter för att spåra finansiell information i företaget, till exempel betalning, faktura och utgiftsrapport. Entitetsgrupper inkluderar Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar och Tax Policy.

Analyze — Aktiviteter relaterade till att analysera data, till exempel analysera mönster, produktanvändning, dataförflyttning, dataförändringar och kundnöjdhet. Entitetsgrupper inkluderar AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty och Journal.

Lägg märke till hur ämnesområdena sträcker sig över både operativa frågor (Sell, Fulfill, Service) och analytiska (Analyze, Finance). Den bredden är poängen: en delad modell är mest värdefull när den kan beskriva samma kund, produkt eller order konsekvent oavsett om data finns i ett transaktionssystem eller ett datalager.

Att välja mellan CIM och andra standarder

CIM är inte den enda delade modellen i företaget. Flera etablerade standarder överlappar delar av dess omfattning, och en mogen arkitektur använder ofta mer än en. Beslutet handlar mindre om att välja en vinnare och mer om att matcha modellens bredd och styrning till ditt problem.

Standard	Primärt fokus	Typisk styrka	Där CIM skiljer sig
CIM	Affärskoncept över flera domäner	Bred, applikations-agnostisk täckning av CRM/ERP/marknadsföring/service	Designad som ett delat paraply över domäner
OMG Common Core Ontologies / UML-baserade modeller	Notation för konceptuell modellering och övre ontologier	Rigorös formell semantik	CIM är mer direkt affärsinriktat
Branschspecifika modeller (t.ex. detaljhandel, hälsovård, finansvertikaler)	Djup täckning av en sektor	Precision inom vertikalen	CIM byter djup mot bredd
Leverantörsdatamodeller (CRM/ERP-plattformar)	En produkts objekt	Tät integration med den produkten	CIM är leverantörsneutralt genom design

En praktisk tumregel:

• Om du behöver ett delat ordförråd för många system och leverantörer, passar en bred modell som CIM väl.
• Om du behöver djup, reglerad, branschspecifik semantik, kommer en vertikal standard vanligtvis att vara mer exakt, och du kan mappa den till CIM vid gränserna.
• Om du integrerar inom en enskild leverantörs ekosystem, kan den leverantörens egen modell vara tillräcklig — men det hjälper dig inte att ansluta till nästa leverantör.

Det vanligaste mönstret i den verkliga världen är ett hub-and-spoke-tillvägagångssätt: CIM (eller en annan kanonisk modell) sitter i mitten och varje källsystem mappas till den. Detta är samma princip bakom kanoniska datamodeller i masterdatahantering och bakom idén om “conformed dimension” som populariserats inom dimensionsmodellering av Ralph Kimball.

Praktisk vägledning för att anta CIM

Att anta en gemensam modell är lika mycket en organisatorisk som en teknisk övning. Ett fåtal beslut avgör om insatsen lönar sig.

Börja med ett begränsat omfång. Försök inte att mappa alla system till varje ämnesområde samtidigt. Välj en domän med högt värde – Party och Sell är vanliga utgångspunkter eftersom kund- och möjlighetsdata ofta är duplicerade – och bevisa mappningen från början till slut.

Besluta om din policy för utökningar tidigt. CIM är utformad för att växa med konsortiet och bidragen, men din organisation kommer oundvikligen att behöva attribut som modellen ännu inte definierar. Upprätta en konvention för lokala utökningar (till exempel ett namnsutrymme-prefix) så att anpassade attribut tydligt kan skiljas från standardattribut och kan stämmas av senare.

Behandla versionshantering som en förstklassig prioritet. Ämnesområdena bär versionsmarkörer som v1.0 och v0.1.1, vilket signalerar att modellen utvecklas. Lås versionen du bygger mot, spåra ändringar och planera för migrering. Detta är samma disciplin som du skulle tillämpa på vilket beroende som helst.

Mappa, kopiera inte. CIM är en konceptuell och logisk modell. Motstå frestelsen att generera fysiska scheman direkt från den utan att ta hänsyn till prestanda, indexering och åtkomstmönstren för de system som kommer att konsumera data. Använd modellen för att samordna betydelsen, och designa sedan den fysiska lagringen för din arbetsbelastning.

Styr mappningen. Mappningen mellan ett källsystem och CIM är i sig en tillgång. Versionshantera den, granska den och tilldela ägandeskap. Verktyg inom dataintegration – ETL- och ELT-plattformar, datakataloger och lineage-verktyg – kan hjälpa dig att spåra var varje attribut kommer ifrån och hur det flödar, vilket är exakt den typ av metadata som ämnesområdet Analyze förutser med entiteter som Data Lineage.

Engagera communityn. Eftersom CIM är öppen källkod och konsortiedriven är luckor du hittar ofta luckor som andra också har hittat. Att bidra med en föreslagen entitet eller ett attribut tillbaka till projektet är både gott medborgarskap och ett sätt att minska din långsiktiga underhållsbörda.

Format, diagram och konsumtion

CIM-designerna är tillgängliga i flera format för varje domän, inklusive exempeldiagram. Detta är viktigt eftersom olika målgrupper konsumerar en datamodell på olika sätt:

• Arkitekter vill ha diagram och relationsvyer för att resonera kring struktur.
• Ingenjörer vill ha maskinläsbara definitioner som de kan mata in i kodgenerering, schemavalidering eller mappningsverktyg.
• Analytiker och data stewards vill ha dokumentation som förklarar vad varje entitet och attribut betyder i affärstermer.

Publicering i flera format är ett medvetet designval som sänker barriären för adoption. När du utvärderar en delad modell, kontrollera att den levereras i format som din verktygskedja faktiskt kan ta emot – en modell som bara existerar som en PDF är mycket mindre användbar än en med strukturerade definitioner.

Vanliga frågor

Vad är Cloud Information Model (CIM)?

Cloud Information Model är en öppen, applikationsagnostisk datamodell som definierar delade affärskoncept – såsom Party, Account och Sales Order – så att olika molnsystem och lokala system kan utbyta data med ett gemensamt ordförråd. Den är organiserad i ämnesområden, entitetsgrupper, entiteter och attribut, och förvaltas som ett öppen källkodsprojekt under The Linux Foundation.

Vad är skillnaden mellan en supertyp och en undertyp i CIM?

En supertyp är en entitet som utökas av undertypsentiteter och definierar de attribut som är gemensamma för liknande koncept. En undertyp utökar en annan entitet och ärver attributen från sin supertyp. Till exempel kan Party fungera som en supertyp med Person och Organization som undertyper, så att delade attribut definieras en gång och specialiserade attribut finns i undertypen.

Hur relaterar CIM till ett databasschema?

CIM är en konceptuell och logisk modell, inte ett fysiskt schema. Dess entiteter är analoga med databastabeller och dess attribut med fält, vilket gör översättningen intuitiv, men du bör fortfarande designa den fysiska lagringen – indexering, partitionering, denormalisering – utifrån dina egna frågemönster snarare än att kopiera modellen bokstavligen.

Är CIM en ersättning för branschspecifika datastandarder?

Nej. CIM är bred och domänöverskridande, medan vertikala standarder är djupa och sektorspecifika. Många organisationer använder ett hub-and-spoke-tillvägagångssätt där CIM fungerar som den kanoniska modellen i centrum och branschstandarder eller leverantörsmodeller mappas till den vid kanterna.

Varför har CIM-ämnesområden versionsnummer?

Versionsmarkörer som v1.0 och v0.1.1 indikerar att modellen utvecklas och att vissa ämnesområden är mer mogna än andra. Att låsa en version, spåra ändringar och planera migreringar är samma disciplin för beroendehantering som du skulle tillämpa på vilket delat bibliotek eller schema som helst.

Hur hanterar jag attribut som CIM inte definierar?

Upprätta en dokumenterad konvention för utökningar, till exempel ett prefix med namnrymd (namespace), så att anpassade attribut tydligt kan skiljas från standardattribut. Överväg sedan att bidra med luckan tillbaka till projektet, eftersom modellen är utformad för att växa genom bidrag från konsortiet och communityn.