Cloud-Informationsmodell

Das Cloud Information Model (CIM) ist ein offenes, anwendungsunabhängiges Schema zur Beschreibung der Entitäten, die sich durch ein modernes Unternehmen bewegen: Parteien, Produkte, Bestellungen, Zahlungen und die Beziehungen, die sie miteinander verbinden. Anstatt für jede Integration ein maßgeschneidertes Datenmodell zu erfinden, bietet CIM ein gemeinsames Vokabular, sodass sich ein CRM, ein ERP, eine Commerce-Plattform und ein Analytics-Warehouse darauf einigen können, was ein „Sales Order“ oder ein „Product Relationship Type“ tatsächlich bedeutet. Dieser Artikel führt durch die Entitätsgruppen, aus denen das Modell besteht, und geht dann detailliert auf eine repräsentative Entität – ProductRelationshipType – ein, um zu zeigen, wie CIM Beziehungen, Rollen und Schlüssel in der Praxis ausdrückt.

Wichtige Erkenntnisse

• CIM organisiert Unternehmensdaten in Entitätsgruppen (Party, Product, Sales Order, Payment und andere), die schrittweise und nicht alle auf einmal übernommen werden können.
• Jede Entität wird mit einer Term URI, einer Beschreibung, skalaren Eigenschaften und Link-Eigenschaften definiert – eine Struktur, die sauber auf JSON-LD, RDF und Property-Graph-Stores abgebildet werden kann.
• Beziehungsentitäten wie ProductRelationshipType kodieren Rollen (Parent/Child), sodass Bundles, Optionen und Abdeckungen ohne hartkodierte Geschäftslogik modelliert werden können.
• Das Modell ist bewusst anwendungsunabhängig: Es beschreibt, was Daten bedeuten, nicht wie ein bestimmter Anbieter sie speichert.
• Die Einführung von CIM ist eine Mapping-Übung, kein „Rip-and-Replace“ – Sie richten bestehende Systeme an gemeinsamen Begriffen aus und schließen die Lücken.

Warum ein gemeinsames Modell wichtig ist

Die Unternehmensintegration weist einen bekannten Fehlermodus auf: Jedes System spricht seinen eigenen Dialekt. Salesforce nennt es ein Account, SAP nennt es einen Business Partner und ein eigenentwickelter Abrechnungsdienst nennt es einen Customer. Wenn Sie Punkt-zu-Punkt-Mappings zwischen jedem Paar erstellen, wächst die Anzahl der Übersetzungen quadratisch mit den beteiligten Systemen, und jedes neue System vervielfacht den Wartungsaufwand.

Ein kanonisches Modell löst dieses quadratische Problem. Sie mappen jedes System einmal auf das gemeinsame Modell, und das gemeinsame Modell wird zum Hub. Dies ist derselbe architektonische Instinkt, der hinter Standards wie OAGIS (Open Applications Group Integration Specification), dem Common Warehouse Metamodel der OMG und dem Vokabular für Commerce von schema.org steckt.

CIM steht in dieser Tradition, ist jedoch auf Interoperabilität in der Cloud-Ära ausgelegt und wird als offene Begriffe mit dereferenzierbaren URIs veröffentlicht.

Der praktische Nutzen besteht darin, dass ein Datenarchitekt Fragen wie „Welche Systeme halten den maßgeblichen Datensatz für eine Party?“ oder „Wie stellen wir ein Produktbündel konsistent über den Katalog und die Bestellung hinweg dar?“ unter Verwendung eines einzigen Referenzpunkts beantworten kann.

Die Entitätsgruppen im Überblick

CIM ist kein einzelnes monolithisches Schema; es ist eine Menge lose gekoppelter Gruppen. Zu den im Modell genannten Gruppen gehören:

Verwandte: Fivetran — Die vollständig verwaltete ELT-Pipeline, die einfach weiterläuft.

• Account – der kommerzielle Beziehungskontext für eine Party.
• Contact Point – Telefonnummern, E-Mail-Adressen und ähnliche Erreichbarkeitskanäle.
• Lead – eine potenzielle Party, die noch nicht qualifiziert ist.
• Party und Party Role – das allgemeine Konzept eines Akteurs und der Rollen, die er spielt (Kunde, Lieferant, Mitarbeiter).
• Payment und Payment Method – wie Geld fließt und welche Instrumente verwendet werden.
• Product Attribute, Product Catalog und Product – die verkaufbaren und beschreibbaren Waren und Dienstleistungen.
• Sales Order und seine große Familie von Unterentitäten – das transaktionale Herzstück des Modells.
• Shipment – Fulfillment und Logistik.

Die Sales Order-Gruppe ist bei weitem die granularste, und es lohnt sich zu verstehen, warum. In einer Bestellung konzentrieren sich die Geschäftsregeln: Preise, Steuern, Anpassungen, Liefergruppierungen und zeilenbezogene Notizen sind alle dort verknüpft.

CIM zerlegt die Bestellung in viele kleine Entitäten – Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log und mehr – anstatt in eine einzige breite Tabelle. Diese Zerlegung ist eine bewusste Designentscheidung: Sie ermöglicht es jedem Anliegen, sich unabhängig zu entwickeln, und erlaubt es Systemen, nur die Ausschnitte zu abonnieren, die für sie relevant sind.

Anatomie einer CIM-Entität

Jede Entität in CIM folgt der gleichen Form, was die programmatische Nutzung des Modells vorhersehbar macht. Betrachten Sie ProductRelationshipType, die Entität, die beschreibt, warum zwei Produkte miteinander in Beziehung stehen.

Wenn Sie einkaufen: Boomi AtomSphere — Enterprise iPaaS für die Hybrid-Cloud-to-On-Premise-Integration.

• Term URI – http://cloudinformationmodel.org/model/ProductRelationshipType. Dies ist der weltweit eindeutige Bezeichner für das Konzept. Da es sich um eine URI handelt, kann sie dereferenziert und direkt in RDF/JSON-LD-Graphen verwendet werden.
• Description – „Reasons why products are related such as bundle, option or covering.“ Dies sagt Ihnen, dass die Entität ein Typ oder eine Klassifizierung ist, nicht die Beziehungsinstanz selbst.
• Scalar Properties – die primitiven Felder, die Daten tragen.
• Link Properties – Verweise auf andere Entitäten. ProductRelationshipType hat keine, was an sich informativ ist: Es ist eine Blattentität, ein kontrolliertes Vokabular und kein Hub.

Die skalaren Eigenschaften sind:

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”

Dass die id eine GUID ist, ist eine bedeutsame Konvention: Es bedeutet, dass Bezeichner ohne Koordination zwischen Systemen weltweit eindeutig sind, was genau das ist, was man möchte, wenn Datensätze in verschiedenen Clouds erstellt und später zusammengeführt werden.

Beziehungen mit Rollen modellieren

Der aufschlussreichste Teil von ProductRelationshipType ist das Paar aus Rolleneigenschaften. Eine Produktbeziehung ist gerichtet, und CIM erfasst diese Richtung mit zwei benannten Rollen anstatt einer einzigen undurchsichtigen „Typ“-Zeichenfolge.

Denken Sie an ein Bundle. Ein „Starter Kit“ besteht aus einem „Router“ und einem „Kabel“. In CIM-Begriffen:

• Das übergeordnete Produkt (parent product) spielt die durch parentProductRole beschriebene Rolle – zum Beispiel „Besteht aus“.
• Das untergeordnete Produkt (child product) spielt die durch childProductRole beschriebene Rolle – zum Beispiel „Komponente von“.

Indem Sie beide Rollen als Zeichenfolgen im Typ speichern, erhalten Sie eine wiederverwendbare Definition. Eine beliebige Anzahl tatsächlicher Produkt-zu-Produkt-Links kann auf dieselbe ProductRelationshipType-Zeile verweisen, sodass das Vokabular klein und konsistent bleibt, während die Beziehungsinstanzen zahlreich bleiben. Dies ist ein klassisches Normalisierungsmuster: Trennen Sie den Typ der Beziehung von ihren Instanzen.

Die Beschreibung nennt explizit drei Varianten – Bundle, Option und Covering –, was auf den Bereich der kommerziellen Semantik hinweist, den das Modell abdecken möchte:

Verwandte: Matillion — Push-Down-ELT für Cloud-Data-Warehouses.

• Bundle – Produkte, die zusammen als Einheit verkauft werden (übergeordnetes Produkt „besteht aus“ untergeordneten Produkten).
• Option – eine Auswahl oder ein Add-on, das einem Basisprodukt zugeordnet ist.
• Covering – ein Produkt, das ein anderes umschließt oder schützt, was in Versicherungs- und Garantiekontexten üblich ist.

So legen Sie Ihr Rollenvokabular fest

Da es sich bei parentProductRole und childProductRole um Freiform-Zeichenfolgen handelt, gibt das Modell Ihren genauen Wortlaut nicht vor. Diese Flexibilität ist sowohl ein Merkmal als auch eine Gefahr. Ein paar praktische Regeln:

1. Wählen Sie ein kontrolliertes Vokabular aus und fixieren Sie es. Vereinbaren Sie einen kleinen Satz von Rollenphrasen („Besteht aus“ / „Komponente von“, „Optionales Add-on zu“ / „Hat Option“) und dokumentieren Sie diese. Freitext lädt zu Inkonsistenzen ein.
2. Halten Sie die Rollen symmetrisch und in beide Richtungen lesbar. Ein guter Test: Können Sie die Beziehung von beiden Enden laut vorlesen und ergibt sie Sinn?
3. Überladen Sie Rollen nicht mit Geschäftslogik. Wenn eine Rolle ein bedingtes Verhalten erfordert, gehört diese Logik in die konsumierende Anwendung, nicht in die Zeichenfolge.
4. Versionieren Sie Ihr Vokabular. Wenn Sie eine Rolle hinzufügen, behandeln Sie dies als Schemaänderung mit einem Migrationspfad und nicht als Ad-hoc-Einfügung.

Einführung von CIM in der Praxis

Die Übernahme eines kanonischen Modells ist eine Mapping-Disziplin, keine Migration. Eine praktikable Reihenfolge:

• Inventarisieren Sie Ihre führenden Systeme (Systems of Record). Entscheiden Sie für jede Entitätsgruppe, welches System maßgeblich ist. Die Partei (Party) könnte im CRM liegen; das Produkt im PIM; der Kundenauftrag (Sales Order) im ERP.
• Ordnen Sie jede Quelle CIM-Begriffen zu. Erstellen Sie eine Tabelle: Quellfeld $\rightarrow$ CIM-Eigenschaft. Wenn eine Quelle kein Äquivalent hat, notieren Sie die Lücke; wenn CIM kein Äquivalent hat, notieren Sie die Erweiterung.
• Bezeichner abgleichen. Die GUID-Konvention von CIM bedeutet, dass Sie normalerweise eine Zuordnungstabelle (Crosswalk) zwischen nativen Schlüsseln und CIM-id-Werten pflegen.
• Wählen Sie eine Serialisierung. Die URI-basierten Begriffe von CIM lassen sich natürlich auf JSON-LD und RDF abbilden; sie lassen sich auch sauber in relationale Tabellen oder einen Property Graph übertragen. Das Modell erzwingt keine bestimmte Speichertechnologie.
• Verwalten Sie das Vokabular. Die von Ihnen hinzugefügten Rollenzeichenfolgen, Aufzählungen und Erweiterungen sind die Teile, die am wahrscheinlichsten driften, daher sollten sie unter eine Änderungskontrolle gestellt werden.

Ein nützliches mentales Modell besteht darin, CIM als Austauschschema (Interchange Schema) und Ihre operativen Speicher als System of Record zu behandeln. Sie verlangen nicht von jeder Anwendung, ihr natives Modell aufzugeben; Sie bitten sie, an den Schnittstellen ein gemeinsames Modell zu veröffentlichen und zu konsumieren.

Unsere Wahl: Workato — Automatisierungsgesteuertes iPaaS, auf dem Geschäftsteams tatsächlich aufbauen können.

Vorbehalte und Kompromisse

Kein kanonisches Modell ist kostenlos, und CIM ist keine Ausnahme.

• Abstraktion hat ihren Preis. Ein Modell, das allgemein genug ist, um Branchen zu überspannen, wird für keine einzelne Branche perfekt passen. Rechnen Sie mit zusätzlichen Erweiterungen.
• Die Gruppe „Sales Order“ ist umfangreich. Ihre feinkörnige Zerlegung ist leistungsstark, bedeutet aber mehr Joins und mehr zu mappende Entitäten. Teams mit einfachen Auftragsabläufen übernehmen möglicherweise nur eine Teilmenge.
• Freiform-Rollenzeichenfolgen benötigen Governance. Wie bereits erwähnt, ist die Flexibilität in parentProductRole und childProductRole nur so gut wie die Disziplin in ihrer Anwendung.
• Offene Modelle entwickeln sich weiter. Da CIM gemeinschaftsorientiert ist, können Begriffe im Laufe der Zeit hinzugefügt oder verfeinert werden. Binden Sie sich an eine Version und prüfen Sie Änderungen gezielt.

Der Kompromiss ist im Wesentlichen der klassische zwischen Treue zu einem spezifischen System und Portabilität über Systeme hinweg. CIM optimiert die Portabilität, was die richtige Entscheidung ist, wenn Interoperabilität das Ziel ist.

Häufig gestellte Fragen

Was ist das Cloud Information Model?

Das Cloud Information Model ist ein offenes, anwendungsunabhängiges Datenmodell, das gemeinsame Entitäten und Begriffe für Unternehmensdaten wie Parteien, Produkte, Aufträge und Zahlungen definiert. Es bietet ein gemeinsames Vokabular, sodass verschiedene Cloud- und On-Premises-Systeme Daten ohne maßgeschneiderte Punkt-zu-Punkt-Mappings austauschen können.

Wofür wird ProductRelationshipType verwendet?

ProductRelationshipType definiert die Gründe, warum zwei Produkte miteinander in Beziehung stehen – zum Beispiel als Bundle, Option oder Covering. Es speichert eine übergeordnete und eine untergeordnete Rolle, sodass gerichtete Produkt-zu-Produkt-Links auf eine wiederverwendbare, gemeinsame Definition verweisen können, anstatt die Semantik bei jedem Link zu wiederholen.

Warum verwendet CIM GUIDs für Primärschlüssel?

Die Verwendung einer GUID für die id-Eigenschaft bedeutet, dass Bezeichner ohne zentrale Koordination global eindeutig sind. Dies ist in Multi-Cloud- und Multi-Vendor-Umgebungen wichtig, in denen Datensätze in verschiedenen Systemen erstellt und später zusammengeführt werden, da Kollisionen so effektiv vermieden werden.

Ist CIM ein Datenbankschema oder ein Datenaustauschformat?

Es ist am besten als konzeptionelles Austauschmodell und nicht als physisches Datenbankschema zu verstehen. Seine URI-basierten Begriffe lassen sich natürlich auf JSON-LD, RDF, relationale Tabellen oder Property Graphs abbilden, sodass Sie es mit jeder Speichertechnologie implementieren können, die Ihre Architektur bereits verwendet.

In welcher Beziehung steht CIM zu anderen Standards wie OAGIS oder schema.org?

CIM teilt das Ziel dieser Bemühungen – ein gemeinsames Vokabular für Interoperabilität –, ist jedoch auf die Unternehmensintegration der Cloud-Ära ausgerichtet und wird als offene, dereferenzierbare Begriffe veröffentlicht. In der Praxis können Sie CIM an den Schnittstellen, an denen Partner dies benötigen, anderen Standards zuordnen.

Muss ich das gesamte Modell auf einmal übernehmen?

Nein. CIM ist in lose gekoppelten Entitätsgruppen organisiert, sodass Sie die Gruppen übernehmen können, die Sie benötigen – beispielsweise Party und Product – und diese später erweitern können. Die meisten Teams beginnen mit den Entitäten, die die größten Integrationsschwierigkeiten verursachen, und bauen von dort aus auf.

Weiterführende Literatur

• Sales order — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — gemeinsames Vokabular für strukturierte Daten im Web