Cloud Information Model

Willkommen bei CIM, einem anwendungsunabhängigen Datenmodell, das die Integration vereinfacht und Innovationen beschleunigt.

Wichtige Erkenntnisse

• CIM ist ein offenes, anwendungsunabhängiges Datenmodell – ein gemeinsames Vokabular von Geschäftskonzepten (Kunden, Bestellungen, Produkte usw.), das es verschiedenen Cloud- und On-Premises-Systemen ermöglicht, Daten ohne maßgeschneiderte Punkt-zu-Punkt-Zuordnungen auszutauschen.
• Es existiert, um ein spezifisches, kostspieliges Problem zu lösen: Jede Anwendung liefert ihr eigenes Datenmodell, sodass Integrationsteams am Ende benutzerdefinierten Übersetzungscode schreiben und pflegen müssen, der fehleranfällig ist und Innovationen verlangsamt.
• Es wird als offener Standard verwaltet, erstellt von einem Konsortium und als Open Source unter der Joint Development Foundation (Teil der Linux Foundation) bereitgestellt – sodass jeder dazu beitragen, es überprüfen und übernehmen kann.
• Inhalte sind in Themenbereichen (Domänen) organisiert, die jeweils ein wichtiges Geschäftskonzept darstellen, wobei die Designs in mehreren Formaten, einschließlich Beispieldiagrammen, veröffentlicht werden.
• CIM ist ein Modell, kein Produkt. Es definiert Bedeutung und Struktur; Sie entscheiden weiterhin selbst, wie Sie Daten in Ihren eigenen Systemen zuordnen, speichern und bewegen.

Ein neuer Standard für Dateninteroperabilität

CIM wird von einem offenen Konsortium entwickelt, das gegründet wurde, um eine standardbasierte Lösung für die Verbindung von Unternehmensprodukten bereitzustellen. Mit CIM können Sie nahtlose und maßgeschneiderte persönliche Erlebnisse über cloudnative Anwendungen hinweg schaffen.

Um die digitale Transformation zu beschleunigen und Kunden über alle Kanäle hinweg personalisierte Interaktionen zu bieten, setzen viele Unternehmen auf mehrere Cloud- und On-Premises-Anwendungen. Jede bringt ihr eigenes Datenmodell mit, was Entwickler dazu zwingt, benutzerdefinierten Code zu erstellen, zu testen und zu verwalten, der für die Zuordnung und Übersetzung von Daten zwischen verschiedenen Systemen erforderlich ist. Anstatt die digitale Transformation zu beschleunigen, verlangsamt dieser Prozess die Innovation und führt zu brüchigen Integrationen.

CIM ist eine moderne, offene Spezifikation, die dabei hilft, die Schwierigkeiten bei der Datenintegration zu mildern. CIM bietet einen definierten Standard für die einfache Kommunikation zwischen verschiedenen Datenformaten. Als Open-Source-Projekt im Rahmen der Joint Development Foundation (unter der Linux Foundation) heißen wir alle Mitwirkenden willkommen.

Warum anwendungsspezifische Datenmodelle scheitern

Das Kernproblem, das CIM angeht, ist nicht, dass eine einzelne Anwendung ein schlechtes Datenmodell hat. Die meisten sind innerhalb ihrer eigenen Grenzen vollkommen vernünftig. Das Problem ist die kombinatorische Explosion, die entsteht, wenn man viele davon verbindet.

Betrachten Sie einen typischen Enterprise-Stack: ein CRM, ein ERP, eine Marketing-Automatisierungsplattform, ein Support-Desk, ein Data Warehouse und eine Handvoll branchenspezifischer SaaS-Tools. Wenn jedes System seine eigene Vorstellung von „Kunde“, „Konto“, „Bestellung“ und „Produkt“ hat, dann erfordert jedes Systempaar, das Daten austauschen muss, eine eigene Zuordnung. Die Anzahl der Integrationen wächst etwa quadratisch zur Anzahl der Systeme, und jede Zuordnung ist ein kleines, undokumentiertes, herrenloses Stück Logik, das jemand für immer pflegen muss.

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

Die Symptome sind jedem bekannt, der eine Integrationspraxis geleitet hat:

• Semantische Drift. „Kunde“ im CRM bedeutet eine Abrechnungseinheit; im Support-Desk bedeutet es eine Person, die Tickets einreicht. Das gleiche Wort, zwei Bedeutungen, stillschweigend in Einklang gebracht durch eine Zuordnung, an deren Erstellung sich niemand mehr erinnert.
• Brüchige Pipelines. Ein Anbieter benennt ein Feld um oder ändert ein Enum, und ein ETL-Job schlägt um 2 Uhr morgens fehl, weil die Zuordnung fest auf die alte Struktur codiert war.
• Doppelter Aufwand. Zwei Teams erstellen unabhängig voneinander nahezu identische Übersetzungen zwischen denselben zwei Systemen, da es keinen gemeinsamen Referenzpunkt gibt.
• Vendor-Lock-in durch Daten. Die Migration von einer Plattform ist teuer, nicht wegen der Software, sondern wegen der akkumulierten Übersetzungslogik, die an deren Schema gebunden ist.

Ein gemeinsames, anwendungsunabhängiges Modell bekämpft die Grundursache: Anstelle von N-zu-N-Zuordnungen bildet jedes System einmal ein gemeinsames Modell ab, und dieses gemeinsame Modell trägt die Bedeutung.

Was „anwendungsunabhängig“ eigentlich bedeutet

Es ist wichtig, bei der Designphilosophie präzise zu sein, da „agnostisch“ oft vage verwendet wird.

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

Ein anwendungsunabhängiges Modell gehört nicht dem Produkt eines einzelnen Anbieters und ist auch nicht für dieses optimiert. Es beschreibt Geschäftskonzepte in Begriffen, die für einen Fachexperten erkennbar wären – ein Kunde, eine Bestellung, ein Produkt, ein Standort – und nicht in Begriffen, die die internen Tabellen einer bestimmten Anwendung widerspiegeln. Diese Neutralität macht es zu einem nützlichen Hub: Kein Teilnehmer muss die Weltanschauung eines Konkurrenten übernehmen, um interoperabel zu sein.

Dies ist derselbe architektonische Instinkt, der auch anderen neutralen Austauschstandards zugrunde liegt. So wie das Resource Description Framework (RDF) und schema.org dem Web ein gemeinsames Vokabular zur Beschreibung von Dingen geben und so wie EDI und später UBL (Universal Business Language, ein OASIS-Standard) Lieferketten ein gemeinsames Format für Transaktionen gaben, zielt CIM darauf ab, Unternehmensanwendungen ein gemeinsames Vokabular für ihre Kerngeschäftseinheiten zu geben. Der Unterschied liegt im Umfang und in der Modernität: CIM zielt auf die vernetzte, API-gesteuerte Cloud- und On-Premises-Welt ab, statt auf den Batch-Dateiaustausch.

Ein hilfreiches mentales Modell ist das Muster des kanonischen Datenmodells aus der Unternehmensintegration, das in Gregor Hohpes und Bobby Woolfs Enterprise Integration Patterns populär wurde. CIM ist faktisch ein kollaborativ gepflegtes kanonisches Modell – der „Hub“ in einer Hub-and-Spoke-Integrationstopologie –, das jedoch offen, versioniert und organisationsübergreifend geteilt wird, anstatt privat innerhalb eines Unternehmens entwickelt zu werden.

Wie CIM organisiert ist: Themenbereiche und Domänen

Kollaborativ definierte Inhalte sind in Domänen oder Themenbereichen organisiert. Jeder Themenbereich repräsentiert ein wichtiges Geschäftskonzept. Die CIM-Designs sind für jede Domäne in mehreren Formaten verfügbar, einschließlich Beispieldiagrammen. Die Anzahl und der Umfang der Themenbereiche werden mit dem Konsortium und den Beiträgen wachsen.

In der Praxis bedeutet dies, dass Sie CIM als eine Bibliothek verwandter Modelle und nicht als ein einzelnes monolithisches Schema betrachten sollten. Typische Themenbereiche konzentrieren sich auf erkennbare Geschäftsbelange – zum Beispiel Parteien und Konten, Produkte und Kataloge, Bestellungen und Transaktionen sowie die Beziehungen, die sie miteinander verbinden. Da jeder Bereich mit Diagrammen und maschinenlesbaren Definitionen veröffentlicht wird, können verschiedene Teams unterschiedliche Bereiche zu unterschiedlichen Zeiten übernehmen, ohne auf die Fertigstellung des gesamten Modells warten zu müssen.

Aus dieser Struktur ergeben sich einige praktische Implikationen:

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

• Inkrementelle Einführung. Sie müssen nicht Ihr gesamtes Unternehmen am ersten Tag auf CIM abbilden. Beginnen Sie mit dem Themenbereich, der am meisten schmerzt – normalerweise der Kunden- oder Bestelldomäne – und erweitern Sie diesen.
• Erweitern statt verzweigen. Wenn CIM ein Konzept vermissen lässt, das Sie benötigen, ist das offene Modell für Erweiterungen konzipiert. Es ist vorzuziehen, eine Erweiterung zurückzugeben, als einen privaten Fork zu pflegen, da ein Fork driftet und den Interoperabilitätsvorteil verliert.
• Behandeln Sie Diagramme als Dokumentation, nicht als Quelle der Wahrheit. Die Beispieldiagramme sind für Menschen; die maschinenlesbaren Definitionen sind das, was Ihre Werkzeuge konsumieren sollten.

CIM in der Integrationslandschaft: So entscheiden Sie

CIM ist eine von mehreren Optionen zur Beherrschung der Integrationskomplexität. Um eine gute Wahl treffen zu können, muss das Werkzeug auf das Problem abgestimmt sein. In der folgenden Tabelle werden die wichtigsten Ansätze gegenübergestellt, die ein Unternehmensdatenarchitekt normalerweise abwägt.

Ansatz	Was es ist	Am besten, wenn	Hauptkompromiss
Punkt-zu-Punkt-Mapping	Benutzerdefinierter Code, der direkt zwischen zwei Systemen übersetzt	Nur zwei Systeme, stabile Schemata, kurzer Zeithorizont	Skaliert nicht; N-zu-N-Explosion; fragil
Kanonisches Modell (z. B. CIM)	Ein gemeinsames, neutrales Modell, auf das jedes System einmal mappt	Viele Systeme, herstellerübergreifend, langlebige Integration	Vorab-Modellierungsaufwand; Governance erforderlich
Anbieter-iPaaS-Konnektoren	Vorgefertigte Konnektoren einer Integrationsplattform	Gängige SaaS-Paare, Geschwindigkeit vor Kontrolle	Konnektorspezifische Semantik; potenzieller Lock-in
Industrielle Austauschstandards (EDI, UBL, HL7 usw.)	Domänenspezifische Nachrichtenformate	Regulierte oder etablierte Branchen	Enger Anwendungsbereich; oft stapelorientiert
Datenvirtualisierung / Föderation	Quellenübergreifende Abfrage ohne Zentralisierung	Analytics, überwiegend lesender Zugriff	Löst semantische Konflikte nicht von selbst

Die Entscheidungsheuristik ist unkompliziert: Wenn Sie mehr als eine Handvoll Systeme haben, die sich über die Bedeutung gemeinsamer Entitäten einigen müssen, und diese Systeme von verschiedenen Anbietern stammen, rentiert sich ein kanonisches Modell. Wenn Sie zwei Systeme haben und nicht vorhaben, weitere hinzuzufügen, ist Punkt-zu-Punkt in Ordnung. Wenn Ihr Bedarf rein analytisch und schreibgeschützt ist, reicht eine Föderation möglicherweise aus – beachten Sie jedoch, dass die Föderation das semantische Problem verschiebt, anstatt es zu lösen.

CIM ist eine Ergänzung und kein Ersatz für die umliegenden Tools. Eine ETL- oder ELT-Pipeline (erstellt mit etwas wie Apache Airflow, dbt oder einer kommerziellen Plattform) erledigt immer noch den Datentransport; CIM definiert, was die Daten bedeuten, sobald sie eintreffen. Ein Message-Broker wie Apache Kafka übernimmt immer noch den Transport; CIM definiert die Form der Events. Das Modell ist der Vertrag; die Werkzeuge sind die Installation.

Leserfavorit: Airbyte — Open-Source-ELT mit einer Managed-Cloud-Option.

Governance, Lizenzierung und warum die Stiftung wichtig ist

CIM ist Open Source als Teil der Joint Development Foundation, die unter der Linux Foundation operiert. Dies ist kein triviales Detail – es ist zentral dafür, warum ein Unternehmen sicher auf CIM aufbauen kann.

Die Linux Foundation ist ein etabliertes, neutrales Zuhause für kollaborative Open-Source-Projekte, und die Joint Development Foundation bietet eine schlanke Rechtsstruktur für die gemeinsame Entwicklung von Standards und Spezifikationen. CIM dort zu hosten bedeutet:

• Neutrale Verwaltung. Kein einzelner Anbieter kontrolliert das Modell, daher bedeutet die Übernahme nicht, die Roadmap eines Mitbewerbers zu übernehmen.
• Offene Mitwirkung. Jeder – Anbieter, Unternehmen, einzelne Mitwirkende – kann Änderungen vorschlagen, und der Prozess ist transparent.
• Vorhersehbare Lizenzierung. Von der Foundation gehostete Spezifikationen enthalten in der Regel Bedingungen, die für eine breite, lizenzgebührenfreie Übernahme konzipiert sind, was für Rechts- und Beschaffungsteams, die einen Standard bewerten, von enormer Bedeutung ist.

Für einen Architekten, der intern argumentiert, ist diese Governance-Geschichte oft genauso wichtig wie der technische Inhalt. „Es ist ein offener Standard unter der Linux Foundation“ beantwortet die Fragen, die die Einführung von Standards oft verhindern: Wer kontrolliert ihn? Was passiert, wenn ein Anbieter aussteigt? Können wir unsere Erweiterungen beisteuern?

Erste Schritte: Ein praktischer Einführungsweg

Die Einführung eines gemeinsamen Modells ist ebenso sehr eine organisatorische wie eine technische Aufgabe. Ein pragmatischer Ablauf sieht so aus:

1. Inventarisieren Sie Ihre gemeinsam genutzten Entitäten. Identifizieren Sie die Geschäftskonzepte, die in mehr als einem System vorkommen – normalerweise Kunde, Produkt, Bestellung und Standort. Das sind Ihre Kandidaten.
2. Wählen Sie einen Themenbereich und eine Integration. Wählen Sie die Integration mit dem höchsten Leidensdruck und dem geringsten Risiko (lowest blast radius), um das Modell zu beweisen. Eine einzelne Reporting-Pipeline oder das Onboarding einer neuen Anwendung ist ideal.
3. Mappen Sie jedes System einmal auf CIM. Erstellen Sie die Übersetzung von jedem Quellsystem zur CIM-Darstellung und von CIM zu jedem Ziel. Widerstehen Sie dem Drang, direkt von System zu System zu mappen.
4. Dokumentieren Sie Ihre Erweiterungen. Wenn CIM ein Konzept nicht abdeckt, halten Sie die Erweiterung explizit fest und erwägen Sie, sie zurückzugeben.
5. Legen Sie die Verantwortlichkeit fest. Ein kanonisches Modell ohne Verwalter verfällt. Weisen Sie einem Team oder einer Rolle die Verantwortung für die Mappings und die Verfolgung von Upstream-Änderungen zu.
6. Versionieren und testen. Behandeln Sie das Modell und seine Mappings als versionierte Artefakte mit Tests, genau wie Sie es mit Anwendungscode tun würden.

Der häufigste Fehler besteht darin, CIM als einmalige Modellierungsübung und nicht als lebendigen Vertrag zu behandeln. Die erfolgreichen Organisationen behandeln das Modell so, wie sie eine API behandeln: versioniert, getestet, mit klarer Ownership und bewusst weiterentwickelt.

Partner, die zu CIM beitragen

CIM ist eine Konsortialleistung, und sein Wert wächst mit der Beteiligung. Partner tragen Inhalte zu Themenbereichen bei, prüfen Vorschläge und helfen dabei, die Richtung des Modells zu gestalten. Da die Arbeit offen ist, sind Beiträge nicht auf große Anbieter beschränkt – Unternehmen mit echten Integrationsproblemen und einzelne Praktiker mit Fachkenntnissen sind gleichermaßen willkommen.

Nehmen Sie Kontakt auf

Sind Sie daran interessiert, der CIM-Initiative beizutreten? Großartig! Für weitere Informationen können Sie uns gerne eine E-Mail senden. E-Mail senden.

Häufig gestellte Fragen

Was ist das Cloud Information Model (CIM)?

CIM ist ein anwendungsunabhängiges Open-Source-Datenmodell, das ein gemeinsames, auf Standards basierendes Vokabular für die Geschäftskonzepte bereitstellt, die Unternehmen über Cloud- und On-Premises-Anwendungen hinweg austauschen müssen. Es wird von einem offenen Konsortium erstellt und unter der Joint Development Foundation, einem Teil der Linux Foundation, gehostet. Sein Zweck besteht darin, den benutzerdefinierten Mapping-Code zu reduzieren, den instabile Punkt-zu-Punkt-Integrationen erfordern.

Ist CIM ein Produkt oder eine Spezifikation?

CIM ist eine Spezifikation – ein Modell und eine Reihe von Definitionen – und kein ausführbares Produkt. Es definiert die Bedeutung und Struktur gemeinsamer Entitäten; Sie wählen weiterhin Ihre eigenen ETL/ELT-Tools, Message-Broker und Speicher. Betrachten Sie es als den Vertrag, den Ihre Integrations-Infrastruktur implementiert, und nicht als die Infrastruktur selbst.

Wie unterscheidet sich CIM von der Integrationsplattform eines Anbieters?

Eine Integrationsplattform (ein iPaaS oder eine Connector-Bibliothek) verschiebt Daten und liefert oft vorgefertigte Connectors aus, aber diese Connectors kodieren anbieterspezifische Semantik. CIM ist neutral und anbieterunabhängig, sodass Sie nicht an das Weltbild einer einzigen Plattform gebunden sind. Die beiden ergänzen sich: Sie können CIM als kanonisches Modell innerhalb jeder Integrationsplattform verwenden.

Was sind Themenbereiche (Subject Areas) in CIM?

Themenbereiche (auch Domänen genannt) sind die Organisationseinheiten des Modells, die jeweils ein wichtiges Geschäftskonzept wie Kunden, Produkte oder Bestellungen darstellen. Entwürfe werden in mehreren Formaten veröffentlicht, einschließlich Beispieldiagrammen, und es wird erwartet, dass die Anzahl der Themenbereiche wächst, wenn das Konsortium und die Community mehr Inhalte beisteuern.

Können wir CIM erweitern, wenn es unsere Konzepte nicht abdeckt?

Ja. CIM ist darauf ausgelegt, erweitert zu werden, und da es Open Source unter einer neutralen Stiftung ist, können Sie im Rahmen des Beitragsprozesses Ergänzungen vorschlagen. Das gemeinsame Modell zu erweitern und die Änderungen zurückzugeben, ist der Beibehaltung eines privaten Forks deutlich vorzuziehen, der mit der Zeit divergiert und den Interoperabilitätsvorteil einbüßt, der die Einführung von CIM überhaupt motiviert hat.

Wer sollte CIM einführen?

Am wertvollsten ist es für Unternehmen, die viele Anwendungen verschiedener Anbieter betreiben, die sich auf die Bedeutung gemeinsamer Entitäten einigen müssen – die klassische Situation für Enterprise-Datenarchitekten und Integrationsingenieure. Auch Anwendungs- und Plattformanbieter profitieren, indem sie ihre Schemata an einem neutralen Modell ausrichten, was die Integration ihrer Produkte für Kunden erleichtert. Wenn Sie nur zwei stabile Systeme haben, kann ein einfacheres Punkt-zu-Punkt-Mapping ausreichend sein.

Weiterführende Literatur

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia