Strategia orgów to decyzja o krajobrazie

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 5 z 6 w rozdziale Zrozumieć dane przedsiębiorstwa, rozdziale 4 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Narysuj krajobraz systemów · Dalej: Krajobraz Steve Trucking

Pytanie, na które odpowiada ten moduł: jeden org czy wiele i gdzie działa?

Kiedy uczę kandydatów na CTA, mówię im, że największa decyzja w scenariuszu zapada w ciągu pierwszych pięciu czy dziesięciu minut: z iloma orgami Salesforce mamy do czynienia? Jeden duży org? Regionalne orgi dla Ameryki Północnej, EMEA i APAC? Osobne orgi dla osobnych jednostek biznesowych? Specjalny org dla kraju z własnymi zasadami? A bezpośrednio z tym związane: gdzie działają te orgi?

To nie są szczegóły administracyjne. Zmieniają to, gdzie mieszkają dane, integracje, raportowanie, tożsamość i sposób, w jaki ludzie na całym świecie docierają do systemu. Dlatego traktuję strategię orgów jako decyzję o krajobrazie i dlatego podejmuję ją jako pierwszą.

Zacznij od jednego orgu

Moje stanowisko wyjściowe jest proste: zacznij od jednego orgu. Nie dlatego, że jeden org jest zawsze właściwy, ale dlatego, że potrzebuję powodu, żeby dodać kolejny. Jeden org daje mi jedno miejsce na wspólne dane klientów, jeden model bezpieczeństwa, jedno miejsce wdrożeń, jeden zestaw integracji, jedno miejsce raportowania. A jeden org nadal może obsługiwać różne jednostki biznesowe, kraje, procesy, typy rekordów, aplikacje, modele udostępniania i doświadczenia.

Nie dodaję więc orgu dlatego, że Europa robi coś trochę inaczej, dział ma własny proces sprzedaży albo jednostki biznesowe się nie lubią. To są wymagania, a nie granice orgów. Pytanie brzmi: jaka siła jest dość mocna, żeby uzasadnić kolejny org?

Wiele orgów ma swój koszt

Podziel jeden org na trzy (Ameryka Północna, Europa, Azja i Pacyfik), a nie narysujesz trzech schludnych prostokątów; stworzysz nowe pytania. Gdzie mieszka klient globalny? A jeśli działa w dwóch regionach: dwie kopie, i która jest właścicielem? Jak ktokolwiek raportuje globalnie? Czy ERP integruje się ze wszystkimi trzema, czy hurtownia dostaje trzy strumienie, czy dostawca tożsamości łączy się ze wszystkimi trzema? Czy wdrażamy tę samą funkcjonalność trzy razy i utrzymujemy zgodność trzech modeli danych? Jeśli agent potrzebuje globalnego widoku klienta, który org pyta?

Wróć do krajobrazu z modułu 4. Jeden prostokąt Salesforce staje się trzema, a każdą strzałkę trzeba narysować od nowa. Wiele orgów to nie błąd. Ale nigdy nie jest za darmo.

Szukaj prawdziwych granic

Co może uzasadnić kolejny org? Granice na tyle prawdziwe, że kształtują architekturę: rezydencja danych, regulacje, rozdział prawny, naprawdę różne modele operacyjne, przejęcie, które jeszcze się nie zintegrowało, regionalne ograniczenie hostingu, bardzo różne zasady zarządzania, czasem skala albo izolacja. Ta lista nie jest pełna. Chodzi o odróżnienie „te grupy są różne” od „te grupy potrzebują granicy architektonicznej”. Ta druga poprzeczka wisi dużo wyżej.

Geografia to nie automatycznie strategia orgów

„Działamy w 30 krajach, więc potrzebujemy 30 orgów”. Nie. Geografia ma znaczenie, gdy niesie ze sobą wymaganie architektoniczne. Firma może mieć użytkowników na całym świecie na jednej wspólnej architekturze. Nie liczę więc krajów; pytam, co przychodzi razem z nimi. Gdzie wolno przechowywać dane? Gdzie wolno je przetwarzać? Czy są ograniczenia przenoszenia danych osobowych przez granice? Umowne zobowiązania dotyczące rezydencji? Czy region potrzebuje innej usługi albo innego hostingu Salesforce? „Mamy biuro w Niemczech” samo w sobie nie wystarczy.

Hosting jest częścią rysunku

Tu nowoczesna platforma czyni krajobraz ciekawszym. Hyperforce uruchamia Salesforce na infrastrukturze chmury publicznej w regionach na całym świecie, dając klientom większy wybór i kontrolę nad tym, gdzie przechowywane są ich dane (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), po angielsku). Kiedy więc oznaczam prostokąt „Salesforce, Europa”, ta lokalizacja może mieć znaczenie.

Ale tu liczy się precyzja. Wybór miejsca, w którym działa org, to nie obietnica, że każdy bajt każdej usługi tam zostanie. Salesforce każe klientom przejrzeć dokumentację dotyczącą zaufania i zgodności dla Hyperforce, w tym dodatkowych podprzetwarzających dla usług, które kupują (to samo źródło). Nie mów więc „jesteśmy na Hyperforce w kraju X, więc wszystko zostaje w kraju X”. Wiedz, z których usług naprawdę korzystasz i jakie wymaganie spełniasz. I zauważ, co wybierasz: region, a nie chmurę pod spodem. Hyperforce działa na AWS, a od końca 2026 roku także na Google Cloud, i to Salesforce decyduje, u którego dostawcy stoi org; klient z udokumentowanym powodem regulacyjnym, żeby unikać któregoś z nich, rozmawia ze swoim zespołem opiekującym się kontem (to samo źródło).

Nie baw się w prawnika

Tu też architekci muszą znać swoją rolę. Jeśli ktoś mówi „europejskie prawo o prywatności wymaga osobnego orgu”, nie przyjmę tego na ślepo. Nie mianuję się też prawnikiem firmy, żeby ogłosić, że nie wymaga. Zapytam: jakie konkretne wymaganie spełniamy? Gdzie dane są przechowywane, gdzie są przetwarzane, przekazywanie przez granice, kto może mieć do nich dostęp w ramach wsparcia, umowa, wewnętrzna polityka? Potem pracuję z działami prywatności, bezpieczeństwa, zgodności i prawnym, żeby przełożyć to wymaganie na architekturę. Nie wymyślaj wymagań prawnych i nie ignoruj ich. Tłumacz je.

Kiedy Europa dostaje własny org

Oto granica, którą widzę w prawdziwych scenariuszach. Firma ma silną obecność w USA i silną obecność w Europie: dwie duże bazy klientów, dwa działy sprzedaży i obsługi oraz europejski program ochrony prywatności zbudowany wokół RODO (GDPR). RODO nie mówi „potrzebujesz osobnego orgu Salesforce”. Ustala zasady dla danych osobowych, w tym kiedy wolno je przekazywać poza UE (RODO, rozdział V (opens in a new tab)). Ale ta firma, razem ze swoimi zespołami ds. prywatności i prawnym, decyduje, że dane osobowe jej europejskich klientów powinny mieszkać w orgu hostowanym w Europie, prowadzonym przez jej europejski zespół, w ramach jej europejskiego ładu. To prawdziwe wymaganie i jest ich, nie moje.

Teraz „jeden duży globalny org” nie jest już kwestią preferencji. Na krajobrazie jest granica, Salesforce AMER i Salesforce EMEA, i muszę ją narysować. A drugi org nigdy nie jest tylko jednym prostokątem więcej.

Click to enlarge

Dwa orgi, AMER i EMEA. Bursztynowe jest to, co dodaje drugi org: nie jeden prostokąt więcej, ale każda strzałka od nowa.

Przejdź po strzałkach jeszcze raz

Przy więcej niż jednym orgu przejdź po krajobrazie jeszcze raz. Czy ERP wysyła produkty do każdego orgu? Czy każdy odsyła zamówienia? Gdzie zarządza się klientami jako danymi podstawowymi i czy ich dane mogą przekraczać regiony? Czy warstwa integracyjna jest globalna, czy regionalna? Który dostawca tożsamości loguje których użytkowników? Dokąd idą dane analityczne?

Trzy miejsca najszybciej pokazują koszt:

Raportowanie. Prezes chce globalnego lejka sprzedaży. W jednym orgu to raport Salesforce. W trzech to problem raportowania na poziomie przedsiębiorstwa: replikować, wysyłać do hurtowni, federować? Jak aktualne muszą być dane i czy orgi w ogóle tak samo definiują „lejek”? To, gdzie mieszka analityka, wynika z tego, gdzie mieszkają dane, a jeśli celowo dzielisz dane operacyjne, musisz zaprojektować, jak wiedza znów się połączy.

Dane podstawowe. Klient globalny kupuje w USA, Niemczech i Japonii. Trzy orgi, więc pewnie trzy konta. Skąd wiesz, że to ta sama firma? Jaki jest globalny identyfikator i kto jest jego właścicielem? Jeśli jeden region zmieni adres, czy zmiana powinna się rozejść? Które atrybuty są globalne, a które regionalne? Strategia orgów nie rozwiązuje problemu tożsamości; zmienia go. To rozdział 6.

Integracja. Jeden org: Salesforce, warstwa integracyjna, ERP. Trzy orgi: trzy połączenia do warstwy integracyjnej, może jedno z własnym hostingiem i łącznością, część przepływów wspólna, część regionalna, część danych może przechodzić, a część nie. Nawet sieć może się zmienić: jeśli przedsiębiorstwo potrzebuje dedykowanej prywatnej łączności z Hyperforce (na AWS Salesforce zaleca AWS Direct Connect; to samo FAQ Hyperforce), każdy org i każdy hosting na rysunku to kolejne połączenie do zaplanowania. To, gdzie działa org, może zmienić sposób, w jaki dociera do niego reszta przedsiębiorstwa.

Jeden org czy wiele, to decyzja, którą podejmujesz teraz, na początku, na krajobrazie. To, jak orgi będą potem dzielić się danymi (Salesforce Connect między orgami, integracja między nimi, Data 360), to już mechanika, i omawia ją rozdział 14, Jeden org czy wiele? (coming soon).

Jeśli zaprojektujesz cały model danych i architekturę integracji, a dopiero potem usłyszysz „przy okazji, to muszą być trzy orgi”, nie wprowadzasz drobnej poprawki. Zmieniasz architekturę. Dlatego ta decyzja zapada jako pierwsza.

Nie dziel tylko po to, żeby prostokąty były mniejsze

Duży org wydaje się skomplikowany: mnóstwo jednostek, obiektów, użytkowników, integracji. Ktoś mówi: „Czy nie byłoby czyściej, gdyby każdy miał własny org?”. Rysunek może stać się czyściejszy. Przedsiębiorstwo niekoniecznie. Zamieniasz złożoność wewnętrzną na złożoność rozproszoną: synchronizację, zduplikowane dane, tożsamość między orgami, globalne raportowanie, kilka potoków wydań, zdublowane integracje i automatyzację oraz zarządzanie tym wszystkim. Czasem to nadal właściwa zamiana. Ale osobno to nie to samo co prosto.

A jeden org też nie jest za darmo. Wspólne zarządzanie ma większe znaczenie, zespoły mogą sobie wzajemnie przeszkadzać, granice bezpieczeństwa wymagają starannego projektu, model danych musi służyć wielu grupom, wydania wymagają koordynacji, a regionalne zasady mogą ograniczać wszystkich. To więc nie jest „Steve mówi: zawsze jeden org”. Moje wyjściowe nastawienie to jeden org; potem szukam wymagania dość silnego, żeby mnie od tego odciągnąć.

Pokaż decyzję

Jeśli strategia orgów ma znaczenie, nie rysuj ogólnej chmurki Salesforce. Narysuj orgi i je opisz (AMER, EMEA, cokolwiek jest prawdą), zaznacz wymaganie dotyczące hostingu albo rezydencji stojące za każdym z nich i przejdź po połączeniach. Inny architekt powinien widzieć, dlaczego istnieje każda granica. Jeśli nie potrafię wyjaśnić, dlaczego są trzy prostokąty Salesforce, nie skończyłem podejmować decyzji.

Steve Trucking ma jeden org, w USA, i nic w jego opisie nie wymaga kolejnego. Ale zapamiętaj ten moduł na potrzeby projektu końcowego: przejęcie, które przychodzi z własnym orgiem, to dokładnie taka granica, która sprawdza te pytania.

Poza egzaminem: co zmienia AI. Agent może sprawić, że granica orgu stanie się dla użytkownika niewidoczna. Pod spodem architektura nadal musi zdecydować, który org albo system agent może pytać, jakie dane mogą przekraczać regiony i która odpowiedź jest nadrzędna. AI może ukryć złożoność w doświadczeniu użytkownika; nie usuwa zarządzania ani granicy.

Co tu decyduje architekt

• Czy istnieje prawdziwy powód architektoniczny dla więcej niż jednego orgu, zamiast rozwiązywać różnice wewnątrz jednego.
• Gdzie działa każdy org i które wymaganie dotyczące rezydencji, regulacji, umowy albo biznesu go tam umieszcza.
• Które dane mogą przekraczać granice orgów i regionów, gdzie dane podstawowe są nadrzędne i jak działa globalna tożsamość.
• Jak zmieniają się integracja, tożsamość, analityka i raportowanie, gdy jeden prostokąt Salesforce staje się kilkoma.
• Czy korzyść z rozdzielenia jest warta rozproszonej architektury, którą tworzy.

Czytając scenariusz, najpierw szukam tej decyzji: jeden org czy wiele, gdzie hostowane i co do tego zmusza? Odpowiedz na to, a reszta krajobrazu zacznie nabierać kształtu.

Do zgłębienia

• Pomoc Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab) (RODO), rozdział V (przekazywanie danych osobowych do państw trzecich), sprawdzono 2026-10-14.