Solution Architect vs Software Architect: кто нужен вашей команде?

Вы нашли архитектора на проект и ожидаете, что он поможет довести продукт до релиза без сюрпризов. Но со временем выясняется, что оценка не учла важную интеграцию, команда упирается в неудачное стартовое решение, а систему приходится перестраивать под нагрузку, которую не предусмотрели. Проблема не всегда в квалификации специалиста. Иногда вам просто был нужен архитектор другого профиля: Software Architect, который отвечает за внутреннюю архитектуру и развитие системы, или Solution Architect, который определяет, как закрыть бизнес-задачу, интегрировать решение с другими системами и оценить его стоимость.

В статье разберем, где проходит граница между этими ролями, когда нужна каждая из них и как проверить архитектора на собеседовании.

Почему Solution Architect и Software Architect так часто путают

Начнем с общего: обе роли — про архитектуру. И Software Architect, и Solution Architect не просто выполняют отдельные задачи, а проектируют систему, взвешивают варианты и принимают решения, последствия которых команда будет ощущать годами.

Кроме того, software и solution неофициально работают как синонимы в IT:

решение — это то, что мы пишем,
а то, что мы пишем — это программное обеспечение

Разница — в масштабе этих решений. Software Architect работает прежде всего с программной системой. Solution Architect — с бизнес-задачей, где программное обеспечение может быть лишь частью решения. Купить готовый продукт, перестроить интеграцию или оставить часть процесса в старой системе — тоже варианты, которые он должен оценить.

Путаницу усиливает то, что в компаниях эти роли редко существуют в чистом виде. В небольших командах все архитектурные решения может принимать один человек. В продуктовых компаниях обязанности Solution Architect часто распределяются между несколькими ролями без отдельной должности. Поэтому название в резюме мало что гарантирует.

К тому же зарплаты этих ролей часто похожи. Поэтому компании выбирают между ними прежде всего по своим задачам, а не по четкому разделению ролей на рынке.

Что должен уметь Software Architect на проекте?

Software Architect отвечает на вопрос: «Как будет работать система?». Его задача — спроектировать ее так, чтобы она выдержала не только первый релиз, но и дальнейшее развитие. Эти решения становятся фреймворками, в которых работает команда разработки.

Ближайшая аналогия — архитектор дома, который работает с уже определенными требованиями. Он проектирует новые конструкции, перекрытия, инженерные сети и готовит схемы для строительной бригады. Software Architect делает то же самое с системой: определяет, из каких частей она состоит, как они связаны между собой и по каким правилам систему можно расширять.

Software Architect должен находить ответы на такие вопросы:

• Как система будет вести себя под нагрузкой?
• Что произойдет, если один из сервисов откажет посреди операции?
• Насколько сложно и дорого будет изменить систему через год?
• Из каких компонентов состоит система и как они взаимодействуют?

Типичный инструментарий:

• разделение системы на модули или сервисы с четкой ответственностью;
• паттерны проектирования и понимание их преимуществ и рисков;
• схемы и диаграммы, которые помогают согласовать решение до написания кода;
• работа с нефункциональными требованиями: нагрузкой, доступностью, консистентностью данных и частичными отказами;
• управление техническим долгом: что исправлять сейчас, что можно отложить и когда к этому вернуться.

Ошибка Software Architect не всегда затрагивает весь проект, но часто проявляется уже в готовом продукте — под реальной нагрузкой и с реальными потерями для клиента.

В эту роль чаще всего приходят из разработки, реже — из DevOps. Поэтому в резюме сильного кандидата обычно есть несколько лет практической работы в том же стеке, в котором он впоследствии проектировал системы.

На рынке эта роль довольно предсказуема: зарплата зависит прежде всего от глубины технической экспертизы в конкретном стеке. Для Java, .NET или Cloud уже сложились понятные рыночные ориентиры. По данным ZipRecruiter, среднегодовая зарплата Software Architect в США составляет около $174 тыс. Спрос также стабильный и наибольший в продуктовых компаниях и командах, которые годами развивают один сложный продукт.

Как Solution Architect влияет на бизнес-решения

Solution Architect отвечает на вопрос: «Каким решением выполнить бизнес-задачу?». К нему она приходит не как готовое техническое задание, а как проблема, для которой нужно найти лучший способ решения.

Solution Architect определяет:

• строить ли систему с нуля;
• что оставить в legacy;
• что выгоднее купить в готовом виде;
• как перестроить интеграции между системами.

Если продолжить строительную аналогию, Solution Architect больше всего похож на городского планировщика. Он решает, что должно появиться на определенном участке, как объект подключится к городской инфраструктуре и как повлияет на окружение. Так же Solution Architect работает не с одной системой, а с ее местом среди других: как она будет интегрироваться, что для этого нужно и сколько это будет стоить.

Цель Solution Architect — согласовать архитектуру проекта еще до начала разработки. На пресейле и раннем discovery кода еще нет, команда не сформирована, требования неполные, но бизнес уже должен понимать стоимость, сроки и риски. Задача Solution Architect состоит в том, чтобы уменьшить неопределенность настолько, чтобы проект можно было реалистично оценить с учетом бюджета, регуляторных требований и ограничений по данным.

Инструментарий Solution Architect шире и меньше сфокусирован на внутренней структуре кода:

• сравнение вариантов: построить, купить, интегрировать или оставить как есть — с оценкой стоимости и рисков;
• выбор инфраструктуры, платформ и вендоров с учетом лицензий, поддержки и доступности специалистов;
• распределение ответственности между системами и командами до, во время и после внедрения;
• фиксация допущений и рисков, которые могут повлиять на сроки и оценку;
• работа со стейкхолдерами: сбор требований, согласование между командами и защита решения перед бизнесом.

Solution Architect часто первым обсуждает задачу с заказчиком и объясняет технические варианты людям без опыта в разработке. От того, насколько хорошо он соберет контекст и покажет последствия каждого решения, зависит выбор бизнеса. На этом этапе он работает вместе с продакт-менеджером: Solution Architect оценивает техническую реализацию, а продакт — ценность и окупаемость идеи. Далее Solution Architect согласовывает решение с Software Architect, delivery-менеджерами и командой разработки, а продакт — с бизнес-аналитиками и продакт-оунерами. Позже подключается delivery или CTO, который ориентирует по ресурсам команды.

Решения Solution Architect принимают раньше всего, когда еще ничего не построено, но их ошибки могут проявиться значительно позже — когда команда уже сформирована, контракты подписаны, а часть системы готова. Тогда изменить направление может стоить дороже, чем переписать отдельный модуль. При этом такие специалисты остаются с проектом на протяжении всего его жизненного цикла и следят за запуском, внедрениями и изменениями в бизнесе.

У Solution Architect больше путей входа, чем у Software Architect. Часть кандидатов приходит из разработки, другие — из руководящих и бизнесовых ролей, где уже выполняли похожие задачи: IT-директора, руководители IT-отделов в не-IT компаниях, R&D-менеджеры и специалисты по пресейлу.

Найм Solution Architect менее предсказуем, чем Software Architect. Зарплата может быть на том же уровне или существенно выше — в зависимости от объема ответственности. В частности, от того, входят ли в роль пресейл, прямая работа с клиентом и архитектура нескольких проектов или целого портфеля. Медианная сумма для Solution Architect на американском рынке составляет около $228 тыс. в год.

Какой архитектор нужен: типичные бизнес-сценарии

Если проект пока существует только как идея, важно сразу определить, кто нужен — Solution Architect или Software Architect. Чтобы не ошибиться с ролью, обратите внимание на несколько критериев.

Вы строите один сложный продукт

У вас есть одна система, вы уже собрали команду и выбрали стек. Потенциальные риски — производительность, консистентность данных, поведение под нагрузкой, стоимость изменений через год.

Решение: нанять Software Architect, который будет отвечать за внутреннюю архитектуру системы, ее стабильность и развитие.

У вас много систем, legacy, вендоров и партнеров

Проект состоит из нескольких систем, которые нужно синхронизировать. Есть legacy, исторические данные, внешние вендоры и ограничения по хранению данных. Основные риски возникают на стыках между системами, командами и зонами ответственности.

Решение: привлечь Solution Architect, который определит, как все эти составляющие должны работать вместе.

Вы еще не знаете, что именно строить

У вас есть бизнес-задача, приблизительные сроки и бюджет, но еще нет ответа, нужна ли собственная разработка. Пока непонятно, что лучше — строить, покупать или интегрировать, проектировать систему рано.

Решение: привлечь Solution Architect, который сравнит варианты и поможет оценить их по стоимости, срокам и рискам.

Ваш домен зарегулирован

Банки, медицинский сектор, FinTech и Trading живут с комплаенсом и десятками внешних интеграций. Там каждое решение об инфраструктуре тянет за собой последствия, и роль Solution Architect ощутимо весомее.

Решение: нанимать Solution Architect, если критичны внешние ограничения и интеграции.

Вы — стартап и еще проверяете идею

На этапе прототипа большинство вопросов Solution Architect можно отложить. Они становятся критическими, когда появляются реальные клиенты, внешние сервисы, требования к инфраструктуре и регуляторные ограничения.

Решение: на ранней стадии отдельная роль Solution Architect часто не нужна. Исключение — стартапы в сферах со строгой регуляцией (финансы, медицина), где такие ограничения есть с первого дня.

Вы — сервисная компания

В сервисной компании растет количество задач для Solution Architect, потому что появляется граница между вашей командой и клиентом. Но важно, сколько архитектурных решений клиент действительно готов делегировать.

Решение: если вы можете влиять на стек, платформу, интеграции и общий подход, Solution Architect будет полезен. Если ключевые решения уже зафиксированы клиентом, потребность в этой роли меньше.

Если ни один пункт не подходит

Посмотрите на последствия ошибки: что пострадает больше всего, если архитектурное решение окажется неудачным?

Решение: если риск в самом продукте, его стабильности и развитии — нужен Software Architect. Если под угрозой бюджет, сроки, интеграции и обязательства перед клиентом — Solution Architect.

Как проверить архитектора на собеседовании

Несмотря на схожесть ролей, Software и Solution Architect говорят о разных вещах. Если задавать им одинаковые вопросы на скрининге, разницу в опыте легко не заметить. Поэтому в рекрутинг-брифе стоит отдельно зафиксировать общие вопросы и специфические для каждой роли.

Вопросы для обеих ролей

• Опишите систему, которую вы проектировали в последний раз: какой у нее масштаб и из чего она состоит. Сильный кандидат объяснит, почему система построена именно так, и назовет минусы и компромиссы своего подхода.
• Что было главной проблемой в этом проекте? Ответ покажет, где кандидат видит основную сложность: в нагрузке и отказоустойчивости или в требованиях, интеграциях и работе с заказчиком.
• Что из вашей архитектуры пришлось изменить впоследствии? Так видно, видел ли кандидат последствия собственных решений и работал ли с системой после стартового проектирования.

Вопросы для Software Architect

• Где в этой системе source of truth? Речь не о базе данных, а о том, какой именно компонент — сервис, кеш или внешняя система — определяет правильное состояние бизнес-сущности и имеет право его менять. И что произойдет, когда это право распределено между несколькими компонентами сразу.
• Что вы сознательно оставили как технический долг — и при каких условиях планировали вернуться? Сильный кандидат объяснит, где пошел на компромисс, почему это было оправдано и при каких условиях долг нужно закрыть. Тревожный сигнал — ответ в духе «технического долга у нас не было».
• Насколько часто вы работаете непосредственно с кодом? Для этой роли отрыв от практики — риск, что решения постепенно будут становиться такими, что хорошо выглядят только в планах.

Вопросы для Solution Architect

• Сколько систем и внешних участников пришлось свести вместе — и кто за что отвечал? Проверяется то, мыслит ли кандидат границами ответственности: что контролирует каждая система, что меняется после внедрения и где проходят точки перехода.
• С кем вне команды разработки вы согласовывали решение? Ответ должен выходить за пределы инженерии: заказчик, фаундеры, финансы, безопасность. Важно также, умеет ли кандидат объяснять технические решения людям без технического бэкграунда.

Когда вы нанимаете архитектора, то нанимаете не по тайтлу, а по опыту в определенном типе решений. Название должности в резюме этого не гарантирует: в одной компании Solution и Software Architect — это две разные роли, в другой их совмещает один человек, а где-то эти задачи распределены между tech lead’ами. Поэтому лучше спросить не «нам нужен Solution или Software Architect?», а «какие решения нам придется принимать в ближайшее время и кто уже работал с такими задачами?». Это и должно определять выбор архитектора.