Salesforce ist ein System unter vielen
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)
Modul 1 von 6 im Kapitel Unternehmensdaten verstehen, Kapitel 4 des Kurses Data Architect. Jedes Modul steht für sich. Weiter: Die Arten von Unternehmensdaten
Die Frage, die dieses Modul beantwortet: Warum zeichnen Datenarchitekt:innen, was die Org umgibt, bevor sie die Org entwerfen?
Wenn ich CTA-Kandidat:innen unterrichte, ist die Hausaufgabe nach dem ersten Tag immer dieselbe. Lesen Sie das Szenario. Beginnen Sie die Systemlandschaft auf einem leeren Blatt. Erst dann wagen Sie einen ersten Versuch am Datenmodell. Nicht die Objekte, nicht die Integrationen im Detail: die Landschaft. Ich will sehen, was Salesforce umgibt, bevor wir entscheiden, was hineingehört.
Das ist für viele Salesforce-Fachleute ein Perspektivwechsel. Wenn Sie Ihre Laufbahn in Administration oder Entwicklung verbracht haben, ist Salesforce ganz natürlich der Mittelpunkt Ihrer Welt. Sie öffnen das Setup, erstellen Objekte, bauen Flows, schreiben Apex und integrieren andere Systeme in Salesforce. Alles scheint mit der Org zu beginnen. In der Architektur müssen wir die Kamera zurückziehen, denn in einem Unternehmen ist Salesforce ein System unter vielen, und oft gehören die Daten gar nicht ihm.
Zeichnen Sie zuerst die Landschaft
Abschnitt betitelt „Zeichnen Sie zuerst die Landschaft “Kapitel 2 hat das logische Modell gebaut, und Kapitel 3 hat gefragt, wie es auf Salesforce lebt. Jetzt mache ich das Problem grösser. Bevor ich entscheide, was Salesforce besitzen soll, will ich das Unternehmen drumherum verstehen. Welche Systeme gibt es schon? Wo werden Kunden angelegt, Produkte definiert, Aufträge gestartet, Rechnungen erzeugt? Wo lebt die Identität? Wo findet die Analytik statt, wo werden Dokumente aufbewahrt, wo liegt die Historie? Welche Systeme brauchen die Daten von Salesforce, und von welchen hängt Salesforce ab?
Diese Fragen ändern die Architektur. Also beginne ich mit einem leeren Blatt, setze Salesforce in die Mitte und zeichne alles drumherum. Modul 4 zeigt genau, wie ich es anordne. Für jetzt lautet die Lektion einfach: Entwerfen Sie die Org nicht, bevor Sie die Welt verstehen, in der sie leben muss.
Salesforce ist oft nicht das führende System
Abschnitt betitelt „Salesforce ist oft nicht das führende System “Nehmen Sie ein ganz gewöhnliches Unternehmen: Salesforce plus ein ERP, ein System für die Unternehmensressourcenplanung wie SAP oder Oracle, das Finanzen, Produkte, Lagerbestand, Einkauf und Auftragsabwicklung führt. Stellen Sie jetzt eine einfache Frage: Wo lebt der Kunde?
Es könnte Salesforce sein, das ERP oder beides, und da wird es interessant. Der Vertrieb bearbeitet Interessenten vielleicht als Accounts in Salesforce, während das ERP die offizielle Kundennummer vergibt, sobald sie zahlende Kunden werden. Produkte und Preise? Wahrscheinlich das ERP. Lagerbestand? Fast nie Salesforce. Aufträge werden vielleicht in Salesforce erfasst und im ERP abgewickelt; Rechnungen kommen aus dem ERP; der Service lebt in Salesforce; die Analytik ist zwischen Salesforce-Berichten und einem Data Warehouse aufgeteilt. Plötzlich ist unser schönes Salesforce-Datenmodell nicht das Datenmodell des Unternehmens. Es ist ein Teil davon.
Die Integration, die ich immer wieder sehe
Abschnitt betitelt „Die Integration, die ich immer wieder sehe “Die häufigste Integration, die ich sehe, geht so: Kunden, Produkte und Preise fliessen aus dem ERP in Salesforce, und Aufträge fliessen hinaus. Setzen Sie SAP, Oracle oder irgendein anderes ERP ein; die Form bleibt dieselbe. Das ERP besitzt den Golden Record für den Kunden und das Produkt, also kommen diese Flüsse von rechts in Salesforce hinein. Der Vertrieb schliesst das Geschäft in Salesforce ab, also beginnt der Auftrag dort und geht zurück ins ERP, um abgewickelt, fakturiert und verbucht zu werden.
Diese Flüsse sind nicht nur Integrationen. Sie sagen mir, wo das Unternehmen die Wahrheit vermutet.
Einbahnpfeile machen mich nervös
Abschnitt betitelt „Einbahnpfeile machen mich nervös “Wann immer ich eine Integration mit nur einem Fluss sehe, werde ich langsam besorgt. Auf der obersten Ebene zeichnet jemand einen einzigen Pfeil: Aufträge von Salesforce ans ERP. Gut. Jetzt schauen Sie genauer hin. Wie kann ich einen Auftrag ans ERP schicken, wenn ich dessen Kunden, Produkte oder Preise nicht kenne? Der Auftrag muss an einem Kunden hängen, den das ERP bereits hat, und jede Position muss eine SKU sein, die das ERP bereits verkauft. Ich kann keine Auftragsposition für ein Produkt schicken, das auf der anderen Seite nicht existiert. Bevor dieser Auftragspfeil funktionieren kann, müssen also Rückflüsse existieren, die in die andere Richtung laufen.
Das ist die Frage, die ich jedem Pfeil stelle: Wovon hängt dieser Fluss ab? Der Pfeil auf oberster Ebene, den Sie sehen, braucht meist Rückflüsse, die Sie noch nicht gezeichnet haben.
Schauen Sie noch genauer hin, und Sie finden den Rückweg. Salesforce schickt einen Auftrag. Und dann? Wurde er angenommen oder abgelehnt? Wurde er versandt, teilweise versandt, storniert? Wurde er fakturiert? Muss jemand in Salesforce das wissen? Vielleicht nicht. Aber jemand hätte fragen sollen. Wenn nichts zurückkommt, gut. Sagen Sie mir, warum.
Das Unternehmen ist nicht auf einmal entstanden
Abschnitt betitelt „Das Unternehmen ist nicht auf einmal entstanden “Landschaften werden auch deshalb kompliziert, weil niemand sie auf einmal gebaut hat. Daten sind in Wellen gekommen. Zuerst Dateien: Datensätze mit festem Format, dann Dateien mit Trennzeichen wie CSV. Dann relationale Datenbanken für operative Daten. Dann Data Warehouses, um sie für Analysen zusammenzuführen. Dann NoSQL-Datenbanken für Dokumente, Schlüssel-Wert-Paare und Graphen, die nicht sauber in Tabellen passen. Dann Data Lakes für riesige Mengen roher und halbstrukturierter Daten, und Lakehouses, die beides verbinden. Ereignisströme wie Kafka oder der Salesforce-Ereignisbus bewegen Daten in dem Moment, in dem sie entstehen, statt in nächtlichen Batches. Und jetzt Föderation, bei der Daten nicht erst an einen Ort kopiert werden müssen, bevor eine andere Plattform sie nutzen kann.
Die Technologie ist noch nicht der Punkt. Der Punkt ist: Die neue Welle lässt die alte selten verschwinden. Gehen Sie in ein grosses Unternehmen, und Sie finden alle auf einmal: relationale Datenbanken, das ERP, Salesforce, ein Data Warehouse, einen Lake, SFTP-Ablagen, APIs, Ereignisströme, die Tabelle, die jemand jeden Freitag noch per E-Mail verschickt, und das eine System, das niemand anzufassen wagt, weil die Person, die es gebaut hat, vor sechs Jahren in Rente gegangen ist. Das ist das Unternehmen, das Sie architektieren, nicht das aus der Produktbroschüre.
Verschiedene Systeme gibt es aus verschiedenen Gründen
Abschnitt betitelt „Verschiedene Systeme gibt es aus verschiedenen Gründen “Deshalb beginne ich auch nie mit «Wie bekommen wir alle Daten in Salesforce?» Warum sollte ich alle dort haben wollen? Salesforce ist vielleicht der beste Ort für Vertrieb und Service, um mit Kunden zu arbeiten. Das macht es nicht zum Finanzsystem, zum Data Warehouse des Unternehmens, zum Telemetriespeicher, zum Dokumentenarchiv oder zur Heimat jedes Klicks, jedes GPS-Messwerts und jeder historischen Transaktion, die das Unternehmen je erzeugt hat.
Kapitel 3 hat für eine Org gefragt: Wo sollten diese Daten liegen? Auf Unternehmensebene wird dieselbe Frage grösser: Manchmal besitzt Salesforce die Daten, manchmal hält es eine Kopie, manchmal nur eine Referenz, und manchmal sollte es sie gar nicht haben.
Core, Off-Core und Hyperforce
Abschnitt betitelt „Core, Off-Core und Hyperforce “Es gibt noch eine Grenze zu verstehen: Selbst «Salesforce» ist nicht eine Laufzeitumgebung und eine Datenbank. In Kapitel 3 hiess auf dem Core (on core), wo die Daten liegen: auf Ihrem Schreibtisch, in den eigenen Objekten der Org. Hier beschreiben dieselben Worte, wo ein Produkt läuft. Sie werden in der Architektur beides hören.
Historisch beherbergte die Core-Laufzeit den grössten Teil der Plattform. Heute beschreibt Salesforce eine Plattform aus Hunderten unabhängiger, metadatengesteuerter Dienste, wobei Core das einzige führende System für Anwendungsmetadaten bleibt (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), auf Englisch). Deshalb hören Sie in der Architektur, eine Funktion laufe auf dem Core (on core) oder ausserhalb des Core (off core).
Das war schon lange wichtig, bevor sich die Plattform in Dienste aufgeteilt hat. Wenn ich eine Klasse frage, warum Salesforce für die Angebotserstellung SteelBrick gekauft hat und nicht Apttus, ist die Antwort, auf die ich hinauswill, einfach: SteelBrick war zu 100 % auf dem Core gebaut. Flows und Trigger leben im Core, also bekommt ein dort gebautes Produkt die Metadaten, Anpassungen und Automatisierung der Plattform gleich mit. Dieses Angebotsprodukt ist inzwischen Revenue Cloud gewichen, aber die Lektion nicht. Dann gibt es nahe am Core (Near-Core), und Data 360 ist das Beispiel, das ich verwende. Data 360 ist nicht Core. Sein Tenant liegt ausserhalb des Core: Die Daten und die Mechanismen, die sie verarbeiten, laufen in einem eigenen Lakehouse, neben der relationalen Datenbank der Org statt darin (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), auf Englisch). Aber die Bildschirme, mit denen Sie es einrichten und steuern, werden auf dem Core angezeigt, in der Org. Am präzisesten sage ich es so: auf dem Core verwaltet, ausserhalb des Core gehostet. Keine der Daten und keine Verarbeitung läuft tatsächlich im Core; die Oberfläche auf dem Core steuert den Tenant ausserhalb des Core. Und dann gibt es natürlich alles, was ausserhalb des Core liegt, weil es gar nicht Salesforce ist.
Mir geht es weniger darum, auswendig zu lernen, welches Produkt dieses Jahr wo läuft, denn das ändert sich, als um die Gewohnheit: Eine Grenze kann Datenbewegung, Latenz, Identität, Integration und Datenresidenz beeinflussen. Nehmen Sie also nicht an, dass die Daten eines Produkts direkt neben Ihren Account-Datensätzen liegen, nur weil Salesforce draufsteht. Schauen Sie sich die tatsächliche Architektur an.
Dann gibt es Hyperforce: die Infrastruktur von Salesforce, gebaut für die Public Cloud und als Code definiert, statt der traditionellen eigenen Rechenzentren, die Kunden mehr Wahl gibt, wo ihre Daten liegen (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), auf Englisch). Das zählt, und Modul 5 kommt darauf zurück. Aber Infrastrukturarchitektur ist keine Datenarchitektur des Unternehmens. Eine Org in die Public Cloud zu verlegen sagt Ihnen nicht, wem der Kunde gehört, wo der Lagerbestand lebt, wo die Analytik läuft oder welche Daten eine Grenze überschreiten dürfen. Hyperforce kann einige dieser Entscheidungen prägen, besonders die Datenresidenz. Es ersetzt nicht das Wissen über die Landschaft.
Die Landschaft kommt vor dem Kasten
Abschnitt betitelt „Die Landschaft kommt vor dem Kasten “Hier ist also die Gewohnheit. Jemand gibt Ihnen ein Szenario. Beginnen Sie nicht, die Salesforce-Lösung zu bauen. Finden Sie zuerst die Systeme: das ERP, den Identitätsanbieter, das Data Warehouse, die Integrationsplattform, Partnersysteme, Kundenkanäle, Dokumentenspeicher. Dann finden Sie die Daten, die zwischen ihnen fliessen: Kunden, Produkte, Aufträge, Rechnungen, Dokumente, Ereignisse, Identitäten. Dann fragen Sie, wem jedes gehört. Erst dann entscheiden Sie, was in Salesforce gehört. Sonst entwerfen Sie einen Kasten, ohne zu wissen, womit er verbunden ist.
Schritt 1 von 3: die Org, die wir entwerfen, für sich allein. Von hier aus sieht sie aus wie die ganze Welt.
Schritt 2 von 3: Zoomen Sie heraus. Salesforce ist ein System unter vielen (Modul 4 zeigt dieses Layout).
Schritt 3 von 3: die ersten Pfeile. Kunden, Produkte und Preise hinein vom ERP, Aufträge hinaus: Sie zeigen, wo das Unternehmen die Wahrheit vermutet.
Die Landschaft verändert das Datenmodell
Abschnitt betitelt „Die Landschaft verändert das Datenmodell “Deshalb zählt das für die Datenarchitektur. Kapitel 2 sagt, der Kunde ist eine wichtige Entität. Gut. Dann sagt die Landschaft, dass das ERP für den Kunden massgeblich ist. Das ändert das physische Modell. Salesforce behält vielleicht trotzdem einen lokalen Account, weil die Leute ihn jeden Tag nutzen, aber jetzt brauchen wir die Kennung des ERP als externe ID; wir müssen wissen, welche Felder Salesforce ändern darf (ich kennzeichne die Felder des ERP mit einem Präfix erp_, wie wir in Modul 3 sehen werden); wie schnell Änderungen aus dem ERP ankommen; ob Salesforce einen Kunden anlegen kann, bevor das ERP von ihm weiss; und was passiert, wenn die beiden sich widersprechen. Das sind keine Integrationsfragen für später. Es sind Fragen der Datenarchitektur, und die Landschaft hat sie offengelegt.
So beisst einer davon zu. Jemand im Vertrieb konvertiert einen Lead für ein grosses Getränkeunternehmen, legt den Account an, gewinnt das Geschäft, und der Kunde geht hinüber ins ERP. Aber das Unternehmen macht seit Jahren Geschäfte mit diesem Getränkeunternehmen, und das ERP hat es bereits. Jetzt gibt es zwei. Hätte der Vertrieb diesen Account überhaupt anlegen dürfen? Kapitel 5 und 6 kommen darauf zurück; in der Landschaft sehen Sie es kommen.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welche Systeme Salesforce umgeben und welche Rolle jedes spielt.
- Welchem System jede wichtige Art von Daten gehört, bevor entschieden wird, wie viel davon Salesforce hält.
- Was in Salesforce hineinfliesst, was hinausfliesst und was zurückkommt.
- Welche Daten Salesforce besitzen, kopieren, referenzieren, föderieren, archivieren oder in Ruhe lassen sollte.
- Welche Plattform- und Infrastrukturgrenzen zählen, statt anzunehmen, dass alles mit der Marke Salesforce an einem Ort lebt.
Der Wechsel von der Entwicklung in die Architektur heisst oft nicht, eine weitere Funktion zu lernen. Er heisst zu lernen, wann man aufhört, auf Salesforce zu schauen: die Kamera zurückziehen, den Daten folgen, herausfinden, wem die Wahrheit gehört, dann zurückkommen und entscheiden, welche Aufgabe Salesforce haben soll.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
- Salesforce-Hilfe, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.