Нарисуйте ландшафт раньше, чем 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 — одна система из многих, и довольно часто не он владеет данными.
Изображение создано с помощью ИИ.
Идеи этой главы
Заголовок раздела «Идеи этой главы »- Сначала ландшафт. Найдите системы, затем данные, которые движутся между ними, затем того, кто владеет каждой частью. Только после этого решайте, в чем работа Salesforce.
- Стрелка зависит от других стрелок. Чтобы заказы уходили в ERP, сначала должны прийти клиенты, продукты и цены. Когда я вижу интеграцию только с одним потоком, я начинаю беспокоиться.
- У данных есть виды и нагрузки. Мастер-данные, справочные, транзакционные, метаданные, аналитические и неструктурированные данные меняются, растут и используются по-разному; операционной (OLTP), аналитической (OLAP) и потоковой нагрузкам нужны разные дома. Org ведет бизнес; хранилища и озера данных его анализируют.
- У систем есть роли, а не только логотипы. Записи, взаимодействия, справочная, аналитическая. «Salesforce — наша система записи»: для чего?
- Где живет аналитика, зависит от того, где живут данные. Все в ядре — стандартные отчеты. Данные в других хранилищах — аналитическая платформа, а когда данные Salesforce объединяются с хранилищем данных, то и оно.
- Data 360 находится рядом с ядром (near-core): управляется в ядре, размещается вне ядра. Пользователи к нему никогда не подключаются, поэтому он стоит рядом с «трубопроводом».
- Данные, которыми владеет ERP, читаются локально и записываются под контролем, с префиксом
erp_, чтобы по схеме было видно, кто владеет каждым полем. - На ландшафте стрелка начинается у системы, которая открывает соединение, а ее подпись говорит, что движется и в какую сторону. Два потока — две стрелки; двусторонняя стрелка — только для коннектора.
- У каждой стрелки есть клиент и сервер, и каждый отвечает за свою половину. На ландшафт ничего из этого не попадает, но у каждой стрелки это есть.
- Считайте, прежде чем рисовать стрелки. Нули идут в инвентаризацию, и они выбирают механизм: пакетная обработка, синхронный вызов или события.
- Стратегия org — это решение на уровне ландшафта, и принимается оно в первые минуты: один org или несколько и где он работает.
- Текущее состояние показывает, что не так. Красным — плохой процесс, штриховой линией — ручная работа, красными точками — то, чего не хватает.
Схема ландшафта Steve
Заголовок раздела «Схема ландшафта Steve »Системный ландшафт можно рисовать по-разному. Это мой способ, отточенный за много лет, и он читается как предложение: люди слева приходят к Salesforce в середине, которому доверяют через системы над ним, который обслуживает через каналы под ним и который связан с бэк-офисом справа.
| Где | Что там находится |
|---|---|
| Слева | Люди, сверху вниз: внутренние пользователи, партнеры, клиенты |
| В центре | Salesforce, один простой прямоугольник, его сообщества касаются его снизу |
| Сверху | Поставщики удостоверений над Salesforce; AppExchange сдвинут вправо; публичные сайты слева вверху |
| Справа | Слой интеграции, затем внутренние системы: ERP, финансы, хранилище данных |
| Под слоем интеграции | Data 360, рядом с ядром, вместе с «трубопроводом» |
| Внизу | Клиентские каналы: электронная почта, веб-формы, телефон, мессенджеры |
| Справа внизу | Данные внутрь и наружу: архивы, загрузки данных, внешние источники, партнеры |
Системы — это карточки в бледных подписанных зонах, у каждой свой значок, а легенда объясняет, что все означает. За рисунком стоит инвентаризация: для каждого набора данных или потока — его владелец, объем, механизм и время, аутентификация и что с ним делать: копировать, ссылаться или федерировать.
Ландшафт из модуля 4 со стрелками.
Путь по этой главе
Заголовок раздела «Путь по этой главе »Шесть модулей, каждый самостоятелен.
- Salesforce — одна система из многих. Почему ландшафт идет раньше прямоугольника, интеграция, которую я вижу снова и снова, и обратные потоки, от которых она зависит, данные волнами, а также ядро, рядом с ядром и Hyperforce.
- Виды корпоративных данных. Шесть видов; где создаются, редактируются, где на них ссылаются; OLTP и OLAP; реальное время, почти реальное время и пакетная обработка; четыре вопроса за категориями.
- Системы вокруг Salesforce. Роли систем; ERP, хранилище данных и lakehouse; аналитика следует за данными; MDM; интеграция и события; поставщик удостоверений, о котором забывают разработчики; где находится Data 360.
- Нарисуйте системный ландшафт. Моя схема, построенная с чистого холста; нули раньше стрелок; стрелки, которые начинаются у инициатора; клиент и сервер за каждой стрелкой, в обе стороны; дорожки (swim lanes) для диалогов; инвентаризация за рисунком.
- Стратегия org — это решение на уровне ландшафта. Начните с одного org; что оправдывает еще один; регион, а не провайдер; разделение на AMER и EMEA из-за GDPR; что добавляет второй org.
- Ландшафт Steve Trucking. Сегодня, до нормального внедрения, с пометками: манифесты, которые попадают в RouteDesk; маршруты, которые вручную перебивают в Salesforce и обратно; остров данных GPS; таблица, которая питает финансы; и 108 000 звонков в год «где моя доставка?».
Закончив, проверьте себя с помощью учебного пособия к главе: чек-лист для экзамена, привычки за его пределами, ключевые термины и несколько вопросов.
Что здесь решает архитектор
Заголовок раздела «Что здесь решает архитектор »- Какие системы окружают Salesforce и какую роль играет каждая.
- Какая система владеет каждым важным видом данных, прежде чем решать, сколько из них хранит Salesforce.
- Как работает каждое соединение: что движется, в каком направлении, как проходит аутентификацию, как быстро и что возвращается.
- Сколько org и где они работают — это решается первым, потому что от этого зависит все остальное на ландшафте.
- Понято ли текущее состояние достаточно хорошо, чтобы проектировать целевое.
За пределами экзамена: ландшафт превращается в карту для агентов. Прежде чем агент сможет ответить на вопрос «где моя доставка?», кто-то должен знать, какая система авторитетна для каждого факта, насколько он актуален и как агент может до него добраться. Каждый модуль заканчивается тем, что ИИ меняет в его части картины.
Дополнительно
Заголовок раздела «Дополнительно »- 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) (на английском).