Skyinformasjonsmodell

(CIM) er et åpent, applikasjonsagnostisk skjema for å beskrive enhetene som beveger seg gjennom en moderne virksomhet: parter, produkter, ordrer, betalinger og relasjonene som knytter dem sammen. I stedet for å finne opp en skreddersydd datamodell for hver integrasjon, tilbyr CIM et delt vokabular slik at en CRM, en ERP, en handelsplattform og et analyselager kan bli enige om hva en “Sales Order” eller en “Product Relationship Type” faktisk betyr. Denne artikkelen går gjennom enhetsgruppene som utgjør modellen, og borer deretter inn i én representativ enhet – ProductRelationshipType – for å vise hvordan CIM uttrykker relasjoner, roller og nøkler i praksis.

Viktige takeaways

• CIM organiserer virksomhetsdata i enhetsgrupper (Party, Product, Sales Order, Payment og andre) som kan tas i bruk trinnvis i stedet for alle på en gang.
• Hver enhet er definert med en Term URI, en beskrivelse, skalare egenskaper og lenkeegenskaper – en struktur som mapper rent til JSON-LD, RDF og property-graph-lagre.
• Relasjonsenheter som ProductRelationshipType koder for roller (forelder/barn) slik at pakker, alternativer og dekninger kan modelleres uten hardkodet forretningslogikk.
• Modellen er bevisst applikasjonsagnostisk: den beskriver hva data betyr, ikke hvordan en bestemt leverandør lagrer dem.
• Å ta i bruk CIM er en kartleggingsøvelse, ikke en “rip-and-replace” – du samkjører eksisterende systemer med delte termer og utbedrer gapene.

Hvorfor en delt modell er viktig

Virksomhetsintegrasjon har en kjent feilmodus: hvert system snakker sin egen dialekt. Salesforce kaller det en Account, SAP kaller det en Business Partner, og en hjemmelaget faktureringstjeneste kaller det en Customer. Når du bygger punkt-til-punkt-mappinger mellom hvert par, vokser antallet oversettelser med kvadratet av systemene som er involvert, og hvert nytt system multipliserer vedlikeholdsbyrden.

En kanonisk modell bryter dette kvadratiske problemet. Du mapper hvert system én gang til den delte modellen, og den delte modellen blir navet. Dette er det samme arkitektoniske instinktet bak standarder som OAGIS (Open Applications Group Integration Specification), OMGs Common Warehouse Metamodel og schema.orgs vokabular for handel. CIM bygger på denne tradisjonen, men er spisset for interoperabilitet i skyæraen og publisert som åpne termer med derefererbare URI-er.

Den praktiske gevinsten er at en dataarkitekt kan svare på spørsmål som “hvilke systemer har den autoritative posten for en Party?” eller “hvordan representerer vi en produktpakke konsekvent på tvers av katalogen og ordren?” ved å bruke ett enkelt referansepunkt.

Enhetsgruppene på et øyeblikk

CIM er ikke et enkelt monolittisk skjema; det er et sett med løst koblede grupper. Gruppene som er navngitt i modellen inkluderer:

• Account — den kommersielle relasjonskonteksten for en part.
• Contact Point — telefonnumre, e-postadresser og lignende kontaktkanaler.
• Lead — en potensiell part som ennå ikke er kvalifisert.
• Party og Party Role — det generelle konseptet om en aktør og rollene den spiller (kunde, leverandør, ansatt).
• Payment og Payment Method — hvordan penger flyttes og instrumentene som brukes.
• Product Attribute, Product Catalog og Product — de salgbare og beskrivbare varene og tjenestene.
• Sales Order og dens store familie av underenheter — det transaksjonelle hjertet av modellen.
• Shipment — oppfyllelse og logistikk.

Sales Order-gruppen er den desidert mest detaljerte, og det er verdt å forstå hvorfor. En ordre er der forretningsreglene konsentreres: priser, skatter, justeringer, leveringsgrupperinger og notater per linje er alle knyttet til den.

Relatert: Fivetran — Den fullt administrerte ELT-rørledningen som bare fortsetter å kjøre.

CIM dekomponerer ordren i mange små enheter – Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log og flere – i stedet for én bred tabell. Denne dekomponeringen er et bevisst designvalg: det lar hvert anliggende utvikle seg uavhengig og lar systemer abonnere kun på de delene de bryr seg om.

Anatomi til en CIM-enhet

Hver enhet i CIM følger samme form, noe som gjør modellen forutsigbar å konsumere programmatisk. Tenk på ProductRelationshipType, enheten som beskriver hvorfor to produkter er relatert.

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Dette er den globalt unike identifikatoren for konseptet. Fordi det er en URI, kan den derefereres og brukes direkte i RDF/JSON-LD-grafer.
• Beskrivelse — “Reasons why products are related such as bundle, option or covering.” Dette forteller deg at enheten er en type eller klassifisering, ikke selve relasjonsinstansen.
• Skalare egenskaper — de primitive feltene som bærer data.
• Lenkeegenskaper — referanser til andre enheter. ProductRelationshipType har ingen, noe som i seg selv er informativt: det er en bladenhet, et kontrollert vokabular snarere enn et nav.

De skalare egenskapene er:

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

Property	Term URI	Range	Mandatory	Description
id	.../model/id	guid	yes	Primary key
parentProductRole	.../model/parentProductRole	string	yes	The first role in the relationship, e.g. “Consists of”
childProductRole	.../model/childProductRole	string	yes	The second role in the relationship, e.g. “Component of”

At id er en GUID er en meningsfull konvensjon: det betyr at identifikatorer er globalt unike uten koordinering mellom systemer, noe som er akkurat det man ønsker når poster opprettes i forskjellige skyer og senere slås sammen.

Modellering av relasjoner med roller

Den mest lærerike delen av ProductRelationshipType er paret med rolleegenskaper. En produktrelasjon er retningsbestemt, og CIM fanger opp denne retningen med to navngitte roller i stedet for en enkelt ugjennomsiktig “type”-streng.

Tenk på en pakke. Et “Starter Kit” består av en “Router” og en “Cable”. I CIM-termer:

• Foreldreproduktet spiller rollen som er beskrevet av parentProductRole — for eksempel “Består av”.
• Barneproduktet spiller rollen som er beskrevet av childProductRole — for eksempel “Komponent av”.

Ved å lagre begge rollene som strenger på typen, får du en gjenbrukbar definisjon. Et hvilket som helst antall faktiske produkt-til-produkt-lenker kan referere til den samme ProductRelationshipType-raden, slik at vokabularet forblir lite og konsistent mens relasjonsforekomstene forblir mange. Dette er et klassisk normaliseringsmønster: skille typen relasjon fra dens forekomster.

Beskrivelsen nevner eksplisitt tre varianter — pakke (bundle), opsjon (option) og dekning (covering) — som antyder rekkevidden av kommersiell semantikk modellen har til hensikt å dekke:

• Pakke (Bundle) — produkter som selges sammen som en enhet (forelder “består av” barn).
• Opsjon (Option) — et valg eller tillegg knyttet til et basisprodukt.
• Dekning (Covering) — et produkt som pakker inn eller beskytter et annet, vanlig i forsikrings- og garantisammenheng.

Hvordan bestemme ditt rolle-vokabular

Fordi parentProductRole og childProductRole er fritekststrenger, dikterer ikke modellen din eksakte ordlyd. Den fleksibiliteten er både en funksjon og en fare. Noen praktiske regler:

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

1. Velg et kontrollert vokabular og frys det. Bli enige om et lite sett med rollefraser (“Består av” / “Komponent av”, “Valgfritt tillegg til” / “Har opsjon”) og dokumenter dem. Fritekst inviterer til avvik.
2. Hold rollene symmetriske og lesbare i begge retninger. En god test: kan du lese relasjonen høyt fra begge ender og få det til å gi mening?
3. Ikke overbelast roller med forretningslogikk. Hvis en rolle trenger betinget oppførsel, hører den logikken hjemme i den forbrukende applikasjonen, ikke i strengen.
4. Versjoner vokabularet ditt. Når du legger til en rolle, behandle det som en skjemaendring med en migreringsbane, ikke som et ad-hoc-innlegg.

Implementering av CIM i praksis

Å ta i bruk en kanonisk modell er en kartleggingsdisiplin, ikke en migrasjon. En fungerende sekvens:

• Inventar dine registresystemer (systems of record). For hver enhetsgruppe, avgjør hvilket system som er autoritativt. Party kan bo i CRM; Product i PIM; Sales Order i ERP.
• Kartlegg hver kilde til CIM-termer. Bygg en tabell med kildefelt $\rightarrow$ CIM-egenskap. Der en kilde ikke har noe tilsvarende, noter gapet; der CIM ikke har noe tilsvarende, noter utvidelsen.
• Avstem identifikatorer. CIMs GUID-konvensjon betyr at du vanligvis vil opprettholde en kryssreferanse mellom native nøkler og CIM id-verdier.
• Velg en serialisering. CIMs URI-baserte termer kartlegges naturlig til JSON-LD og RDF; de oversettes også rent til relasjonstabeller eller en egenskapsgraf. Modellen tvinger ikke frem en lagringsteknologi.
• Styr vokabularet. Rollestrengene, oppregningene og utvidelsene du legger til er delene som mest sannsynlig vil avvike, så sett dem under endringskontroll.

En nyttig mental modell er å behandle CIM som utvekslingsskjemaet og dine operasjonelle lagre som registresystemet. Du ber ikke hver applikasjon om å forlate sin native modell; du ber dem om å publisere og konsumere en delt modell i grensesnittene.

Forbehold og avveininger

Ingen kanonisk modell er kostnadsfri, og CIM er intet unntak.

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

• Abstraksjon har en pris. En modell som er generell nok til å spenne over flere bransjer, vil ikke passe perfekt til noen av dem. Forvent å legge til utvidelser.
• Sales Order-gruppen er tung. Dens finkornede dekomponering er kraftig, men betyr flere joins og flere enheter å kartlegge. Team med enkle ordreflyter kan velge å bare ta i bruk et utvalg.
• Fritekststrenger for roller trenger styring. Som nevnt er fleksibiliteten i parentProductRole og childProductRole bare så god som disiplinen rundt den.
• Åpne modeller utvikler seg. Fordi CIM er fellesskapsorientert, kan termer legges til eller raffineres over tid. Lås deg til en versjon og gjennomgå endringer bevisst.

Avveiningen er i bunn og grunn den klassiske mellom troskap til et spesifikt system og portabilitet på tvers av systemer. CIM optimerer for portabilitet, noe som er det riktige valget når interoperabilitet er målet.

Vanlige spørsmål

Hva er Cloud Information Model?

Cloud Information Model er en åpen, applikasjons-agnostisk datamodell som definerer delte enheter og termer for bedriftsdata som parter, produkter, ordrer og betalinger. Den gir et felles vokabular slik at ulike sky- og on-premises-systemer kan utveksle data uten skreddersydde punkt-til-punkt-kartlegginger.

Hva brukes ProductRelationshipType til?

ProductRelationshipType definerer årsakene til at to produkter er relatert — for eksempel en pakke, en opsjon eller en dekning. Den lagrer en foreldrerolle og en barnerolle slik at retningsbestemte produkt-til-produkt-lenker kan referere til en gjenbrukbar, delt definisjon i stedet for å gjenta semantikken på hver lenke.

Hvorfor bruker CIM GUID-er for primærnøkler?

Bruk av en GUID for id-egenskapen betyr at identifikatorer er globalt unike uten sentral koordinering. Dette er viktig i multi-cloud- og multi-vendor-miljøer der poster opprettes i ulike systemer og senere slås sammen, fordi kollisjoner effektivt unngås.

Er CIM et databaseskjema eller et datautvekslingsformat?

Det forstås best som en konseptuell og utvekslingsmodell snarere enn et fysisk databaseskjema. Dens URI-baserte termer kartlegges naturlig til JSON-LD, RDF, relasjonstabeller eller egenskapsgrafer, slik at du kan implementere den i den lagringsteknologien din arkitektur allerede bruker.

Hvordan forholder CIM seg til andre standarder som OAGIS eller schema.org?

CIM deler målet med disse anstrengelsene – et felles vokabular for interoperabilitet – men er dimensjonert for enterprise-integrasjon i sky-æraen og publisert som åpne, derefererbare termer. I praksis kan du mappe CIM til andre standarder i ytterkantene der partnere krever det.

Må jeg ta i bruk hele modellen på en gang?

Nei. CIM er organisert i løst koblede enhetsgrupper, slik at du kan ta i bruk gruppene du trenger – for eksempel Party og Product – og utvide senere. De fleste team starter med enhetene som forårsaker mest integreringsproblemer og vokser derfra.

Videre lesing

• Salgsordre — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — felles vokabular for strukturerte data på nettet