В этой рецензии продолжаем линию на обзор книг по бизнес-практикам в ИТ, которую задала недавняя статья издательства БХВ. Книгу «Практическое руководство для архитекторов решений» написал российский автор Дмитрий Бардин, архитектор решений из Кинопоиска. Автор старался показать, как объединить архитектуру отдельного приложения с корпоративной архитектурой. Книга адресована разработчикам, аналитикам и руководителям групп (тимлидам), которые хотят понять, чем на самом деле занимается архитектор решений и как в эту роль перейти.
Рецензия по традиции начинается со ссылки на страницу книги «Практическое руководство для архитекторов решений» на сайте издательства БХВ. Напомним, что на все бумажные книги по компьютерным технологиям от издательств «БХВ Петербург», «Alist» и «Фолиант» доступен промокод SSPSOFT на скидку 25% как подарок читателям Хабра от нашего блога.
Книга вышла в 2026 году в серии «Профессиональное программирование», объем 400 страниц, девять глав. Во введении автор объясняет, откуда взялась идея книги. Когда Бардин возглавил группу архитекторов, перед ним встал вопрос, как и чему учить сильных разработчиков и инженеров, чтобы они выросли до уровня архитекторов решений.
Ответа сразу не нашлось, но позже накопленный опыт превратился в текст этой книги. Сам автор называет его сборником практических рецептов.
Для кого эта книга
Для наиболее широкой аудитории ИТ-книг в лице начинающих специалистов (джунов), стажеров и студентов совет будет таков, что читать эту книгу рано. Паттерны вроде SAGA, CQRS или Data Vault 2.0 даны сжато, в расчете на читателя, который уже встречал их в продуктовой среде (продакшене) или хотя бы при оценке кода (код-ревью). Оптимальная аудитория читателей, на наш взгляд, выглядит так:
• Ведущие разработчики и руководители направлений (техлиды), которых уже назначили архитекторами или вот-вот назначат.
• Системные и бизнес-аналитики, которым стало тесно/скучно в рамках одного продукта и которые хотят расти по профессии и влиять на решения в продуктовой дорожной карте компании.
• Архитекторы систем, переходящие на уровень решения, собранного из нескольких систем и интеграций.
• DevOps-инженеры и руководители проектов, которым нужно понимать логику архитектурных решений и мотивы компромиссов.
• Продавцы (в т.ч. пресейл-инженеры) и консультанты в компаниях заказной разработки, где зачастую аудит ИТ-инфраструктуры заказчика и архитектуру решения приходится изучать и готовить до подписания договора.
• CTO небольших и средних компаний, где архитектурной практики пока нет, но ее предстоит выстраивать с нуля.
Книга почти не привязана к какому-либо стеку технологий . Для аналитиков и менеджеров это облегчает чтение, а инженер или разработчик здесь не увидят привычных листингов. Код в книге встречается только в виде коротких фрагментов контрактов и архитектурных тестов.
Обзор глав
Глава 1. ИТ-архитектура и ее роль
Автор разбирает определения архитектуры под разными углами зрения, от ГОСТ Р 57100-2025 до формулировок Гради Буча и Мартина Фаулера и разводит понятия архитектуры и дизайна системы.
Самая полезная часть 1 главы посвящена так называемым антипаттернам работы архитектора. Это когда архитектор превращается в многозадачного менеджера, который ведет проекты, нанимает людей и даже сам кодит урывками, закрывая зависшие задачи. Архитектурный совет в такой компании даже якобы существует, но ответственность в нем размазана даже на уволившихся. В целом, кто работал в средних и больших российских компаниях, эту картину знает без прикрас.
Глава 2. Кто такой архитектор
Здесь рассказ про четыре домена архитектуры (бизнес, данные, приложения, инфраструктура), социотехническая архитектура и варианты нарезки команд по функциям, по доменам и по схеме «осьминог». Отдельно показано, как роль архитектора вписывается в идеологию ведения проектов по типам водопада, Agile и SAFe.
Автор дает понимание, почему архитектура в гибкой разработке превращается из «пути от А до Б» в серию стадий, которые запускают в эксплуатацию по мере готовности. Глава завершается сравнением ролей бизнес-архитектора, архитектора предприятия, архитектора решений и технического архитектора, а также разбором распространенных мифов о профессии архитектора.
Глава 3. Архитектура решения
Работа архитектора описана как постоянный переход от как есть “as is” к тому как должно быть “to be” через переходные архитектуры. Мотивационное видение показано в нотации Archimate, стратегия продукта разобрана на картах Уордли на примере эволюции рядового сайта со скидками до маркетплейса с отдельным сервисом промоакций.
Дальше идут “упоминание акционеров по Фриману”, функциональные и нефункциональные требования, модели качества ISO 25010 и МакКолла, сценарии атрибутов качества, приоритизация по MoSCoW и архитектурно значимые требования (ASR). Показана прямая формулировка разделения труда, когда аналитик работает с функциональными требованиями, архитектор отвечает за нефункциональные.
Для справки: Бизнес-тренер Эдвард Фриман проводил мысль, что компания работает не только на акционеров. Она должна учитывать интересы всех, кто влияет на бизнес или проект либо зависит от его результата:, т.е. заказчиков, пользователей, команды, партнеров, регуляторов, инвесторов.
Глава 4. Функциональная архитектура решения
Это короткая глава про бизнес-процессы и нотации для их описания, от UML и IDEF до EPC, DFD, BPMN и Archimate. Автор объясняет, какую нотацию выбирать под аудиторию и цель. Вторая половина главы отдана «событийному штурму» (Event Storming) по Брандолини с правилами работы со стикерами и примерами реальных досок.
Event Storming — это формат учебного практикума (воркшопа), который придумал тренер Альберто Брандолини. Разработчики, аналитики и представители бизнеса вместе восстанавливают бизнес-процесс на большой доске, реальной или виртуальной, с помощью цветных стикеров.
Глава 5. Архитектура данных
Это одна из самых объемных глав, около 70 страниц. Разведены понятия руководства и управления данными (Data Governance и Data Management), подробно разобраны измерения качества данных. Затем подробно разбираются измерения качества данных, описываются хранилища в их эволюции:
Корпоративное хранилище данных (DWH) по подходам Кимбалла и Инмона.
Гибридная модель хранилища (Data Vault 2.0). Она показана на таблицах хабов, связей и сателлитов для заказов и промоакций.
Озеро данных (Data Lake).
Озерохранилище (Data LakeHouse), которое объединяет озеро и хранилище.
Фабрика данных (Data Fabric).
Сетка данных (Data Mesh).
В главе полезен также раздел о том, как внедрять Data Mesh, когда в компании уже живут DWH и озеро. Далее DataOps, ETL против ELT, Zero ETL, методология DAMA-DMBOK, модели зрелости, метрики TCO и ROI и отличие Data Privacy от Data Security.
Глава 6. Архитектура приложений и техническая архитектура
Здесь центральная часть книги, больше ста страниц. Автор проходит по всему стеку решений архитектора, описывая следующие сущности:
Взаимодействия, протоколы, стили API, типы обмена и выбор между централизованной интеграционной платформой и гибкими интеграциями.
Архитектурные стили от многослойной архитектуры и сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) с разбором, почему SOA так и не оправдала ожиданий и далее до микросервисов, событийной и бессерверной архитектуры (Serverless).
Выбор баз данных с учетом теорем согласованности распределенных систем (CAP и PACELC) и моделей транзакций (строгой ACID и гибкой BASE), включая векторные БД для поиска по смыслу в сценариях генерации с опорой на документы (RAG).
Паттерны масштабирования, производительности и надежности, среди них автоматический выключатель (circuit breaker), изоляция отсеков (bulkhead), обратное давление (backpressure) и слой защиты от чужих контрактов (anti-corruption layer), а также бюджет ошибок через показатели, целевые уровни и соглашения об уровне обслуживания (SLI, SLO, SLA).
Безопасность по рейтингу уязвимостей OWASP, стратегии развертывания, наблюдаемость от «версии 1.0» до «3.0», распределенные транзакции через двухфазную фиксацию и цепочки компенсаций (SAGA), управление API (API Management).
Инфраструктура с уровнями надежности ЦОД (Tier), моделями аренды инфраструктуры, платформы и готового ПО (IaaS, PaaS, SaaS), сеткой сервисов (service mesh), системами хранения данных (СХД), расчетом ядер под нагрузку в запросах в секунду (RPS) и планом аварийного восстановления.
Каждый паттерн дан с плюсами, минусами и условиями применимости. Формула расчета ядер сопровождается перечнем причин, почему она дает завышенную пропускную способность. По таким оговоркам видно автора, который считал инфраструктуру для живой нагрузки.
Глава 7. Управление архитектурой
Основа главы: техническая стратегия, методологии и стандарты архитектуры, цикл разработки архитектуры (ADM) из методологии TOGAF, архитектурные строительные блоки и блоки решений (ABB и SBB), архитектурные принципы с примерами хороших и плохих формулировок.
Практическая часть включает шаблон журнала архитектурных решений (ADR), архитектурный репозиторий в системе контроля версий Git с диаграммами в PlantUML и сквозной пример документа по шаблону Arc42 для торговой площадки (маркетплейса) на двадцать с лишним страниц. Завершают главу функции соответствия, которые автоматически проверяют архитектуру на выполнение заданных требований, и технологический радар для управления набором используемых технологий.
Глава 8. Архитектура и риски
В этой главе про допустимый уровень риска (риск-аппетит), предельная емкость риска, классификация рисков уровня ИТ и подробный проход по методу анализа архитектурных компромиссов (ATAM) с деревом полезности, сценариями и шаблоном фиксации рисков.
Для сравнения описаны упрощенная оценка архитектурных альтернатив (LAAAM), сделан активный разбор промежуточного проекта (ARID) и анализ затрат и выгод архитектурных решений (CBAM). Для продуктовых команд предложен облегченный коллективный поиск рисков на доске (риск-шторминг). Глава заканчивается контролем рисков через функции соответствия, панели мониторинга (дашборды) и тесты на архитектуру кода.
Глава 9. Модернизация легаси
Описание текущего состояния системы (as is), рационализация портфеля приложений по методике TIME от Gartner (сохранить, инвестировать, мигрировать, вывести из эксплуатации), стратегии миграции семейства 7R и сравнение вариантов перепроектирования (Rearchitect), замены (Replace) и переноса на новую платформу (Replatform).
Последние страницы посвящены оценке трудозатрат экспертными методами, конструктивной моделью стоимости (COCOMO II) и методом функциональных точек. Для архитектора, которому поручили «придумать, как сделать хорошо, и сказать, сколько это стоит», это готовый план действий.
Насколько эта книга близка к практике российского ИТ?
Заметная часть материала пересказывает методологию TOGAF, свод знаний по управлению данными DAMA-DMBOK, книги Ричардса и Форда, Дехгани и Хононова. Заметно, где автор пишет из собственного опыта в российских компаниях, а где пересказывает западные управленческие схемы.
Как итоговое впечатление, методология и организационные проблемы описаны изнутри отечественной ИТ- индустрии, а сквозной технический пример местами уходит в облачные сервисы, которые российским компаниям недоступны (или доступны через разные обходные схемы).
Что надо признать за советы и контент уровня “Топ”
В первую очередь, можно отметить антипаттерны роли архитектора из главы 1 и совет не принимать предложение о работе (оффер) в компанию, где «все держится на архитекторе Петре». Об этом явно пишет человек, который сам проходил собеседования на позицию архитектора.
Второй топ-контент — это про историю методологий как свидетельство очевидца. До середины 2010-х в РФ доминировала каскадная модель ведения проектов (известная как “водопад”) со спиральными элементами, особенно в госсекторе и заказной разработке. Затем пришли гибкая методология Scrum и гибриды «водопада с элементами гибкой разработки», позже масштабируемая гибкая методология SAFe. Автор опирается на опросы компании ScrumTrek и прямо пишет, что гибкая разработка (Agile) у каждой компании своя.
Регуляторика тоже описана в книге. Здесь про ГОСТ 34-й серии, ГОСТ Р 57100-2025, 152-ФЗ, ЦБ как регулятор финансовых технологий, электронный чек через оператора фискальных данных (ОФД), Национальная система управления данными, импортозамещение как ограничение при выборе продуктов, отсутствие ЦОД высшего уровня надежности Tier IV в России.
Хорошо удался портрет унаследованной системы (легаси). База с двумя тысячами хранимых процедур, толстый клиент на Delphi или VBScript, коробочный продукт, внедренный «в рамках импортозамещения», дырявый, глючный и без обновлений. Любой, кто работал с легаси автоматизированной банковской системой (АБС) или в ИТ-отделе в страховой компании, узнает в описании свою систему.
Удались медийные кейсы как опыт автора в Кинопоиске. Изоляция рекомендательной системы от потокового вещания через шаблон изоляции отсеков (bulkhead), географическое распределение нагрузки и сеть доставки контента (CDN) для онлайн-кинотеатра..
Еще хорошо показана прагматика в управлении данными. Автор советует внедрять руководство данными (Data Governance) маленькими шагами по принципу 20/80 и признает, что тяжелая модель DAMA хорошо работает в банках и госструктурах, но для производства и среднего бизнеса избыточна.
Примерно две трети книги написаны из реального опыта российских компаний, остальное составляет добротный конспект международных методологий. Главный недостаток в этой части связан с техническим примером на облаке AWS, который логичнее было бы построить на отечественном облаке и инструментах.
Заключение
«Практическое руководство для архитекторов решений» дает очень цельную картину профессии архитектора, которая в российских компаниях до сих пор часто существует как «лычка» для опытного разработчика. Автор показывает, где заканчивается архитектура приложения и начинается архитектура решения, и дает инструменты для каждого шага.
Конкретики в книге много, это сбор нефункциональных требований, журнал архитектурных решений (ADR), метод анализа архитектурных компромиссов (ATAM), функции соответствия и оценка модернизации по модели стоимости COCOMO II. Главы про данные и про архитектуру приложений работают как справочник, к которому можно неоднократно возвращаться при проектировании.
Технический пример в облаке AWS и рейтинг OWASP года требуют поправки на реальность 2026 года для российского ИТ, но основа книги от них не зависит. Для разработчика или аналитика, который готовится к переходу на позицию архитектора решений, это одна из лучших понятийных книг на русском языке.
Немного о нас как компании — у нас почти всегда есть вакансии, мы 19 лет занимаемся заказной разработкой ПО и ИТ‑аутсорсингом (входим в Топ-50 ИТ-компаний России по рейтингу RAEX). Ждем резюме специалистов, готовых работать оффлайн в Москве (ЦАО) или в Томске, а также удаленно из любой точки России. Подробности о вакансиях читайте на странице ХХ.ру или пишите напрямую в ЛС руководителю службы найма в ТГ (можно и на почту job@ssp-soft.com). Не забудьте добавить «секретную фразу» в сопроводительное письмо: «Увидел(а) вашу вакансию на Хабре».
Успехов в освоении профессии архитектора решений!
Нам будет приятно, если заглянете в наш канал SSP SOFT в Telegram, там публикуем разные полезности из мира ИТ, советы для поддержания здоровья и продуктивности, проводим конкурсы с призами.