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)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

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

Вопрос, на который отвечает этот модуль: почему архитектор данных рисует то, что окружает org, прежде чем проектировать сам org?

Когда я учу кандидатов в CTA, домашнее задание после первого дня всегда одно и то же. Прочитайте сценарий. Начните системный ландшафт с чистого холста. Только потом попробуйте набросать модель данных. Не объекты, не интеграции в деталях: ландшафт. Я хочу увидеть, что окружает Salesforce, прежде чем мы решим, что должно быть внутри.

Для многих специалистов по Salesforce это смена точки зрения. Если вы всю карьеру были администратором или разработчиком, Salesforce естественным образом — центр вашего мира. Вы открываете Setup, создаете объекты, строите flow, пишете 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 владеет золотой записью клиента и продукта, поэтому эти потоки приходят справа, в Salesforce. Продажи закрывают сделку в Salesforce, поэтому заказ начинается там и уходит обратно в ERP, чтобы его исполнили, выставили счет и учли.

Эти потоки — не просто интеграции. Они говорят мне, где, по мнению предприятия, живет истина.

Односторонние стрелки меня настораживают

Когда я вижу интеграцию только с одним потоком, я начинаю беспокоиться. На верхнем уровне кто-то рисует одну стрелку: заказы из Salesforce в ERP. Хорошо. Теперь посмотрите глубже. Как я могу отправить заказ в ERP, если не знаю ее клиентов, ее продуктов или ее цен? Заказ должен быть привязан к клиенту, который в ERP уже есть, и каждая строка должна быть SKU, который ERP уже продает. Я не могу отправить позицию для продукта, которого нет на другой стороне. Значит, прежде чем стрелка заказов сможет работать, должны существовать обратные потоки, идущие в другую сторону.

Это вопрос, который я задаю каждой стрелке: от чего зависит этот поток? Стрелке верхнего уровня, которую вы видите, обычно нужны обратные потоки, которые вы еще не нарисовали.

Посмотрите еще глубже — и найдете обратный путь. Salesforce отправляет заказ. А дальше? Его приняли или отклонили? Его отгрузили, отгрузили частично, отменили? Выставили ли счет? Нужно ли кому-то в Salesforce об этом знать? Может, и не нужно. Но кто-то должен был спросить. Если ничего не возвращается — хорошо. Объясните мне почему.

Предприятие появилось не сразу

Ландшафты усложняются отчасти потому, что никто не строил их разом. Данные приходили волнами. Сначала файлы: записи фиксированного формата, затем файлы с разделителями вроде CSV. Затем реляционные базы данных для операционных данных. Затем хранилища данных, чтобы свести их вместе для анализа. Затем базы NoSQL для документов, пар «ключ — значение» и графов, которые не ложатся аккуратно в таблицы. Затем озера данных для огромных объемов сырых и полуструктурированных данных и lakehouse, которые объединяют одно и другое. Потоки событий, такие как Kafka или шина событий Salesforce, перемещают данные по мере того, как что-то происходит, а не ночными пакетами. А теперь федерация, при которой данные не нужно копировать в одно место, чтобы ими могла пользоваться другая платформа.

Технологии пока не главное. Главное вот что: новая волна редко отменяет старую. Зайдите на крупное предприятие, и вы найдете их все сразу: реляционные базы данных, ERP, Salesforce, хранилище данных, озеро, выгрузки на SFTP, API, потоки событий, таблицу, которую кто-то до сих пор рассылает по почте каждую пятницу, и ту единственную систему, которую все боятся трогать, потому что ее автор ушел на пенсию шесть лет назад. Вот предприятие, архитектуру которого вы строите, а не то, что в рекламном буклете.

Разные системы существуют по разным причинам

Поэтому я никогда не начинаю с вопроса «как нам перенести все данные в Salesforce?». Зачем мне там все? Salesforce может быть лучшим местом, где продавцы и сотрудники службы поддержки работают с клиентами. Но это не делает его финансовой системой, корпоративным хранилищем данных, хранилищем телеметрии, архивом документов или домом для каждого клика, каждого показания GPS и каждой исторической транзакции, которые компания когда-либо произвела.

Глава 3 спрашивала, где должны жить эти данные?, для одного org. На уровне предприятия тот же вопрос становится больше: иногда Salesforce владеет данными, иногда хранит копию, иногда только ссылку, а иногда ему вообще не следует их иметь.

Ядро, вне ядра и Hyperforce

Есть еще одна граница, которую нужно понимать: даже «Salesforce» — это не одна среда выполнения и не одна база данных. В главе 3 в ядре означало, где лежат данные: на вашем столе, в собственных объектах org. Здесь те же слова описывают, где работает продукт. Вы услышите, как архитекторы используют оба значения.

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

Это было важно задолго до того, как платформа разделилась на сервисы. Когда я спрашиваю аудиторию, почему Salesforce купил для расчета предложений SteelBrick, а не Apttus, ответ, которого я жду, прост: SteelBrick был построен на 100 % в ядре. Flow и триггеры живут в ядре, поэтому продукт, построенный там, получает вместе с ним метаданные, настройки и автоматизацию платформы. С тех пор этот продукт для расчета предложений уступил место Revenue Cloud, но урок остался. Дальше есть рядом с ядром (near-core), и мой пример — Data 360. Data 360 — не ядро. Его тенант находится вне ядра: данные и механизмы, которые их обрабатывают, работают в собственном lakehouse, рядом с реляционной базой данных org, а не внутри нее (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Но экраны, через которые вы его настраиваете и контролируете, показываются в ядре, в org. Поэтому точнее всего я могу сказать так: управляется в ядре, размещается вне ядра. Ни данные, ни обработка на самом деле не работают в Core; интерфейс в Core управляет тенантом вне ядра. Ну и, конечно, есть все, что находится вне ядра, потому что это вообще не Salesforce.

Меня меньше волнует, помните ли вы, какой продукт где работает в этом году, потому что это меняется, — важнее привычка: граница может влиять на перемещение данных, задержку, удостоверения, интеграцию и резидентность. Поэтому не думайте, что раз на продукте написано Salesforce, его данные лежат прямо рядом с вашими записями организаций. Смотрите на реальную архитектуру.

Еще есть 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; и что происходит, когда две системы расходятся. Это не вопросы интеграции на потом. Это вопросы архитектуры данных, и их выявил ландшафт.

Вот как один из них кусается. Продавец преобразует интерес для крупной компании по производству напитков, создает организацию, выигрывает сделку, и клиент уходит в ERP. Но компания годами работает с этим производителем напитков, и в ERP он уже есть. Теперь их двое. Должен ли был продавец вообще иметь возможность создать эту организацию? Главы 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.