CIM-Modell

Das Cloud Information Model (CIM) ist ein offenes, anwendungsunabhängiges Datenmodell, das Unternehmen ein gemeinsames Vokabular für die Entitäten bieten soll, die in CRM-, ERP-, Marketing-, Service- und Analysesystemen vorkommen. Anstatt dass jeder Anbieter seine eigenen Objektnamen und -beziehungen erfindet, definiert CIM einen gemeinsamen Satz von Themenbereichen, Entitäten und Attributen, auf die jedes System abgebildet werden kann. Das Modell wird als Open-Source-Projekt unter der Linux Foundation verwaltet, die ein breites Portfolio an kollaborativen Daten- und Infrastrukturprojekten beherbergt.

In diesem Artikel wird erklärt, wie das CIM aufgebaut ist, wie seine Komponenten zueinander in Beziehung stehen, wie Supertypen und Subtypen funktionieren und wie die Themenbereiche organisiert sind. Es behandelt auch die praktischen Entscheidungen, vor denen ein Architekt bei der Einführung von CIM steht – Mapping, Governance, Versionierung und Erweiterung – und wo das Modell im Vergleich zu anderen Industriestandards einzuordnen ist.

Wichtige Erkenntnisse

• CIM organisiert Geschäftskonzepte in Themenbereichen, die jeweils Entitätsgruppen, Entitäten und Attribute enthalten – eine Hierarchie, die sich sauber auf Schemata, Tabellen und Spalten abbilden lässt.
• Supertypen und Subtypen ermöglichen es dem Modell, gemeinsame Merkmale (eine Party, die eine Person oder eine Organisation ist) auszudrücken und gleichzeitig Spezialisierungen zu erlauben.
• Das Modell ist bewusst anwendungsunabhängig: Es beschreibt Geschäftskonzepte, nicht die Implementierung eines einzelnen Anbieters.
• CIM wird in mehreren Formaten mit Beispieldiagrammen veröffentlicht, sodass es gleichermaßen von Modellierungstools, Codegeneratoren und Dokumentationen genutzt werden kann.
• Die Anzahl und der Umfang der Themenbereiche wachsen mit dem Konsortium und den Beiträgen der Community, daher sollte die Einführung Versionierung und Änderungsmanagement berücksichtigen.
• CIM ist eine Option unter mehreren; die richtige Wahl hängt davon ab, ob Sie ein breites domänenübergreifendes Modell oder einen engen, tiefen Standard für eine einzelne Branche benötigen.

Wie das CIM aufgebaut ist

Das CIM ist in Komponenten organisiert, sodass Inhalte einfacher navigiert und genutzt werden können. Jede Ebene der Hierarchie beantwortet eine andere Frage, und das Verständnis dieser Hierarchie ist der erste Schritt zur effektiven Nutzung des Modells.

• Themenbereich (Subject Area) – Ein wichtiges Geschäftskonzept, das vom CIM-Konsortium identifiziert wurde, wie z. B. Party. Jeder Themenbereich enthält eine oder mehrere Entitätsgruppen. Betrachten Sie einen Themenbereich als einen Bounded Context: Er fasst alles zusammen, was das Unternehmen über ein umfassendes Thema wissen muss.
• Entitätsgruppe (Entity Group) – Eine logische Gruppierung verwandter Entitäten innerhalb eines Themenbereichs, z. B. Account. Entitätsgruppen halten große Themenbereiche navigierbar und bieten Teams eine natürliche Einheit für die Zuweisung der Verantwortlichkeit.
• Entität (Entity) – Ein eindeutiges Objekt, über das eine Organisation Informationen sammelt, beispielsweise ein Account Contact. Eine Entität ist analog zu einer Standard-Datenbanktabelle.
• Attribut (Attribute) – Ein eindeutiges Merkmal einer Entität, z. B. Account Id oder Contact Email. Ein Attribut ist analog zu einem Standard-Datenbankfeld innerhalb einer Tabelle.

Diese vierstufige Hierarchie ist bewusst vertraut gestaltet. Datenarchitekten, die mit relationaler Modellierung, dimensionaler Modellierung oder Entity-Relationship-Diagrammen gearbeitet haben, werden das Muster sofort erkennen. Der Mehrwert von CIM ist keine neuartige Modellierungstechnik, sondern ein gemeinsamer, vorab ausgehandelter Satz von Namen und Beziehungen, auf den sich mehrere Organisationen und Anbieter einigen können.

Ein nützliches mentales Modell: Ein Themenbereich ist in etwa ein Schema oder eine Domäne; eine Entitätsgruppe ist in etwa ein Namespace oder Modul; eine Entität ist eine Tabelle; ein Attribut ist eine Spalte. Diese Zuordnung ist approximativ – CIM ist ein konzeptionelles und logisches Modell, kein physisches –, aber sie hilft bei der Übersetzung von CIM in eine physische Implementierung.

Supertypen und Subtypen

Über die vier Kernkomponenten hinaus passt das CIM-Design Entitäten an und erweitert sie mithilfe von Supertypen und Subtypen in weitere Gruppierungen. Hier gewinnt das Modell einen Großteil seiner Ausdruckskraft.

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

• Supertyp – Eine Entität, die durch Subtyp-Entitäten erweitert wird und gemeinsame Attribute für ähnliche Konzepte definiert.
• Subtyp – Eine Entität, die eine andere Entität erweitert und die Attribute von ihrer Supertyp-Entität erbt.

Das klassische Beispiel ist Party. Eine Party ist jeder oder alles, mit dem das Unternehmen Geschäfte macht. Eine Person und eine Organisation sind beide Parties und teilen Attribute – einen Namen, Identifikatoren, Kontaktpunkte –, aber jede hat Attribute, die die andere nicht besitzt.

Die Modellierung von Party als Supertyp mit Person und Organisation als Subtypen vermeidet die Duplizierung der gemeinsamen Attribute und hält Beziehungen (z. B. „diese Opportunity gehört zu dieser Party“) konsistent, unabhängig davon, welcher Subtyp involviert ist.

Eine solche Vererbung ist ein etabliertes Konzept in der Datenmodellierung und findet sich in Standards wie der UML der Object Management Group sowie in den branchenweit verwendeten Entity-Relationship-Konventionen. Wenn Sie CIM physisch implementieren, müssen Sie entscheiden, wie die Vererbung dargestellt werden soll:

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

• Einzelne Tabelle (Single Table) – Speichern aller Subtypen in einer Tabelle mit einer Diskriminatorspalte. Einfach abzufragen, kann aber viele nullable Spalten erzeugen.
• Class Table Inheritance – Eine Tabelle für den Supertyp und eine pro Subtyp, verknüpft über einen gemeinsamen Schlüssel. Normalisiert und sauber, erfordert jedoch Joins.
• Concrete Table Inheritance – Eine separate, in sich geschlossene Tabelle pro Subtyp. Schnell für subtypspezifische Abfragen, dupliziert jedoch gemeinsame Attribute.

Es gibt keine universell richtige Antwort. Die richtige Wahl hängt von den Abfragemustern, der Anzahl der Subtypen und davon ab, wie oft die gemeinsamen Attribute zusammen gelesen werden. Dokumentieren Sie die Entscheidung, da sie jede nachgelagerte Integration beeinflussen wird.

Die CIM-Themenbereiche

Die Themenbereiche repräsentieren die wichtigsten Geschäftskonzepte, die das Konsortium bisher modelliert hat. Jedes wird mit eigenen Diagrammen und Formaten veröffentlicht, und einige tragen explizite Versionsmarkierungen (z. B. v1.0 oder v0.1.1), was darauf hinweist, dass einige Bereiche ausgereifter sind als andere.

Setup — Definiert, mit wem Sie Geschäfte machen, zum Beispiel Kunde, Lieferant und Verkäufer. Es deckt auch die Software- und Infrastrukturkonzepte ab, die eine Organisation betreibt: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job und IoT Device.

Data Model — Die grundlegenden Modellierungskonzepte selbst.

Hire — Aktivitäten im Zusammenhang mit dem Aufbau Ihres Unternehmens, z. B. interne Geschäftseinheit und Mitarbeiter. Zu den Entitätsgruppen gehören Job Application, Employee, Compensation, Training, Location, Work Territory und Work Report.

Biz Process — Geschäftsprozess- und Geschäftskontinuitätskonzepte.

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

Produce — Handhabung von Material, das Sie kaufen, bewegen und verkaufen, zum Beispiel Produkt und Inventarprodukt. Zu den Entitätsgruppen gehören Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order und Sales Agreement.

Market — Aktivitäten zur Werbung für Ihr Produkt, zum Beispiel Marketingkampagne und Webshop. Zu den Entitätsgruppen gehören Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy und Web Site.

Sell — Aktivitäten zum Verkauf Ihres Produkts, zum Beispiel die Erstellung von Angeboten und Verkaufschancen. Zu den Entitätsgruppen gehören Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program und Competitor.

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

Service — Aktivitäten zur Bereitstellung von Support für ein verkauftes oder gewartetes Produkt, beispielsweise ein Fall oder eine Umfrage. Zu den Entitätsgruppen gehören AI Assistant, Asset, Asset Subscription, Web Content, Case, Task und Event.

Fulfill — Aktivitäten, die Sie durchführen, um eine Bestellung an einen Kunden zu erfüllen, z. B. Versand und Rücksendung. Zu den Entitätsgruppen gehören Fulfillment Order, Shipment, Return Order, Work Order, Work Resource und Work Forecast.

Interact — Aktivitäten zur Verfolgung der Interaktion mit Endbenutzern oder anderen Systemen. Zu den Entitätsgruppen gehören Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey und Loyalty.

Finance — Aktivitäten zur Verfolgung von Finanzinformationen im Unternehmen, zum Beispiel Zahlung, Rechnung und Spesenabrechnung. Zu den Entitätsgruppen gehören Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar und Tax Policy.

Analyze — Aktivitäten im Zusammenhang mit der Analyse von Daten, z. B. Analyse von Mustern, Produktnutzung, Datenbewegung, Datenänderungen und Kundenzufriedenheit. Zu den Entitätsgruppen gehören AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty und Journal.

Beachten Sie, dass die Themenbereiche sowohl operative Belange (Sell, Fulfill, Service) als auch analytische Belange (Analyze, Finance) umfassen. Diese Breite ist der Punkt: Ein gemeinsames Modell ist am wertvollsten, wenn es denselben Kunden, dasselbe Produkt oder dieselbe Bestellung konsistent beschreiben kann, unabhängig davon, ob die Daten in einem Transaktionssystem oder einem Data Warehouse gespeichert sind.

Wahl zwischen CIM und anderen Standards

CIM ist nicht das einzige gemeinsame Modell im Unternehmen. Mehrere etablierte Standards überschneiden sich in Teilen ihres Geltungsbereichs, und eine ausgereifte Architektur verwendet oft mehr als einen. Bei der Entscheidung geht es weniger darum, einen Gewinner auszuwählen, als vielmehr darum, die Breite und Governance des Modells an Ihr Problem anzupassen.

Standard	Hauptfokus	Typische Stärke	Wo sich CIM unterscheidet
CIM	Domainübergreifende Geschäftskonzepte	Breite, anwendungsunabhängige Abdeckung von CRM/ERP/Marketing/Service	Konzipiert als gemeinsames Dach über Domänen hinweg
OMG Common Core Ontologies / UML-basierte Modelle	Konzeptionelle Modellierungsnotation und obere Ontologien	Strenge formale Semantik	CIM ist direkter geschäftsorientiert
Branchenspezifische Modelle (z. B. Einzelhandel, Gesundheitswesen, Finanzbranche)	Umfangreiche Abdeckung eines Sektors	Präzision innerhalb der Vertikalen	CIM tauscht Tiefe gegen Breite
Lieferantendatenmodelle (CRM/ERP-Plattformen)	Die Objekte eines Produkts	Enge Integration mit diesem Produkt	CIM ist vom Design her herstellerneutral

Eine praktische Faustregel:

• Wenn Sie ein gemeinsames Vokabular für viele Systeme und Anbieter benötigen, ist ein umfassendes Modell wie CIM sehr gut geeignet.
• Wenn Sie tiefe, regulierte, branchenspezifische Semantik benötigen, ist ein vertikaler Standard normalerweise präziser, und Sie können ihn an den Schnittstellen auf CIM abbilden.
• Wenn Sie innerhalb des Ökosystems eines einzelnen Anbieters integrieren, kann das eigene Modell dieses Anbieters ausreichend sein – es wird Ihnen jedoch nicht dabei helfen, eine Verbindung zum nächsten Anbieter herzustellen.

Das häufigste Muster in der Praxis ist ein Hub-and-Spoke-Ansatz: CIM (oder ein anderes kanonisches Modell) sitzt in der Mitte und jedes Quellsystem wird darauf abgebildet. Dies ist das gleiche Prinzip, das hinter kanonischen Datenmodellen in der Stammdatenverwaltung und hinter der Idee der „konformen Dimension“ steht, die in der dimensionalen Modellierung von Ralph Kimball populär gemacht wurde.

Praktische Anleitung zur Einführung von CIM

Die Einführung eines gemeinsamen Modells ist sowohl eine organisatorische als auch eine technische Aufgabe. Einige Entscheidungen bestimmen, ob sich der Aufwand lohnt.

Beginnen Sie mit einem begrenzten Bereich. Versuchen Sie nicht, jedes System gleichzeitig jedem Themenbereich zuzuordnen. Wählen Sie eine hochwertige Domain – Party und Sell sind gängige Ausgangspunkte, da Kunden- und Opportunity-Daten weit verbreitet sind – und beweisen Sie die Zuordnung end-to-end.

Entscheiden Sie frühzeitig über Ihre Erweiterungsrichtlinie. CIM ist darauf ausgelegt, mit dem Konsortium und den Beiträgen zu wachsen, aber Ihre Organisation benötigt zwangsläufig Attribute, die das Modell noch nicht definiert. Legen Sie eine Konvention für lokale Erweiterungen fest (z. B. ein Namespace-Präfix), damit benutzerdefinierte Attribute klar von Standardattributen unterschieden werden können und später abgeglichen werden können.

Behandeln Sie die Versionierung als ein erstklassiges Anliegen. Die Themenbereiche tragen Versionsmarkierungen wie v1.0 und v0.1.1, die signalisieren, dass sich das Modell weiterentwickelt. Fixieren Sie die Version, auf der Sie aufbauen, verfolgen Sie Änderungen und planen Sie die Migration. Dies ist die gleiche Disziplin, die Sie auf jede Abhängigkeit anwenden würden.

Zuordnen, nicht kopieren. CIM ist ein konzeptionelles und logisches Modell. Widerstehen Sie der Versuchung, physische Schemata direkt daraus zu generieren, ohne Leistung, Indizierung und die Zugriffsmuster der Systeme zu berücksichtigen, die die Daten nutzen. Verwenden Sie das Modell, um die Bedeutung abzustimmen, und entwerfen Sie dann den physischen Speicher für Ihre Arbeitslast.

Steuern Sie die Zuordnung. Die Zuordnung zwischen einem Quellsystem und CIM ist an sich schon ein Asset. Versionieren Sie sie, überprüfen Sie sie und weisen Sie die Verantwortlichkeit zu. Tools im Bereich der Datenintegration – ETL- und ELT-Plattformen, Datenkataloge und Lineage-Tools – können Ihnen helfen, den Ursprung jedes Attributs und seinen Fluss zu verfolgen. Dies ist genau die Art von Metadaten, die der Themenbereich Analyze mit Entitäten wie Data Lineage vorsieht.

Beteiligen Sie sich an der Community. Da CIM Open Source und konsortialgesteuert ist, sind Lücken, die Sie finden, oft Lücken, die auch andere gefunden haben. Das Zurückspielen einer vorgeschlagenen Entität oder eines Attributs in das Projekt ist sowohl ein Zeichen guter Community-Mitgliedschaft als auch eine Möglichkeit, Ihren langfristigen Wartungsaufwand zu reduzieren.

Formate, Diagramme und Nutzung

Die CIM-Designs sind in mehreren Formaten für jede Domäne verfügbar, einschließlich Beispieldiagrammen. Dies ist wichtig, da verschiedene Zielgruppen ein Datenmodell unterschiedlich nutzen:

• Architekten benötigen Diagramme und Beziehungsansichten, um über die Struktur zu reflektieren.
• Ingenieure benötigen maschinenlesbare Definitionen, die sie in Codegenerierungs-, Schemavalidierungs- oder Mapping-Tools einspeisen können.
• Analysten und Stewards benötigen eine Dokumentation, die erklärt, was jede Entität und jedes Attribut in geschäftlichen Begriffen bedeutet.

Die Veröffentlichung in mehreren Formaten ist eine bewusste Designentscheidung, die die Hürde für die Einführung senkt. Überprüfen Sie bei der Evaluierung eines gemeinsam genutzten Modells, ob es in Formaten geliefert wird, die Ihre Toolchain tatsächlich aufnehmen kann – ein Modell, das nur als PDF vorliegt, ist weitaus weniger nützlich als eines mit strukturierten Definitionen.

Häufig gestellte Fragen

Was ist das Cloud Information Model (CIM)?

Das Cloud Information Model ist ein offenes, anwendungsunabhängiges Datenmodell, das gemeinsame Geschäftskonzepte – wie Party, Account und Sales Order – definiert, sodass verschiedene Cloud- und On-Premises-Systeme Daten unter Verwendung eines gemeinsamen Vokabulars austauschen können. Es ist in Themenbereiche, Entitätsgruppen, Entitäten und Attribute unterteilt und wird als Open-Source-Projekt unter der Linux Foundation verwaltet.

Was ist der Unterschied zwischen einem Supertyp und einem Subtyp in CIM?

Ein Supertyp ist eine Entität, die durch Subtyp-Entitäten erweitert wird und die Attribute definiert, die ähnlichen Konzepten gemeinsam sind. Ein Subtyp erweitert eine andere Entität und erbt die Attribute seines Supertyps. Beispielsweise kann Party als Supertyp mit Person und Organization als Subtypen fungieren, sodass gemeinsame Attribute einmal definiert werden und spezialisierte Attribute im Subtyp liegen.

In welcher Beziehung steht CIM zu einem Datenbankschema?

CIM ist ein konzeptionelles und logisches Modell, kein physisches Schema. Seine Entitäten sind analog zu Datenbanktabellen und seine Attribute zu Feldern, was die Übersetzung intuitiv macht. Dennoch sollten Sie den physischen Speicher – Indizierung, Partitionierung, Denormalisierung – basierend auf Ihren eigenen Abfragemustern entwerfen, anstatt das Modell wörtlich zu kopieren.

Ist CIM ein Ersatz für branchenspezifische Datenstandards?

Nein. CIM ist breit gefächert und domänenübergreifend, während vertikale Standards tiefgreifend und sektorspezifisch sind. Viele Organisationen verwenden einen Hub-and-Spoke-Ansatz, bei dem CIM als kanonisches Modell im Zentrum dient und Industriestandards oder Anbietermodelle an den Rändern darauf abgebildet werden.

Warum haben CIM-Themenbereiche Versionsnummern?

Versionsmarkierungen wie v1.0 und v0.1.1 weisen darauf hin, dass sich das Modell weiterentwickelt und dass einige Themenbereiche ausgereifter sind als andere. Das Fixieren einer Version, das Verfolgen von Änderungen und das Planen von Migrationen ist die gleiche Disziplin des Abhängigkeitsmanagements, die Sie auf jede gemeinsam genutzte Bibliothek oder jedes Schema anwenden würden.

Wie gehe ich mit Attributen um, die CIM nicht definiert?

Legen Sie eine dokumentierte Erweiterungskonvention fest, z. B. ein Namespace-Präfix, damit benutzerdefinierte Attribute klar von Standardattributen unterscheidbar sind. Erwägen Sie dann, die Lücke wieder in das Projekt einzubringen, da das Modell darauf ausgelegt ist, durch Beiträge des Konsortiums und der Community zu wachsen.