Владельцы устанавливают политику, архитекторы ее обеспечивают

Также доступно на 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 курса Data Architect, Часть 1: Как стать архитектором данных. Назад: Понимание корпоративных данных.

Скажите «управление данными» (data governance), и люди представят себе совещания: комитеты, политики, документ, который никто не читает. Я каждый раз задаю другой вопрос: где эта политика обеспечивается?

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

И не рассчитывайте закончить. Управление данными никогда не бывает завершено. Оно идет приливами и отливами и не пускает худшие из плохих данных. Это просто, когда Salesforce стоит особняком, и сложнее — и нужнее, — когда Salesforce — один узел в ландшафте, который мы нарисовали в главе 4. Поэтому та глава и шла первой: ландшафт говорит вам, как далеко должно дотягиваться управление данными.

Финансовый директор объясняет политики работы с данными, а архитектор прикрепляет, что обеспечивает каждую из них: проверку, общий доступ и хранение

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

Позиции этой главы

Ведите программу так, как работает компания: централизованно, федеративно или гибридно; архитектору нужно знать, кто утверждает политику.
Владелец записи — не владелец данных. Поле Owner управляет назначением и доступом; ответственность за данные лежит на бизнесе.
Открытое или закрытое создание записей зависит от управления вокруг данных. Открытое подходит для большинства малых и средних org; закрывайте его, когда организации (Account) ведутся в ERP или синхронизируются с ней; средний путь — предварительный тип записи с контролируемым преобразованием в управляемый.
Если поле ведется в ERP, вы его не меняете, вы просите его изменить. Золотая запись гибридна: мастер-поля ERP приходят внутрь, собственные поля Salesforce никогда не уходят обратно, а двунаправленным потокам нужно правило разрешения конфликтов.
Классифицируйте чувствительные поля, а не все поля. Документируйте широко; классифицируйте осознанно; храните и бизнес-метаданные, и технические.
Рассказывайте о законах. Многие архитекторы никогда не слышали о законах за пределами своего региона, а эти законы формируют проектирование систем.
Используйте стандартную модель согласия везде, где можете, вместо того чтобы строить ее заново.
Ради права на забвение прежде всего контролируйте, куда попадают персональные данные. Удаление — редкое и трудное дело; проектируйте так, чтобы персональные данные оседали в немногих местах, а затем находите каждую копию: историю полей, архивы, аналитические копии, поисковые индексы и диалоги агентов, — прежде чем истечет срок.
Shield — ответ на ключевые регуляторные требования, такие как шифрование хранимых данных, с компромиссами, которые нужно учесть при проектировании.
Field Audit Trail — при регулировании. Стандартная история полей — вариант по умолчанию.
Настройте Event Monitoring до того, как он понадобится, и передавайте события в хранилище, например Splunk. Нельзя сначала столкнуться с проблемой, а потом выяснить, что вы их не собирали.

Управляемый жизненный цикл данных

Click to enlarge

Семь вопросов на протяжении жизни данных. Инструменты поддерживают политику, но не определяют ее.

Путь по этой главе

Шесть модулей, каждый самостоятелен.

Управление данными закладывается в org. Владельцы, стюарды и хранители данных; централизованная, федеративная или гибридная модель; владелец записи и владелец данных; превращение каждой политики в точку обеспечения.
Не пускать плохие данные. «Достаточно хорошо» как бизнес-определение; открытое и закрытое создание, предварительная запись и тип записи для каждого потока; гибридная золотая запись и двунаправленные потоки; решение о качестве на каждой границе данных.
Знайте свои данные: словарь, происхождение и классификация. Бизнес- и технические метаданные; что данные означают, откуда они пришли, как с ними нужно обращаться и почему классификация без обеспечения — лишь украшение.
Законы о конфиденциальности определяют проектирование. Законы, которые нужно узнавать, что у них общего (права, передача данных, уведомление об утечках, подотчетность), и вопросы, которые их переживут; анонимизированные и псевдонимизированные данные; соответствие требованиям — это не продукт.
Согласие и право на забвение. Согласие как данные, стандартная модель согласия, срок на каждый запрос и проектирование удаления до того, как придет первый запрос.
Защищать, хранить и доказывать. Компромиссы шифрования, песочницы, хранение, история полей и Field Audit Trail, а также Event Monitoring, настроенный заранее.

Закончив, проверьте себя с помощью учебного пособия к главе: чек-лист для экзамена, привычки за его пределами, ключевые термины и несколько вопросов.

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

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

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

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

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

Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (на английском, проверено 2026-10-14).
Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (на английском, проверено 2026-10-14).
Regulation (EU) 2016/679 (GDPR) (opens in a new tab), EUR-Lex (на английском, проверено 2026-10-14).

Далее: Мастер-данные и идентичность