Стратегия 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)

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

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

Модуль 5 из 6 главы Понимание корпоративных данных, глава 4 курса Data Architect. Каждый модуль самостоятелен. Назад: Нарисуйте системный ландшафт · Далее: Ландшафт Steve Trucking

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

Когда я учу кандидатов в CTA, я говорю им, что самое важное решение в сценарии принимается в первые пять-десять минут: со сколькими org Salesforce мы имеем дело? Один большой org? Региональные org для Северной Америки, EMEA и APAC? Отдельные org для отдельных бизнес-подразделений? Особый org для страны со своими правилами? И прямо с этим связано: где работают эти org?

Это не административные мелочи. Они меняют то, где живут данные, интеграции, отчетность, удостоверения и то, как люди по всему миру добираются до системы. Поэтому я считаю стратегию org решением на уровне ландшафта и принимаю его первым.

Начните с одного org

Моя исходная позиция проста: начните с одного org. Не потому, что один org всегда прав, а потому, что мне нужна причина, чтобы добавить еще один. Один org дает одно место для общих данных о клиентах, одну модель безопасности, одно место для развертывания, один набор интеграций, одно место для отчетности. И один org все равно может поддерживать разные бизнес-подразделения, страны, процессы, типы записей, приложения, модели общего доступа и интерфейсы.

Поэтому я не добавляю org из-за того, что Европа делает что-то немного иначе, у подразделения свой процесс продаж или бизнес-подразделения недолюбливают друг друга. Это требования, а не границы org. Вопрос в другом: какая сила достаточно велика, чтобы оправдать еще один org?

У нескольких org есть цена

Разделите один org на три (Северная Америка, Европа, Азиатско-Тихоокеанский регион), и вы не нарисовали три аккуратных прямоугольника; вы создали новые вопросы. Где живет глобальный клиент? Что, если он работает в двух регионах: две копии, и какая из них им владеет? Как кому-то строить глобальную отчетность? Интегрируется ли ERP со всеми тремя, получает ли хранилище данных три потока, подключается ли поставщик удостоверений ко всем трем? Развертываем ли мы одну и ту же функциональность трижды и поддерживаем три модели данных согласованными? Если агенту нужен глобальный взгляд на клиента, какой org он спрашивает?

Вернитесь к ландшафту из модуля 4. Один прямоугольник Salesforce становится тремя, и каждую стрелку приходится перерисовывать. Несколько org — это не ошибка. Но это никогда не бесплатно.

Ищите реальные границы

Что может оправдать еще один org? Границы, достаточно реальные, чтобы формировать архитектуру: резидентность данных, регулирование, юридическое разделение, действительно разные операционные модели, поглощение, которое еще не интегрировано, региональное ограничение на размещение, сильно различающееся управление, иногда масштаб или изоляция. Список неполный. Смысл в том, чтобы отличать «эти группы разные» от «этим группам нужна архитектурная граница». Вторая планка гораздо выше.

География — еще не стратегия org

«Мы работаем в 30 странах, значит, нам нужно 30 org». Нет. География важна, когда она приносит архитектурное требование. У компании могут быть пользователи по всему миру на одной общей архитектуре. Поэтому я не считаю страны; я спрашиваю, что приходит вместе с ними. Где можно хранить данные? Где их можно обрабатывать? Есть ли ограничения на передачу персональных данных через границы? Договорные обещания о резидентности? Нужен ли региону другой сервис Salesforce или другое размещение? «У нас есть офис в Германии» само по себе — недостаточная причина.

Размещение — часть рисунка

Здесь современная платформа делает ландшафт интереснее. Hyperforce запускает Salesforce на инфраструктуре публичного облака в регионах по всему миру, давая клиентам больше выбора и контроля над тем, где находятся их данные (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Поэтому, когда я подписываю прямоугольник «Salesforce, Европа», это местоположение может иметь значение.

Но будьте точны. Выбор того, где живет org, — не обещание, что каждый байт каждого сервиса останется там. Salesforce советует клиентам изучить документацию по доверию и соответствию требованиям для Hyperforce, включая дополнительных субобработчиков для покупаемых сервисов (тот же источник). Поэтому не говорите «мы на Hyperforce в стране X, значит, все остается в стране X». Знайте, какими сервисами вы на самом деле пользуетесь и какое требование выполняете. И обратите внимание на то, что вы выбираете: регион, а не облако под ним. Hyperforce работает на AWS, а с конца 2026 г. и на Google Cloud, и на каком провайдере будет org, решает Salesforce; клиент с задокументированной регуляторной причиной избегать одного из них обращается к своей команде по работе с клиентом (тот же источник).

Не играйте в юриста

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

Когда у Европы свой org

Вот граница, которую я вижу в реальных сценариях. У компании сильное присутствие в США и сильное присутствие в Европе: две большие клиентские базы, два подразделения продаж и обслуживания и европейская программа конфиденциальности, построенная вокруг GDPR. GDPR не говорит «вам нужен отдельный org Salesforce». Он устанавливает правила для персональных данных, в том числе для того, когда их можно передавать за пределы ЕС (GDPR, Chapter V (opens in a new tab)). Но эта компания вместе со своими специалистами по конфиденциальности и юристами решает, что персональные данные ее европейских клиентов должны жить в org, размещенном в Европе, которым управляет ее европейская команда, по ее европейским правилам управления. Это реальное требование, и оно их, а не мое.

Теперь «один большой глобальный org» — уже не предпочтение. На ландшафте есть граница, Salesforce AMER и Salesforce EMEA, и я должен ее нарисовать. А второй org никогда не бывает просто еще одним прямоугольником.

Click to enlarge

Два org, AMER и EMEA. Янтарным — то, что добавляет второй org: не еще один прямоугольник, а заново каждую стрелку.

Снова пройдите по стрелкам

Когда org больше одного, пройдите по ландшафту еще раз. Отправляет ли ERP продукты в каждый org? Отправляет ли каждый из них заказы обратно? Где ведутся клиенты и могут ли их данные пересекать регионы? Слой интеграции глобальный или региональный? Какой поставщик удостоверений обслуживает вход каких пользователей? Куда идут аналитические данные?

Быстрее всего цена видна в трех местах:

Отчетность. Генеральный директор хочет глобальную воронку продаж. В одном org это отчет Salesforce. В трех это задача корпоративной отчетности: реплицировать, отправить в хранилище данных, федерировать? Насколько актуальными должны быть данные, и одинаково ли вообще org определяют «воронку»? Где живет аналитика, зависит от того, где живут данные, и если вы намеренно разделили операционные данные, вам нужно спроектировать, как аналитика снова сойдется воедино.

Мастер-данные. Глобальный клиент покупает в США, Германии и Японии. Три org — значит, скорее всего, три организации (Accounts). Как узнать, что это одна и та же компания? Какой глобальный идентификатор и кто им владеет? Если один регион меняет адрес, должно ли изменение распространиться? Какие атрибуты глобальные, а какие региональные? Стратегия org не решает проблему идентичности; она меняет эту проблему. Это глава 6.

Интеграция. Один org: Salesforce, слой интеграции, ERP. Три org: три подключения к слою интеграции, возможно, одно со своим размещением и сетевым подключением, какие-то потоки общие, какие-то региональные, какие-то данные можно передавать между регионами, а какие-то нет. Может измениться даже сеть: если предприятию нужно выделенное частное подключение к Hyperforce (на AWS Salesforce рекомендует AWS Direct Connect; тот же FAQ по Hyperforce), каждый org и каждое размещение на рисунке — это еще одно подключение, которое нужно спланировать. То, где работает org, может изменить то, как до него добирается остальное предприятие.

Один org или несколько — это решение, которое принимается сейчас, в начале, на ландшафте. То, как org затем обмениваются данными (межорговый Salesforce Connect, интеграция между ними, Data 360), — это механика, и ее разбирает глава 14, Один org или несколько? (coming soon).

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

Не разделяйте только ради того, чтобы прямоугольники стали меньше

Большой org кажется сложным: много подразделений, объектов, пользователей, интеграций. Кто-то говорит: «Не будет ли чище, если у каждого будет свой org?» Рисунок, может, и станет чище. Предприятие — не обязательно. Вы обменяли внутреннюю сложность на распределенную: синхронизация, дублирующиеся данные, идентичность между org, глобальная отчетность, несколько конвейеров релизов, дублирующиеся интеграции и автоматизация и управление всем этим. Иногда это все равно правильный обмен. Но отдельно не значит просто.

И один org тоже не бесплатен. Общее управление становится важнее, команды могут влиять друг на друга, границы безопасности требуют тщательного проектирования, модель данных должна обслуживать много групп, релизы требуют координации, а региональные правила могут ограничивать всех. Так что это не «Steve говорит: всегда один org». Моя исходная склонность — один org; затем я ищу требование, достаточно сильное, чтобы сдвинуть меня с этой позиции.

Сделайте решение видимым

Если стратегия org важна, не рисуйте абстрактное облако Salesforce. Нарисуйте org и подпишите их (AMER, EMEA — что есть на самом деле), отметьте требование к размещению или резидентности за каждым и пройдите по соединениям. Другой архитектор должен видеть, почему существует каждая граница. Если я не могу объяснить, почему на рисунке три прямоугольника Salesforce, я не закончил решение.

У Steve Trucking один org, в США, и ничто в брифе не требует второго. Но держите этот модуль в голове для итогового проекта: поглощение, которое приходит со своим org, — именно та граница, которая проверяет эти вопросы.

За пределами экзамена: что меняет ИИ. Агент может сделать границу org невидимой для пользователя. Но внутри архитектура все равно должна решить, к какому org или системе агенту можно обращаться, какие данные могут пересекать регионы и какой ответ авторитетен. ИИ может спрятать сложность в пользовательском опыте; он не убирает ни управление, ни границу.

Что здесь решает архитектор

• Есть ли реальная архитектурная причина для более чем одного org, вместо того чтобы решать различия внутри одного.
• Где работает каждый org и какое требование — резидентности, регуляторное, договорное или бизнес-требование — определяет это место.
• Какие данные могут пересекать границы org и регионов, где авторитетны мастер-данные и как работает глобальная идентичность.
• Как меняются интеграция, удостоверения, аналитика и отчетность, когда один прямоугольник Salesforce становится несколькими.
• Стоит ли выгода от разделения той распределенной архитектуры, которую оно создает.

Когда я читаю сценарий, я первым делом ищу это решение: один org или несколько, где они размещены и что их к этому вынуждает? Ответьте на эти вопросы, и остальной ландшафт начнет обретать форму.

Дополнительно

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), на английском, проверено 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), глава V (передача персональных данных в третьи страны), на английском, проверено 2026-10-14.