Die Org-Strategie ist eine Entscheidung über die Landschaft

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)

Mit KI erstelltes Bild

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

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

Die Frage, die dieses Modul beantwortet: Eine Org oder viele, und wo läuft sie?

Wenn ich CTA-Kandidat:innen unterrichte, sage ich ihnen, dass die größte Entscheidung in einem Szenario in den ersten fünf oder zehn Minuten fällt: Mit wie vielen Salesforce-Orgs haben wir es zu tun? Eine große Org? Regionale Orgs für Nordamerika, EMEA und APAC? Getrennte Orgs für getrennte Geschäftsbereiche? Eine besondere Org für ein Land mit eigenen Regeln? Und direkt damit verbunden: Wo laufen diese Orgs?

Das sind keine Administrationsdetails. Sie verändern, wo die Daten liegen, die Integrationen, die Berichte, die Identität und wie Menschen auf der ganzen Welt das System erreichen. Deshalb behandle ich die Org-Strategie als Entscheidung über die Landschaft, und deshalb treffe ich sie zuerst.

Beginnen Sie mit einer Org

Meine Ausgangsposition ist einfach: Beginnen Sie mit einer Org. Nicht weil eine Org immer richtig ist, sondern weil ich einen Grund brauche, eine weitere hinzuzufügen. Eine Org gibt mir einen Ort für gemeinsame Kundendaten, ein Sicherheitsmodell, einen Ort zum Bereitstellen, einen Satz Integrationen, einen Ort für Berichte. Und eine Org kann trotzdem verschiedene Geschäftsbereiche, Länder, Prozesse, Datensatztypen, Apps, Freigabemodelle und Erlebnisse tragen.

Ich füge also keine Org hinzu, weil Europa die Dinge etwas anders macht, eine Sparte einen eigenen Vertriebsprozess hat oder die Geschäftsbereiche sich nicht mögen. Das sind Anforderungen, keine Org-Grenzen. Die Frage lautet: Welche Kraft ist stark genug, um eine weitere Org zu rechtfertigen?

Mehrere Orgs haben ihren Preis

Teilen Sie eine Org in drei (Nordamerika, Europa, Asien-Pazifik), und Sie haben nicht drei saubere Kästen gezeichnet; Sie haben neue Fragen geschaffen. Wo lebt ein globaler Kunde? Was, wenn er in zwei Regionen tätig ist: zwei Kopien, und welche besitzt ihn? Wie berichtet jemand global? Integriert sich das ERP mit allen dreien, bekommt das Data Warehouse drei Feeds, verbindet sich der Identitätsanbieter mit allen dreien? Stellen wir dieselbe Funktionalität dreimal bereit und halten drei Datenmodelle abgestimmt? Wenn ein Agent eine globale Sicht auf einen Kunden braucht, welche Org fragt er?

Gehen Sie zurück zur Landschaft aus Modul 4. Aus einem Salesforce-Kasten werden drei, und jeder Pfeil wird neu gezeichnet. Mehrere Orgs sind nicht falsch. Kostenlos sind sie nie.

Suchen Sie echte Grenzen

Was kann eine weitere Org rechtfertigen? Grenzen, die echt genug sind, um die Architektur zu prägen: Datenresidenz, Regulierung, rechtliche Trennung, wirklich unterschiedliche Betriebsmodelle, eine Übernahme, die noch nicht zusammengeführt ist, eine regionale Hosting-Einschränkung, sehr unterschiedliche Governance, manchmal Volumen oder Isolation. Die Liste ist nicht vollständig. Es geht darum, „Diese Gruppen sind verschieden“ von „Diese Gruppen brauchen eine Architekturgrenze“ zu unterscheiden. Die zweite Hürde liegt viel höher.

Geografie ist nicht automatisch eine Org-Strategie

„Wir sind in 30 Ländern tätig, also brauchen wir 30 Orgs.“ Nein. Geografie zählt, wenn sie eine Architekturanforderung mitbringt. Ein Unternehmen kann Benutzer auf der ganzen Welt auf einer gemeinsamen Architektur haben. Also zähle ich keine Länder; ich frage, was mit ihnen kommt. Wo dürfen die Daten gespeichert werden? Wo dürfen sie verarbeitet werden? Gibt es Grenzen für die Übermittlung personenbezogener Daten über Grenzen hinweg? Vertragliche Zusagen zur Datenresidenz? Braucht eine Region einen anderen Salesforce-Dienst oder -Host? „Es gibt ein Büro in Deutschland“ reicht für sich allein nicht.

Das Hosting gehört in die Zeichnung

Hier macht die moderne Plattform die Landschaft interessanter. Hyperforce betreibt Salesforce auf Public-Cloud-Infrastruktur in Regionen auf der ganzen Welt und gibt Kunden mehr Wahl und Kontrolle darüber, wo ihre Daten liegen (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), auf Englisch). Wenn ich also einen Kasten mit „Salesforce, Europa“ beschrifte, kann dieser Standort zählen.

Aber seien Sie genau. Zu wählen, wo eine Org lebt, ist kein Versprechen, dass jedes Byte jedes Dienstes dort bleibt. Salesforce fordert Kunden auf, die Vertrauens- und Compliance-Dokumentation für Hyperforce zu prüfen, einschließlich der zusätzlichen Unterauftragsverarbeiter für die Dienste, die sie kaufen (dieselbe Quelle). Sagen Sie also nicht „Wir sind auf Hyperforce in Land X, also bleibt alles in Land X.“ Wissen Sie, welche Dienste Sie tatsächlich nutzen und welche Anforderung Sie erfüllen. Und beachten Sie, was Sie wählen: die Region, nicht die Cloud darunter. Hyperforce läuft auf AWS, ab Ende 2026 auch auf Google Cloud, und Salesforce entscheidet, bei welchem Anbieter eine Org liegt; ein Kunde mit einem dokumentierten regulatorischen Grund, einen davon zu meiden, spricht mit seinem Account-Team (dieselbe Quelle).

Spielen Sie nicht die Rechtsabteilung

Hier müssen wir in der Architektur auch unsere Rolle kennen. Wenn jemand sagt „Das europäische Datenschutzrecht verlangt eine getrennte Org“, akzeptiere ich das nicht blind. Ich ernenne mich aber auch nicht zur Rechtsabteilung des Unternehmens und erkläre, dass es das nicht tut. Ich frage: Welche konkrete Anforderung erfüllen wir? Wo Daten gespeichert werden, wo sie verarbeitet werden, die grenzüberschreitende Übermittlung, wer für den Support darauf zugreifen darf, ein Vertrag, eine interne Richtlinie? Dann arbeite ich mit Datenschutz, Sicherheit, Compliance und Rechtsabteilung, um diese Anforderung in Architektur zu übersetzen. Erfinden Sie keine rechtlichen Anforderungen, und ignorieren Sie sie nicht. Übersetzen Sie sie.

Wenn Europa eine eigene Org bekommt

Hier ist eine Grenze, die ich in echten Szenarien sehe. Ein Unternehmen ist stark in den USA und stark in Europa vertreten: zwei große Kundenstämme, zwei Vertriebs- und Serviceorganisationen und ein europäisches Datenschutzprogramm, das auf der DSGVO aufbaut. Die DSGVO sagt nicht „Sie brauchen eine eigene Salesforce-Org.“ Sie legt Regeln für personenbezogene Daten fest, auch dafür, wann sie aus der EU übermittelt werden dürfen (DSGVO, Kapitel V (opens in a new tab)). Aber dieses Unternehmen entscheidet gemeinsam mit seinen Datenschutz- und Rechtsteams, dass die personenbezogenen Daten seiner europäischen Kunden in einer in Europa gehosteten Org liegen sollen, betrieben von seinem europäischen Team, unter seiner europäischen Governance. Das ist eine echte Anforderung, und sie ist ihre, nicht meine.

Jetzt ist „eine große globale Org“ keine Vorliebe mehr. Es gibt eine Grenze in der Landschaft, Salesforce AMER und Salesforce EMEA, und ich muss sie zeichnen. Und die zweite Org ist nie nur ein weiterer Kasten.

Click to enlarge

Zwei Orgs, AMER und EMEA. Das Bernsteinfarbene ist, was die zweite Org hinzufügt: nicht ein weiterer Kasten, sondern jeder Pfeil noch einmal.

Gehen Sie die Pfeile erneut ab

Mit mehr als einer Org gehen Sie die Landschaft erneut ab. Schickt das ERP Produkte an jede Org? Schickt jede Aufträge zurück? Wo werden Kunden als Stammdaten geführt, und dürfen ihre Daten Regionen überschreiten? Ist die Integrationsschicht global oder regional? Welcher Identitätsanbieter meldet welche Benutzer an? Wohin gehen die analytischen Daten?

Drei Stellen zeigen den Preis am schnellsten:

Berichte. Der CEO will eine globale Pipeline. In einer Org ist das ein Salesforce-Bericht. In drei ist es ein Berichtsproblem des Unternehmens: replizieren, ins Data Warehouse schicken, föderieren? Wie aktuell muss es sein, und definieren die Orgs „Pipeline“ überhaupt gleich? Wo die Analytik lebt, folgt daraus, wo die Daten leben, und wenn Sie die operativen Daten absichtlich aufteilen, müssen Sie entwerfen, wie die Erkenntnisse wieder zusammenkommen.

Stammdaten. Ein globaler Kunde kauft in den USA, in Deutschland und in Japan. Drei Orgs, also wahrscheinlich drei Accounts. Woher wissen Sie, dass es dasselbe Unternehmen ist? Was ist die globale Kennung, und wem gehört sie? Wenn eine Region die Adresse ändert, soll sich das verbreiten? Welche Attribute sind global und welche regional? Die Org-Strategie löst die Identität nicht; sie verändert das Identitätsproblem. Das ist Kapitel 6.

Integration. Eine Org: Salesforce, die Integrationsschicht, das ERP. Drei Orgs: drei Verbindungen in die Integrationsschicht, vielleicht eine mit eigenem Host und eigener Konnektivität, manche Flüsse gemeinsam, manche regional, manche Daten dürfen hinüber und manche nicht. Selbst das Netzwerk kann sich ändern: Wenn das Unternehmen eine eigene private Konnektivität zu Hyperforce braucht (auf AWS empfiehlt Salesforce AWS Direct Connect; dieselbe Hyperforce-FAQ), ist jede Org und jeder Host in der Zeichnung eine weitere zu planende Verbindung. Wo eine Org läuft, kann ändern, wie der Rest des Unternehmens sie erreicht.

Eine Org oder viele ist eine Entscheidung, die Sie jetzt treffen, am Anfang, in der Landschaft. Wie die Orgs dann Daten teilen (organisationsübergreifendes Salesforce Connect, Integration zwischen ihnen, Data 360), ist die Mechanik, und Kapitel 14, Eine Org oder viele? (coming soon), behandelt sie.

Wenn Sie das ganze Datenmodell und die Integrationsarchitektur entwerfen und erst dann hören „übrigens, das müssen drei Orgs sein“, haben Sie keine kleine Anpassung vorgenommen. Sie haben die Architektur geändert. Deshalb kommt die Entscheidung zuerst.

Teilen Sie nicht, nur um die Kästen kleiner zu machen

Eine große Org fühlt sich kompliziert an: viele Einheiten, Objekte, Benutzer, Integrationen. Jemand sagt: „Wäre es nicht sauberer, wenn jeder seine eigene Org hätte?“ Die Zeichnung würde vielleicht sauberer. Das Unternehmen vielleicht nicht. Sie haben interne Komplexität gegen verteilte Komplexität getauscht: Synchronisation, doppelte Daten, Identität über Orgs hinweg, globale Berichte, mehrere Release-Pipelines, duplizierte Integrationen und Automatisierung, und die Governance über all das. Manchmal ist das trotzdem der richtige Tausch. Aber getrennt heißt nicht einfach.

Und eine Org ist auch nicht kostenlos. Gemeinsame Governance zählt mehr, Teams können sich gegenseitig beeinflussen, Sicherheitsgrenzen brauchen einen sorgfältigen Entwurf, das Datenmodell muss vielen Gruppen dienen, Releases brauchen Abstimmung, und regionale Regeln können alle einschränken. Es heißt also nicht „Steve sagt: immer eine Org“. Meine Ausgangsneigung ist eine Org; dann suche ich die Anforderung, die stark genug ist, mich davon abzubringen.

Machen Sie die Entscheidung sichtbar

Wenn die Org-Strategie zählt, zeichnen Sie keine generische Salesforce-Wolke. Zeichnen Sie die Orgs und beschriften Sie sie (AMER, EMEA, was immer real ist), notieren Sie die Hosting- oder Residenzanforderung hinter jeder und gehen Sie die Verbindungen ab. Andere in der Architektur sollten sehen können, warum jede Grenze existiert. Wenn ich nicht erklären kann, warum es drei Salesforce-Kästen gibt, habe ich die Entscheidung nicht zu Ende getroffen.

Steve Trucking betreibt eine Org, in den USA, und nichts in seinem Steckbrief verlangt eine weitere. Aber behalten Sie dieses Modul für das Abschlussprojekt im Kopf: Eine Übernahme, die mit einer eigenen Org kommt, ist genau die Art von Grenze, die diese Fragen auf die Probe stellt.

Über die Prüfung hinaus: Was KI ändert. Ein Agent kann eine Org-Grenze für den Benutzer unsichtbar machen. Darunter muss die Architektur trotzdem entscheiden, welche Org oder welches System der Agent fragen darf, welche Daten Regionen überschreiten dürfen und welche Antwort maßgeblich ist. KI kann die Komplexität im Erlebnis verbergen; sie beseitigt weder die Governance noch die Grenze.

Was Architekt:innen hier entscheiden

• Ob es einen echten Architekturgrund für mehr als eine Org gibt, statt die Unterschiede innerhalb einer zu lösen.
• Wo jede Org läuft und welche Residenz-, regulatorische, vertragliche oder geschäftliche Anforderung sie dorthin setzt.
• Welche Daten Org- und Regionsgrenzen überschreiten dürfen, wo Stammdaten maßgeblich sind und wie globale Identität funktioniert.
• Wie sich Integration, Identität, Analytik und Berichte ändern, wenn aus einem Salesforce-Kasten mehrere werden.
• Ob der Nutzen der Trennung die verteilte Architektur wert ist, die sie schafft.

Wenn ich ein Szenario lese, suche ich zuerst diese Entscheidung: eine Org oder viele, gehostet wo, und erzwungen wodurch? Beantworten Sie das, und der Rest der Landschaft beginnt Form anzunehmen.

Weiterlesen

• 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.
• EUR-Lex, Verordnung (EU) 2016/679, Datenschutz-Grundverordnung (opens in a new tab), Kapitel V (Übermittlungen personenbezogener Daten an Drittländer), geprüft am 2026-10-14.