Мислити як архітектор
Також доступно 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)
Модуль 1 з 7 розділу Мислити як архітектор даних, першого розділу курсу Data Architect. Кожен модуль самостійний. Попередній: огляд розділу · Наступний: Модель даних — це скелет
Питання, на яке відповідає цей модуль: Яка різниця між тим, щоб будувати, і тим, щоб проєктувати архітектуру, і що насправді робить архітектор?
Більшу частину своєї кар’єри я був будівельником.
Я починав як розробник. Працював із Java і .NET, перш ніж перейти до Salesforce, і роками проєктував системи, писав код, інтегрував платформи, навчав архітекторів і рецензував архітектури.
Але один із найважливіших уроків, які я засвоїв дорогою, такий: бути чудовим будівельником і бути чудовим архітектором — не завжди одне й те саме.
Будівельник питає:
Як мені це збудувати?
Архітектор мусить ставити інший набір запитань:
Чи варто нам це будувати?
Чому ми будуємо це саме так?
Які є альтернативи?
Що станеться, коли це стане більшим?
Що станеться, коли це зламається?
І яке рішення ми ухвалюємо сьогодні, про яке через три роки пошкодуємо, що не подумали над ним ретельніше?
Пам’ятаю проєкт для роздрібного бізнесу із записами на прийом. Я запитав: скільки записів на день на один магазин? Потім: скільки у вас магазинів? І скільки днів на тиждень ви працюєте? Дуже швидко я зрозумів, що лише за перший рік у нас будуть мільйони записів. Саме такі запитання архітектор ставить на початку проєкту.
Ця зміна мислення — те, про що насправді цей курс.
Людина, яка тримає креслення
Section titled “Людина, яка тримає креслення ”Я багато разів використовував цю аналогію, коли навчав архітекторів.
Уявіть будівельний майданчик. Там люди заливають бетон, прокладають електрику, монтують сантехніку, зводять каркас стін і виконують десятки інших спеціалізованих робіт. Їм потрібно дуже добре знати свою справу.
Але хтось також має тримати креслення.
Ця людина має розуміти, як усі ці частини поєднуються. Вона має помічати, коли щось в одній частині проєкту створює проблему деінде.
Це і є архітектура.
У технологіях ми іноді помилково думаємо, що архітектор — це просто людина, яка знає найбільше. Насправді ні. Знання платформи важливе. Потрібна технічна глибина. Але архітектура — не вікторина.
Робота архітектора — ухвалювати добрі рішення, іноді з неповною інформацією та суперечливими вимогами, і розуміти наслідки цих рішень.
Це зовсім інша навичка.
Не просто приймайте вимогу
Section titled “Не просто приймайте вимогу ”Одна з перших звичок, яку я хочу виробити в архітекторів, проста:
Питайте «чому».
Вам кажуть:
Нам потрібен ще один об’єкт.
Чому?
Нам треба скопіювати це поле в Account.
Чому?
Нам потрібно зберігати всі ці дані в Salesforce.
Чому?
Це не означає бути складною людиною. Це означає розуміти справжню бізнес-вимогу, замість того щоб одразу втілювати запропоноване рішення.
Вимога часто приходить замаскованою під дизайн.
«Нам потрібен новий користувацький об’єкт» — не обов’язково вимога. Справжня вимога може бути такою: «нам треба відстежувати цю інформацію окремо». Це не одне й те саме.
Щойно ви зрозуміли справжню вимогу, можна шукати альтернативи. Можливо, новий об’єкт — саме правильна відповідь. Можливо, інформації місце в чомусь, що вже існує. Можливо, Salesforce взагалі не має володіти цими даними.
Архітектор має відокремлювати те, що потрібно бізнесу, від одного запропонованого способу це забезпечити.
Ми працювали над застосунком для продажів, і в замовника було кілька погоджень, кожне з погоджувачем і датою. Першим проханням було додати Approver 2 і Approver 3, кожен із датою, як поля в Opportunity. Коли ми копнули глибше, то зрозуміли, що погоджень може бути більше двох чи трьох. Тож ми винесли погодження в дочірній об’єкт. Просили більше полів; вимогою було відстежувати кожне погодження, скільки б їх не виявилося.
Думати далі за вимогу
Section titled “Думати далі за вимогу ”З питання «чому» випливають дві звички, і кожна отримає власний модуль далі в цьому розділі.
Зазвичай відповідь не одна. Salesforce дає нам багато способів розв’язати задачу, і деякі з них хибні майже одразу. Вибір між тими, що працюють, — це мистецтво компромісів (модуль 4).
А вимоги, які вам дали, — не всі вимоги, які у вас є. Ніхто не каже «переконайтеся, що це працює, коли нічне завантаження вдається лише наполовину», але це все одно вимога. Я дивлюся на кожен дизайн крізь три лінзи: будуйте для сьогодні, плануйте на завтра, плануйте на випадок збою (модуль 5).
Подумайте про людину, яка наймає архітектора спроєктувати будівлю. Вона не просить пожежну сигналізацію чи спринклерну систему або щоб будівля встояла під час землетрусу. Вона очікує цього як частини роботи, не питаючи. Наш світ влаштований так само. Ніхто не просить коректної обробки помилок, журналів чи способу відновитися, коли щось ламається. Саме архітектор має знати, які з цих систем належать до дизайну, і закласти їх.
Робіть свої міркування видимими
Section titled “Робіть свої міркування видимими ”Архітектор не повинен просто зайти в кімнату й оголосити: «Робимо ось так».
Ваша робота — ще й пояснити чому. Я хочу, щоб зацікавлені сторони розуміли альтернативи, які ми розглядали, і компроміси, що з ними пов’язані. Це не означає давати керівникові 40-сторінковий проєктний документ. Це означає вміти пояснити ту саму архітектуру розробникові, бізнесу і керівникові: різні розмови про одне рішення.
А робиться це за допомогою чітких креслень та інструкцій, як у людини, що тримає креслення на будмайданчику. Для архітектора даних одне з найважливіших таких креслень — модель даних.
Якщо ніхто не розуміє, чому ухвалили рішення, велика ймовірність, що хтось його зрештою скасує. І в нього можуть бути цілком розумні причини, бо первісне рішення ніхто так і не пояснив.
Архітекторові не треба будувати все
Section titled “Архітекторові не треба будувати все ”Є ще один перехід, який буває важким, особливо для тих, хто приходить в архітектуру з розробки.
Вам не потрібно власноруч будувати все.
Мені досі подобається розуміти, як усе працює на дуже технічному рівні, і цей фундамент важливий. Але як архітектор ви відповідаєте за більше, ніж ваша власна реалізація. Вам не треба будувати все; вам треба вміти дати тим, хто будує, правильний напрям і правильні параметри. Це означає розуміти достатньо, щоб спрямовувати їхню роботу, розпізнавати, коли запропонована реалізація створює архітектурну проблему, і переходити між деталями та загальною картиною.
Іноді це означає заглибитися в запит, API чи модель даних.
Іноді — відступити й запитати, чи варто нам узагалі цим займатися.
І дедалі частіше будують не лише люди. З ШІ архітектор може працювати безпосередньо з інструментом, що генерує об’єкти, код і екрани. Тоді напрям, параметри й настанови отримує ШІ, і давати їх добре стає дедалі більшою відповідальністю архітектора. Ми повернемося до цього в модулі 7.
Це частина шляху від будівельника до архітектора.
Ваша робота — ухвалювати рішення
Section titled “Ваша робота — ухвалювати рішення ”Зрештою, архітектура — це про рішення.
Деякі рішення легко змінити. Інші — ні.
Макет сторінки можна змінити. Мітку можна перейменувати.
Але оберіть хибну базову модель даних, опублікуйте ідентифікатори, від яких почнуть залежати десятки систем, або покладіть головну копію критичних даних не в те місце — і передумати стане набагато дорожче.
Це архітектурні рішення. І саме на таких рішеннях зосереджується цей курс.
Як архітектор даних ви ухвалюватимете рішення про те, як структурована інформація, де вона живе, як зростає, як переміщується, хто має до неї доступ і як її розуміє решта підприємства.
Технології важливі.
Але знати кожну функцію Salesforce — не мета.
Мета — розвинути судження, щоб знати, який інструмент використати, коли його використати, чим ви жертвуєте і що буде далі.
Це і є мислити як архітектор.
А тепер можна починати мислити як архітектор даних.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Чи є запит справжньою вимогою, чи лише одним запропонованим дизайном для неї.
- Які запитання поставити, перш ніж щось будувати: чи варто, чому саме так, що ще можна зробити, що станеться, коли воно виросте або зламається.
- Які рішення ухвалює архітектор, а які належать тим, хто будує; і який напрям і параметри дати будівельникам — людям чи ШІ.
- Як пояснити рішення так, щоб його зрозуміли і розробник, і бізнес, і керівник.