Salesforce to jeden system z wielu

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

Pytanie, na które odpowiada ten moduł: dlaczego architekt danych rysuje to, co otacza org, zanim zaprojektuje org?

Kiedy uczę kandydatów na CTA, praca domowa po pierwszym dniu jest zawsze taka sama. Przeczytaj scenariusz. Zacznij krajobraz systemów od pustego płótna. Dopiero potem spróbuj modelu danych. Nie obiektów, nie szczegółów integracji: krajobrazu. Chcę zobaczyć, co otacza Salesforce, zanim zdecydujemy, co należy do jego wnętrza.

Dla wielu specjalistów Salesforce to zmiana perspektywy. Jeśli przez całą karierę pracujesz jako administrator albo programista, Salesforce jest naturalnie środkiem twojego świata. Otwierasz Konfigurację, tworzysz obiekty, budujesz Flow, piszesz Apex i integrujesz inne systemy z Salesforce. Wszystko wydaje się zaczynać od orgu. Architekt musi odsunąć kamerę, bo w przedsiębiorstwie Salesforce to jeden system z wielu, a dość często nie jest tym, który jest właścicielem danych.

Najpierw narysuj krajobraz

Rozdział 2 zbudował model logiczny, a rozdział 3 zapytał, jak żyje on w Salesforce. Teraz powiększę problem. Zanim zdecyduję, czego właścicielem powinien być Salesforce, chcę zrozumieć przedsiębiorstwo wokół niego. Jakie systemy już istnieją? Gdzie powstają klienci, gdzie definiuje się produkty, gdzie zaczynają się zamówienia, gdzie generuje się faktury? Gdzie mieszka tożsamość? Gdzie odbywa się analityka, gdzie przechowuje się dokumenty, gdzie leży historia? Które systemy potrzebują danych Salesforce, a od których Salesforce zależy?

Te pytania zmieniają architekturę. Zaczynam więc od pustego płótna, umieszczam Salesforce pośrodku i rysuję wszystko wokół. Moduł 4 pokazuje dokładnie, jak to układam. Na razie lekcja jest prosta: nie projektuj orgu, zanim zrozumiesz świat, w którym musi żyć.

Salesforce często nie jest systemem ewidencji

Weźmy bardzo typowe przedsiębiorstwo: Salesforce plus ERP, system planowania zasobów przedsiębiorstwa, taki jak SAP czy Oracle, który obsługuje finanse, produkty, zapasy, zakupy i realizację zamówień. Teraz zadaj proste pytanie: gdzie mieszka klient?

Może to być Salesforce, ERP albo oba, i tu robi się ciekawie. Handlowcy mogą prowadzić potencjalnych klientów jako konta w Salesforce, a ERP nadaje oficjalny numer klienta dopiero wtedy, gdy ktoś zacznie płacić. Produkty i ceny? Pewnie ERP. Zapasy? Prawie nigdy Salesforce. Zamówienia mogą być rejestrowane w Salesforce, a realizowane w ERP; faktury pochodzą z ERP; serwis mieszka w Salesforce; analityka dzieli się między raporty Salesforce a hurtownię. Nagle nasz ładny model danych Salesforce nie jest modelem danych przedsiębiorstwa. Jest jego częścią.

Integracja, którą widzę raz za razem

Najczęstsza integracja, jaką widzę, wygląda tak: klienci, produkty i ceny płyną do Salesforce z ERP, a zamówienia płyną na zewnątrz. Wstaw w to miejsce SAP, Oracle albo dowolny inny ERP; kształt jest ten sam. ERP jest właścicielem złotego rekordu (golden record) klienta i produktu, więc te przepływy przychodzą z prawej strony, do Salesforce. Dział sprzedaży zamyka transakcję w Salesforce, więc zamówienie zaczyna się tam i wraca do ERP, żeby zostało zrealizowane, zafakturowane i zaksięgowane.

Te przepływy to nie tylko integracje. Mówią mi, gdzie według przedsiębiorstwa mieszka prawda.

Jednokierunkowe strzałki mnie niepokoją

Kiedy widzę integrację, która ma tylko jeden przepływ, zaczynam się niepokoić. Na wysokim poziomie ktoś rysuje jedną strzałkę: zamówienia z Salesforce do ERP. W porządku. Teraz spójrz głębiej. Jak mogę wysłać zamówienie do ERP, jeśli nie znam jego klientów, produktów ani cen? Zamówienie musi być powiązane z klientem, którego ERP już ma, a każda pozycja musi być SKU, które ERP już sprzedaje. Nie mogę wysłać pozycji zamówienia dla produktu, który nie istnieje po drugiej stronie. Zanim więc ta strzałka zamówień zacznie działać, muszą istnieć przepływy zwrotne, biegnące w przeciwną stronę.

To pytanie zadaję każdej strzałce: od czego zależy ten przepływ? Strzałka na wysokim poziomie, którą widać, zwykle potrzebuje przepływów zwrotnych, których jeszcze nie narysowano.

Spójrz jeszcze głębiej, a znajdziesz drogę powrotną. Salesforce wysyła zamówienie. I co dalej? Zostało przyjęte czy odrzucone? Zostało wysłane, wysłane częściowo, anulowane? Zafakturowane? Czy ktoś w Salesforce musi o tym wiedzieć? Może nie musi. Ale ktoś powinien był zapytać. Jeśli nic nie wraca, w porządku. Powiedz mi dlaczego.

Przedsiębiorstwo nie powstało od razu

Krajobrazy się komplikują między innymi dlatego, że nikt nie zbudował ich naraz. Dane przychodziły falami. Najpierw pliki: rekordy o stałym formacie, potem pliki rozdzielane separatorem, takie jak CSV. Potem relacyjne bazy danych dla danych operacyjnych. Potem hurtownie danych, żeby zebrać je razem do analizy. Potem bazy NoSQL dla dokumentów, par klucz-wartość i grafów, które nie mieszczą się zgrabnie w tabelach. Potem data lake dla ogromnych ilości surowych i półustrukturyzowanych danych oraz lakehouse, który łączy jedno z drugim. Strumienie zdarzeń, takie jak Kafka czy szyna zdarzeń Salesforce, przenoszą dane w chwili, gdy coś się dzieje, zamiast w nocnych partiach. A teraz federacja, w której dane nie muszą być kopiowane w jedno miejsce, zanim inna platforma będzie mogła ich użyć.

Technologia nie jest jeszcze tu najważniejsza. Ważne jest to: nowa fala rzadko sprawia, że stara znika. Wejdź do dużego przedsiębiorstwa, a znajdziesz je wszystkie naraz: relacyjne bazy danych, ERP, Salesforce, hurtownię, data lake, zrzuty SFTP, API, strumienie zdarzeń, arkusz kalkulacyjny, który ktoś wciąż wysyła mailem w każdy piątek, i ten jeden system, którego wszyscy boją się dotknąć, bo osoba, która go zbudowała, przeszła na emeryturę sześć lat temu. To jest przedsiębiorstwo, dla którego projektujesz architekturę, a nie to z broszury produktowej.

Różne systemy istnieją z różnych powodów

Dlatego też nigdy nie zaczynam od pytania „jak wprowadzić wszystkie dane do Salesforce?”. Po co miałbym chcieć mieć je tam wszystkie? Salesforce może być najlepszym miejscem, w którym handlowcy i serwisanci pracują z klientami. To nie czyni z niego systemu finansowego, hurtowni danych przedsiębiorstwa, magazynu telemetrii, archiwum dokumentów ani domu dla każdego kliknięcia, odczytu GPS i historycznej transakcji, jakie firma kiedykolwiek wytworzyła.

Rozdział 3 pytał, gdzie powinny mieszkać te dane?, dla jednego orgu. Na poziomie przedsiębiorstwa to samo pytanie staje się większe: czasem Salesforce jest właścicielem danych, czasem trzyma kopię, czasem tylko odwołanie, a czasem w ogóle nie powinien ich mieć.

Core, poza core i Hyperforce

Jest jeszcze jedna granica do zrozumienia: nawet „Salesforce” to nie jedno środowisko uruchomieniowe i jedna baza danych. W rozdziale 3 w core oznaczało, gdzie leżą dane: na twoim biurku, we własnych obiektach orgu. Tutaj te same słowa opisują, gdzie działa produkt. Usłyszysz, jak architekci używają obu znaczeń.

Historycznie środowisko Core obsługiwało większość platformy. Dziś Salesforce opisuje platformę złożoną z setek niezależnych usług sterowanych metadanymi, w której Core pozostaje jedynym systemem ewidencji metadanych aplikacji (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), po angielsku). Dlatego usłyszysz, jak architekci mówią, że dana funkcja działa w core albo poza core.

Miało to znaczenie na długo przed tym, zanim platforma podzieliła się na usługi. Kiedy pytam grupę, dlaczego Salesforce kupił SteelBrick do ofertowania, a nie Apttus, odpowiedź, na którą czekam, jest prosta: SteelBrick był zbudowany w 100% w core. Flow i triggery żyją w core, więc produkt zbudowany tam dostaje wraz z nim metadane, dostosowania i automatyzację platformy. Ten produkt do ofertowania ustąpił już miejsca Revenue Cloud, ale lekcja pozostała. Jest też blisko core (near-core), a moim przykładem jest Data 360. Data 360 to nie core. Jego tenant jest poza core: dane i mechanizmy, które je przetwarzają, działają we własnym lakehouse, obok relacyjnej bazy danych orgu, a nie w jej wnętrzu (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), po angielsku). Ale ekrany, których używasz, żeby go skonfigurować i nim sterować, są wyświetlane w core, w orgu. Najprecyzyjniej mogę to ująć tak: zarządzany w core, hostowany poza core. Żadne dane ani przetwarzanie nie działają faktycznie w Core; interfejs na Core steruje tenantem poza core. No i oczywiście jest wszystko, co jest poza core, bo w ogóle nie jest Salesforce.

Mniej mi zależy na zapamiętaniu, który produkt działa gdzie w tym roku, bo to się zmienia, a bardziej na nawyku: granica może wpływać na przepływ danych, opóźnienia, tożsamość, integrację i rezydencję danych. Nie zakładaj więc, że skoro produkt ma w nazwie Salesforce, jego dane leżą tuż obok twoich rekordów kont. Przyjrzyj się prawdziwej architekturze.

Do tego dochodzi Hyperforce: infrastruktura Salesforce zbudowana dla chmury publicznej i zdefiniowana jako kod, zamiast tradycyjnych, własnych centrów danych, dająca klientom większy wybór co do tego, gdzie przechowywane są ich dane (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), po angielsku). To ma znaczenie, a moduł 5 do tego wraca. Ale architektura infrastruktury to nie architektura danych przedsiębiorstwa. Przeniesienie orgu do chmury publicznej nie mówi ci, kto jest właścicielem klienta, gdzie mieszkają zapasy, gdzie działa analityka ani które dane mogą przekroczyć granicę. Hyperforce może kształtować część tych decyzji, zwłaszcza dotyczących rezydencji. Nie zastępuje znajomości krajobrazu.

Krajobraz przed prostokątem

Oto więc nawyk. Ktoś daje ci scenariusz. Nie zaczynaj budować rozwiązania w Salesforce. Najpierw znajdź systemy: ERP, dostawcę tożsamości, hurtownię, platformę integracyjną, systemy partnerów, kanały klientów, magazyny dokumentów. Potem znajdź dane, które przepływają między nimi: klientów, produkty, zamówienia, faktury, dokumenty, zdarzenia, tożsamości. Potem zapytaj, kto jest właścicielem każdego z nich. Dopiero wtedy zdecyduj, co należy do Salesforce. Inaczej projektujesz prostokąt, nie wiedząc, z czym się łączy.

Click to enlarge

Krok 1 z 3: projektowany przez nas org, sam. Stąd wygląda jak cały świat.

Click to enlarge

Krok 2 z 3: oddal widok. Salesforce to jeden system spośród wielu (tego układu uczy moduł 4).

Click to enlarge

Krok 3 z 3: pierwsze strzałki. Klienci, produkty i ceny przychodzą z ERP, zamówienia wychodzą: strzałki mówią, gdzie według firmy mieszka prawda.

Krajobraz zmienia model danych

Oto dlaczego to ważne dla architekta danych. Rozdział 2 mówi, że klient to ważna encja. Dobrze. Potem krajobraz mówi, że ERP jest nadrzędny dla klienta. To zmienia model fizyczny. Salesforce może nadal trzymać lokalne konto, bo ludzie używają go codziennie, ale teraz potrzebujemy identyfikatora z ERP jako External ID; musimy wiedzieć, które pola Salesforce może zmieniać (pola ERP oznaczam prefiksem erp_, jak zobaczymy w module 3); jak szybko przychodzą zmiany z ERP; czy Salesforce może utworzyć klienta, zanim ERP się o nim dowie; i co się dzieje, gdy oba systemy się nie zgadzają. To nie są pytania o integrację na później. To pytania o architekturę danych, a krajobraz je ujawnił.

Oto jak jedna z nich potrafi ugryźć. Handlowiec konwertuje potencjalnego klienta (lead) dla dużej firmy napojowej, tworzy konto, wygrywa transakcję, a klient trafia do ERP. Ale firma od lat robi interesy z tą firmą napojową i ERP już ją ma. Teraz są dwie. Czy handlowiec w ogóle powinien móc utworzyć to konto? Rozdziały 5 i 6 do tego wracają; to w krajobrazie widać, że to nadchodzi.

Co tu decyduje architekt

• Jakie systemy otaczają Salesforce i jaką rolę odgrywa każdy z nich.
• Który system jest właścicielem każdego ważnego rodzaju danych, zanim zapadnie decyzja, ile z nich trzyma Salesforce.
• Co płynie do Salesforce, co płynie na zewnątrz i co wraca.
• Które dane Salesforce powinien posiadać, kopiować, wskazywać, federować, archiwizować albo zostawić w spokoju.
• Które granice platformy i infrastruktury mają znaczenie, zamiast zakładać, że wszystko z marką Salesforce mieszka w jednym miejscu.

Przejście od programisty do architekta to często nie nauka kolejnej funkcji. To nauka tego, kiedy przestać patrzeć na Salesforce: odsunąć kamerę, iść za danymi, znaleźć właściciela prawdy, a potem wrócić i zdecydować, jakie zadanie powinien mieć Salesforce.

Do zgłębienia

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Pomoc Salesforce, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.