Знайте свої інструменти: дев’ять запитань

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

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

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

Модуль 6 з 7 розділу Мислити як архітектор даних, першого розділу курсу Data Architect. Кожен модуль самостійний. Попередній: Будуйте для сьогодні. Плануйте на завтра. Плануйте на випадок збою. · Наступний: Архітектор даних в епоху ШІ

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

Архітекторам потрібне судження. Але судження без знань не надто корисне. Інструменти все одно треба знати.

Я роками навчаю архітекторів, і одна з моїх рамок — набір запитань, на які ви маєте вміти відповісти про кожен важливий інструмент чи можливість у вашій архітектурі. Спершу я викладав вісім запитань. Тепер додав дев’яте. Технології змінюються, Salesforce змінюється, з’являються нові продукти, старі можливості еволюціонують, а ШІ все це прискорює. Ці запитання працюють і далі.

Дев’ять запитань

Щоразу, коли вивчаєте чи оцінюєте технологію, питайте:

1. Що це?
2. Де це використовується?
3. Як цим користуватися?
4. Які в мене альтернативи?
5. Які в цього сильні сторони?
6. Які в цього слабкі сторони?
7. Як пояснити це розробникам, бізнесу і керівникам?
8. Як це підтримувати в довгостроковій перспективі?
9. Скільки це коштує, яких ліцензій потребує і які в цього ліміти?

Якщо ви можете відповісти на всі дев’ять, ви починаєте розуміти інструмент як архітектор. Зверніть увагу, чого немає в списку: «Чи можу я це налаштувати?» Це важливо, але це лише частина знання інструмента.

Click to enlarge

1. Що це?

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

2. Де це використовується?

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

3. Як цим користуватися?

Так, архітектори мають розуміти реалізацію. Вам не треба будувати кожен компонент, але треба розуміти достатньо, щоб знати, що ви просите збудувати інших. Знайте, як це налаштовується, як із цим працює розробник, як дані потрапляють усередину й назовні, як це розгортається й захищається і як виглядає в експлуатації. Я не хочу, щоб архітектор проєктував навколо технології, яку бачив лише на слайді продукту. Забрудніть руки: збудуйте щось, зламайте щось, подивіться, як воно поводиться насправді. Архітектура стає кращою, коли спирається на реальність.

4. Які в мене альтернативи?

Це, мабуть, найважливіше запитання у списку. Якщо ви знаєте лише один спосіб розв’язати задачу, у вас не архітектурне рішення, а варіант за замовчуванням. Щоразу, коли хтось пропонує технологію, я хочу знати, що ще ми могли б зробити. Інша можливість Salesforce? Щось декларативне чи код? Чи може ця можливість жити поза Salesforce? Чи можна лишити дані там, де вони є, замість копіювати, використати подію замість виклику API або взагалі нічого не будувати? Альтернативи створюють компроміси, а компроміси — серце архітектури.

5. Які в цього сильні сторони?

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

6. Які в цього слабкі сторони?

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

7. Як пояснити це різним аудиторіям?

Це одне з запитань, що відрізняють технічні знання від архітектурної майстерності. Чи можете ви пояснити ту саму технологію розробникові, бізнесу і керівникові? Це не мають бути однакові пояснення. Розробникові потрібні API, поведінка транзакцій, безпека, обробка збоїв і шаблони реалізації. Бізнес цікавить, що це дає і як змінюється його процес. Керівника цікавлять вартість, ризик, терміни, вплив на організацію і які варіанти рішення лишає відкритими чи закриває. Ви не змінюєте правду; ви змінюєте рівень абстракції. Якщо єдиний спосіб пояснити технологію — словами її документації, працюйте над своїм розумінням далі.

8. Як це підтримувати в довгостроковій перспективі?

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

9. Скільки це коштує, яких ліцензій потребує і які в цього ліміти?

Це запитання я додав до початкових восьми, і сьогодні вважаю, що його неможливо оминути. Технологія може бути ідеальним технічним рішенням і водночас хибним архітектурним, якщо не сходиться економіка. Чи входить вона в наявні ліцензії, чи це доповнення? Ліцензується за користувачами, використанням, споживанням, сховищем чи транзакціями? Що стається з вартістю, коли ми масштабуємося?

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

Розібраний приклад: Apex sharing

Ось один із моїх найчастіших прикладів роботи цих запитань. Ми отримуємо вимогу щодо складного спільного доступу — такого, якого не досягти жодним правилом спільного доступу на основі власника чи критеріїв. Це веде нас до Apex sharing: коду, який сам записує записи спільного доступу. Тож тепер нам треба знати, що таке Apex sharing, де він використовується, як ним користуватися і решту. Це ескалація: Apex sharing — це альтернатива (запитання 4) для випадків, коли потрібні правила виходять за межі того, що можна виразити спільним доступом на основі власника й критеріїв.

Тепер його слабкі сторони (запитання 6). Скажімо, у нас клієнтська спільнота з 10 чи 20 мільйонами учасників, і ми використовуємо ліцензію Customer Community, а не Customer Community Plus. Це користувачі великого обсягу (high-volume users). У них немає ролей, і вони взагалі не використовують модель спільного доступу: їхній доступ дають sharing sets і share groups, зіставлені через їхній акаунт і контакт. Для них немає запису спільного доступу, який міг би записати Apex, тож Apex sharing для них не працює. А запитання про вартість і ліцензування (запитання 9) — саме те, що нас туди привело: вибір ліцензії вирішив, які інструменти спільного доступу взагалі існують.

Тож так само, як Apex sharing був альтернативою правилам на основі власника й критеріїв, вам може трапитися випадок, коли потрібна альтернатива Apex sharing. І на цьому етапі для складних правил спільного доступу справді немає варіантів на основі конфігурації. Зрештою ви робите об’єкт лише для читання і контролюєте доступ через Apex. Ось чому всі дев’ять запитань ставлять до вибору, а не після.

Не завчайте платформу

Це найважливіше тоді, коли ви вивчаєте архітектуру Salesforce. Не намагайтеся завчити Salesforce. Ви не зможете: платформа завелика і змінюється занадто швидко. Я давно працюю з Salesforce і досі вчуся. Це нормально.

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

За межами іспиту: ШІ дає змогу швидше відповідати на дев’ять запитань — і легше помилятися. Натрапивши на незнайому технологію, ви можете попросити ШІ пояснити її, порівняти три підходи, перелічити її ліміти й типові режими збоїв або аргументувати проти її використання. Це чудовий дослідницький помічник. Але він може помилятися, застаріти або впевнено переплутати два продукти чи редакції зі схожими назвами. Усе, що впливає на рішення, перевіряйте: ідіть за джерелом і звіряйтеся з актуальною документацією, лімітами й ліцензуванням. Довіряй, але перевіряй (модуль 7).

Вивчайте запитання, а не лише відповіді

У цьому курсі ми зустрінемо багато технологій. Я не хочу, щоб ви збирали відповіді; я хочу, щоб ви практикували запитання. Коли говоритимемо про big objects, зовнішні дані, Data 360, інтеграційні шаблони чи можливість ШІ, яку Salesforce випустить через пів року після написання цього розділу, ставте ті самі дев’ять запитань.

Відповіді зміняться. Запитання довговічні. Саме це робить їх архітектурною рамкою, а не конспектом.

Знайте свої інструменти: у чому вони добрі, у чому погані, що ще можна використати, скільки вони коштують і де ламаються. І знайте достатньо, щоб пояснити рішення людям, яким із ним жити. Так архітектор вивчає технології.

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

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

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

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-09; повторно 2026-10-12): користувачі великого обсягу (ліцензії External Apps, Customer Community, High Volume Customer Portal і Authenticated Website) не мають ролей; їхній доступ дають sharing sets і share groups; їх не можна включати в правила спільного доступу на основі власника, а записами, якими вони володіють, не можна ділитися вручну.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (англійською, перевірено 2026-10-09; повторно 2026-10-12): користувачі великого обсягу (Customer Community, High Volume Customer Portal, Authenticated Website) не використовують модель спільного доступу, бо їхні ліцензії не підтримують ролей; доступ працює через зіставлення користувача з lookup-полями Account і Contact, через sharing sets або share groups. Та сама сторінка перелічує, коли Apex managed sharing — правильний інструмент.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), запитання в Trailblazer Community, листопад 2024 р. (англійською, перевірено 2026-10-09; повторно 2026-10-12): практик повідомляє, що вставлення записів спільного доступу для користувачів великого обсягу завершилося помилкою. Польовий звіт, а не офіційна документація. (Онлайн-спільнота Trailblazer Community стане доступною лише для читання 30 жовтня 2026 р.; посилання може змінитися.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-09): sharing set надає доступ до записів, пов’язаних з акаунтом або контактом користувача.