Cloud Information Model

(CIM) er et åbent, applikations-agnostisk skema til beskrivelse af de enheder, der bevæger sig gennem en moderne virksomhed: parter, produkter, ordrer, betalinger og de relationer, der binder dem sammen. I stedet for at opfinde en skræddersyet datamodel for hver integration, tilbyder CIM et fælles ordforråd, så et CRM, en ERP, en handelsplatform og et analyselager kan blive enige om, hvad en “Sales Order” eller en “Product Relationship Type” faktisk betyder. Denne artikel gennemgår de enhedsgrupper, der udgør modellen, og dykker derefter ned i én repræsentativ enhed — ProductRelationshipType — for at vise, hvordan CIM udtrykker relationer, roller og nøgler i praksis.

Key Takeaways

• CIM organiserer virksomhedsdata i enhedsgrupper (Party, Product, Sales Order, Payment og andre), der kan vedtages trinvist i stedet for alle på én gang.
• Hver enhed er defineret med en Term URI, en beskrivelse, skalære egenskaber og link-egenskaber — en struktur, der mapper rent til JSON-LD, RDF og property-graph stores.
• Relationsenheder som ProductRelationshipType koder for roller (parent/child), så bundter, optioner og dækninger kan modelleres uden hårdkodning af forretningslogik.
• Modellen er bevidst applikations-agnostisk: den beskriver, hvad data betyder, ikke hvordan en bestemt leverandør gemmer dem.
• At adoptere CIM er en kortlægningsøvelse, ikke en “rip-and-replace” — du tilpasser eksisterende systemer til fælles termer og udfylder hullerne.

Hvorfor en delt model betyder noget

Enterprise-integration har en velkendt fejltilstand: hvert system taler sin egen dialekt. Salesforce kalder det en Account, SAP kalder det en Business Partner, og en hjemmelavet faktureringstjeneste kalder det en Customer. Når du bygger punkt-til-punkt-kortlægninger mellem hvert par, vokser antallet af oversættelser med kvadratet af de involverede systemer, og hvert nyt system multiplicerer vedligeholdelsesbyrden.

En kanonisk model bryder det kvadratiske problem. Du mapper hvert system én gang til den delte model, og den delte model bliver hubben. Dette er det samme arkitektoniske instinkt bag standarder som OAGIS (Open Applications Group Integration Specification), OMG’s Common Warehouse Metamodel og schema.org’s ordforråd for handel. CIM bygger på denne tradition, men er scoped til interoperabilitet i cloud-æraen og udgivet som åbne termer med dereferencebare URI’er.

Det praktiske udbytte er, at en dataarkitekt kan besvare spørgsmål som “hvilke systemer har den autoritative rekord for en Party?” eller “hvordan repræsenterer vi et produktbundt konsekvent på tværs af kataloget og ordren?” ved hjælp af et enkelt referencepunkt.

Enhedsgrupperne på et blik

CIM er ikke et enkelt monolitisk skema; det er et sæt af løst koblede grupper. De grupper, der er navngivet i modellen, inkluderer:

• Account — den kommercielle relationskontekst for en part.
• Contact Point — telefonnumre, e-mailadresser og lignende kontaktkanaler.
• Lead — en potentiel part, der endnu ikke er kvalificeret.
• Party og Party Role — det generelle koncept om en aktør og de roller, den spiller (kunde, leverandør, medarbejder).
• Payment og Payment Method — hvordan penge flyttes, og de anvendte instrumenter.
• Product Attribute, Product Catalog og Product — de salgbare og beskrivbare varer og tjenester.
• Sales Order og dens store familie af underenheder — det transaktionelle hjerte i modellen.
• Shipment — opfyldelse og logistik.

Sales Order-gruppen er langt den mest granulære, og det er værd at forstå hvorfor. En ordre er der, hvor forretningsreglerne koncentreres: prissætning, skatter, justeringer, leveringsgrupperinger og noter pr. linje er alle knyttet til den.

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

CIM dekomponerer ordren i mange små enheder — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log og flere — snarere end én bred tabel. Denne dekomponering er et bevidst designvalg: det lader hver bekymring udvikle sig uafhængigt og lader systemer kun abonnere på de dele, de er interesserede i.

Anatomi af en CIM-entitet

Hver enhed i CIM følger den samme form, hvilket gør modellen forudsigelig at forbruge programmatisk. Overvej ProductRelationshipType, den enhed, der beskriver hvorfor to produkter er relaterede.

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Dette er den globalt unikke identifikator for konceptet. Fordi det er en URI, kan den dereferences og bruges direkte i RDF/JSON-LD-grafer.
• Beskrivelse — “Reasons why products are related such as bundle, option or covering.” Dette fortæller dig, at entiteten er en type eller klassifikation, ikke selve relationsinstansen.
• Skalære egenskaber — de primitive felter, der bærer data.
• Link-egenskaber — referencer til andre enheder. ProductRelationshipType har ingen, hvilket i sig selv er informativt: det er en blad-entitet, et kontrolleret ordforråd snarere end en hub.

De skalære egenskaber er:

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

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 meningsfuld konvention: det betyder, at identifikatorer er globalt unikke uden koordinering mellem systemer, hvilket er præcis, hvad man ønsker, når poster oprettes i forskellige clouds og senere flettes.

Modellering af relationer med roller

Den mest lærerige del af ProductRelationshipType er parret af rolle-egenskaber. En produktrelation er retningsbestemt, og CIM fanger denne retning med to navngivne roller i stedet for en enkelt uigennemsigtig “type”-streng.

Tænk på en pakke. Et “Starter Kit” består af en “Router” og et “Kabel”. I CIM-termer:

• Moderproduktet spiller rollen beskrevet af parentProductRole — for eksempel “Består af”.
• Underproduktet spiller rollen beskrevet af childProductRole — for eksempel “Komponent af”.

Ved at gemme begge roller som strenge på typen får du en genbrugelig definition. Et hvilket som helst antal faktiske produkt-til-produkt-links kan referere til den samme ProductRelationshipType-række, så ordforrådet forbliver lille og konsistent, mens relationsinstanserne forbliver talrige. Dette er et klassisk normaliseringsmønster: adskil typen af relation fra dens instanser.

Beskrivelsen nævner eksplicit tre varianter — bundle, option og covering — hvilket antyder spændvidden af kommerciel semantik, som modellen har til hensigt at dække:

• Bundle — produkter, der sælges sammen som en enhed (moderprodukt “består af” underprodukter).
• Option — et valg eller en tilføjelse associeret med et basisprodukt.
• Covering — et produkt, der indpakker eller beskytter et andet, hvilket er almindeligt i forsikrings- og garantisammenhænge.

Sådan bestemmer du dit rolle-ordforråd

Fordi parentProductRole og childProductRole er strenge i fri form, dikterer modellen ikke din nøjagtige formulering. Den fleksibilitet er både en funktion og en risiko. Et par praktiske regler:

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

1. Vælg et kontrolleret ordforråd og frys det. Bliv enige om et lille sæt rollefraser (“Består af” / “Komponent af”, “Valgfri tilføjelse til” / “Har option”) og dokumenter dem. Fritekst inviterer til drift.
2. Hold rollerne symmetriske og læsbare i begge retninger. En god test: kan du læse relationen højt fra begge ender, så det giver mening?
3. Overbelast ikke roller med forretningslogik. Hvis en rolle kræver betinget adfærd, hører den logik hjemme i den forbrugende applikation, ikke i strengen.
4. Versionér dit ordforråd. Når du tilføjer en rolle, skal du behandle det som en skemaændring med en migreringssti, ikke som en ad-hoc-indsættelse.

Implementering af CIM i praksis

At adoptere en kanonisk model er en kortlægningsdisciplin, ikke en migration. En brugbar sekvens:

• Kortlæg dine registreringssystemer (systems of record). For hver enhedsgruppe skal du beslutte, hvilket system der er autoritativt. Party bor måske i CRM; Product i PIM; Sales Order i ERP.
• Map hver kilde til CIM-termer. Byg en tabel med kildefelt $\rightarrow$ CIM-egenskab. Hvor en kilde ikke har et tilsvarende element, skal hullet noteres; hvor CIM ikke har et tilsvarende element, skal udvidelsen noteres.
• Afstem identifikatorer. CIM’s GUID-konvention betyder, at du typisk vil vedligeholde en crosswalk mellem native nøgler og CIM id-værdier.
• Vælg en serialisering. CIM’s URI-baserede termer mapper naturligt til JSON-LD og RDF; de oversættes også rent til relationelle tabeller eller en property graph. Modellen tvinger ikke en bestemt lagringsteknologi igennem.
• Styr ordforrådet. De rollestrenge, enumerationer og udvidelser, du tilføjer, er de dele, der er mest tilbøjelige til at drifte, så placer dem under ændringskontrol.

En nyttig mental model er at behandle CIM som udvekslingsskemaet og dine operationelle lagre som registreringssystemet. Du beder ikke enhver applikation om at opgive sin native model; du beder dem om at publicere og forbruge en fælles model ved grænsefladerne.

Forbehold og afvejninger

Ingen kanonisk model er omkostningsfri, og CIM er ingen undtagelse.

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

• Abstraktion har en pris. En model, der er generel nok til at spænde over industrier, vil ikke passe perfekt til nogen af dem. Forvent at skulle tilføje udvidelser.
• Sales Order-gruppen er tung. Dens finkornede dekomponering er kraftfuld, men betyder flere joins og flere enheder, der skal mappes. Teams med simple ordreflows vil måske kun adoptere en delmængde.
• Rollestrenge i fri form kræver styring. Som nævnt er fleksibiliteten i parentProductRole og childProductRole kun så god som den disciplin, der følger med.
• Åbne modeller udvikler sig. Fordi CIM er fællesskabsorienteret, kan termer blive tilføjet eller forfinet over tid. Lås til en version og gennemgå ændringer bevidst.

Afvejningen er i bund og grund den klassiske mellem troskab mod et specifikt system og portabilitet på tværs af systemer. CIM optimerer for portabilitet, hvilket er det rigtige valg, når interoperabilitet er målet.

Ofte stillede spørgsmål

Hvad er Cloud Information Model?

Cloud Information Model er en åben, applikations-agnostisk datamodel, der definerer delte enheder og termer for virksomhedsdata såsom parter, produkter, ordrer og betalinger. Den giver et fælles ordforråd, så forskellige cloud- og on-premises systemer kan udveksle data uden skræddersyede punkt-til-punkt-mappings.

Hvad bruges ProductRelationshipType til?

ProductRelationshipType definerer årsagerne til, at to produkter er relaterede —for eksempel en bundle, en option eller en covering. Den gemmer en moderrolle og en underrolle, så retningsbestemte produkt-til-produkt-links kan referere til en genbrugelig, delt definition i stedet for at gentage semantikken på hvert link.

Hvorfor bruger CIM GUID’er til primærnøgler?

Brug af en GUID til id-egenskaben betyder, at identifikatorer er globalt unikke uden central koordinering. Det er vigtigt i multi-cloud og multi-vendor miljøer, hvor poster oprettes i forskellige systemer og senere flettes, fordi kollisioner effektivt undgås.

Er CIM et databaseskema eller et dataudvekslingsformat?

Det forstås bedst som en konceptuel og udvekslingsmodel snarere end et fysisk databaseskema. Dens URI-baserede termer mapper naturligt til JSON-LD, RDF, relationelle tabeller eller property graphs, så du kan implementere det i den lagringsteknologi, din arkitektur allerede bruger.

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

CIM deler målet med disse bestræbelser – et fælles ordforråd for interoperabilitet – men er målrettet virksomhedsintegration i cloud-æraen og udgivet som åbne, dereferencebare termer. I praksis kan du mappe CIM til andre standarder i grænsefladerne, hvor partnere kræver det.

Skal jeg implementere hele modellen på én gang?

Nej. CIM er organiseret i løst koblede enhedsgrupper, så du kan implementere de grupper, du har brug for – f.eks. Party og Product – og udvide senere. De fleste teams starter med de enheder, der skaber størst integrationsbesvær, og vokser derfra.

Yderligere læsning

• Sales order — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — fælles ordforråd for strukturerede data på nettet