Небольшое послесловие к вебинару «Поток архитектурных решений», запись которого вы можете посмотреть здесь: https://youtu.be/9vtf33NIJrE Метафора проектирования в форме процесса последовательного принятия решений нравится многим моим собеседникам. Кого-то прельщает возможность формализации архитектурной деятельности, другие видят в этом потенциал для автоматического создания архитектурных описаний в ходе разработки (см. Архитектура как код), третьи, вероятно, вспоминают институтские занятия про теорию игр и деревья решений. Приверженцы agile видят в архитектурных решениях реализацию идеи architecture owner, собирающего жемчужины решений, родившихся у самоорганизованных команд. Латентные любители «водопада» — подтверждение инженерного подхода к проектированию ИТ-решений.
Я сам, скорее всего, принадлежу именно к третьей категории, в глубине души мечтая о том, чтоб процесс проектирования был не сильно сложнее, чем разработка стратегии игры из 6 главы замечательной книжки Чарльза Уэзерелла “Этюды для программистов”, доставшейся мне в качестве курсовой на каком-то из младших курсов. Именно поэтому мне хочется предостеречь читателей этой заметки от подкупающего своей простотой взгляда на проектирование, как на преодоление развилок в графе.
Казалось бы, всё очень просто: есть задача реализации какой-то системы. На самом старте проекта мы имеем некоторое количество «развилок», касающихся выбора технологий, организации данных, функциональной декомпозиции. Осуществление первого выбора открывает нам второй уровень, состоящий из более детальных и, быть может, менее важных решений. И так далее мы опускаемся в принятие совокупности решений, выбирая лучшие или просто достаточно хорошие на каждом из уровней. Так вот, эта простая и понятная модель неверна. Несколько аргументов почему:
- Пространство решений существенно больше, чем это описано выше. Мы можем не только выбрать некое решение А из набора альтернатив А, B и C, но и осуществить множество других выборов. Например, тянуть время и не выбирать ничего или же расширить список вариантов, добавив к ним D, Е и F. Можем для разнообразия подумать головой и попробовать совместить преимущества некоторых вариантов. Более того последовательность выборов важна: уйдя слишком глубоко в одну ветвь дерева, вряд ли мы захотим возвращаться за низковисящим яблоком на соседней ветке.
- Постановка задачи обычно настолько неконкретна, что одно только формулирование и обсуждение с заказчиком вариантов реализации склоняет потребность в ту или иную сторону. Т.е. мы формулируем требования в ходе рассмотрения вариантов их реализации. Мысль эта отлично выражена Фредериком Бруксом в его второй книжке Design of Design (Проектирование процесса проектирования) и чуть менее внятно в модели Twin Peaks
(см., например, здесь https://www.microtool.de/en/what-is-the-twin-peaks-model/ ) - Процесс архитектурных решений не изолирован одним проектом, системой или задачей. Мы живем в постоянно меняющемся поле идей, приоритетов, организационных и технологических изменений. Имея в портфеле несколько проектов всегда можно немного слукавить. В отличии от экзамена в институте, предполагающего вытягивание билета вслепую или бэклога с заданными приоритетами, реальная деятельность допускает выбор задачи, на которую нам заранее известен ответ. Из трех потенциальных проектов мы отдадим предпочтение тому, который решается микросервисной архитектурой. Два других мы тоже обязательно сделаем, но потом… Когда пользователь напишет полные, непротиворечивые, однозначно трактуемые требования. Упорядоченные по важности и согласованные всеми заинтересованными лицами, включая отдел информационной безопасности.
- А еще архитектурные решения принимаются не последовательно, а параллельно, причем различными акторами, преследующими противоречивые цели и имеющими разные интересы. Организация — сложная система (привет любителям Пятой дисциплины и Large Scale SCRUM), существующая благодаря временному достижению некоторого динамического равновесия. Какое уж тут «дерево архитектурных решений»?
Значит ли всё мною сказанное, что построенный в модели архитектурных решений подход заведомо неверен? Разумеется нет! Ну, или корректней будет высказаться фразой Джорджа Бокса (George E. P. Box): «В сущности, все модели неправильны, но некоторые полезны»
PS: В комментариях ниже простой пример: https://mxsmirnov.com/2019/10/22/ps-adr/#comment-31308