Continuous Architecture in Practice — выпуск 1

Клуб вернулся в эфир после паузы, и первые две главы помогает разбирать гость Максим — архитектор с четырнадцатью годами в телекоме, из них восемь во главе департамента ИТ-архитектуры, с опытом работы в регуляторе и в одном цифровом банке, сейчас на фрилансе и с занятиями по ИТ-архитектуре; ведущие рекомендуют его телеграм-канал про архитектуру и ИТ-решения. Обложку обсуждают отдельно: это первая книга новой серии про архитектуру и дизайн, где отдельные тома посвящены монолитам и микросервисам и API. Авторов трое, их имена участники честно называют сложными — уверенно звучит только Пьер; у двух из троих книга уже была, а нынешняя выросла из вопросов читателей, как всё это имплементировать в конкретной компании, поэтому здесь появился сквозной кейс через все главы. План клуба — четыре эфира по две главы, с последними страницами в финале.

Первая глава начинается с определений архитектуры — строительная аналогия, планы реализации, структура и связи, — и итоговое определение участникам кажется размытым: авторы исподволь внедряют собственный термин. Александр вспоминает, что многие книги по архитектуре втыкаются в ту же проблему и уходят в рефлексию, а Максим считает старт с определения прямым косяком: одно из процитированных определений критиковали все, и, по его словам, его недавно переделали — раньше речь шла о системе, теперь о чём-то куда более абстрактном. Ему кажется, что всю главу авторы подшучивают над архитекторами, чтобы дистанцироваться от нынешнего состояния ИТ-архитектуры и предложить свою альтернативу. Цель вложений в архитектуру сформулирована просто: доставлять бизнес-ценность в продакшн быстро и постоянно; причин названо четыре — атрибуты качества, принципы и стандарты, переиспользование и развитие, стратегическое планирование.

Вызовы архитектору — фокус на технологиях вместо бизнес-контекста, попытки решать организационные проблемы техническими средствами, репутация тех, кто тормозит поставку, — участники ловят на непоследовательности: вызовы будто описывают разные компании — то организацию, где вместо архитекторов большие активности тащат сами сильные инженеры, то корпорацию с гейтами и масштабированным agile. Один из ведущих признаётся, что при чтении это не мешало, а в разговоре стало видно, что картина не складывается. Максим резюмирует: книга вообще про процессы, откровений о делении системы на компоненты здесь не будет, будут рассуждения, как связать архитектурный процесс с разработкой; идея непрерывной архитектуры не первая, но у этих авторов самая целостная. Отдельно разбирают цитату из принципов Agile о том, что лучшие архитектуры рождаются у самоорганизующихся команд: смысл не в отказе от архитектуры, а в том, что её не должны навязывать сверху. В начале нулевых в такие слова можно было поверить, замечает один из участников, а через двадцать с лишним лет мы смотрим на ту самую архитектуру, которую вырастили самоорганизующиеся команды.

Шесть принципов пересказывает Вова: идти от проектов к продуктам; опираться на атрибуты качества, а не на функциональные требования, которые не сужают выбор решения; принимать решение максимально поздно, но не позже, чем нужно; использовать силу маленького — слабо связанные модули эволюционируют легче монолита; проектировать под пайплайн сборки, тестирования, деплоя и эксплуатации; влиять на организацию команд. Максим помнит, что в предыдущей книге принципов было, кажется, семь, и разбирает их придирчиво: продукт ценен тем, что объединяет центр затрат и центр выручки, и им можно управлять по венчурному принципу «убить или развивать», тогда как в проекте деньги сравнивают один-два раза. Деление требований на функциональные и нефункциональные он называет архаичным: девятки нужны не абстрактные, а привязанные к конкретному сценарию. «Силу маленького» авторы, по его мнению, не раскрыли — без ответа на вопрос «зачем» модульность вырождается в микросервисное безумие. Его мечта — чтобы вызовы прямо связали с принципами: отвечать шестью принципами на четыре вызова, не показывая, какой на какой, — не по-архитекторски.

Вторую главу открывает роль архитектора: когда всё замыкается на одном человеке, он становится бутылочным горлышком, поэтому ответственность за архитектуру авторы переносят на команду. Максим видит здесь прямую отсылку к Фредерику Бруксу: тот предлагал рекрутировать в архитекторы лучших и поручать им дизайн, а тут отвечают, что архитектурой должны заниматься все, и обещают для этого инструменты. Дальше архитектор балансирует между продакт-менеджментом с растущим числом фичей и сокращающимся time to market, деливери, которое выкатывает быстро, но ломко, и эксплуатацией; ведущий замечает, что дальше во второй главе эта линия растворилась. Активностей четыре: атрибуты качества, требования к которым описывают сценариями по методу ATAM — стимул, ожидаемый ответ, измеримость, окружение — с примерами вроде роста цены облака не больше чем на десять процентов; принятие и фиксация решений как основной unit of work архитектора; работа с техническим долгом; и цикл обратной связи, длины которого ведущему в книге не хватило: продакшн после большого проекта, каждый релиз или дробление внутри итерации. Главное здесь то, что задача архитектора не схема и не документ, а изменение того, что работает в продакшене.

Технический долг делят на кодовый, архитектурный и продиктованный инфраструктурой, а замечают его по медленным изменениям, лишней работе и росту дефектов. Максим ругает схемы: вторая нарисована в топологии первой, но про другое, и, изучив C4 Саймона Брауна — одного из тех, кто написал книге рекомендацию, — авторы могли бы прямо сказать, что это детализация квадратика с предыдущей картинки. Ему книга интересна больше эволюционной архитектуры, где всё упиралось в фитнес-функции, а внятного объяснения, что это и как ими пользоваться, он так и не встретил. Настоящую проблему книги он видит на схеме уровней: наверху решений мало, зато их фиксируют, внизу их много, но они не записаны, и остальная часть книги — про то, как запустить стрелку снизу вверх. Из трендов обсуждают архитектуру, которой владеет команда, и нотации: в UML верили все, но повально им не пользуются, есть ещё C4 и ArchiMate, а диаграммы должны быть простыми, согласованными и понятными аудитории. Финальная канбан-доска принимает запросы на архитектурные решения; через неделю клуб читает главу про данные.