Cloud Information Model

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

Wichtige Erkenntnisse

• CIM ist ein gemeinsames, offenes Datenmodell, kein Produkt. Es definiert gemeinsame Geschäftskonzepte und ihre Beziehungen, sodass verschiedene Anwendungen Daten ohne maßgeschneiderte, einmalige Zuordnungen austauschen können.
• Es wird als offener Standard verwaltet. CIM ist Open Source unter der Joint Development Foundation, einem Teil der Linux Foundation, und heißt Mitwirkende von Anbietern, Unternehmen und der breiteren Community willkommen.
• Der Inhalt ist in Themenbereichen (Domänen) organisiert. Jede Domäne stellt ein wichtiges Geschäftskonzept dar und wird in mehreren Formaten, einschließlich Diagrammen, veröffentlicht, sodass Architekten und Ingenieure es schrittweise übernehmen können.
• Der Kernwert besteht darin, die Sprödigkeit der Integration zu reduzieren. Ein kanonisches Modell ersetzt Punkt-zu-Punkt-Übersetzungscode durch ein stabiles Ziel, auf das und von dem viele Systeme abbilden können.
• Die Einführung ist eine Designentscheidung, kein einfacher Umschalter. Sie entscheiden, welche Domänen übernommen werden sollen, wie Sie Ihre Quellsysteme zuordnen und wie Sie Erweiterungen im Laufe der Zeit steuern.

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 Erfahrungen ü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-Premise-Anwendungen. Jede verfügt über ein eigenes Datenmodell, was Entwickler dazu zwingt, benutzerdefinierten Code zu erstellen, zu testen und zu verwalten, der zum Zuordnen und Übersetzen 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 dazu beiträgt, die Schwierigkeiten bei der Integration von Daten 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.

Das Problem, das CIM angeht, ist struktureller und nicht zufälliger Natur. Wenn jedes System seinen eigenen Dialekt spricht – eines nennt einen Kunden „Kontakt“, ein anderes „Partei“, ein drittes „Konto“ –, pflegen Integrationsteams letztendlich ein wachsendes Netz paarweiser Zuordnungen.

Jede neue Anwendung vervielfacht die Anzahl der erforderlichen Übersetzungen, und jede Schemaänderung in einem beliebigen System kann Auswirkungen nach außen haben und nachgelagerte Pipelines unterbrechen. Ein kanonisches Modell verändert die Form dieses Problems: Anstatt dass N Systeme aufeinander abgebildet werden, wird jedes System einmal einem gemeinsamen Vokabular zugeordnet.

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

Warum die Punkt-zu-Punkt-Integration scheitert

Es ist hilfreich, konkret über die Fehlermodi zu sprechen, die ein gemeinsames Modell motivieren.

• Kombinatorisches Wachstum. Bei Punkt-zu-Punkt-Zuordnungen wächst die Anzahl der Übersetzungspfade ungefähr mit dem Quadrat der Anzahl der Systeme. Das Hinzufügen einer zehnten Anwendung ist weitaus teurer als das Hinzufügen der zweiten.
• Semantische Drift. Zwei Teams können beide „den Kunden abbilden“ und sich dennoch darüber nicht einig sein, ob ein Kunde eine Person, eine Organisation oder eine Abrechnungsbeziehung ist. Die Daten fließen, aber die Bedeutung divergiert.
• Brüchiges Änderungsmanagement. Eine Feldumbenennung oder ein neues erforderliches Attribut in einem Quellsystem erzwingt Änderungen bei jedem Verbraucher, der darauf zugreift.
• Duplizierte Logik. Validierungs-, Deduplizierungs- und Identitätsauflösungsregeln werden in jeder Integration neu implementiert, anstatt einmal definiert zu werden.
• Druck durch Anbieterbindung (Vendor Lock-in). Wenn die Integrationslogik mit dem Schema eines bestimmten Anbieters verknüpft ist, wird der Wechsel oder das Hinzufügen von Anbietern zu einem Projekt zur Neuplattformierung.

Ein kanonisches Modell wie CIM macht die Zuordnungsarbeit nicht überflüssig – jedes Quellsystem benötigt weiterhin eine Zuordnung zum Modell. Was es eliminiert, ist die Vervielfachung dieser Arbeit. Sie erstellen eine Zuordnung pro System zum gemeinsamen Modell, und das Modell selbst stellt den stabilen Vertrag zwischen ihnen bereit.

Wie CIM organisiert ist: Themenbereiche

Kollaborativ definierte Inhalte werden 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.

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

Diese domänenorientierte Struktur ist wichtig für die Einführung. Man benötigt selten das gesamte Modell auf einmal. Ein typisches Unternehmen beginnt mit den Domänen, die seine problematischsten Integrationen betreffen, beweist den Ansatz und expandiert dann. Gemeinsame Ausgangspunkte sind in der Regel die Konzepte, die in fast jedem System vorkommen:

• Partei / Kunde – die Personen und Organisationen, mit denen Sie Geschäfte machen, und die Rollen, die sie spielen.
• Produkt – was Sie verkaufen, anbieten oder verwalten, einschließlich Katalogen und Klassifizierungen.
• Konto und Beziehung – wie Parteien mit Produkten, Verträgen und untereinander in Beziehung stehen.
• Interaktion und Aktivität – die Ereignisse, Transaktionen und Engagements, die das oben Genannte verbinden.

Da jeder Themenbereich mit Diagrammen und mehreren Darstellungsformaten veröffentlicht wird, können Architekten das konzeptionelle Modell überprüfen, Ingenieure eine maschinenlesbare Form nutzen und Geschäftsbeteiligte validieren, ob die Konzepte mit der Realität übereinstimmen. Dieser Multiformat-Ansatz ist eine bewusste Designentscheidung: Ein Modell, das nur Ingenieure lesen können, neigt dazu, von der geschäftlichen Bedeutung abzuweichen.

Wie CIM im Vergleich zu anderen Ansätzen abschneidet

CIM ist eine von mehreren Optionen zur Erreichung der Interoperabilität. Eine gute Wahl zu treffen bedeutet, die Kompromisse zu verstehen.

Ansatz	Was es ist	Stärken	Trade-offs
Punkt-zu-Punkt-Mapping	Direkte Übersetzungen zwischen jedem Systempaar	Einfach für zwei Systeme; keine gemeinsame Governance erforderlich	Wächst kombinatorisch; fragil; duplizierte Logik
Kanonisches Modell (CIM-Stil)	Ein gemeinsames, anwendungsunabhängiges Vokabular, auf das jedes System mappt	Linearer Mapping-Aufwand; stabiler Vertrag; projektübergreifend wiederverwendbar	Erfordert Governance und Einigung; Mapping pro System weiterhin erforderlich
Branchendatenstandards	Vertikale Standards für einen bestimmten Sektor (z. B. Gesundheitswesen, Finanzen)	Tiefe Domainabdeckung; regulatorische Angleichung	Enger Anwendungsbereich; deckt möglicherweise keine branchenübergreifenden Unternehmenskonzepte ab
Anbieterdatenmodelle	Das native Schema einer Plattform, das als Integrations-Hub bereitgestellt wird	Enge Tooling-Integration; schnell innerhalb des Ökosystems eines Anbieters	Lock-in-Risiko; andere Anbieter müssen sich an das Modell einer Partei anpassen
API-first / Schema-on-read	Pro API definierte Verträge; Bedeutung wird zum Zeitpunkt des Verbrauchs aufgelöst	Flexibel; schneller Start	Semantische Konsistenz hängt von der Disziplin ab; schwieriger in großem Maßstab zu steuern

Der praktische Leitfaden: Verwenden Sie ein kanonisches Modell, wenn Sie viele Systeme, domänenübergreifende Konzepte und eine langlebige Integrationslandschaft haben. Verwenden Sie Punkt-zu-Punkt, wenn der Umfang tatsächlich nur zwei Systeme umfasst und kurzzeitig ist. Industriestandards und CIM ergänzen sich – ein vertikaler Standard kann eine Domäne informieren, während CIM das übergreifende Unternehmensvokabular bereitstellt.

Wie man CIM in der Praxis einführt

Die Einführung ist eine Abfolge bewusster Entscheidungen und keine einzelne Migration. Ein praktikables Muster sieht so aus:

1. Wählen Sie eine problematische, gut abgegrenzte Integration. Wählen Sie eine Domäne, in der der Mapping-Schmerz real ist und der Umfang klein genug ist, um schnell einen Mehrwert zu beweisen.
2. Inventarisieren Sie die Quellsysteme und ihre Schemata. Dokumentieren Sie, wie jedes System die Konzepte in Ihrem gewählten Themenbereich (Subject Area) bezeichnet und wo sie voneinander abweichen.
3. Mappen Sie jedes System auf die CIM-Domäne. Erstellen Sie pro System ein Mapping auf das gemeinsame Modell. Behandeln Sie diese Mappings als versionierte Artefakte, nicht als Wegwerfskripte.
4. Definieren Sie Ihre Erweiterungsrichtlinie im Voraus. Entscheiden Sie, wie Sie mit Konzepten umgehen, die CIM noch nicht abdeckt – Erweiterungen sollten dokumentiert, konsistent benannt und dem Konsortium vorgeschlagen werden, sofern sie allgemein nützlich sind.
5. Etablieren Sie eine Governance. Weisen Sie Verantwortlichkeiten für die Mappings, einen Review-Prozess für Änderungen und einen Rhythmus für die Synchronisierung mit Upstream-CIM-Updates zu.
6. Erweitern Sie Domäne für Domäne. Nutzen Sie die Mapping-Muster und die Governance der ersten Domäne wieder, um die Kosten für die nächste zu senken.

Zwei Vorbehalte sollten deutlich benannt werden. Erstens fügt ein kanonisches Modell eine Ebene hinzu – es ist nicht kostenlos, und der Nutzen ergibt sich aus der Wiederverwendung über viele Integrationen hinweg, nicht aus einer einzelnen. Zweitens liegt die eigentliche Arbeit im Mapping; das Modell gibt Ihnen ein stabiles Ziel vor, aber jemand muss immer noch entscheiden, wie jedes Quellfeld diesem entspricht, und diese Entscheidung profitiert von fachlichem Input, nicht nur von Engineering.

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

Governance, Lizenzierung und Mitwirken

CIM ist als Teil der Joint Development Foundation Open Source, die unter der Linux Foundation operiert. Diese Struktur ist für Unternehmen, die es evaluieren, wichtig: Die Linux Foundation ist ein etabliertes Zuhause für kollaborative, herstellerneutrale Open-Source-Projekte, und die Joint Development Foundation bietet einen rechtlichen Rahmen, der speziell für die Entwicklung und den Betrieb von Standards und Spezifikationsprojekten konzipiert ist.

Für einen Unternehmensdatenarchitekten ergeben sich aus diesem Governance-Modell folgende praktische Auswirkungen:

• Anbieterneutralität. Kein einzelner Anbieter kontrolliert die Spezifikation, was das Risiko verringert, dass das Modell so gestaltet wird, dass es eine bestimmte Plattform bevorzugt.
• Offene Mitwirkung. Jeder kann Änderungen vorschlagen, was bedeutet, dass sich das Modell weiterentwickeln kann, um reale Integrationsbedürfnisse widerzuspiegeln, statt einer einzelnen Roadmap zu folgen.
• Spezifikationsorientierter Prozess. Das Modell der Joint Development Foundation ist auf die Erstellung und Pflege von Spezifikationen ausgerichtet, was mit der Art und Weise übereinstimmt, wie Standards in Beschaffungs- und Architekturprüfungen übernommen und referenziert werden.

Beiträge sind erwünscht und allen offen. Beiträge nehmen typischerweise die Form neuer oder verfeinerter Themenbereiche, Korrekturen und Klarstellungen, Beispieldiagrammen und Feedback aus realen Integrationsprojekten an. Die wertvollsten Beiträge kommen oft von Praktikern, die auf ein spezifisches Mapping-Problem gestoßen sind und das Konzept beschreiben können, das es löst.

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

Mitmachen

Sind Sie daran interessiert, der CIM-Initiative beizutreten? Großartig! Bitte zögern Sie nicht, uns für weitere Informationen eine E-Mail zu senden.

Neben E-Mails sind die natürlichsten Wege des Engagements, die veröffentlichten Themenbereiche für Ihre Interessendomäne zu prüfen, zu versuchen, eines Ihrer Systeme auf eine Domäne zu mappen, und die gefundenen Lücken an die Community zurückzumelden. Da die Anzahl und der Umfang der Themenbereiche mit dem Konsortium und den Beiträgen wachsen, verbessert sich das Modell proportional zu der Anzahl der realen Integrationsprobleme, die seine Nutzer einbringen.

Häufig gestellte Fragen

Was genau ist das Cloud Information Model?

CIM ist ein anwendungsunabhängiges, offenes Datenmodell, das gemeinsame Geschäftskonzepte und deren Beziehungen definiert, sodass verschiedene Anwendungen Daten über ein gemeinsames Vokabular austauschen können. Es wird von einem offenen Konsortium erstellt und als offene Spezifikation veröffentlicht. Anstatt ein Produkt zu sein, das man installiert, ist es ein Modell, auf das man seine Systeme mappt.

Für wen ist CIM gedacht?

Es richtet sich an Unternehmensdatenarchitekten, Integrations- und ETL-Ingenieure, Anwendungs- und Plattformanbieter sowie Open-Source-Mitwirkende. Jeder, der mehrere Cloud- und On-Premise-Systeme mit unterschiedlichen Schemata verbinden muss, ist ein potenzieller Nutzer. Anbieter profitieren davon, dass ein gemeinsames Modell den benutzerdefinierten Aufwand reduziert, der für die Integration in ihre Produkte erforderlich ist.

Wie wird CIM gesteuert und lizenziert?

CIM ist Open Source und Teil der Joint Development Foundation, die unter der Linux Foundation operiert. Dies bietet ein herstellerneutrales, spezifikationsorientiertes Governance-Framework. Diese Struktur soll das Modell offen für Beiträge und unabhängig von der Kontrolle eines einzelnen Anbieters halten.

Wie unterscheidet sich CIM vom nativen Datenmodell eines Anbieters?

Das native Modell eines Anbieters ist für das Produkt und Ökosystem dieses Anbieters optimiert; wenn Sie es als Ihren Integrationshub übernehmen, führt dies tendenziell zu einem Lock-in. CIM ist anwendungsagnostisch konzipiert, sodass keine einzelne Plattform das Vokabular definiert. Der Kompromiss besteht darin, dass CIM Governance und Abstimmung zwischen den Teams erfordert, während ein Anbietermodell innerhalb der Tooling-Landschaft dieses Anbieters sofort einsatzbereit ist.

Muss ich weiterhin Mappings schreiben, wenn ich CIM verwende?

Ja. Jedes Quellsystem benötigt weiterhin ein Mapping zum gemeinsamen Modell. Der Vorteil besteht darin, dass Sie ein Mapping pro System zu CIM schreiben, anstatt für jedes Systempaar eine separate Übersetzung. Dadurch wird aus dem kombinatorischen Mapping-Aufwand ein annähernd linearer Aufwand, und Sie erhalten einen stabilen Vertrag, der Änderungen in einzelnen Systemen übersteht.

Wie beginne ich mit der Einführung von CIM?

Beginnen Sie mit einer einzigen, problematischen („high-pain“), gut abgegrenzten Integration in einem Themenbereich (Subject Area). Inventarisieren Sie die Quellschemata, ordnen Sie jedes System der CIM-Domäne zu, definieren Sie eine Erweiterungs- und Governance-Richtlinie und behandeln Sie die Mappings als versionierte Artefakte. Sobald die erste Domäne ihren Wert beweist, erweitern Sie Domäne für Domäne und verwenden dabei die von Ihnen festgelegten Muster und die Governance wieder.

Weiterführende Literatur

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia