Системного архитектора часто начинают искать после того, как продукт уже оброс интеграциями, команды принимают несовместимые решения, а любое изменение бьёт по трём сервисам. В этот момент бизнес хочет «сильного архитектора», но не может объяснить, какие решения он должен принимать и какие полномочия получит.
В подборе разработчиков такая размытость особенно опасна: под одним названием на рынок выходят enterprise architect, solution architect, системный архитектор и технический лидер. У них разные уровни ответственности, а совпадение слова architect в резюме ничего не гарантирует.
Определите уровень архитектурной роли
Системный архитектор обычно отвечает за устройство конкретной системы или группы связанных систем: компоненты, контракты, данные, интеграции, нефункциональные требования и эволюцию решения. Solution architect чаще проектирует решение под определённую бизнес-задачу и стыкует продукты. Enterprise architect работает на уровне ландшафта, принципов и портфеля технологий. Названия могут отличаться, поэтому границы нужно описать задачами.
Когда отдельный архитектор действительно нужен
несколько команд меняют одну сложную платформу
много внешних и внутренних интеграций
высоки требования к надёжности, безопасности или данным
решения имеют дорогие долгосрочные последствия
технические лидеры локально сильны, но нет общего направления
предстоит крупная миграция или декомпозиция legacy
Если продукт небольшой, одна команда владеет кодом, а решения быстро обратимы, отдельная архитектурная позиция может создать лишний слой согласований. Иногда правильнее усилить Engineering Manager или Staff/Principal Engineer.
Что зафиксировать в профиле
Опишите масштаб: пользователи, нагрузка, критичность, география, число команд, данные и регуляторные ограничения. Затем перечислите три–пять решений, которые предстоит принять в первый год. Только после этого добавляйте технологии. Архитектор ценен не энциклопедией паттернов, а способностью выбрать подход при конкретных ограничениях.
Как читать архитектурный опыт
Ищите не «разрабатывал архитектуру», а объект решения и последствия. Что менялось? Какие альтернативы рассматривались? Какие ограничения были по срокам, бюджету, людям и совместимости? Что кандидат сделал лично, кто утвердил решение, как проходила миграция и чем измерили результат?
Trade-offs важнее правильного ответа
В архитектуре редко существует единственно верное решение. Один вариант быстрее вывести, другой проще поддерживать, третий лучше выдерживает рост, но дороже. Сильный кандидат явно называет компромиссы, необратимые решения и условия пересмотра. Слабый выбирает знакомую технологию и объясняет её модностью или абстрактным best practice.
Нефункциональные требования
Проверьте, как кандидат переводит слова «быстро», «надёжно» и «масштабируемо» в измеримые критерии. Обсудите latency, throughput, доступность, восстановление, целостность данных, безопасность, стоимость и наблюдаемость. Архитектор не обязан сам реализовать каждый механизм, но должен видеть зависимости между требованиями.
Интеграции и данные
Для сложного продукта критичны контракты между системами, версии API, синхронные и асинхронные взаимодействия, владение данными, миграции и деградация зависимостей. Дайте кандидату схему с несколькими сервисами и внешним провайдером. Попросите найти риски и предложить эволюционный план без фантазии о полном переписывании мира.
Архитектурные документы и решения
Уточните, как кандидат фиксирует ADR, диаграммы, принципы и ограничения, кто читает документы и как они обновляются. Документация нужна не для архива, а для качества решений и общей картины у команд. Пятидесятистраничный документ, который никто не открывает, не является признаком зрелости.
Лидерство без формальной власти
Архитектор часто влияет на команды, которыми не управляет. Поэтому проверяйте, как он разбирает несогласие, вовлекает инженеров, признаёт ошибки и добивается исполнения решения. Техническая правота без доверия превращает архитектуру в презентацию, а не в работающую систему.
Кейс для интервью
Предложите продукт, который вырос из монолита, имеет три команды, нестабильную внешнюю интеграцию и требования к ускорению релизов. Дайте ограничения: нельзя остановить разработку и нет бюджета на полный rewrite. Попросите кандидата задавать вопросы, обозначить варианты, риски, этапы и критерии успеха. Не оценивайте красоту схемы отдельно от логики.
Красные флаги
архитектура начинается с выбора технологии
кандидат не спрашивает о бизнес-целях
единственное решение — переписать систему
нет опыта доведения решения до production
игнорируются стоимость и возможности команды
несогласие объясняется слабостью других инженеров
Чек-лист найма
Развести системного, solution и enterprise-архитектора.
Зафиксировать масштаб и будущие решения.
Проверить два завершённых архитектурных кейса.
Провести один системный кейс с ограничениями.
Оценить коммуникацию и влияние на команды.
Сверить полномочия, ответственность и критерии успеха.
Как сравнивать архитекторов, если решения разные
Не выбирайте кандидата только потому, что его схема совпала с мнением текущей команды. Оцените качество вопросов, полноту ограничений, ясность альтернатив, внимание к миграции и способность менять решение при новых данных. Два сильных архитектора могут предложить разные варианты и оба рассуждать профессионально. Scorecard должен измерять способ принятия решений, а не лояльность к любимому стеку интервьюера.
Первые результаты после выхода
В первые месяцы архитектору разумно провести диагностику ландшафта, определить владельцев решений, собрать карту рисков и договориться о формате архитектурных записей. От него не стоит ждать мгновенного редизайна всей платформы. Хороший ранний результат — общая картина, приоритетные проблемы, несколько принятых решений и понятный эволюционный план, который поддерживают команды. Если полномочий на внедрение нет, даже сильный найм быстро превратится в декоративную функцию.
Для редкой роли полезен подбор IT и digital-специалистов с картой компаний-доноров и смежных названий. Иначе поиск застрянет на одном title, хотя подходящие люди могут называться Staff Engineer, Principal Engineer или Solution Architect.
FAQ
Должен ли архитектор писать код?
Зависит от роли и стадии продукта. Ему нужна техническая глубина и контакт с реализацией, но доля hands-on должна быть честно определена до найма.
Нужен ли опыт именно в нашей отрасли?
Он критичен при специфичной регуляторике или доменных ограничениях. В остальных случаях важнее сходный масштаб и тип задач.
Можно ли проверить архитектора тестовым?
Короткий живой кейс с контекстом обычно полезнее большого домашнего задания. Он показывает вопросы, компромиссы и коммуникацию.
Кто должен участвовать в интервью?
CTO или руководитель инженерии, сильный технический лидер и представитель ключевого продукта. Толпа из десяти интервьюеров только размывает ответственность.
Как отличить архитектора от сильного senior-разработчика?
По масштабу решений, работе между командами, влиянию на долгосрочную эволюцию системы и способности связывать технические ограничения с бизнесом.
Вывод
Подбор системного архитектора — это поиск человека под конкретный масштаб решений. Если вам нужен подбор разработчиков, начните с ответственности, ограничений и будущих изменений, а не со списка паттернов.
IT and Digital ведёт подбор разработчиков по реальным архитектурным кейсам и личному вкладу кандидата — без попытки найти человека, который уже видел точную копию вашей системы.