Малюйте ландшафт раніше за org
Також доступно 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)
Розділ 4 курсу Data Architect, Частина 1: Стати архітектором даних. Попередній: Архітектура даних Salesforce.
Коли я навчаю кандидатів у CTA, домашнє завдання після першого дня завжди однакове. Прочитайте сценарій. Почніть системний ландшафт із чистого аркуша. А тоді, і лише тоді, візьміться за модель даних.
Людей дивує такий порядок. Ми ж архітектори даних; хіба не варто починати з моделі даних? Ось чому я так не роблю. Якщо я спершу малюю модель даних, я вже вирішив, що належить до Salesforce. Якщо я спершу малюю ландшафт, я бачу все, що має формувати це рішення: ERP, що володіє клієнтами й продуктами, сховище даних, що відповідає на запитання за п’ять років, постачальника ідентичності, що вирішує, хто заходить, партнера, що щодня по обіді надсилає файл, застарілу систему, яку, як усі кажуть, от-от виведуть з ужитку.
Розділи 2 і 3 проєктували org: якою має бути модель і як вона живе в Salesforce. Цей розділ відводить камеру і малює те, що оточує org, перш ніж org спроєктовано. Salesforce — одна система з багатьох, і досить часто не та, що володіє даними.
Зображення згенеровано ШІ.
Ідеї цього розділу
Section titled “Ідеї цього розділу ”- Ландшафт іде першим. Знайдіть системи, потім дані, що рухаються між ними, потім те, хто володіє кожною частиною. Лише тоді вирішуйте, яка робота Salesforce.
- Стрілка залежить від інших стрілок. Щоб замовлення пішли в ERP, спершу мають прийти клієнти, продукти й ціни. Щоразу, бачачи інтеграцію лише з одним потоком, я починаю непокоїтися.
- Дані бувають різних видів — і різних навантажень. Основні, довідкові, транзакційні дані, метадані, аналітичні й неструктуровані дані змінюються, зростають і використовуються по-різному; операційне (OLTP), аналітичне (OLAP) і потокове навантаження потребують різних домівок. Org веде бізнес; сховища даних і data lakes його аналізують.
- Системи мають ролі, а не лише логотипи. Облік, взаємодія, довідка, аналітика. «Salesforce — наша система обліку»: для чого?
- Аналітика живе там, де живуть дані. Усе в ядрі — стандартні звіти. Дані в інших сховищах — аналітична платформа, а коли дані Salesforce поєднують зі сховищем даних — саме сховище даних.
- Data 360 — поряд з ядром (near-core): керується в ядрі, розміщується поза ядром. Користувачі ніколи з ним не з’єднуються, тож він стоїть разом із «трубопроводом».
- Дані, якими володіє ERP, читаються локально, а записуються під контролем, із префіксом
erp_, щоб схема показувала, хто володіє кожним полем. - На ландшафті стрілка починається в системі, яка відкриває з’єднання, а її підпис каже, що рухається і в який бік. Два потоки — це дві стрілки; двобічна стрілка — лише для конектора.
- Кожна стрілка має клієнта й сервер, і кожен відповідає за свою половину. Нічого з цього не потрапляє на ландшафт, але це є в кожної стрілки.
- Порахуйте, перш ніж малювати стрілки. Нулі йдуть в інвентар, і вони обирають механізм: пакетний, синхронний чи події.
- Стратегія org — це рішення рівня ландшафту, ухвалене в перші хвилини: одна org чи кілька і де вона працює.
- Поточний стан показує, що не так. Червоне — поганий процес, пунктир — вручну, червоні точки — те, чого бракує.
Компонування ландшафту від Steve
Section titled “Компонування ландшафту від Steve ”Є багато способів малювати системний ландшафт. Це мій, відшліфований за багато років, і він читається як речення: люди ліворуч дістаються до Salesforce посередині, якому довіряють через системи над ним, який обслуговує через канали під ним і який з’єднаний із бек-офісом праворуч.
| Де | Що там |
|---|---|
| Ліворуч | Люди, згори донизу: внутрішні користувачі, партнери, клієнти |
| Посередині | Salesforce, один простий прямокутник, і спільноти, що торкаються його знизу |
| Угорі | Постачальники ідентичності над Salesforce; AppExchange зсунуто праворуч; публічні сайти вгорі ліворуч |
| Праворуч | Інтеграційний шар, потім внутрішні системи: ERP, фінанси, сховище даних |
| Під інтеграційним шаром | Data 360, поряд з ядром, разом із «трубопроводом» |
| Унизу | Клієнтські канали: пошта, вебформи, телефон, месенджери |
| Праворуч унизу | Дані на вході й виході: архіви, завантаження даних, зовнішні джерела, партнери |
Системи — це картки в блідих підписаних зонах, кожна з іконкою, а легенда пояснює, що все означає. За малюнком стоїть інвентар: для кожного набору даних чи потоку — його власник, обсяг, механізм і таймінг, автентифікація, а також чи копіювати його, посилатися на нього чи федерувати.
Ландшафт із модуля 4, зі стрілками.
Шлях через цей розділ
Section titled “Шлях через цей розділ ”Шість модулів, кожен самостійний.
- Salesforce — одна система з багатьох. Чому ландшафт іде раніше за прямокутник, інтеграція, яку я бачу знову і знову, і зворотні потоки, від яких вона залежить, дані хвилями, а також ядро, near-core і Hyperforce.
- Види корпоративних даних. Шість видів; створено, редаговано, посилаються; OLTP і OLAP; реальний час, майже реальний час і пакетна обробка; чотири запитання за категоріями.
- Системи навколо Salesforce. Ролі систем; ERP, сховище даних і lakehouse; аналітика йде за даними; MDM; інтеграція й події; постачальник ідентичності, про якого забувають розробники; де стоїть Data 360.
- Намалюйте системний ландшафт. Моє компонування, збудоване з чистого аркуша; нулі раніше за стрілки; стрілки, що починаються в ініціатора; клієнт і сервер за кожною стрілкою, в обидва боки; доріжки для розмов; інвентар за малюнком.
- Стратегія org — це рішення рівня ландшафту. Почніть з однієї org; що виправдовує другу; регіон, а не провайдер; поділ на AMER і EMEA через GDPR; що додає друга org.
- Ландшафт Steve Trucking. Сьогодні, до належного впровадження, з позначками: маніфести, що потрапляють у RouteDesk, маршрути, які вручну передруковують у Salesforce і назад, острів даних GPS, таблиця, що живить фінанси, і 108 000 дзвінків на рік «де моя доставка?».
Коли закінчите, перевірте себе за навчальним посібником до розділу: контрольний список для іспиту, звички, що виходять за його межі, ключові терміни і кілька запитань.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Які системи оточують Salesforce і яку роль грає кожна.
- Яка система володіє кожним важливим видом даних, перш ніж вирішувати, скільки з них зберігає Salesforce.
- Як працює кожне з’єднання: що рухається, в якому напрямку, як воно автентифікується, як швидко і що повертається.
- Скільки org і де вони працюють, вирішено першим, бо від цього залежить усе інше на ландшафті.
- Чи поточний стан зрозумілий достатньо добре, щоб проєктувати цільовий.
За межами іспиту: ландшафт стає картою для агентів. Перш ніж агент зможе відповісти «де моя доставка?», хтось має знати, яка система авторитетна для кожного факту, наскільки він актуальний і як агент може до нього дістатися. Кожен модуль завершується тим, що ШІ змінює для його частини картини.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (англійською, перевірено 2026-10-14).
- Додаткове читання для кандидатів на CTA: Salesforce Architects публікує власні настанови щодо діаграм, How to Build Salesforce Diagrams (opens in a new tab) (англійською).