Системы вокруг 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): где ведется авторитетная версия чего-либо.
• Система взаимодействия: где люди выполняют работу.
• Справочная система: где система находит нужную ей информацию, которой она не владеет.
• Аналитическая система: где данные сходятся, чтобы измерять, анализировать и прогнозировать.

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

ERP: у бэк-офиса есть гравитация

ERP — система, которую вы чаще всего найдете рядом с Salesforce; она ведет финансы, запасы, закупки, исполнение заказов и выставление счетов. Шаблон из модуля 1 (клиенты и продукты внутрь, заказы наружу) означает, что продуктами владеет ERP, но продавцам они все равно нужны в Salesforce. Хорошо: заведите их. Но копирование данных не передает владение. Копия — это не полномочия.

Моя позиция: данные, которыми владеет ERP, читаются локально и записываются под контролем. Пользователи Salesforce получают данные там, где работают, но Salesforce не может менять то, чем владеет ERP. И я делаю это видимым в схеме: поля ERP получают префикс erp_, например erp_Product_Number__c, чтобы любой, кто читает объект, знал, кто владеет каждым полем и что менять его нужно осторожно. Сам префикс ничего не обеспечивает; это делают разрешения, правила проверки и шаблон интеграции. Он сообщает намерение, и это видимая карта полномочий (authority map).

Хранилище, озеро и lakehouse

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

Вы встретите три вида аналитических хранилищ. Хранилище данных (data warehouse) содержит структурированные данные, подготовленные для анализа. Озеро данных (data lake) содержит гораздо больше данных в большем числе форм, часто сырых. Lakehouse объединяет одно и другое: хранение как в озере, анализ как в хранилище. Знайте их, потому что они появляются на ландшафтах. Но мой опыт говорит, что lakehouse и data mesh на проектах Salesforce все еще нишевые. Типичный ландшафт — это CRM, ERP, хранилище данных и слой интеграции, а другие платформы — там, где они действительно нужны бизнесу. Изучайте архитектуру; не гонитесь за словарем.

Аналитика живет там, где живут данные

Это одна из моих самых твердых позиций: где живет аналитика, зависит от того, где живут данные. Если отчету нужны только организации, возможности и продавцы, все находится в ядре: стандартные отчеты и панели мониторинга. Потом бизнес просит добавить счета из ERP. Потом себестоимость продуктов. Потом пять лет заказов из хранилища данных. Потом активность на сайте. В какой-то момент тащить все это в операционную CRM только ради отчетов перестает иметь смысл. Как только задействованы другие хранилища, нужна аналитическая платформа: Tableau (включая Tableau Next, построенный на Data 360) или CRM Analytics, где она уже используется. Она необходима, когда данные Salesforce объединяются с хранилищем данных. Требование не просто усложнилось; ландшафт изменил то, где на вопрос нужно отвечать. Поэтому я никогда не начинаю с вопроса «какой инструмент аналитики?». Я начинаю с вопроса где данные?

Я спрашиваю кандидатов в CTA о том же: «Какая из моих диаграмм решает это красиво? Ландшафт». Если у вас все в ядре, используйте отчеты. Если у вас данные в других репозиториях, я хочу увидеть аналитическую платформу. Ландшафт отвечает на вопрос об отчетности раньше, чем кто-то откроет конструктор отчетов. (Названия продуктов меняются; где сегодня находится аналитика Salesforce, разбирает глава о Data 360.)

MDM: кто этот клиент на самом деле?

Теперь представьте, что информация о клиентах живет в Salesforce, ERP, электронной коммерции, программе лояльности и системе партнера, и каждая из них думает, что знает, кто клиент. Вот здесь появляется управление мастер-данными (MDM): установление и контроль авторитетной идентичности ключевых данных во всех системах. Но MDM — это не «главная база клиентов». Трудные вопросы — какая система может создать клиента, какими атрибутами владеет каждая система, как находят дубликаты, какой идентификатор выживает и что происходит, когда системы расходятся. Глава 6 целиком об этом. Здесь узнайте роль: если MDM-платформа есть, она может быть критически важной авторитетной системой между Salesforce и остальным предприятием.

Слой интеграции и события

Соедините каждую систему напрямую с каждой другой, и ландшафт быстро превратится в спагетти. Поэтому у предприятий есть слой интеграции: ESB (корпоративная сервисная шина) или iPaaS (интеграционная платформа как услуга). В ландшафтах Salesforce чаще всего встречается MuleSoft. Он служит посредником, чтобы каждому приложению не приходилось понимать все остальные.

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

И не каждая интеграция — это система A, вызывающая систему B. Иногда что-то происходит (создается заказ, у доставки меняется статус, грузовик въезжает в регион), публикуется событие, и откликается тот, кому это интересно. У событий в движении тоже есть инфраструктура: собственные возможности событий Salesforce, корпоративная шина событий, другие системы обмена сообщениями. Рисуйте механизмы, которые переносят данные, а не только базы данных.

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

Есть один прямоугольник, который я всегда хочу видеть на ландшафте и о котором разработчики редко думают: поставщик удостоверений (identity provider). Разработчики входят прямо в свои песочницы по имени пользователя и паролю, поэтому во время разработки удостоверения невидимы. Потом приходит UAT или продакшн, и вдруг появляется корпоративный единый вход для сотрудников, может быть, второй поставщик для партнеров, вход через соцсети для клиентов. Удостоверения всегда были частью архитектуры. Просто разработчик их еще не видел.

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

Есть и практическая тонкость: конфигурация удостоверений разворачивается, но не полностью. Конфигурация единого входа SAML и поставщики аутентификации — это типы Metadata API, поэтому они проходят через конвейер (SamlSsoConfig (opens in a new tab)). Но секреты потребителя поставщиков аутентификации больше не возвращаются в ответах 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 (на английском).