Системи навколо Salesforce

🌐 Також доступно 28 мовами

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) · Deutsch (Schweiz)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 3 з 6 розділу Розуміння корпоративних даних, розділ 4 курсу Data Architect. Кожен модуль самостійний. Попередній: Види корпоративних даних · Наступний: Намалюйте системний ландшафт

Питання, на яке відповідає цей модуль: Що оточує Salesforce і яку роль грає кожна система?

Попередній модуль розсортував дані. Тепер я хочу їх кудись покласти, і саме тут архітектори Salesforce потрапляють у біду. Ми знаємо Salesforce, тож дані клієнтів означають Account, дані замовлень — Order, документи — Files, аналітика — Reports. Але підприємство купило Salesforce не для того, щоб замінити все інше, чим володіє. Може бути ERP, що веде фінанси й виконання замовлень, сховище даних із роками історії, інтеграційна платформа, постачальник ідентичності, системи партнерів, платформа подій, MDM-платформа і Data 360, що з’єднує кілька з них. Робота не в тому, щоб завчити технології. Вона в тому, щоб розуміти, яка робота в кожної системи.

Не починайте з назви продукту

«У нас SAP» — мені цього недостатньо. Як і Snowflake, MuleSoft, Tableau чи Data 360. Я хочу знати, що ця система робить у цій архітектурі: якими даними володіє, що читає, що змінює, хто нею користується, що від неї залежить, що станеться, коли вона впаде. Дві компанії можуть мати точно ті самі продукти і зовсім різні архітектури.

Тож я позначаю системи за роллю. Чотири ролі покривають більшість:

• Система обліку (system of record): де підтримується авторитетна версія чогось.
• Система взаємодії (system of engagement): де люди виконують роботу.
• Довідкова система (system of reference): куди система йде по інформацію, яка їй потрібна, але якою вона не володіє.
• Аналітична система (system of insight): де дані сходяться, щоб вимірювати, аналізувати й прогнозувати.

Одна платформа може грати кілька ролей, і ролі різняться залежно від даних. Salesforce може бути системою обліку для звернень, системою взаємодії для сервісних агентів і споживачем даних про продукти, якими володіє ERP. Тож коли хтось каже «Salesforce — наша система обліку», закінчіть речення: система обліку для чого?

ERP: у бек-офісу є гравітація

ERP — система, яку найчастіше знайдете поруч із Salesforce; вона веде фінанси, запаси, закупівлі, виконання замовлень і виставлення рахунків. Шаблон із модуля 1 (клієнти й продукти всередину, замовлення назовні) означає, що ERP володіє продуктами, але продавцям вони досі потрібні в Salesforce. Гаразд: заведіть їх. Але копіювання даних не передає власності. Копія — не авторитетність.

Моя позиція: дані, якими володіє ERP, читаються локально, а записуються під контролем. Користувачі Salesforce отримують дані там, де працюють, але Salesforce не може змінювати те, чим володіє ERP. І я роблю це видимим у схемі: поля ERP мають префікс erp_, як-от erp_Product_Number__c, щоб кожен, хто читає об’єкт, знав, хто володіє кожним полем, і був обережним зі змінами. Префікс нічого не примушує; це роблять дозволи, перевірки та інтеграційний шаблон. Він повідомляє намір, і це карта авторитетності, зроблена видимою.

Сховище даних, data lake і lakehouse

Операційні системи ведуть бізнес; аналітичні допомагають його розуміти. «Покажи мої відкриті можливості» — звіт Salesforce. «Покажи п’ять років продажів, виконання замовлень, повернень, звернень, запасів і фінансів по всіх каналах» — інша задача.

Ви зустрінете три види аналітичних сховищ. Сховище даних (data warehouse) містить структуровані дані, підготовлені для аналізу. Data lake містить значно більше даних у більшій кількості форм, часто сирих. Lakehouse поєднує обидва: зберігання в стилі lake з аналізом у стилі warehouse. Знайте їх, бо вони з’являються на ландшафтах. Але мій досвід такий: lakehouses і data mesh досі нішеві в проєктах Salesforce. Типовий ландшафт — CRM, ERP, сховище даних та інтеграційний шар, з іншими платформами там, де бізнесу вони справді потрібні. Вивчайте архітектуру; не ганяйтеся за словником.

Аналітика живе там, де живуть дані

Це одна з моїх найтвердіших позицій: аналітика живе там, де живуть дані. Якщо звітові потрібні лише акаунти, можливості й продавці, усе в ядрі: стандартні звіти й дашборди. Потім бізнес просить додати рахунки з ERP. Потім собівартість продуктів. Потім п’ять років замовлень зі сховища даних. Потім активність на сайті. У якийсь момент тягнути все це в операційну CRM лише заради звітів перестає мати сенс. Щойно залучені інші сховища даних, стає потрібною аналітична платформа: Tableau (зокрема Tableau Next, побудований на Data 360) або CRM Analytics там, де вона вже використовується. Вона необхідна, коли дані Salesforce поєднують зі сховищем даних. Вимога не просто ускладнилася; ландшафт змінив, де треба відповідати на запитання. Тож я ніколи не починаю з «який інструмент аналітики?» Я починаю з де лежать дані?

Я питаю кандидатів на CTA те саме: «Яка з моїх діаграм розв’язує це найкраще? Ландшафт». Якщо все в ядрі — використовуйте звіти. Якщо у вас дані в інших репозиторіях, я хочу бачити аналітичну платформу. Ландшафт відповідає на питання звітності ще до того, як хтось відкриє конструктор звітів. (Назви продуктів змінюються; розділ про Data 360 розповідає, де аналітика Salesforce перебуває сьогодні.)

MDM: хто цей клієнт насправді?

Тепер припустімо, що інформація про клієнтів живе в Salesforce, ERP, електронній комерції, платформі лояльності й системі партнера, і кожна з них думає, що знає, хто клієнт. Тут з’являється управління основними даними (MDM): встановлення й врядування авторитетної ідентичності ключових даних у різних системах. Але MDM — не «головна база клієнтів». Складні запитання — яка система може створювати клієнта, якими атрибутами володіє кожна система, як знаходять дублікати, який ідентифікатор виживає і що стається, коли системи не згодні. Про це весь розділ 6. Тут розпізнайте роль: якщо MDM-платформа існує, вона може бути критичною авторитетною ланкою між Salesforce і рештою підприємства.

Інтеграційний шар і події

З’єднайте кожну систему безпосередньо з кожною іншою, і ландшафт швидко перетвориться на спагеті. Тому в підприємствах є інтеграційний шар: ESB (enterprise service bus) чи iPaaS (integration platform as a service). MuleSoft — те, що найчастіше зустрінете на ландшафтах Salesforce. Він посередничає, щоб кожному застосунку не треба було розуміти кожен інший.

Але прямокутник MuleSoft посередині не робить інтеграцію доброю. Я досі хочу знати, що через нього проходить, а що ні, хто перетворює дані, хто володіє контрактом, що стається, коли пункт призначення недоступний, синхронно це чи асинхронно і як ми знаємо, що повідомлення дійшло. Курс Integration Architect іде вглиб; тут розпізнайте це як окрему роль.

І не кожна інтеграція — це система A, що викликає систему B. Іноді щось стається (створено замовлення, доставка змінила статус, вантажівка в’їхала в регіон), публікується подія, і всі зацікавлені реагують. Події в русі теж мають інфраструктуру: власні можливості подій Salesforce, корпоративну шину подій, інші засоби обміну повідомленнями. Малюйте механізми, що несуть дані, а не лише бази даних.

Система, про яку забувають розробники: ідентичність

Є один прямокутник, який я завжди хочу бачити на ландшафті і про який розробники рідко думають: постачальник ідентичності. Розробники входять у свої sandboxes просто з логіном і паролем, тож під час розробки ідентичність невидима. Потім настає UAT чи продакшн, і раптом з’являється корпоративний single sign-on для співробітників, можливо, другий постачальник для партнерів, соціальний вхід для клієнтів. Ідентичність завжди була частиною архітектури. Розробник просто ще її не бачив.

Постачальник ідентичності (IdP) — система, що автентифікує користувача і встановлює ідентичність, якій довіряє Salesforce. Йому місце на ландшафті з першого дня, навіть якщо налаштовують його пізніше в конвеєрі випусків, бо хто може увійти, вирішує, хто може дістатися до даних.

Є й практичний нюанс: конфігурацію ідентичності можна розгортати, але не повністю. Конфігурація SAML single sign-on і постачальники автентифікації — типи Metadata API, тож вони проходять конвеєром (SamlSsoConfig (opens in a new tab)). Але consumer secrets постачальників автентифікації більше не повертаються у відповідях Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), а сертифікати зазвичай різняться між середовищами. Плануйте частини, що переїжджають, і частини, що ні.

Click to enlarge

Читайте ландшафт як ролі, а не логотипи: чим кожна система володіє, що читає чи що вирішує.

Де стоїть Data 360?

Data 360 породжує гарне запитання про малювання. Я ставлю його праворуч, під ESB чи MuleSoft. Причина — його з’єднання: користувачі ніколи не з’єднуються з ним безпосередньо, а він безпосередньо з’єднується з багатьма бекенд-системами. Тож йому місце разом із «трубопроводом» даних, де ці лінії лишаються короткими, а не з користувачами. Намалюйте його як ще один екран, куди входять люди, — і ви розповідаєте не ту історію.

Адміністратори й команди даних справді відкривають екрани Data 360, але ці екрани — в org, в ядрі. Тенант, який виконує роботу, — його дані й обробка — працює поза ядром. Тому я називаю його поряд з ядром (near-core): керується в ядрі, розміщується поза ядром (модуль 1 пояснює ці терміни). Малюнок іде за тенантом: він стоїть разом із «трубопроводом», з однією лінією назад до org, яка ним керує.

Те, що він робить, словами Salesforce, включає zero copy: технологію федерації даних, що дає підприємству змогу звертатися до даних і запитувати їх без копіювання (Zero Copy (opens in a new tab)). Можливості й конектори швидко змінюються, тож розділ про Data 360 розглядає їх як слід, а не перетворює цей модуль на огляд продукту.

Читайте ландшафт як відповідальності

Дивлячись на ландшафт, не читайте логотипи; читайте відповідальності. ERP: чим вона володіє? Сховище даних: на які запитання воно відповідає? Інтеграційна платформа: що вона переносить? IdP: кого він автентифікує? MDM: якою ідентичністю керує? Data 360: що він з’єднує і для чого? Salesforce: за що він насправді відповідає? Щойно ви можете на це відповісти, прямокутники щось означають, а стрілки між ними стають набагато цікавішими. Далі ми малюємо їх свідомо.

Що тут вирішує архітектор

• Яку роль грає кожна система, понад назву продукту.
• Яка система авторитетна для кожного важливого набору даних і де Salesforce тримає лише локальну копію.
• Чи доступні дані, якими володіє ERP, у Salesforce із контрольованим записом і як ця власність видна в схемі.
• Де місце аналітиці, виходячи з того, де живуть дані.
• Де на ландшафті стоять ідентичність, інтеграція, події та авторитетність щодо основних даних.

Ландшафт із десятьма прямокутниками — не архітектура; це інвентар. Архітектура починається, коли ви можете показати на кожен прямокутник і сказати, чому він там, чим володіє, хто ним користується, що Salesforce від нього потрібно і що зламається, якщо неправильно зрозуміти його роль.

Додаткові матеріали

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (сторінка продукту, англійською, перевірено 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 (англійською).