Руководитель направления архитектуры решений Альфа-Банка Михаил Салахов, у которого за плечами больше 20 лет в IT и последние 5 лет в банковской архитектуре, выпустил подробный разбор профессии архитектора решений. Для русскоязычной IT-аудитории это полезный маркер: роль, которую часто романтизируют как «человек, который рисует диаграммы», на практике оказывается смесью системного мышления, переговоров и ответственности за чужие сроки и бюджеты.
В материале, сообщает Habr / Карьера, Салахов разбирает профессию по пунктам: кто такой архитектор решений, чем он отличается от корпоративного, системного и технического архитектора, как проходит собеседование, что происходит на онбординге и во что превращается первый год в роли. Его базовый тезис звучит довольно трезво: архитектор решений нужен не для презентаций про светлое цифровое будущее, а для того, чтобы бизнес-идея превратилась в исполнимое проектное решение, где заранее понятно, какие системы придется менять, как они будут интегрироваться и где проект рискует подорваться о реальность.
Ключевая зона ответственности здесь шире, чем может показаться по названию. Архитектор решений, по описанию автора, держит в голове весь IT-ландшафт банка, декомпозирует требования, определяет, какие функции должны появиться или измениться, раскладывает их по существующим системам и проектирует интеграции между ними и внешними сервисами. Ошибка на этом этапе стоит дорого не в метафорическом, а в вполне прикладном смысле: если какую-то доработку не заметили, ее не заложат в бюджет, не учтут в плане, а потом проект поедет по привычному маршруту «сроки вправо, расходы вверх, бизнес недоволен». Итог работы архитектора решений в Альфа-Банке оформляется в виде «архитектурного вижена» — верхнеуровневого документа с диаграммами систем, потоков данных, интеграций, процессов и ролей. Проще говоря, это не код и не ТЗ на все случаи жизни, а карта будущих изменений, по которой дальше смогут двигаться команды.
Отдельно интересно, что в профессию, по словам Салахова, не заходят по прямой траектории из учебника. В архитекторы решений приходят руководители разработки, продуктовых команд, аналитики, управленцы из интеграторов и вендоров, а также специалисты с опытом крупных проектов. То есть рынок по-прежнему воспринимает эту роль как следующую ступень после серьезной инженерной или управленческой школы, а не как стартовую позицию для человека, который хорошо выучил модные аббревиатуры. Автор прямо подчеркивает: архитектор решений прежде всего практик. Нужны не только знания о базах данных, очередях, паттернах и интеграциях, но и умение разговаривать с разработчиками, техлидами, безопасниками, руководителями бизнеса и корпоративными архитекторами так, чтобы после встречи стало понятнее, а не наоборот.
Банковский контекст здесь тоже не случайный. Салахов объясняет ценность опыта в финтехе сочетанием требований, которые редко уживаются мирно: безопасность, регуляторика, надежность, масштаб и постоянное давление на скорость вывода нового функционала. Это важный сигнал для рынка: архитектор решений в крупной компании отвечает не за абстрактную «правильную архитектуру», а за баланс между ограничениями, которые конфликтуют почти по определению. Поэтому на собеседовании кандидатов проверяют не только теорией. Вопросы касаются стандартов, очередей, оркестраторов, баз данных, ИБ, языков программирования, а еще дают практические кейсы, где нужно быстро собрать «архитектуру на салфетке». Из советов кандидату особенно показателен набор антибанальностей: подключаться с видео, быть готовым рисовать и шарить экран, не бояться спорить за собственное решение и не подглядывать ответы, включая подсказки от ИИ. Логика жесткая, но понятная: если человек может пересказать теорию, но разваливается на практическом кейсе, на реальном проекте это вскроется еще дороже.
Не менее показателен блок про онбординг и первый год. В Альфа-Банке онбординг архитектора решений считается завершенным через 3 месяца. За это время от человека ожидают не просто знакомство с процессами, а уже разработку и согласование архитектуры для реального проекта и участие в ранних стадиях реализации. Дальше начинается вполне взрослая жизнь: несколько задач одновременно, бэклог разной степени зрелости, постоянные переключения между приоритетами, необходимость фиксировать вопросы и ответы по требованиям и вести историю так, чтобы в задачу мог зайти любой участник. В этой части профессия выглядит не как клуб визионеров, а как дисциплина по удержанию сложности под контролем. Даже отмененная задача, как пишет автор, должна оставлять за собой понятный след: кто передумал, почему передумал и что именно было остановлено. Для крупных организаций это не бюрократия ради бюрократии, а страховка от коллективной амнезии.
Любопытна и бытовая сторона роли. Судя по описанию Салахова, рабочий день архитектора решений быстро заполняется встречами, обсуждениями бизнес-задач, консультациями команд и архитектурным надзором на этапе реализации. То есть чем ближе роль к реальной ценности для бизнеса, тем меньше в ней одиночной работы в башне из UML-диаграмм. Архитектора постоянно втягивают туда, где нужно снять противоречия между командами, неполными требованиями и ограничениями ландшафта. Для разработчиков это полезное напоминание: архитектура в enterprise-среде редко про идеальную технику в вакууме. Для менеджеров и HR это тоже сигнал: искать архитектора решений только по чек-листу технологий бессмысленно, если кандидат не умеет договариваться, формулировать рамки решения и держать удар от разнонаправленных стейкхолдеров.
На фоне рынка, где архитектурные роли часто подают либо как карьерный туман, либо как почетную ссылку из разработки в бесконечные созвоны, такой разбор ценен именно своей приземленностью. Из него следует простой, хотя и не очень утешительный вывод: архитектор решений остается одной из немногих IT-позиций, где за красивой схемой почти всегда стоит чужой бюджет, несколько команд и длинный хвост последствий. А значит, спрос на таких специалистов будет расти не там, где любят громкие тайтлы, а там, где бизнес уже понял цену архитектурной ошибки.