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)

From a hilltop at dawn, one house in the foreground and a whole valley town beyond: streets, a factory, warehouses, a rail line and a river. — Зображення згенеровано ШІ

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

Питання, на яке відповідає цей модуль: Чому архітектор даних малює те, що оточує org, перш ніж проєктувати саму org?

Коли я навчаю кандидатів у CTA, домашнє завдання після першого дня завжди однакове. Прочитайте сценарій. Почніть системний ландшафт із чистого аркуша. Лише потім візьміться за модель даних. Не за об’єкти, не за інтеграції в деталях: за ландшафт. Я хочу бачити, що оточує Salesforce, перш ніж ми вирішимо, що належить усередину.

Для багатьох фахівців Salesforce це зміна погляду. Якщо всю кар’єру ви були адміністратором чи розробником, Salesforce природно є центром вашого світу. Ви відкриваєте Setup, створюєте об’єкти, будуєте flows, пишете Apex і інтегруєте інші системи в Salesforce. Усе ніби починається з org. Архітектор має відвести камеру, бо в підприємстві Salesforce — одна система з багатьох, і досить часто не та, що володіє даними.

Спершу намалюйте ландшафт

Розділ 2 побудував логічну модель, а розділ 3 запитав, як вона живе в Salesforce. Тепер я зроблю задачу більшою. Перш ніж вирішувати, чим має володіти Salesforce, я хочу зрозуміти підприємство навколо. Які системи вже існують? Де створюються клієнти, визначаються продукти, починаються замовлення, генеруються рахунки? Де живе ідентичність? Де відбувається аналітика, де зберігаються документи, де лежить історія? Яким системам потрібні дані Salesforce, а від яких залежить Salesforce?

Ці запитання змінюють архітектуру. Тож я починаю з чистого аркуша, ставлю Salesforce посередині й малюю все навколо. Модуль 4 точно показує, як я це компоную. Поки що урок простий: не проєктуйте org, перш ніж зрозумієте світ, у якому їй доведеться жити.

Salesforce часто не є системою обліку

Візьміть дуже поширене підприємство: Salesforce плюс ERP, система планування ресурсів підприємства, як-от SAP чи Oracle, що веде фінанси, продукти, запаси, закупівлі й виконання замовлень. Тепер поставте просте запитання: де живе клієнт?

Це може бути Salesforce, ERP або обидва, і тут стає цікаво. Продавці можуть вести потенційних клієнтів як Accounts у Salesforce, а ERP видає офіційний номер клієнта, щойно той стає платником. Продукти й ціни? Мабуть, ERP. Запаси? Майже ніколи не Salesforce. Замовлення можуть фіксувати в Salesforce і виконувати в ERP; рахунки йдуть з ERP; сервіс живе в Salesforce; аналітика поділена між звітами Salesforce і сховищем даних. Раптом наша гарна модель даних Salesforce — не модель даних підприємства. Вона лише її частина.

Інтеграція, яку я бачу знову і знову

Найпоширеніша інтеграція, яку я бачу, така: клієнти, продукти й ціни течуть у Salesforce з ERP, а замовлення течуть назад. Підставте SAP, Oracle чи будь-яку іншу ERP — форма та сама. ERP володіє golden record (еталонним записом) клієнта й продукту, тож ці потоки приходять справа, у Salesforce. Продажі закривають угоду в Salesforce, тож замовлення починається там і повертається в ERP, щоб його виконали, виставили рахунок і облікували.

Ці потоки — не просто інтеграції. Вони кажуть мені, де, на думку підприємства, живе правда.

Однобічні стрілки мене непокоять

Щоразу, бачачи інтеграцію лише з одним потоком, я починаю непокоїтися. На високому рівні хтось малює одну стрілку: замовлення із Salesforce в ERP. Гаразд. Тепер подивіться глибше. Як я можу надіслати замовлення в ERP, якщо не знаю її клієнтів, продуктів чи цін? Замовлення має бути прив’язане до клієнта, який в ERP уже є, і кожен рядок має бути SKU, який ERP уже продає. Я не можу надіслати рядок для продукту, якого на іншому боці не існує. Тож перш ніж ця стрілка замовлень запрацює, мають існувати зворотні потоки, що йдуть в інший бік.

Це запитання я ставлю кожній стрілці: від чого залежить цей потік? Стрілка високого рівня, яку ви бачите, зазвичай потребує зворотних потоків, яких ви ще не намалювали.

Подивіться ще глибше — і знайдете зворотний шлях. Salesforce надсилає замовлення. А далі? Його прийняли чи відхилили? Його відвантажили, частково відвантажили, скасували? Виставили рахунок? Чи треба комусь у Salesforce про це знати? Можливо, ні. Але хтось мав запитати. Якщо нічого не повертається — гаразд. Поясніть чому.

Підприємство виникло не одразу

Ландшафти ускладнюються частково тому, що ніхто не будував їх одразу. Дані приходили хвилями. Спершу файли: записи фіксованого формату, потім файли з роздільниками, як-от CSV. Потім реляційні бази для операційних даних. Потім сховища даних, щоб звести все разом для аналізу. Потім NoSQL-бази для документів, пар «ключ–значення» і графів, які не вкладаються акуратно в таблиці. Потім data lakes для величезних обсягів сирих і напівструктурованих даних, і lakehouses, що поєднують обидва підходи. Потоки подій, як-от Kafka чи шина подій Salesforce, переносять дані в момент, коли щось стається, а не нічними пакетами. А тепер федерація, де дані не треба спершу копіювати в одне місце, щоб інша платформа могла ними користуватися.

Технології поки не головне. Головне ось що: нова хвиля рідко змушує стару зникнути. Зайдіть у велике підприємство, і ви знайдете їх усі водночас: реляційні бази, ERP, Salesforce, сховище даних, data lake, SFTP-файли, API, потоки подій, таблицю, яку хтось досі надсилає щоп’ятниці, і ту одну систему, якої всі бояться торкатися, бо людина, що її збудувала, пішла на пенсію шість років тому. Це підприємство, для якого ви проєктуєте архітектуру, а не те, що з рекламної брошури.

Різні системи існують з різних причин

Ось чому я ніколи не починаю з «як нам завести всі дані в Salesforce?» Навіщо мені там усі дані? Salesforce може бути найкращим місцем для продавців і сервісних працівників, щоб працювати з клієнтами. Це не робить його фінансовою системою, корпоративним сховищем даних, сховищем телеметрії, архівом документів чи домом для кожного кліку, кожного показання GPS і кожної історичної транзакції, яку компанія будь-коли створила.

Розділ 3 питав де мають жити ці дані? для однієї org. На рівні підприємства те саме запитання стає більшим: іноді Salesforce володіє даними, іноді тримає копію, іноді лише посилання, а іноді взагалі не має їх мати.

Core, off-core і Hyperforce

Є ще одна межа, яку треба розуміти: навіть «Salesforce» — це не одне середовище виконання й не одна база даних. У розділі 3 в ядрі (on core) означало, де лежать дані: на вашому столі, у власних об’єктах org. Тут ті самі слова описують, де працює продукт. Ви почуєте, як архітектори вживають обидва значення.

Історично більшу частину платформи хостило середовище Core. Сьогодні Salesforce описує платформу із сотень незалежних сервісів, керованих метаданими, де Core лишається єдиною системою обліку метаданих застосунків (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Тому ви чуєте, як архітектори кажуть, що можливість працює в ядрі чи поза ядром (off core).

Це мало значення задовго до того, як платформа розділилася на сервіси. Коли я питаю аудиторію, чому Salesforce купив SteelBrick для квотування, а не Apttus, відповідь, якої я чекаю, проста: SteelBrick був побудований на 100% в ядрі. Flows і тригери живуть у ядрі, тож продукт, побудований там, отримує разом із ним метадані, кастомізації й автоматизацію платформи. Той продукт для квотування відтоді поступився Revenue Cloud, але урок лишився. Далі є поряд з ядром (near-core), і приклад, який я використовую, — Data 360. Data 360 — не ядро. Його тенант (tenant) поза ядром: дані й механізми, що їх обробляють, працюють у власному lakehouse, поруч із реляційною базою org, а не всередині неї (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Але екрани, якими ви його налаштовуєте й керуєте, показуються в ядрі, в org. Тож найточніше я можу сказати так: керується в ядрі, розміщується поза ядром. Жодні дані чи обробка насправді не працюють у Core; інтерфейс у Core керує тенантом поза ядром. А далі, звісно, є все, що поза ядром, бо це взагалі не Salesforce.

Мені менш важливо завчити, який продукт де працює цього року, бо це змінюється, ніж звичка: межа може впливати на рух даних, затримку, ідентичність, інтеграцію і резидентність даних. Тож не припускайте, що коли продукт називається Salesforce, його дані лежать просто поруч із вашими записами Account. Дивіться на реальну архітектуру.

А ще є Hyperforce: інфраструктура Salesforce, збудована для публічної хмари й визначена як код, замість традиційних власних дата-центрів, що дає клієнтам більше вибору, де зберігаються їхні дані (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Це важливо, і модуль 5 до цього повертається. Але архітектура інфраструктури — не архітектура корпоративних даних. Перенесення org у публічну хмару не каже вам, хто володіє клієнтом, де живуть запаси, де працює аналітика чи які дані можуть перетинати кордон. Hyperforce може формувати деякі з цих рішень, особливо щодо резидентності. Він не замінює знання ландшафту.

Ландшафт іде раніше за прямокутник

Тож ось звичка. Хтось дає вам сценарій. Не починайте будувати рішення Salesforce. Спершу знайдіть системи: ERP, постачальника ідентичності, сховище даних, інтеграційну платформу, системи партнерів, клієнтські канали, сховища документів. Потім знайдіть дані, що рухаються між ними: клієнти, продукти, замовлення, рахунки, документи, події, ідентичності. Потім запитайте, хто володіє кожним із них. Лише тоді вирішуйте, що належить до Salesforce. Інакше ви проєктуєте прямокутник, не знаючи, з чим він з’єднаний.

Click to enlarge

Крок 1 з 3: org, яку ми проєктуємо, сама по собі. Звідси вона здається цілим світом.

Click to enlarge

Крок 2 з 3: віддаліться. Salesforce — одна система з багатьох (цього компонування навчає модуль 4).

Click to enlarge

Крок 3 з 3: перші стрілки. Клієнти, продукти й ціни надходять з ERP, замовлення виходять: стрілки показують, де, на думку підприємства, живе правда.

Ландшафт змінює модель даних

Ось чому це важливо для архітектора даних. Розділ 2 каже, що клієнт — важлива сутність. Гаразд. А потім ландшафт каже, що ERP авторитетна щодо клієнта. Це змінює фізичну модель. Salesforce досі може тримати локальний Account, бо люди користуються ним щодня, але тепер нам потрібен ідентифікатор ERP як External ID; треба знати, які поля Salesforce може змінювати (я позначаю поля ERP префіксом erp_, як побачимо в модулі 3); як швидко надходять зміни з ERP; чи може Salesforce створити клієнта до того, як про нього дізнається ERP; і що станеться, коли вони не збігатимуться. Це не інтеграційні запитання на потім. Це запитання архітектури даних, і ландшафт їх виявив.

Ось як одне з них кусає. Продавець конвертує лід великої компанії-виробника напоїв, створює Account, виграє угоду, і клієнт переходить в ERP. Але компанія роками вела справи з цим виробником напоїв, і в ERP він уже є. Тепер їх двоє. Чи мав продавець узагалі змогу створити цей Account? Розділи 5 і 6 до цього повертаються; ландшафт — це місце, де ви бачите це заздалегідь.

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

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

Перехід від розробника до архітектора часто полягає не в тому, щоб вивчити ще одну функцію. Він у тому, щоб навчитися, коли перестати дивитися на Salesforce: відвести камеру, піти за даними, знайти, хто володіє правдою, а потім повернутися й вирішити, якою має бути робота Salesforce.

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

Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (англійською, перевірено 2026-10-14).
Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (англійською, перевірено 2026-10-14).