Systemy wokół Salesforce

🌐 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ł 3 z 6 w rozdziale Zrozumieć dane przedsiębiorstwa, rozdziale 4 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Rodzaje danych w przedsiębiorstwie · Dalej: Narysuj krajobraz systemów

Pytanie, na które odpowiada ten moduł: co otacza Salesforce i jaką rolę odgrywa każdy system?

Poprzedni moduł posortował dane. Teraz chcę je gdzieś umieścić i tu architekci Salesforce wpadają w kłopoty. Znamy Salesforce, więc dane klientów to konto, dane zamówień to zamówienie, dokumenty to pliki, analityka to raporty. Ale przedsiębiorstwo nie kupiło Salesforce, żeby zastąpić wszystko inne, co posiada. Może mieć ERP obsługujący finanse i realizację zamówień, hurtownię z latami historii, platformę integracyjną, dostawcę tożsamości, systemy partnerów, platformę zdarzeń, platformę MDM i Data 360 łączące kilka z nich. Zadanie nie polega na zapamiętywaniu technologii. Polega na zrozumieniu, jaką pracę wykonuje każdy system.

Nie zaczynaj od nazwy produktu

„Mamy SAP” nie mówi mi dość. Tak samo Snowflake, MuleSoft, Tableau czy Data 360. Chcę wiedzieć, co ten system robi w tej architekturze: jakich danych jest właścicielem, co czyta, co zmienia, kto z niego korzysta, co od niego zależy, co się dzieje, gdy nie działa. Dwie firmy mogą mieć dokładnie te same produkty i zupełnie różne architektury.

Oznaczam więc systemy według ról. Cztery role obejmują większość przypadków:

• System of record (system ewidencji): tam utrzymywana jest nadrzędna wersja czegoś.
• System zaangażowania (system of engagement): tam ludzie wykonują pracę.
• System referencyjny (system of reference): tam system sięga po informacje, których potrzebuje, ale których nie jest właścicielem.
• System wiedzy (system of insight): tam dane schodzą się, żeby mierzyć, analizować i przewidywać.

Jedna platforma może odgrywać kilka ról, a role różnią się w zależności od danych. Salesforce może być systemem ewidencji dla zgłoszeń, systemem zaangażowania dla agentów serwisu i odbiorcą danych produktowych, których właścicielem jest ERP. Kiedy więc ktoś mówi „Salesforce to nasz system ewidencji”, dokończ zdanie: system ewidencji dla czego?

ERP: zaplecze ma grawitację

ERP to system, który najczęściej znajdziesz obok Salesforce; obsługuje finanse, zapasy, zakupy, realizację zamówień i rozliczenia. Wzorzec z modułu 1 (klienci i produkty do środka, zamówienia na zewnątrz) oznacza, że właścicielem produktów jest ERP, ale handlowcy i tak potrzebują ich w Salesforce. Dobrze: sprowadź je. Ale skopiowanie danych nie przenosi własności. Kopia to nie autorytet.

Moje stanowisko: dane, których właścicielem jest ERP, czyta się lokalnie, a zapisuje pod kontrolą. Użytkownicy Salesforce dostają dane tam, gdzie pracują, ale Salesforce nie może zmieniać tego, czego właścicielem jest ERP. I pokazuję to w schemacie: pola ERP mają prefiks erp_, na przykład erp_Product_Number__c, żeby każdy, kto czyta obiekt, wiedział, kto jest właścicielem każdego pola, i był ostrożny przy jego zmianie. Prefiks niczego nie egzekwuje; robią to uprawnienia, walidacja i wzorzec integracji. Komunikuje zamiar i jest widoczną mapą autorytetów.

Hurtownia, data lake i lakehouse

Systemy operacyjne prowadzą biznes; systemy analityczne pomagają go zrozumieć. „Pokaż mi moje otwarte szanse sprzedaży” to raport Salesforce. „Pokaż mi pięć lat sprzedaży, realizacji, zwrotów, zgłoszeń, zapasów i finansów we wszystkich kanałach” to inny problem.

Spotkasz trzy rodzaje magazynów analitycznych. Hurtownia danych przechowuje dane ustrukturyzowane przygotowane do analizy. Data lake przechowuje dużo więcej danych w większej liczbie form, często surowych. Lakehouse łączy jedno z drugim: przechowywanie jak w data lake z analizą jak w hurtowni. Znaj je, bo pojawiają się na krajobrazach. Ale z mojego doświadczenia lakehouse i data mesh to wciąż nisza w projektach Salesforce. Typowy krajobraz to CRM, ERP, hurtownia i warstwa integracyjna, a inne platformy tam, gdzie biznes naprawdę ich potrzebuje. Ucz się architektury; nie goń za słownictwem.

Analityka mieszka tam, gdzie dane

To jedno z moich najmocniejszych stanowisk: to, gdzie mieszka analityka, wynika z tego, gdzie mieszkają dane. Jeśli raport potrzebuje tylko kont, szans sprzedaży i handlowców, wszystko jest w core: standardowe raporty i pulpity. Potem biznes prosi o dodanie faktur z ERP. Potem kosztu produktu. Potem pięciu lat zamówień z hurtowni. Potem aktywności na stronie internetowej. W którymś momencie wciąganie tego wszystkiego do operacyjnego CRM tylko po to, żeby o tym raportować, przestaje mieć sens. Gdy w grę wchodzą inne magazyny danych, platforma analityczna staje się konieczna: Tableau (w tym Tableau Next, zbudowane na Data 360) albo CRM Analytics tam, gdzie już jest używane. Jest niezbędna, gdy dane Salesforce łączy się z hurtownią. Wymaganie nie tylko się skomplikowało; krajobraz zmienił miejsce, w którym trzeba odpowiadać na pytanie. Dlatego nigdy nie zaczynam od „które narzędzie analityczne?”. Zaczynam od gdzie są dane?

Kandydatów na CTA pytam o to samo: „Który z moich diagramów rozwiązuje to pięknie? Krajobraz”. Jeśli wszystko masz w core, używaj raportów. Jeśli masz dane w innych repozytoriach, chcę zobaczyć platformę analityczną. Krajobraz odpowiada na pytanie o raportowanie, zanim ktokolwiek otworzy kreator raportów. (Nazwy produktów się zmieniają; rozdział o Data 360 omawia, gdzie dziś stoi analityka Salesforce).

MDM: kim naprawdę jest ten klient?

Teraz załóżmy, że informacje o kliencie mieszkają w Salesforce, ERP, sklepie internetowym, platformie lojalnościowej i systemie partnera, a każdy z nich uważa, że wie, kim jest klient. Tu wchodzi zarządzanie danymi podstawowymi (MDM): ustalanie nadrzędnej tożsamości kluczowych danych w wielu systemach i zarządzanie nią. Ale MDM to nie „główna baza klientów”. Trudne pytania brzmią: który system może utworzyć klienta, których atrybutów właścicielem jest każdy system, jak znajduje się duplikaty, który identyfikator przetrwa i co się dzieje, gdy systemy się nie zgadzają. O tym jest cały rozdział 6. Tu rozpoznaj rolę: jeśli istnieje platforma MDM, może być kluczowym autorytetem między Salesforce a resztą przedsiębiorstwa.

Warstwa integracyjna i zdarzenia

Połącz każdy system bezpośrednio z każdym innym, a krajobraz szybko zamieni się w spaghetti. Dlatego przedsiębiorstwa mają warstwę integracyjną: ESB (enterprise service bus) albo iPaaS (integration platform as a service). W krajobrazach Salesforce najczęściej spotkasz MuleSoft. Pośredniczy, żeby każda aplikacja nie musiała rozumieć każdej innej.

Ale prostokąt MuleSoft pośrodku nie sprawia, że integracja jest dobra. Nadal chcę wiedzieć, co przez nią przechodzi, a co nie, kto przekształca dane, kto jest właścicielem kontraktu, co się dzieje, gdy cel nie działa, czy jest synchroniczna, czy asynchroniczna i skąd wiemy, że komunikat dotarł. Kurs Integration Architect wchodzi w to głęboko; tu rozpoznaj ją jako osobną rolę.

I nie każda integracja polega na tym, że system A wywołuje system B. Czasem coś się dzieje (powstaje zamówienie, dostawa zmienia status, ciężarówka wjeżdża do regionu), publikowane jest zdarzenie, a kto jest zainteresowany, ten reaguje. Zdarzenia w ruchu też mają infrastrukturę: własne mechanizmy zdarzeń Salesforce, magistralę zdarzeń przedsiębiorstwa, inne systemy komunikatów. Rysuj mechanizmy, które przenoszą dane, a nie tylko bazy danych.

System, o którym zapominają programiści: tożsamość

Jest jeden prostokąt, który zawsze chcę mieć na krajobrazie, a o którym programiści rzadko myślą: dostawca tożsamości. Programiści logują się do swoich sandboxów prosto nazwą użytkownika i hasłem, więc podczas budowy tożsamości nie widać. Potem przychodzi UAT albo produkcja i nagle jest firmowe single sign-on dla pracowników, może drugi dostawca dla partnerów, logowanie przez media społecznościowe dla klientów. Tożsamość zawsze była częścią architektury. Programista po prostu jeszcze jej nie widział.

Dostawca tożsamości (IdP) to system, który uwierzytelnia użytkownika i ustala tożsamość, której ufa Salesforce. Należy do krajobrazu od pierwszego dnia, nawet jeśli konfiguruje się go później w potoku wydań, bo to, kto może wejść, decyduje o tym, kto może dostać się do danych.

Jest też praktyczny haczyk: konfigurację tożsamości da się wdrażać, ale nie w całości. Konfiguracja SAML single sign-on i dostawcy uwierzytelniania to typy Metadata API, więc przechodzą przez potok (SamlSsoConfig (opens in a new tab), po angielsku). Ale sekrety konsumenta dostawców uwierzytelniania nie są już zwracane w odpowiedziach Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), po angielsku), a certyfikaty zwykle różnią się między środowiskami. Zaplanuj części, które się przenoszą, i te, które się nie przenoszą.

Click to enlarge

Czytaj krajobraz jako role, nie logotypy: czego każdy system jest właścicielem, co czyta, o czym decyduje.

Gdzie leży Data 360?

Data 360 stawia ciekawe pytanie rysunkowe. Umieszczam je po prawej, pod ESB czy MuleSoft. Powodem są jego połączenia: użytkownicy nigdy nie łączą się z nim bezpośrednio, a ono łączy się bezpośrednio z wieloma systemami zaplecza. Należy więc do hydrauliki danych, gdzie te linie zostają krótkie, a nie do strefy użytkowników. Narysuj je jak kolejny ekran, do którego ludzie się logują, a opowiesz złą historię.

Administratorzy i zespoły danych owszem otwierają ekrany Data 360, ale te ekrany są w orgu, w core. Tenant, który wykonuje pracę, jego dane i jego przetwarzanie działają poza core. Dlatego nazywam je near-core (blisko core): zarządzane w core, hostowane poza core (moduł 1 wyjaśnia te pojęcia). Rysunek idzie za tenantem: stoi razem z hydrauliką danych, z jedną linią z powrotem do orgu, który nim zarządza.

To, co robi, według słów Salesforce, obejmuje zero copy: technologię federacji danych, która pozwala przedsiębiorstwu uzyskiwać dostęp do danych i je odpytywać bez kopiowania (Zero Copy (opens in a new tab), po angielsku). Możliwości i konektory szybko się zmieniają, więc porządnie omawia je rozdział o Data 360, zamiast zamieniać ten moduł w wycieczkę po produkcie.

Czytaj krajobraz jako odpowiedzialności

Patrząc na krajobraz, nie czytaj logotypów; czytaj odpowiedzialności. ERP: czego jest właścicielem? Hurtownia: na jakie pytania odpowiada? Platforma integracyjna: co przenosi? IdP: kogo uwierzytelnia? MDM: jaką tożsamością zarządza? Data 360: co łączy i po co? Salesforce: za co naprawdę odpowiada? Gdy potrafisz na to odpowiedzieć, prostokąty zaczynają coś znaczyć, a strzałki między nimi stają się dużo ciekawsze. Dalej rysujemy je świadomie.

Co tu decyduje architekt

• Jaką rolę odgrywa każdy system, poza nazwą produktu.
• Który system jest nadrzędny dla każdego ważnego zbioru danych i gdzie Salesforce trzyma tylko lokalną kopię.
• Czy dane, których właścicielem jest ERP, są dostępne w Salesforce z kontrolowanym zapisem i jak tę własność widać w schemacie.
• Gdzie należy analityka, na podstawie tego, gdzie mieszkają dane.
• Gdzie na krajobrazie leżą tożsamość, integracja, zdarzenia i autorytet danych podstawowych.

Krajobraz z dziesięcioma prostokątami to nie architektura; to inwentarz. Architektura zaczyna się wtedy, gdy możesz wskazać każdy prostokąt i powiedzieć, dlaczego tam jest, czego jest właścicielem, kto z niego korzysta, czego Salesforce od niego potrzebuje i co się zepsuje, jeśli źle zrozumiesz jego rolę.

Do zgłębienia

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Pomoc Salesforce, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (strona produktu, po angielsku), sprawdzono 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (po angielsku).