У великій команді один архітектор, через якого проходять усі рішення, стає вузьким місцем: рішення чекають тижнями, а ухвалюються далеко від людей, що знають деталі. У маленькій - навпаки, рішення ухвалюються «мимохідь», і через рік ніхто не пам'ятає чому.
Поділ рішень за вартістю зміни:
- оборотні («двосторонні двері») - легко змінити: структура класів усередині модуля, вибір бібліотеки для внутрішньої задачі. Ухвалюються швидко, тими, хто робить роботу;
- необоротні («односторонні двері») - дорого змінити: формат публічного API, основна база, розбиття на сервіси, модель даних, автентифікація. Тут варто зупинитися, зібрати думки й записати рішення.
Процес порад (advice process) - підхід, який описує Андрю Гармел-Ло в статті на сайті Мартіна Фаулера:
- будь-хто може ухвалити архітектурне рішення, але спершу мусить порадитися з тими, кого воно зачепить, і з тими, хто має досвід у цій галузі;
- порада не є вето - відповідальність за рішення лишається на тому, хто його ухвалює;
- рішення фіксується в ADR - разом із контекстом, альтернативами й отриманими порадами;
- архітектурний форум (регулярна зустріч) - місце, де обговорюють поточні рішення й діляться ними, а не орган затвердження.
Інструменти, що підтримують такий підхід:
- ADR - пам'ять про рішення і їхні причини;
- принципи архітектури - кілька загальноприйнятих правил («межі модулів не перетинаємо напряму», «нові інтеграції - через черги»), щоб більшість рішень можна було ухвалити самостійно, звіряючись із ними;
- технологічний радар - перелік технологій зі статусами «використовуємо», «пробуємо», «не використовуємо»;
- функції придатності - автоматична перевірка того, що вже вирішено.
Чого уникати:
- рішення без обговорення з тими, хто житиме з наслідками (експлуатація, безпека, інші команди);
- комітет, що затверджує все - повільно й знімає відповідальність з авторів;
- рішення без запису - через рік їх «виправляють» люди, які не знають контексту.
На співбесіді важливо показати, що архітектура - не лише технічні знання, а й процес: як збирати інформацію, зважувати компроміси, документувати й поширювати рішення.
Докладніше в документації: Martin Fowler: Scaling the Practice of Architecture, Conversationally