Чотири способи керувати основними даними

🌐 Також доступно 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)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 2 з 6 розділу Основні дані та ідентичність, розділ 6 курсу Data Architect. Кожен модуль самостійний. Попередній: Одне джерело істини на атрибут · Наступний: Зіставлення, злиття і survivorship

Питання, на яке відповідає цей модуль: Як організації керують основними даними і який стиль пасує?

Модуль 1 сказав, що авторитетність призначають атрибут за атрибутом. Тепер: що робити, коли ці атрибути живуть одразу в кількох системах? Інформація про клієнта в Salesforce, ERP, білінгу, підтримці, можливо Data 360, можливо сховищі даних, і в кожній — своя версія. Цю задачу намагається розв’язати управління основними даними (MDM), і MDM — не одна архітектура. Ви почуєте про чотири шаблони: registry, консолідація, співіснування і централізоване. Це не налаштування продукту. Це чотири відповіді на одне запитання: скільки авторитетності має шар керування?

Почніть із задачі, а не з продукту

Люди чують MDM і йдуть купувати MDM-продукт. Я б почав із задачі. Нам треба лише знати, що кілька записів — той самий клієнт? Нам потрібен один об’єднаний погляд для аналітики? Нам треба вирішувати, які значення авторитетні, і повертати їх в інші системи? Чи ми хочемо, щоб одна центральна система створювала основні дані для всіх? Дуже різні вимоги, дуже різні архітектури.

Registry: скажіть мені, хто є хто

Найлегший шаблон. Registry не замінює джерела. ERP зберігає свого клієнта, Salesforce — свій акаунт, білінг — свого клієнта, а registry з’ясовує, що ці записи представляють ту саму сутність: акаунт Salesforce 001…, клієнт ERP SAP-43821 і клієнт білінгу BILL-9127 належать одному клієнтові. Джерела лишаються на місцях і не перезаписуються. Тепер на «покажіть усе, що ми знаємо про цього клієнта» є відповідь.

Але зверніть увагу, на що registry не відповідає. Salesforce каже 123 Main Street, ERP — 125, білінг — «123 Main St., Suite 200». Registry знає, що вони належать разом. Він не вирішує, котре треба змінити. Пов’язати — не означає керувати.

З мого досвіду, registry — норма в проєктах Salesforce, далі консолідація і співіснування; чисто централізоване MDM рідкісне. Registry поширений, бо він неінвазивний. Не треба перепроєктовувати кожну операційну систему, перш ніж отримати цінність. Salesforce і далі робить своє, ERP робить своє, а ви додаєте шар ідентичності. Це набагато менша зміна, ніж сказати кожній системі: «ви більше не контролюєте дані клієнтів; їх контролює ця нова центральна система».

Click to enlarge

Реєстр відповідає: які записи належать одній сутності?

Консолідація: зведіть дані разом

Консолідація бере дані з кількох джерел і поєднує їх у центральне представлення — для звітності, аналітики, сегментації, аналізу клієнтів. Знайомий приклад — сховище даних: Salesforce надсилає клієнта, ERP — фінанси, білінг — платежі, і бізнес нарешті може аналізувати клієнта між системами. Джерела досі існують і можуть досі бути авторитетними. Напрямок важливий: дані течуть у консолідовану систему, яка зазвичай не повертає керованих змін. Кращий погляд на клієнта без того, щоб стати його операційною авторитетною системою.

Registry і консолідацію легко сплутати. Різниця в тому, що централізується: registry централізує ідентичність («ці належать разом»); консолідація централізує більше даних («зведіть атрибути разом, щоб ми могли ними користуватися»). Жодна не каже «ця центральна система тепер майстер, і кожен застосунок мусить приймати її значення».

Click to enlarge

Консолідація зводить дані разом, не забираючи власності в джерел.

Співіснування: вирішіть і поверніть

У співіснуванні шар керування отримує справжню авторитетність. Дані досі живуть у кількох операційних системах, але процес MDM вирішує кероване значення й публікує його назад. Salesforce, ERP і білінг мають кожен свою юридичну назву; процес MDM визначає керовану й розповсюджує її в усі три. Системи співіснують, але сходяться на керованому значенні.

Це набагато сильніша форма MDM. Вона каже не «ці належать разом»; вона каже «для цього атрибута саме це значення використовує підприємство». Для цього потрібно більше, ніж зіставлення: бізнес-правила, власність, survivorship, двобічна інтеграція, обробка помилок і врядування, бо хтось має вирішити, чому перемагає одне значення.

Click to enlarge

Співіснування не просто пов’язує записи. Воно вирішує керовані значення й надсилає їх назад.

Централізоване: майстер створює істину

Найсильніший шаблон. У централізованому MDM керовані основні дані створюються й підтримуються в центральному майстрі й розповсюджуються всім іншим. Замість того щоб кожна система створювала свого клієнта, а MDM узгоджувала їх потім, ви створюєте керованого клієнта в майстрі, а потім надсилаєте його в Salesforce, ERP і білінг. Дуже сильне врядування і дуже значна зміна: наявні процеси створюють власних клієнтів, у користувачів свої робочі процеси, інтеграції припускають локальне створення, а підрозділи можуть навіть не погоджуватися, що таке клієнт. Тому в ландшафтах Salesforce, які я бачу, це рідкість. Це може бути правильним. Але це набагато більше рішення, ніж встановити інструмент.

Click to enlarge

Централізоване MDM переносить створення й авторитетність у майстер.

Чотири поруч

Стиль	Що централізується	Джерела лишаються?	Повертає керовані значення?
Registry	Ідентичність і зв’язки	Так	Зазвичай ні
Консолідація	Ідентичність плюс об’єднані дані	Так	Зазвичай ні
Співіснування	Ідентичність, дані й керовані рішення	Так	Так
Централізоване	Створення й авторитетність	Так, як споживачі	Так

Вниз по таблиці шар керування отримує більше авторитетності, а організації зазвичай треба більше змінюватися.

Варто знати для іспиту. Знайте чотири стилі впровадження MDM: registry (пов’язує ідентичності; джерела зберігають свої дані), консолідація (зводить дані разом, зазвичай для аналізу), співіснування (вирішує керовані значення й публікує їх назад у джерела) і централізоване (майстер створює дані; джерела їх споживають).

Тож немає такого: «централізоване найзріліше, тож усі мають туди дійти». Обирайте найлегший шаблон, що розв’язує задачу. Треба знати, що записи належать разом? Думайте про registry. Об’єднаний погляд для аналітики? Консолідація. Керовані значення, синхронізовані назад у кілька операційних систем? Співіснування. Один процес, що створює й контролює основні дані для всіх? Централізоване.

Де місце Data 360?

Data 360 будує уніфіковані профілі з багатьох джерел, що дуже схоже на MDM, і він справді розв’язує частину задачі. Його розпізнавання ідентичності зіставляє профілі джерел в уніфіковану ідентичність і зберігає зв’язки з вихідними записами (Data 360 Architecture (opens in a new tab)). Це робить його найближчим до registry. Він також може показувати узгоджені значення на уніфікованому профілі. Але це не робить його централізованою системою golden record, що переписує джерела. Уніфікований погляд — не автоматично керований корпоративний запис. Модуль 4 повністю про цю різницю.

Спільна модель — не спільна істина

Ви почуєте й про канонічну модель даних. Account у Salesforce, бізнес-партнер в ERP і клієнт у білінгу — усі зіставляються з одним узгодженим корпоративним поняттям, Customer, з узгодженими ідентифікаторами й атрибутами, щоб кожній інтеграції не треба було розуміти форму кожної іншої системи. Модель даних Data 360 — приклад гармонізації джерел у спільні поняття. Але канонічна модель відповідає на як нам послідовно це представити? MDM відповідає на як нам ідентифікувати, керувати й вести це між системами? Зіставте всі три системи ідеально в одну форму Customer — і Salesforce досі каже 123 Main Street, а ERP — 125. Ви розв’язали структуру, а не авторитетність. Гармонізація і керування — не взаємозамінні.

Один бізнес, кілька шаблонів

Тож «Steve Trucking потрібне MDM» — не вимога. Для чого? Роздрібні партнери, розподільчі центри, бригади, вантажівки, отримувачі — різні домени з різними авторитетними системами: роздрібні партнери під врядуванням Salesforce і фінансової ERP, ідентичність вантажівок — з FleetLink, кожного отримувача надає партнер для кожної доставки. Різні домени можуть мати різні шаблони, а в межах домену атрибути можуть мати різних авторитетних власників. Тож не малюйте посередині діаграми прямокутник із підписом MDM і не називайте це розв’язанням. Запитайте, що цей прямокутник робить.

Стиль також змінює інтеграцію. Registry потрібні зв’язки ідентичності; консолідації — надійні вхідні потоки; співіснуванню — дані в обох напрямках; централізованому — розповсюдження з майстра плюс контролі, що не дають іншим системам створювати конкурентну істину. З ростом авторитетності зростає координація і зростає обробка збоїв: що, як MDM змінить юридичну назву, а ERP її відхилить? Тому співіснування й централізоване — не «registry з більшою кількістю функцій». Вони несуть інші операційні відповідальності.

MDM — бізнес-рішення

Найважливіше: MDM за суттю не технологічне рішення. Це рішення про авторитетність. Хто створює клієнта, хто може його змінювати, хто вирішує, яке значення перемагає, які системи мусять його прийняти, що стається, коли вони не згодні. Інструмент може реалізувати ці рішення; він не може змусити організацію про них домовитися. Тому MDM-проєкт може мати чудову технологію і все одно провалитися: технічна команда розв’язала зіставлення, а бізнес так і не розв’язав власність.

Загальний урок, засвоєний мною на власних помилках: коли кілька систем керують тими самими даними, Salesforce не може узгодити того, про що вони не домовилися. Коли компанія має дві ERP, я питаю, як вони їх синхронізують. Якщо вони не можуть, то й Salesforce не зможе. Модуль 5 розповідає цю історію (Один клієнт, дві ERP).

Що тут вирішує архітектор

• Чи потрібні задачі зв’язки ідентичності, об’єднані дані, повернення керованих значень чи центральне створення.
• Який шаблон пасує кожному домену даних, а не один шаблон для всього підприємства.
• Скільки авторитетності отримує шар керування і які системи мусять приймати його рішення.
• Чи потрібна канонічна модель, без того щоб плутати гармонізацію з авторитетністю.
• Як обраний шаблон змінює напрямок інтеграції, власність і обробку збоїв.

Коли хтось ставить на діаграму прямокутник MDM, запитайте, що він робить. Він знає, які записи належать разом? Поєднує їхні дані? Вирішує, які значення перемагають? Повертає ці рішення? Взагалі створює дані? Відповіді скажуть, яка архітектура у вас насправді і де живе авторитетність.

Додаткові матеріали

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (англійською, перевірено 2026-10-14).