Die Systeme rund um Salesforce

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 3 von 6 im Kapitel Unternehmensdaten verstehen, Kapitel 4 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Die Arten von Unternehmensdaten · Weiter: Die Systemlandschaft zeichnen

Die Frage, die dieses Modul beantwortet: Was umgibt Salesforce, und welche Rolle spielt jedes System?

Das letzte Modul hat die Daten sortiert. Jetzt will ich sie irgendwo ablegen, und hier geraten wir in der Salesforce-Architektur in Schwierigkeiten. Wir kennen Salesforce, also heissen Kundendaten Account, Auftragsdaten Auftrag, Dokumente Dateien und Analytik Berichte. Aber das Unternehmen hat Salesforce nicht gekauft, um alles andere zu ersetzen, was es besitzt. Vielleicht gibt es ein ERP für Finanzen und Auftragsabwicklung, ein Data Warehouse mit Jahren an Historie, eine Integrationsplattform, einen Identitätsanbieter, Partnersysteme, eine Ereignisplattform, eine MDM-Plattform und Data 360, das mehrere davon verbindet. Die Aufgabe ist nicht, Technologien auswendig zu lernen. Sie ist zu verstehen, welche Aufgabe jedes System hat.

Beginnen Sie nicht mit dem Produktnamen

«Wir haben SAP» sagt mir nicht genug. Snowflake, MuleSoft, Tableau oder Data 360 auch nicht. Ich will wissen, was dieses System in dieser Architektur tut: welche Daten ihm gehören, was es liest, was es ändert, wer es nutzt, was von ihm abhängt, was passiert, wenn es ausfällt. Zwei Unternehmen können genau dieselben Produkte besitzen und völlig verschiedene Architekturen haben.

Also beschrifte ich Systeme nach Rolle. Vier Rollen decken das meiste ab:

• Führendes System (System of Record): wo die massgebliche Version von etwas gepflegt wird.
• Engagement-System (System of Engagement): wo Menschen die Arbeit erledigen.
• Referenzsystem (System of Reference): wo ein System Informationen holt, die es braucht, aber nicht besitzt.
• Analysesystem (System of Insight): wo Daten zusammenkommen, um zu messen, zu analysieren und vorherzusagen.

Eine Plattform kann mehrere Rollen spielen, und die Rollen unterscheiden sich je nach Daten. Salesforce kann das führende System für Kundenvorgänge sein, das Engagement-System für den Service und ein Abnehmer von Produktdaten, die dem ERP gehören. Wenn also jemand sagt «Salesforce ist unser führendes System», vervollständigen Sie den Satz: führendes System wofür?

Das ERP: Das Backoffice hat Schwerkraft

Das ERP ist das System, das Sie am häufigsten neben Salesforce finden, für Finanzen, Lagerbestand, Einkauf, Auftragsabwicklung und Fakturierung. Das Muster aus Modul 1 (Kunden und Produkte hinein, Aufträge hinaus) heisst, dass dem ERP die Produkte gehören, der Vertrieb sie aber trotzdem in Salesforce braucht. Gut: Holen Sie sie herein. Aber Daten zu kopieren überträgt nicht die Eigentümerschaft. Eine Kopie ist keine Autorität.

Meine Position: Daten, die dem ERP gehören, werden lokal gelesen und kontrolliert geschrieben. Salesforce-Benutzer bekommen die Daten dort, wo sie arbeiten, aber Salesforce darf nicht ändern, was dem ERP gehört. Und ich mache das im Schema sichtbar: Die Felder des ERP tragen ein Präfix erp_, etwa erp_Product_Number__c, damit jeder, der das Objekt liest, weiss, wem jedes Feld gehört, und beim Ändern vorsichtig ist. Das Präfix setzt nichts durch; das tun Berechtigungen, Validierung und das Integrationsmuster. Es kommuniziert eine Absicht, und es ist die sichtbar gemachte Autoritätskarte.

Das Warehouse, der Lake und das Lakehouse

Operative Systeme betreiben das Geschäft; analytische Systeme helfen, es zu verstehen. «Zeig mir meine offenen Opportunities» ist ein Salesforce-Bericht. «Zeig mir fünf Jahre Umsatz, Abwicklung, Retouren, Kundenvorgänge, Lagerbestand und Finanzen über alle Kanäle» ist ein anderes Problem.

Ihnen begegnen drei Arten analytischer Speicher. Ein Data Warehouse hält strukturierte Daten, für die Analyse aufbereitet. Ein Data Lake hält weit mehr Daten in mehr Formen, oft roh. Ein Lakehouse verbindet beides: Speicherung wie im Lake mit Analyse wie im Warehouse. Kennen Sie sie, denn sie tauchen in Landschaften auf. Aber meine Erfahrung ist, dass Lakehouses und Data Mesh in Salesforce-Projekten noch eine Nische sind. Die typische Landschaft ist CRM, ERP, ein Data Warehouse und eine Integrationsschicht, mit anderen Plattformen dort, wo das Geschäft sie wirklich braucht. Lernen Sie die Architektur; jagen Sie nicht dem Vokabular hinterher.

Die Analytik lebt dort, wo die Daten leben

Das ist eine meiner festesten Positionen: Wo die Analytik lebt, folgt daraus, wo die Daten leben. Braucht der Bericht nur Accounts, Opportunities und das Vertriebsteam, ist alles auf dem Core: Standardberichte und Dashboards. Dann will das Geschäft ERP-Rechnungen hinzufügen. Dann die Produktkosten. Dann fünf Jahre Aufträge aus dem Data Warehouse. Dann die Website-Aktivität. Irgendwann ergibt es keinen Sinn mehr, all das ins operative CRM zu ziehen, nur um darüber zu berichten. Sobald andere Datenspeicher beteiligt sind, wird eine Analyseplattform nötig: Tableau (einschliesslich Tableau Next, gebaut auf Data 360) oder CRM Analytics, wo es bereits im Einsatz ist. Unverzichtbar ist sie, wenn Salesforce-Daten mit einem Data Warehouse zusammengeführt werden. Die Anforderung ist nicht nur komplizierter geworden; die Landschaft hat geändert, wo die Frage beantwortet werden sollte. Also beginne ich nie mit «Welches Analysewerkzeug?» Ich beginne mit Wo sind die Daten?

Dasselbe frage ich CTA-Kandidat:innen: «Welches meiner Diagramme löst das wunderbar? Die Landschaft.» Wenn Sie ganz auf dem Core sind, nutzen Sie Berichte. Wenn Sie Daten in anderen Speichern haben, will ich eine Analyseplattform sehen. Die Landschaft beantwortet die Berichtsfrage, bevor irgendjemand einen Berichtsgenerator öffnet. (Die Produktnamen ändern sich; das Kapitel zu Data 360 behandelt, wo die Analytik von Salesforce heute steht.)

MDM: Wer ist dieser Kunde wirklich?

Nehmen Sie jetzt an, Kundeninformationen leben in Salesforce, dem ERP, dem E-Commerce, einer Treueplattform und einem Partnersystem, und jedes glaubt zu wissen, wer der Kunde ist. Hier kommt das Stammdatenmanagement (MDM) ins Spiel: die massgebliche Identität wichtiger Daten über Systeme hinweg festlegen und steuern. Aber MDM ist nicht «eine Master-Kundendatenbank». Die schweren Fragen sind, welches System den Kunden anlegen darf, welche Attribute welchem System gehören, wie Duplikate gefunden werden, welche Kennung überlebt und was passiert, wenn Systeme sich widersprechen. Darum geht es in Kapitel 6. Hier erkennen Sie die Rolle: Wenn es eine MDM-Plattform gibt, ist sie vielleicht eine entscheidende Autorität zwischen Salesforce und dem Rest des Unternehmens.

Die Integrationsschicht und die Ereignisse

Verbinden Sie jedes System direkt mit jedem anderen, und die Landschaft wird schnell zu Spaghetti. Deshalb haben Unternehmen eine Integrationsschicht: einen ESB (Enterprise Service Bus) oder ein iPaaS (Integration Platform as a Service). MuleSoft ist das, was Ihnen in Salesforce-Landschaften am häufigsten begegnet. Es vermittelt, sodass nicht jede Anwendung jede andere verstehen muss.

Aber ein MuleSoft-Kasten in der Mitte macht die Integration nicht gut. Ich will trotzdem wissen, was hindurchgeht und was nicht, wer die Daten transformiert, wem der Vertrag gehört, was passiert, wenn das Ziel ausfällt, ob es synchron oder asynchron ist und woran wir erkennen, dass eine Nachricht erfolgreich war. Der Kurs Integration Architect geht in die Tiefe; hier erkennen Sie sie als eigene Rolle.

Und nicht jede Integration ist System A, das System B aufruft. Manchmal passiert etwas (ein Auftrag wird angelegt, eine Lieferung ändert ihren Status, ein Lastwagen fährt in eine Region ein), ein Ereignis wird veröffentlicht, und wer interessiert ist, reagiert. Auch Ereignisse in Bewegung haben Infrastruktur: die eigenen Ereignisfunktionen von Salesforce, einen Ereignisbus des Unternehmens, anderes Messaging. Zeichnen Sie die Mechanismen, die die Daten tragen, nicht nur die Datenbanken.

Das System, das in der Entwicklung vergessen wird: Identität

Es gibt einen Kasten, den ich immer in der Landschaft haben will und an den man in der Entwicklung selten denkt: den Identitätsanbieter. In der Entwicklung meldet man sich direkt mit Benutzername und Passwort in den Sandboxes an, also ist Identität während des Bauens unsichtbar. Dann kommen UAT oder Produktion, und plötzlich gibt es das Single Sign-on des Unternehmens für die Belegschaft, vielleicht einen zweiten Anbieter für Partner, Social Sign-on für Kunden. Identität war immer Teil der Architektur. Das Entwicklungsteam hat sie nur noch nicht gesehen.

Ein Identitätsanbieter (IdP) ist das System, das einen Benutzer authentifiziert und die Identität festlegt, der Salesforce vertraut. Er gehört vom ersten Tag an in die Landschaft, auch wenn er erst später in der Release-Pipeline konfiguriert wird, denn wer hereinkommt, entscheidet, wer an die Daten kommt.

Es gibt auch einen praktischen Haken: Die Identitätskonfiguration ist bereitstellbar, aber nicht vollständig. SAML-Single-Sign-on-Konfiguration und Authentifizierungsanbieter sind Metadata-API-Typen, also wandern sie durch die Pipeline (SamlSsoConfig (opens in a new tab), auf Englisch). Aber Consumer Secrets von Authentifizierungsanbietern werden in Antworten der Metadata API nicht mehr zurückgegeben (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), auf Englisch), und Zertifikate unterscheiden sich meist je Umgebung. Planen Sie für die Teile, die wandern, und die, die es nicht tun.

Click to enlarge

Lesen Sie die Landschaft als Rollen, nicht als Logos: was jedes System besitzt, liest oder entscheidet.

Wo sitzt Data 360?

Data 360 wirft eine schöne Zeichenfrage auf. Ich setze es rechts, unter den ESB oder MuleSoft. Der Grund sind seine Verbindungen: Benutzer verbinden sich nie direkt damit, während es sich direkt mit vielen Backend-Systemen verbindet. Es gehört also zu den Datenleitungen, wo diese Linien kurz bleiben, nicht hinaus zu den Benutzern. Zeichnen Sie es wie einen weiteren Bildschirm, an dem sich Menschen anmelden, und Sie erzählen die falsche Geschichte.

Administration und Datenteams öffnen durchaus die Bildschirme von Data 360, aber diese Bildschirme sind in der Org, auf dem Core. Der Tenant, der die Arbeit erledigt, seine Daten und seine Verarbeitung, läuft ausserhalb des Core. Deshalb nenne ich es nahe am Core (Near-Core): auf dem Core verwaltet, ausserhalb des Core gehostet (Modul 1 erklärt die Begriffe). Die Zeichnung folgt dem Tenant: Er sitzt bei den Datenleitungen, mit einer Linie zurück zur Org, die ihn verwaltet.

Was es tut, umfasst in den Worten von Salesforce Zero Copy: eine Technologie zur Datenföderation, mit der ein Unternehmen auf Daten zugreifen und sie abfragen kann, ohne sie zu kopieren (Zero Copy (opens in a new tab), auf Englisch). Die Funktionen und Konnektoren ändern sich schnell, also behandelt das Kapitel zu Data 360 sie richtig, statt dieses Modul zu einer Produkttour zu machen.

Lesen Sie die Landschaft als Verantwortlichkeiten

Wenn Sie eine Landschaft betrachten, lesen Sie nicht die Logos; lesen Sie die Verantwortlichkeiten. Das ERP: Was gehört ihm? Das Data Warehouse: Welche Fragen beantwortet es? Die Integrationsplattform: Was bewegt sie? Der IdP: Wen authentifiziert er? MDM: Welche Identität steuert es? Data 360: Was verbindet es, und wofür? Salesforce: Wofür ist es tatsächlich verantwortlich? Sobald Sie das beantworten können, bedeuten die Kästen etwas, und die Pfeile dazwischen werden viel interessanter. Als Nächstes zeichnen wir sie bewusst.

Was Architekt:innen hier entscheiden

• Welche Rolle jedes System spielt, über seinen Produktnamen hinaus.
• Welches System für jeden wichtigen Datenbestand massgeblich ist und wo Salesforce nur eine lokale Kopie hält.
• Ob Daten, die dem ERP gehören, in Salesforce mit kontrollierten Schreibvorgängen verfügbar sind und wie diese Eigentümerschaft im Schema sichtbar wird.
• Wohin die Analytik gehört, je nachdem, wo die Daten leben.
• Wo Identität, Integration, Ereignisse und Stammdatenautorität in der Landschaft sitzen.

Eine Landschaft mit zehn Rechtecken ist keine Architektur; sie ist ein Inventar. Architektur beginnt, wenn Sie auf jedes Rechteck zeigen und sagen können, warum es da ist, was ihm gehört, wer es nutzt, was Salesforce von ihm braucht und was bricht, wenn Sie seine Rolle missverstehen.

Weiterlesen

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Versionshinweise Winter ‘23, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (Produktseite, auf Englisch), geprüft am 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab) (auf Englisch), martinfowler.com, 2019.