Архітектура — це мистецтво компромісів

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

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

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

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

Питання, на яке відповідає цей модуль: Коли можуть спрацювати кілька рішень, як архітектор обирає і пояснює свій вибір?

Якби архітектура полягала просто в тому, щоб знайти правильну відповідь, усе було б набагато легше. Вивчіть платформу, вивчіть шаблони, вивчіть ліміти, оберіть правильне — готово.

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

Багато способів розв’язати задачу

Я багато разів використовував варіацію цього прикладу, коли навчав архітекторів.

У Salesforce може бути багато способів розв’язати задачу. Іноді я називаю число, скажімо десять, але це аналогія, а не підрахунок. Багато варіантів мають проблеми від самого початку: натрапляють на обмеження платформи, пропускають критичну вимогу або створюють проблему з безпекою чи продуктивністю, яку ми не можемо прийняти. Їх можна швидко відкласти. Деякі інші працюють сьогодні, але матимуть проблеми, коли дані зростуть. Технічно вони функціонують, але не витримають зростання, про яке ми вже знаємо.

Лишається невелика кількість варіантів, які здатні підтримувати ваші потреби надалі, — і тут стає цікаво. Кожен із них може працювати, масштабуватися й задовольняти вимоги. То котрий правильний? Можливо, усі. Робота архітектора — розуміти різницю.

Навіть така проста річ, як список вибору, працює сьогодні й може мати проблеми, коли дані зростуть. Для користувачів список вибору зручний. Але запитайте, звідки беруться значення і скільки їх може бути. Списки вибору найкраще працюють, коли значень менше приблизно 20. Іноді ми доходимо до 50, як штати США, і рідко понад 100, як країни, — і такі списки стають незграбними. Тож для кожного списку вибору знайте верхню межу. А зміна значень списку вибору — це зміна метаданих, а не даних.

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

Click to enlarge

Оптимальне не означає ідеальне

Я обережно вживаю слово оптимальний. Оптимальна архітектура — не та, де кожне окреме рішення ідеальне; такої архітектури, мабуть, не існує. Це та, де загальне рішення збалансоване.

Припустімо, рішення A дає найкращу продуктивність, але дороге і складне в підтримці. Рішення B коштує менше і простіше в експлуатації, але поступається продуктивністю. Рішення C гнучкіше на майбутнє, але додає складності сьогодні. Котре оптимальне? З самих лише цих фактів я не можу відповісти. Мені треба знати бізнес, вимоги й пріоритети, а також які обмеження реальні, а які — лише вподобання. Архітектура залежить від контексту. Тому шаблон, правильний для одного клієнта, може бути зовсім хибним для наступного.

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

Неоптимальне рішення може бути частиною оптимальної архітектури

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

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

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

Знайте, чим ви жертвуєте

Щоразу, коли мені кажуть «це найкраще рішення», моє наступне запитання — «найкраще в чому?» Найшвидше? Найдешевше? Найпростіше? Найбільш масштабоване, найбезпечніше, найгнучкіше? Найлегше в експлуатації, найшвидше в доставці, найменш залежне від рідкісних навичок? Майже завжди є інший вимір, де відповідь не «найкраще». Це і є компроміс. Я хочу знати, що ми отримуємо, і хочу знати, від чого відмовляємося.

Візьмімо два варіанти для великого набору корпоративних даних. Один копіює дані в Salesforce, що полегшує використання вбудованих можливостей Salesforce, але тепер ми відповідаємо за їхнє переміщення, зберігання, синхронізацію, безпеку ще однієї копії і затримки. Інший лишає дані там, де вони є, і звертається до них за потреби. Ми прибрали частину дублювання, але тепер важливіші доступність, продуктивність запитів, мережеві залежності й можливості віддаленої системи. Жоден опис не каже нам, що обрати. Він каже, які запитання ставити.

Вимоги не рівноцінні

Компроміси також змушують побачити, що не кожна вимога має однакову вагу.

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

Мені подобаються вимоги, що витримують запитання: скільки, як багато, як швидко, як часто, для кого і що буде, якщо ні? «Швидко» — не архітектурна вимога. «95 відсотків оновлень клієнтів мають бути доступні сервісному агентові протягом 30 секунд» — уже значно ближче. Тепер можна оцінювати компроміси.

Обмеження змінюють відповідь

Іноді архітектуру обмежують зовсім не технології. Її обмежують гроші, люди, час, ліцензування чи організаційна зрілість.

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

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

Архітекторові потрібен образ «оптимального»

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

Дивлячись на модель даних, я хочу знати, що б я збудував, якби міг оптимізувати під вимоги без зайвих обмежень. Тоді, коли реальні обмеження відштовхують нас від цього дизайну (ми сплощуємо частину моделі, дублюємо деякі дані, відкладаємо інтеграцію, приймаємо тимчасовий ручний процес), я не роблю випадкових компромісів. Я знаю, в якому напрямку відходжу від оптимального і чому. Це мистецтво архітектури, і цей інстинкт потребує практики.

Намалюйте це

Один із найкращих способів зрозуміти компроміс — намалювати його. Архітектурні діаграми — не прикраса для презентації; це інструменти мислення. Якщо ми обираємо між двома підходами, намалюйте обидва. Де живуть дані і куди вони рухаються? Хто ними володіє? Де межі і де забезпечується безпека? Що станеться, коли щось зламається, і що зміниться, коли зросте обсяг?

Діаграма витягує неоднозначність на світло і дає всім ту саму картинку, на яку можна показати пальцем.

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

Оскільки від зустрічі до зустрічі це були ті самі люди, діаграма стала нашою спільною мовою. Люди почали вживати її назви. Повторювані запитання зникли, і зустрічі стали набагато легшими. Я називаю це заземленням зустрічі: проста діаграма, показана щоразу, була варта набагато більше, ніж коштувало її зробити.

Мета — не художня досконалість. Іноді це детальна діаграма для інженерів, іноді п’ять прямокутників і шість стрілок для керівника. Мета — ясність.

Поясніть компроміс

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

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

Think Correct. Think Fast.

У вас не завжди буде три тижні, щоб проаналізувати кожен варіант. Іноді буде три хвилини. Вимога змінюється посеред зустрічі, хтось називає обмеження, про яке ви не знали, або керівник питає: «А що, як наступного року це знадобиться в Європі?»

Я вживаю фразу Think Correct. Think Fast. (думай правильно, думай швидко). Швидкість береться не з того, що ви пропускаєте мислення. Вона береться з того, що ви достатньо подумали ще до настання моменту: вивчили шаблони, знаєте платформу, бачили збої, знаєте, які запитання ставити і які рішення важко скасувати. Тому протягом курсу ми розбираємо сценарії. Що більше рішень ви проаналізуєте, то швидше впізнаєте обриси наступного.

У мене був клієнт, якому потрібне було заповнення форм. Але форм було багато, і запитання могли змінюватися з часом. Я швидко розпізнав потребу в моделі даних для опитувань — шаблон, до якого ми повернемося пізніше в курсі. Оскільки я впізнав шаблон і рішення, то зміг запропонувати повнішу модель даних, яка враховувала й майбутні вимоги, а не лише ті, що були перед нами.

Архітектура — це про баланс

Заглиблюючись в архітектуру даних, ви зустрінете вибори, де я опираюся спокусі дати вам просте правило. Нормалізувати чи сплощувати? Копіювати дані чи федерувати? Синхронно чи асинхронно? Стандартний об’єкт чи користувацький? Архівувати чи тримати онлайн?

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

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

Це не нерішучість. Це архітектура.

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

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