Небольшое послесловие к вебинару «Поток архитектурных решений», запись которого вы можете посмотреть здесь: 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
«Метафора проектирования в форме процесса последовательного принятия решений нравится многим моим собеседникам. » — оно так и есть. Только эта последовательность типа «pinball», а не «happy path». Архитектура последовательно задается моделями (см. 42010:2011), которые, идеально, суть цифровые модели» (см. https://egov-tm.blogspot.com/2018/04/blog-post_31.html ). Эти модели строятся и «выравливаются» (aligned) разными людьми, а архитектор отвечает за целостность всей коллекции.
Между моделями есть естественная упорядоченность, но, очень часто, работая с какими-то моделями мы понимаем проблему лучше и вынуждены сделать «шаг назад» и изменить уже существующую модель. А потом и все модели, которые зависят от нее. Т.е. получается траектория шарика в pinball.
Важно, что есть хорошие методы/паттерны о том, как получить какую-то модель из других моделей.
см. https://improving-bpm-systems.blogspot.com/search/label/%23BAW (лучше читать с «хвоста»).
Спасибо за комментарий. Думаю, по аналогии с технооптимистами и пессимистами можно ввести степень оптимизма в отношении моделей. В моём представлении мира BPMN сценарии не исполняются, изготовленные по чертежам детали дорабатываются напильником и т.п., а последовательность архитектурных решений, если и пинбол, то на нескольких автоматах, шарики между которыми перепрыгивают. Вообще, наверное уместно различать в архитектуре модели фактов и модели решений(потенциального будущего) и вот этим вторым моделям явно не хватает многовариантности
Спасибо за ответ. В природе, BPMN модели исполняются ужЕ последние 15 лет. Да, чем больше цифровых моделей тем лучше. Поэтому заинтересованные лица и их интересы — это тоже цифровые модели.
Что ты имеешь в виду говоря о «многовариантности»? Уточни, пожалуйста.
Проектирование решений — это азартная игра с будущей реальностью. В ряду предположений, мы выбираем на какое из них сделать ставку. Потом карты вскрываются и оказывается, что сработала совсем другая гипотеза. Раньше все архитекторы закладывались на самый худший вариант. Теперь это не всегда можно себе позволить. Первыми с этим столкнулись те, кто планировал нагрузку. Ну нельзя в ряде случаев обеспечить систему «железом» на самый оптимистичный маркетинговый прогноз. Денег не хватит
Развилки архитектурных решений (пример). Чтоб лучше проиллюстрировать эту заметку я выдумал простенький пример, который предлагаю вашему вниманию.
Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище.
К удивлению Семёна вечно занятый Евгений был на рабочем месте. Дорисовывая очередной слайд он бросил Семёну:
– Что у тебя?
– Доработка сервиса обработки заявок, — пробурчал Семён.
– И в чём вопрос? – поинтересовался Евгений.
– Оформляю архитектурные решения, хочу посоветоваться.
Евгений посмотрел эскиз, поморщился и выдал свой любимый вопрос:
– Альтернативы придумал?
– Дорабатываем существующий сервис – Семён слегка замешкался. – Или пишем новый.
В этот момент к разговору внезапно присоединились еще два участника. Проектный менеджер Пётр, курирующий все доработки внутренних приложений в рамках программы цифровизации административной и внтурихозяйственной деятельности и продуктовый менеджер Павел. Эти двое всегда ходили вместе и постоянно спорили между собой.
– Не надо нам ничего переписывать! – не здороваясь начал Пётр. – Всё должно было заработать уже вчера! Десятки заявок в день вручную приходится разгребать.
– Это потому, что Борис накосячил, – включился в разговор Павел. – Вручную разгребаются заявки, которые не обработались с первого раза.
– Ну вот и подвернулась возможность Борису реабилитироваться, — не сдавался Пётр.
Не дожидаясь, пока эти двое окончательно втянутся в бесконечный спор, Евгений встал, подошёл к доске и рисуя квадратики принялся увещевать участников импровизированного совещания:
– У нас несколько вариантов реализации этой задачки. Самый простой, но не самый правильный состоит в том, чтоб сделать ещё одну очередь и написать новый компонент, который будет перекладывать сообщения из старой очереди в новую. Попутно он будет трансформировать ваши заявки.
– Не вариант! – прервал Евгения Павел. – Половина заявок в этот момент уже лежит в очереди ошибочных сообщений и разгребать их будет не ваш волшебный сервис, а рота сотрудников службы поддержи.
Павел покосился на Петра, ища у него поддержки. Вопреки традиции постоянно спорить с Павлом Пётр закивал.
– Хорошо! Вариант номер два, — не отступал Евгений. – Подменяем существующий сервис новым, с таким же интерфейсом, что и сервиса Бориса. Он будет обрабатывать все заявки. Некоторые сразу сбрасывать в очередь, а часть отдавать в старый сервис.
Павел одобрительно закивал:
– Меньшую часть, я надеюсь, — удовлетворенно заметил Павел.
– Как получится, — включился в разговор Семён, про которого все уже, казалось, забыли. – Этот вариант не решит никаких проблем, только создаст новые!
Участники разговора повернулись к Семёну, стали разглядывать его с некоторой нехорошей настороженностью. Семён, уже с меньшей уверенностью, продолжал:
– Наша проблема в чём? Вот в этих синхронных вызовах внешних апи, — Семён указал рукой в правую часть доски, на которой могли бы быть нарисованы интерфейсы внешних систем, используемые для обогащения заявок дополнительными данными. – Сервис Бориса почему тормозит? Потому, что внешние системы ему медленно отвечают. Что новый сервис, что старый, работать всё будет так же плохо! Только дополнительный синхронный вызов воткнем, а по существу ничего не изменится.
Настороженность во взглядах собеседников стала преобразовываться в легкую злобу. Особенно у Евгения, предложившего, как ему казалось, такой отличный вариант.
– Ну и что с этим делать? – первым взял себя в руки Павел.
– Реплики данных из внешних систем, — предположил Семён
– И кто за это заплатит? – поинтересовался Пётр.
…
В общем, в этот день коллеги так ни о чем и не договорились. Евгений отправил Семёна писать adr. Семён быстренько накатал файлик с двумя вариантами: доработать существующий сервис или написать новый. А проблема осталась ждать своего решения
Это же не проблемы моделей — это проблемы governance.