Одне джерело істини на атрибут

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

A key rack beside a front door, five different keys on their own hooks, each with a plain colored tag. — Зображення згенеровано ШІ

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

Питання, на яке відповідає цей модуль: Що насправді означає «єдине джерело істини»?

Є фраза, яку я чую постійно: «Нам потрібне єдине джерело істини». Гаразд. Для чого? Для клієнта? Це недостатньо конкретно. Візьміть акаунт. Хто володіє назвою клієнта, адресою для рахунків, кредитним лімітом, менеджером акаунта, рівнем підтримки, маркетинговими вподобаннями? Ці відповіді не вказують на ту саму систему. ERP може контролювати юридичну назву, адресу для рахунків і кредитний статус; Salesforce — власника стосунків і атрибути продажів; інша платформа — згоду. Тож коли мені кажуть «Salesforce — наше єдине джерело істини щодо клієнта», моє наступне запитання: якої істини?

Істина належить атрибуту

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

Атрибут	Авторитетна система
Юридична назва, адреса для рахунків, ID клієнта в ERP, кредитний ліміт	ERP
Менеджер акаунта, позначка стратегічного акаунта, рівень успіху	Salesforce

Один запис; істина розподілена. Це нормально. «Система обліку = Salesforce» цього не описує. Описує модель авторитетності.

Створено, редаговано, посилаються — і як швидко?

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

Візьміть актив. Клієнт замовляє три велосипеди. Salesforce має можливість і її позиції, а замовлення йде в ERP. ERP його виконує, і саме там активи створюються: три велосипеди, три серійні номери, надіслані назад у Salesforce. Через кілька місяців клієнт телефонує щодо одного з них, і підтримка посилається на актив у зверненні. Тепер комусь треба виправити атрибут. Які з них Salesforce може редагувати, а які належать ERP, що їх створила? І коли ERP змінює один із них, як швидко Salesforce має про це дізнатися? Один актив, чотири запитання, і відповіді не однакові для кожного поля.

Скажімо, юридичну назву створюють в ERP, у Salesforce на неї посилаються, а продавець помічає, що вона неправильна. Чи має він виправити її в Salesforce? Якщо полем володіє ERP, зміна копії нічого не виправляє. У кращому разі наступна синхронізація її перезапише; у гіршому — дві системи тепер розходяться, і ніхто не знає, котрій вірити. Якщо бізнес хоче, щоб продавець ініціював виправлення, — це інша справа: Salesforce дає інтерфейс, надсилає запит в ERP, ERP вносить чи погоджує зміну, і авторитетне значення повертається. Це зовсім інша архітектура, ніж дозволити Salesforce редагувати поле самостійно.

Затримка теж частина істини. ERP змінює кредитний статус клієнта о 10:00; Salesforce синхронізує його вночі; о 15:00 продавець дивиться в Salesforce. Значення хибне? Воно застаріле. Якщо значення змінюється раз на рік, а день затримки нічого не коштує, нічна синхронізація годиться. Якщо воно вирішує, чи приймати сьогодні замовлення на мільйон доларів, — ні. Авторитетність каже, звідки береться істина; затримка — як швидко інші мають дізнатися про зміну. Два окремі рішення.

Система обліку, взаємодії, довідкова

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

Гібридний golden record

Це змінює те, що означає «golden record». Розділ 5 запровадив цю ідею, коли ми не пускали погані дані; тут вона серце дизайну. Люди уявляють один магічний запис, кожне поле якого керується в одному місці. Іноді таким і є дизайн. У Salesforce я частіше бачу гібрид: частина акаунта керується деінде й копіюється всередину (юридична назва, номер клієнта в ERP, адреса для рахунків, кредитний статус), а частина існує лише тому, що потрібна Salesforce (менеджер акаунта, стратегія можливостей, рівень успіху, нотатки про стосунки). Поля ERP заходять, щоб люди могли ними користуватися. Поля Salesforce ніколи не повертаються, бо ERP вони байдужі. Цілком розумно, доки всі знають, що де.

Зробіть авторитетність видимою

Тож я роблю зовнішню авторитетність очевидною в схемі. Якщо поле контролює SAP, воно отримує префікс: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Це та сама ідея, що й префікс erp_ у розділі 4. Використовуйте назву системи, коли ця авторитетність конкретна й стабільна, і загальний префікс, коли зміст важливіший за сьогоднішнього постачальника. Суть у тому, щоб через пів року людина, читаючи модель, бачила: це не просто ще одне поле Salesforce; цим значенням володіє інша система. Не змушуйте людей знову відкривати авторитетність, розбираючи інтеграції.

Побудуйте карту авторитетності

Для важливих основних даних я хочу карту авторитетності: для кожного ключового атрибута — хто його створює, хто володіє бізнес-рішенням, яка система авторитетна і хто чи що може його змінювати. Чотири різні запитання:

Атрибут	Хто створює	Бізнес-власник	Авторитетна система	Хто може змінювати
Юридична назва	Фінанси	Фінанси	ERP	Фінансовий процес
Кредитний ліміт	Фінанси	Фінанси	ERP	Кредитна команда
Менеджер акаунта	Операції продажів	Продажі	Salesforce	Керівництво продажів
Рівень підтримки	Операції сервісу	Сервіс	Salesforce	Керівництво сервісу
Згода	Клієнт	Приватність	Платформа згоди	Клієнт, погоджений процес

Зверніть увагу, що бізнес-власник і авторитетна система — не одне й те саме. Система не володіє політикою; люди володіють. Система зберігає і забезпечує результат. Це знову розділ 5: власники встановлюють політику; архітектори її забезпечують.

Click to enlarge

Один клієнт. Багато атрибутів. Одна авторитетна система для кожного.

Авторитетність змінюється протягом життєвого циклу

Продавець зустрічає потенційного клієнта, про якого ERP ніколи не чула, і створює акаунт у Salesforce. На цей момент Salesforce авторитетний щодо назви, адреси, контактів і кваліфікації. Потенційний клієнт стає клієнтом; ERP створює офіційного клієнта і присвоює номер клієнта, юридичну назву, адресу для рахунків і кредит. Авторитетність перейшла. Salesforce не помилявся раніше; змінився життєвий цикл. Це шаблон «тимчасовий → керований» із розділу 5: до перетворення Salesforce володіє потенційним клієнтом; після — ERP володіє керованими атрибутами, а Salesforce і далі володіє своїми. Тож «яка система володіє акаунтом?» — слабке запитання. Питайте: яка система володіє цим атрибутом на цьому етапі життєвого циклу?

Копія — не авторитетність

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

Довірі потрібне більше, ніж значення

«Адреса для рахунків: 123 Main Street». Чи варто їй довіряти? Я хочу сигналів довіри: звідки вона, коли її востаннє підтвердили, яка система її надала і хто чи що змінив її востаннє: людина, інтеграція, агент? Тепер ERP каже 123 Main Street, Salesforce — 125, а файл партнера — «123 Main St., Suite 200». Яка правильна? Не відповідайте «беріть найновішу». Можливо. Але «найновіша» — саме правило, що припускає, ніби той, хто змінив останнім, заслуговує перемогти. Це може бути правдою, а може бути жахливим. Модуль 3 за це береться. Довіра походить з авторитетності й походження, а не з того, що знайшлося заповнене поле.

Steve Trucking: чия це істина?

Роздрібний партнер надсилає доставку, і в одній цій транзакції ховається кілька істин. Номер замовлення партнера — партнера; Steve Trucking зберігає його, щоб зіставляти оновлення, але не стає його майстром. Статус доставки (прибуло, доставлено, встановлено, виняток) — Steve Trucking; партнер його отримує, але отримання статусу не робить партнера авторитетним щодо того, що сталося на вантажівці. А отримувач — клієнт партнера. Партнер надає ім’я, адресу, телефон і нотатки до доставки, бо вони потрібні Steve Trucking, щоб доставити. Це не робить Steve Trucking майстром ідентичності цієї людини, і ця відмінність вирішує дизайн отримувача на контрольній точці.

Click to enlarge

Одна доставка, дві авторитетні сторони.

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

За межами іспиту: що змінює ШІ. Агенти перетворюють авторитетність атрибутів на правило виконання. Людина бачить неправильну адресу для рахунків і знає: «це з SAP; тут я не маю її змінювати». Агент, якому сказали «онови адресу для рахунків клієнта», цього не знатиме, якщо ми не спроєктуємо. Йому потрібна та сама карта авторитетності, що й архітекторові: доступ до поля не робить це поле правильним місцем для запису.

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

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

Єдине джерело істини не означає одну org, одну ERP, одну MDM-платформу чи один гігантський запис. Воно означає, що для кожної частини керованої інформації архітектура може сказати, де авторитетне значення, і кожна інша система через це знає, як поводитися. Це не єдине джерело істини. Це архітектура істини.

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

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