Solution Architect проектирует комплексные IT-решения, интеграции и внедрения. На странице SkillStat собраны рыночные данные, навыки, roadmap, портфолио, собеседование и курсы.
Как ещё называют Solution Architect
Вакансии используют русские, английские и vendor-specific названия. Важно смотреть, отвечает ли человек за реализуемое решение, интеграции и ограничения, а не только за презентацию продукта.
Архитектор решений отвечает за то, чтобы выбранная схема была полезна бизнесу, технически реализуема и не превращалась в дорогую архитектурную ловушку.
Для этой профессии доступны ограниченные данные. Аналитика носит ориентировочный характер.
По зарплате у профессии нет достаточной собственной актуальной выборки. Поэтому на странице показана оценка с явной маркировкой источника, а не точная медиана только по текущим активным вакансиям.
Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.
Актуальный срез по вакансиям, зарплате, спросу и динамике найма для архитектора решений в Москве и МО.
Архитектор решений работает на стыке бизнеса, продукта, разработки, интеграций, инфраструктуры, безопасности и внедрения. Он берёт не абстрактную «архитектуру», а конкретную задачу: запустить платформу, встроить продукт в enterprise-контур, связать несколько систем, мигрировать старое решение или подготовить техническую часть крупной сделки.
Главная ценность роли — выбрать не самое модное, а реализуемое решение. Solution Architect уточняет цели, ограничения, объём данных, SLA, безопасность, стоимость владения, интеграции, legacy, сроки и командные возможности. Затем сравнивает варианты, объясняет tradeoffs и фиксирует архитектурное решение так, чтобы разработка, аналитики, DevOps, безопасность и заказчик понимали, что именно строится.
От Software Architect эта роль отличается customer-facing и solution scope: меньше фокуса на внутренней структуре одного приложения, больше — на решении целиком, интеграциях, внедрении, стоимости и согласовании. От System Architect отличается тем, что Solution Architect чаще работает с бизнес-контекстом, presale/delivery, клиентскими ограничениями и выбором комбинации продуктов, сервисов и технологий.
Срез по Москве и МО от 23.06.2026: 40 активных вакансий, зарплатная оценка 300 000 ₽, спрос 19/100.
Зарплата считается по расширенному окну профессии. Диапазон и грейдовые зарплаты не показываются.
Активный срез почти полностью senior-heavy: Senior 97.5%, Lead 3%, Middle —, Junior —.
Senior-разработчик глубоко отвечает за код и технические решения внутри команды. Solution Architect отвечает за целевую схему решения, ограничения, интеграции, стоимость владения и согласование между несколькими сторонами.
По данным среза, junior-позиций в этом профиле практически нет. Роль требует доверия: архитектор должен понимать последствия решения для бизнеса, данных, безопасности, эксплуатации и delivery, а это обычно приходит после опыта в разработке, анализе, интеграциях или внедрениях.
Сертификаты AWS, Azure, Kubernetes, 1С или enterprise-вендоров полезны, но не равны профессии. Работодатель смотрит, умеет ли архитектор выбрать решение под constraints, а не просто знает продукт.
Таблица показывает, что архитектор решений отвечает не за один стек, а за реализуемость решения в ограничениях бизнеса, технологий и delivery.
| Параметр | Значение | Как читать |
|---|---|---|
| Кто это | Архитектор реализуемого IT-решения | Связывает бизнес-задачу, технологии, интеграции, безопасность и delivery |
| Главная задача | Выбрать и согласовать решение, которое можно построить и сопровождать | Не просто схема, а решение с tradeoffs, рисками и roadmap |
| Ключевые навыки | Microservices 31%, REST API 26%, Kafka 25%, Kubernetes 25%, PostgreSQL 17% | Частотность по вакансиям Москвы и МО на 23.06.2026 |
| Зарплатная оценка | 300 000 ₽, estimated | Ориентир, а не точная медиана каждого уровня |
| Спрос | 40 вакансий, спрос 19/100, ранг #36 из 71 | Низкий относительно всего IT, но заметный для архитектурной роли |
| Формат | Удалённо 15%, гибрид 63%, офис 23% | Много stakeholder work, поэтому гибрид доминирует |
| Уровни | Senior 97.5%, Lead 3%, Middle —, Junior — | Рынок ждёт опытных специалистов |
| Куда растёт | Lead Solution Architect, Enterprise Architect, CTO track | Рост идёт через масштаб решений и governance |
Рабочий день архитектора решений обычно состоит из уточнения требований, сравнения вариантов, согласования рисков и передачи решения команде внедрения. Ниже безопасный и прикладной сценарий без production-инструкций.
| Ситуация | Что делает Solution Architect | Какой артефакт получается | Как проверить качество | Когда нужна эскалация |
|---|---|---|---|---|
| Заказчик хочет внедрить CRM | Уточняет процессы продаж, роли, источники данных, интеграции и ограничения запуска | Solution vision, context diagram, high-level roadmap | Бизнес понимает границы MVP, интеграции и критерии успеха | Если ожидания по срокам или данным противоречат реальности |
| Нужно заменить старую систему | Описывает текущий landscape, зависимости, ownership данных и план миграции | System landscape, migration plan, risk register | Понятны затронутые системы и порядок перехода | Если нет владельцев legacy-систем или источников правды |
| Требуется интеграция с внешним API | Проверяет контракт, SLA, ограничения, ошибки, безопасность и fallback-сценарии | Integration map, API contract, assumptions log | Команда видит границы ответственности и риски внешней зависимости | Если поставщик не подтверждает критичные условия |
| Нужно мигрировать данные без остановки бизнеса | Разделяет этапы миграции, проверяет качество данных и допустимое окно работ | Data migration plan, rollback approach, risk register | Есть критерии сверки и понятный владелец каждого набора данных | Если RTO/RPO не согласованы с бизнесом |
| Вендор обещает функцию, но есть сомнения | Фиксирует assumption и предлагает PoC для рискованной гипотезы | PoC plan, decision pending, rejected options | Решение основано на проверке, а не на презентации | Если обещание влияет на контракт, сроки или бюджет |
| Безопасность требует дополнительных ограничений | Переводит требования security в архитектурные guardrails и проверяет impact | Security view, NFR list, ADR | Ограничения понятны delivery-команде и не ломают бизнес-сценарий | Если требования конфликтуют с пользовательским сценарием или сроками |
| Нужно выбрать между custom development и готовой платформой | Сравнивает buy, build и customize по TCO, срокам, рискам и сопровождению | Option comparison, TCO estimate, ADR | Выбор объяснён последствиями, а не вкусом команды | Если решение меняет бюджет или модель поддержки |
| Команда разработки говорит, что сроки нереалистичны | Разбирает scope, зависимости, риски и предлагает варианты упрощения | Implementation roadmap, open questions, revised assumptions | Сроки связаны с объёмом, рисками и доступностью экспертов | Если бизнес просит сохранить сроки без изменения scope |
| Бизнес просит ускорить запуск за счёт упрощения | Фиксирует trade-off между MVP, качеством, безопасностью и будущей стоимостью | ADR, risk acceptance, roadmap after MVP | Понятно, что отложено и чем это грозит | Если компромисс несёт регуляторный или высокий operational risk |
| После PoC выяснилось, что допущение неверно | Обновляет решение, rejected options, риски и план внедрения | PoC report, updated ADR, revised architecture pack | Новая архитектура учитывает факт, а не защищает старую гипотезу | Если нужна смена платформы, бюджета или обязательств перед заказчиком |
Сильный Solution Architect не начинает с Kubernetes, Kafka или конкретного вендора. Сначала он выясняет, что должно измениться в бизнесе, какие системы уже есть, какие ограничения нельзя нарушать и какие гипотезы нужно проверить через PoC.
| Область | Что нужно выяснить | Зачем это важно | Что будет, если не спросить | Какой артефакт фиксирует ответ |
|---|---|---|---|---|
| Бизнес-цель | Какую проблему решаем и какой outcome нужен | Архитектура должна поддерживать цель, а не демонстрировать стек | Команда построит технически красивую, но бесполезную систему | Solution vision |
| Пользователи и роли | Кто будет работать с решением и какие права нужны | Роли влияют на UX, security и auditability | Доступы и сценарии придётся переделывать после запуска | Role model, RACI |
| Бизнес-процесс | Как процесс работает сейчас и что меняется после внедрения | Система должна поддерживать реальный flow | Автоматизация закрепит старый хаос | BPMN, process map |
| Текущий landscape | Какие системы, интеграции и ограничения уже есть | Нельзя проектировать новое решение в вакууме | Появятся скрытые зависимости и конфликт владельцев | System landscape |
| Source of truth | Где главный источник данных и кто им владеет | Это снижает риск расхождений и двойного ввода | Сервисы начнут спорить за правду | Data ownership map |
| Интеграции | Какие API, события, очереди, ETL и внешние системы нужны | Интеграции часто определяют сроки и риски | Оценка окажется слишком оптимистичной | Integration map |
| Регуляторика и безопасность | Какие данные, проверки, аудит и ограничения обязательны | Security и compliance нельзя прикрутить в конце | Решение не пройдёт согласование или эксплуатацию | Security view, NFR list |
| Производительность и доступность | Какие нагрузки, latency, RTO/RPO и окна простоя допустимы | NFR влияют на топологию, стоимость и SLA | Решение не выдержит реального режима работы | NFR catalog |
| Стоимость владения | Какие лицензии, инфраструктура, поддержка и изменения ожидаются | Дешёвый старт может стать дорогой эксплуатацией | Бюджет закончится после первого релиза | TCO estimate |
| Границы MVP | Что действительно нужно для первого запуска | Помогает отделить critical scope от желаний | Проект раздуется до невыполнимого | MVP scope, roadmap |
| Критерии успеха | Как понять, что решение принято бизнесом и delivery | Без критериев нельзя проверить результат | Команда будет спорить о готовности субъективно | Acceptance criteria |
| Рискованные гипотезы | Что нужно доказать до контракта или старта реализации | PoC снижает риск невыполнимых обещаний | Риск всплывёт поздно и дорого | PoC plan, assumptions log |
Ядро профессии — не список технологий, а способность собрать решение из требований, ограничений, tradeoffs и понятных артефактов.
| Группа | Что входит | Зачем нужно | Что показать |
|---|---|---|---|
| Discovery | Цели, stakeholders, scope, assumptions, constraints | Чтобы решить нужную проблему, а не внедрить любимый стек | Problem statement и список ограничений |
| NFR | Performance, availability, security, scalability, maintainability, cost | Нефункциональные требования часто определяют архитектуру сильнее функций | NFR table с приоритетами |
| Integration | REST, SOAP, events, Kafka, RabbitMQ, ETL, 1С, legacy | Enterprise-решения редко живут изолированно | Integration map |
| Data | Ownership, contracts, consistency, PostgreSQL, ClickHouse, Redis, SQL | Ошибки в данных дороже ошибок на схеме | Data flow и ownership |
| Platform | Kubernetes, Docker, CI/CD, environments, observability | Решение должно выпускаться и сопровождаться | Deployment view и rollout plan |
| Security | Auth, access, audit, data protection, compliance, threat assumptions | Безопасность должна быть встроена в решение | Security assumptions и risk register |
| Cost | TCO, licensing, cloud cost, support, migration effort | Архитектура живёт в бюджете | Cost drivers и tradeoff notes |
| Decision records | ADR, diagrams, roadmap, risk register, implementation plan | Команды должны понимать, что выбрано и почему | Архитектурный пакет документов |
Архитектурный артефакт должен отвечать на вопрос конкретной аудитории: бизнесу нужны последствия и стоимость, delivery-команде — границы реализации, безопасности — риски, эксплуатации — поддерживаемость. Одна универсальная схема не заменяет architecture pack.
| Артефакт | Для чего нужен | Кто читает | Что должно быть внутри | Типичная ошибка |
|---|---|---|---|---|
| Solution vision | Фиксирует цель, scope и ценность решения | Бизнес, delivery, архитектурный комитет | Цель, границы, high-level вариант, ограничения | Писать как рекламную презентацию без trade-offs |
| Context diagram | Показывает систему в окружении пользователей и соседних систем | Бизнес, аналитики, разработка | Внешние акторы, системы, основные взаимодействия | Смешивать context и детали реализации |
| System landscape | Описывает текущий ландшафт до изменений | Архитекторы, интеграторы, эксплуатация | Системы, ownership, связи, ограничения | Не показывать legacy-зависимости |
| Integration map | Показывает обмены между системами | Разработка, интеграции, безопасность | API, события, очереди, batch, владельцы | Рисовать стрелки без контрактов и владельцев |
| Data flow diagram | Показывает движение и преобразование данных | Data, security, analytics, integration teams | Источники, преобразования, потребители, риски | Не отличать источник правды от копии |
| API contract / OpenAPI | Фиксирует интерфейс интеграции | Разработчики, тестирование, внешние команды | Методы, данные, ошибки, версии, ограничения | Считать контракт второстепенной документацией |
| Event map | Описывает события и асинхронные взаимодействия | Разработка, data, integration teams | События, producers, consumers, semantics | Путать событие с командой или отчётом |
| Sequence diagram | Показывает порядок взаимодействий в сценарии | Разработка, аналитики, QA | Участники, шаги, ошибки, альтернативы | Рисовать только happy path |
| Deployment view | Показывает размещение компонентов | DevOps, cloud, security, эксплуатация | Среды, узлы, сети, зависимости, ограничения | Не учитывать мониторинг и support model |
| Security view | Показывает доступы, зоны доверия и sensitive data | Security, compliance, архитекторы | IAM, границы, данные, аудит, threat assumptions | Оставлять безопасность на финальное ревью |
| NFR list | Фиксирует нефункциональные требования | Все стейкхолдеры | Availability, performance, security, cost, supportability | Писать общие слова без измеримых критериев |
| Architecture Decision Record | Фиксирует решение и последствия | Архитекторы, delivery, future maintainers | Контекст, решение, последствия, rejected options | Описывать только выбранный вариант |
| Risk register | Не даёт потерять риски между пресейлом и реализацией | PM, delivery, архитекторы, заказчик | Риск, impact, вероятность, владелец, действие | Прятать неопределённость в переписке |
| Assumptions log | Показывает, на каких допущениях стоит решение | Команда и заказчик | Допущение, источник, способ проверки | Выдавать assumption за подтверждённый факт |
| Open questions | Фиксирует незакрытые вопросы | Бизнес, аналитики, delivery | Вопрос, владелец, срок ответа, impact | Оставлять открытые вопросы устно |
| Rejected options | Объясняет, почему варианты не выбраны | Архитекторы, заказчик, будущая команда | Вариант, причина отказа, условия пересмотра | Не документировать альтернативы |
| TCO estimate | Показывает стоимость владения | Бизнес, procurement, architecture board | Лицензии, инфраструктура, support, изменения, миграция | Сравнивать только цену внедрения |
| Migration plan | Снижает риск перехода | Delivery, data, operations, business owners | Этапы, проверки, fallback, ownership | Не учитывать качество данных и окно бизнеса |
| Implementation roadmap | Переводит архитектуру в порядок реализации | Delivery, PM, команда | Фазы, зависимости, critical path, risks | Путать roadmap с wish-list |
| RACI / ownership matrix | Разделяет ответственность | Бизнес, delivery, support | Кто отвечает, согласует, консультирует, информируется | Оставлять ownership неявным |
| Runbook / support model | Показывает, как решение будет сопровождаться | Эксплуатация, support, SRE/DevOps | Типовые ситуации, контакты, SLA, escalation | Заканчивать архитектуру на релизе |
| Technical handover | Передаёт решение delivery-команде | Разработка, QA, DevOps, analysts | Диаграммы, решения, риски, ссылки, unresolved items | Передавать только презентацию |
Нефункциональные требования нельзя оставлять на потом: они меняют архитектуру, бюджет, сроки и модель эксплуатации. Часть NFR конфликтует друг с другом, поэтому Solution Architect должен явно фиксировать trade-offs.
| Требование | Что означает | Как влияет на архитектуру | Как проверить | Типичная ошибка |
|---|---|---|---|---|
| Availability | Допустимая доступность сервиса | Влияет на redundancy, SLA, deployment и стоимость | Согласовать целевой уровень и окна простоя | Писать “должно работать всегда” |
| Reliability | Способность работать без повторяемых отказов | Требует устойчивых зависимостей и recovery-процессов | Проверить failure scenarios в безопасной среде | Считать надёжность задачей эксплуатации |
| Performance | Время ответа и пропускная способность | Определяет кеширование, БД, очереди и sizing | Зафиксировать измеримые target values | Говорить “быстро” без метрик |
| Scalability | Возможность расти по пользователям и данным | Влияет на модульность, storage, очереди, cloud | Проверить прогноз нагрузки и growth assumptions | Проектировать максимум без бизнес-смысла |
| Security | Защита данных, доступов и действий | Влияет на IAM, шифрование, аудит, зоны доверия | Security review и traceability требований | Подключать безопасность перед релизом |
| Compliance | Регуляторные и внутренние правила | Меняет хранение, аудит, процессы и vendor choice | Сверить с legal/security/compliance | Считать compliance формальностью |
| Observability | Возможность понять состояние системы | Требует логов, метрик, трассировок и ownership | Проверить, что support видит critical signals | Не планировать наблюдаемость в архитектуре |
| Maintainability | Стоимость будущих изменений | Влияет на границы модулей и документацию | Оценить частоту изменений и командную ownership | Оптимизировать только первый релиз |
| Resilience | Способность переживать сбои зависимостей | Требует fallback, retries policy, graceful degradation | Обсудить допустимые сценарии деградации | Обещать устойчивость без упрощения сценариев |
| Disaster recovery | Восстановление после серьёзного сбоя | Влияет на backup, region strategy и runbook | Согласовать DR-требования и проверки | Не учитывать людей и процедуры |
| RTO | Сколько времени допустимо восстанавливаться | Меняет инфраструктуру и поддержку | Подтвердить с бизнесом по процессам | Выбирать RTO без цены |
| RPO | Сколько данных допустимо потерять | Определяет репликацию, backup и storage | Согласовать с владельцами данных | Считать RPO технической мелочью |
| Data retention | Сроки хранения данных | Влияет на storage, архивы, compliance | Сверить с регуляторикой и бизнесом | Хранить всё бесконечно |
| Auditability | Возможность восстановить действия и решения | Требует журналов, идентичности и политики доступа | Проверить сценарии аудита | Путать audit trail с обычными логами |
| Cost optimization | Рациональная стоимость владения | Влияет на cloud services, licenses, support model | Сравнить TCO, а не только цену запуска | Экономить на критичных свойствах |
| Supportability | Удобство сопровождения после внедрения | Требует runbook, ownership, мониторинга и знаний | Проверить модель поддержки до go-live | Передавать решение без support model |
| Integration latency | Допустимая задержка обмена | Определяет sync/async, cache, queue strategy | Согласовать по бизнес-сценариям | Выбирать синхронность по привычке |
| Deployment constraints | Ограничения релизов и изменений | Влияет на CI/CD, миграции, rollback и governance | Проверить окна, approvals и release policy | Не учитывать enterprise-процессы |
Хороший архитектор решений не скрывает компромиссы. ADR должен фиксировать контекст, выбранное решение, последствия и отвергнутые варианты, иначе архитектура превращается в постфактум-оправдание.
| Ситуация | Какие варианты есть | Что выбираем | Чем жертвуем | Что фиксируем в ADR |
|---|---|---|---|---|
| Купить готовую CRM или разработать кастом | Buy, build, customize | Вариант с лучшим балансом сроков, TCO и fit | Частью гибкости или скоростью запуска | Почему выбран вариант и что проверено до решения |
| Интеграция через API или события | REST/SOAP API, event-driven обмен | Зависит от latency, ownership и надёжности | Простотой отладки или слабой связанностью | Семантика обмена, владельцы, fallback |
| Синхронный обмен или асинхронный | Request-response, очередь, event stream | То, что подходит бизнес-сценарию | Немедленным ответом или устойчивостью | Допустимая задержка и обработка ошибок |
| Монолит или микросервисы | Единое приложение, модульный монолит, сервисы | Минимальная сложность, которая закрывает scale и ownership | Независимостью команд или простотой сопровождения | Почему декомпозиция нужна или отложена |
| Kafka или RabbitMQ | Event streaming, message broker | Инструмент под характер событий и потребителей | Частью функциональности или операционной простотой | Нагрузка, ordering, retention, поддержка |
| ETL или event-driven data flow | Пакетная загрузка, CDC, события | Зависит от свежести данных и контроля качества | Realtime-эффектом или простотой контроля | Source of truth и ответственность за качество |
| On-prem или cloud | Собственная инфраструктура, cloud, hybrid | Баланс compliance, cost, scale и capabilities | Гибкостью или контролем | Ограничения безопасности, стоимость, DR |
| Один источник правды или мастеринг данных | Single source, MDM, domain ownership | То, что реально поддерживается организацией | Скоростью внедрения или чистотой данных | Владелец данных и правила синхронизации |
| Быстрый MVP или полноценная платформа | Минимальный запуск, scalable foundation | MVP с явно принятыми долгами | Краткосрочным качеством или скоростью проверки | Что отложено и когда возвращаемся |
| Вендорская функция или собственная доработка | Vendor feature, extension, custom module | То, что меньше рискует будущими обновлениями | Глубиной кастомизации или независимостью | Vendor lock-in и support implications |
| Высокая доступность или снижение стоимости | HA, резервирование, упрощённый запуск | Уровень, оправданный бизнес-impact | Стоимостью или устойчивостью | Business impact и согласованный risk acceptance |
| Максимальная кастомизация или простота сопровождения | Custom behavior, standard process | Минимум кастома, который нужен бизнесу | Идеальным fit или дешевым support | Почему кастомизация оправдана |
Risk register — не бюрократия, а способ не потерять риск между пресейлом, контрактом и реализацией. Архитектурная зрелость видна не только в схемах, но и в управлении неопределённостью.
| Тип записи | Пример | Почему важно | Кто владелец | Что делать дальше |
|---|---|---|---|---|
| Технический риск | Выбранная платформа может не выдержать требуемую нагрузку | Влияет на сроки, стоимость и NFR | Solution Architect, Tech Lead | Провести PoC или нагрузочную проверку в учебной/тестовой среде |
| Интеграционный риск | Внешний API не подтверждает нужный SLA | Может сорвать процесс или contract scope | Integration owner, vendor manager | Получить подтверждение и описать fallback |
| Риск данных | Нет согласованного source of truth | Приводит к конфликтам данных и отчётов | Data owner, business owner | Назначить владельца и правила синхронизации |
| Риск миграции | Качество legacy-данных неизвестно | Миграция может стать отдельным проектом | Data team, delivery manager | Профилировать данные и запланировать cleansing |
| Вендорский риск | Функция есть только в roadmap поставщика | Нельзя строить обязательство на обещании | Vendor manager, architect | Зафиксировать assumption и alternative option |
| Security-риск | Требуется доступ к чувствительным данным | Влияет на архитектуру и согласования | Security architect | Провести security review до финального design |
| Compliance-риск | Неясны требования хранения или аудита | Решение может не пройти проверку | Compliance owner | Получить формальное требование |
| Performance-риск | Latency интеграции критична для процесса | Может потребоваться другой pattern обмена | Architect, performance engineer | Зафиксировать NFR и проверить гипотезу |
| Cost-риск | Лицензирование растёт с числом пользователей | TCO может резко измениться после запуска | Product owner, finance | Сравнить сценарии роста |
| Delivery-риск | Нужных экспертов нет в команде | Сроки становятся нереалистичными | Delivery manager | Обновить план, staffing и scope |
| Business adoption-риск | Пользователи не готовы менять процесс | Система может быть внедрена формально | Business owner | Спланировать обучение и change management |
| Assumption | Заказчик считает, что CRM уже содержит чистые данные | Допущение может быть ложным | Business analyst, data owner | Проверить sample данных |
| Open question | Кто владеет справочником клиентов | Без ответа нельзя выбрать data ownership | Business owner | Закрыть до design sign-off |
| Dependency | Запуск зависит от поставщика API | Внешняя зависимость влияет на critical path | PM, vendor manager | Поставить дату и fallback |
| Decision pending | Не выбран cloud или on-prem вариант | Блокирует cost model и security design | Architecture board | Назначить decision date и критерии |
TCO включает не только цену внедрения: лицензии, инфраструктуру, интеграции, поддержку, обучение, миграции, безопасность, ограничения вендора и будущие изменения. Vendor lock-in не всегда зло, но его нужно принять осознанно.
| Вариант | Когда подходит | Плюсы | Риски | Что проверить до решения |
|---|---|---|---|---|
| Купить готовую платформу | Нужен быстрый запуск стандартного процесса | Скорость, vendor support, готовые функции | Lock-in, лицензии, ограниченная кастомизация | Fit-gap, roadmap поставщика, TCO на росте |
| Настроить вендорский продукт | Процесс близок к стандартному, но требует адаптации | Меньше custom development | Сложная поддержка кастомизаций | Границы настройки и влияние на обновления |
| Разработать кастомное решение | Нужна уникальная логика или конкурентное отличие | Максимальный fit и контроль | Дорогое сопровождение и staffing risk | Ownership, roadmap, TCO, team capability |
| Расширить текущую систему | Legacy ещё жив и есть понятный owner | Меньше миграционных рисков | Накопление технического долга | Архитектурный предел и support model |
| Собрать hybrid-вариант | Часть функций стандартна, часть уникальна | Баланс скорости и гибкости | Сложность интеграций и ownership | Границы систем и источник правды |
| Использовать cloud managed services | Нужна скорость и managed operations | Меньше операционной нагрузки | Vendor-specific ограничения и стоимость на масштабе | Security, compliance, exit strategy, cost model |
| Оставить legacy и обернуть API | Полная замена слишком рискованна | Быстрый доступ к данным и функциям | Legacy остаётся критичной зависимостью | API boundaries, monitoring, lifecycle plan |
| Начать с MVP и потом расширять | Нужно проверить ценность до крупного бюджета | Снижает риск лишней разработки | Временные решения могут стать постоянными | Какие долги приняты и когда их закрывать |
| Провести PoC перед выбором | Есть высокая техническая или вендорская неопределённость | Раннее снятие риска | PoC может не проверить production constraints | Критерии успеха и что делать при провале |
Для Solution Architect интеграции и данные часто важнее выбора фреймворка. В вакансиях SkillStat это видно по REST API 26%, Apache Kafka 25%, PostgreSQL 17%, 1С 14%, SQL 12%, RabbitMQ 11%, SOAP 10%, ETL 10% и ClickHouse 8%.
| Область | Что проектирует архитектор решений | Какие вопросы задаёт | Какие технологии встречаются | Типичный риск |
|---|---|---|---|---|
| REST API | Контракты синхронных интеграций | Кто владелец API, какие ошибки и версии нужны | REST, OpenAPI, API gateway | Контракт меняется без согласования |
| SOAP | Интеграции с enterprise и legacy-системами | Какие схемы, SLA и ограничения у сервиса | SOAP, WSDL, ESB | Недооценить сложность legacy-контракта |
| OpenAPI | Формальное описание API | Как контракт будет версионироваться и тестироваться | Swagger/OpenAPI tools | Документация расходится с реализацией |
| Event-driven integration | Событийный обмен между доменами | Что является событием и кто потребитель | Kafka, RabbitMQ, event bus | Публиковать события без ownership |
| Kafka | Потоки событий и интеграции с несколькими потребителями | Нужны ли retention, ordering, replay, governance | Apache Kafka | Взять Kafka там, где хватит простого обмена |
| RabbitMQ | Очереди задач и маршрутизация сообщений | Какие гарантии доставки и обработчики нужны | RabbitMQ | Путать очередь задач с event streaming |
| ESB / iPaaS | Централизованные интеграционные flows | Кто управляет маршрутами и трансформациями | ESB, iPaaS, integration platform | Создать скрытую точку связанности |
| ETL | Пакетную загрузку и преобразование данных | Какая свежесть данных нужна бизнесу | ETL tools, SQL, DWH | Использовать batch там, где нужен near real-time |
| CDC | Снятие изменений из источников данных | Какие таблицы и ownership допустимы | CDC tools, Kafka connectors | Нарушить границы владения данными |
| Batch exchange | Периодический обмен файлами или пакетами | Как контролировать качество и повторы | SFTP, files, schedulers | Оставить ошибки обмена невидимыми |
| Master data | Правила мастер-данных | Кто владеет клиентом, товаром, договором | MDM, CRM, ERP | Дубли и конфликт справочников |
| Source of truth | Главный источник по каждому типу данных | Какая система имеет право менять данные | CRM, ERP, core system, DWH | Несколько систем считают себя главными |
| Data ownership | Ответственность за данные и качество | Кто исправляет ошибку и утверждает модель | RACI, data catalog | Нет владельца, есть только интеграция |
| Data migration | Перенос данных между системами | Как проверяем полноту, качество и откат | SQL, ETL, migration tools | Оценить миграцию как техническую выгрузку |
| CRM/ERP/1С integration | Связь бизнес-платформ с внешними системами | Какие справочники и процессы критичны | 1С, ERP, CRM, API, ETL | Не учесть отраслевые ограничения |
| External vendor API | Интеграции с поставщиками | Какие SLA, лимиты, безопасность и поддержка | REST, SOAP, webhooks | Обещать стабильность без контракта |
| Нотация / диаграмма | Для чего нужна | Кому полезна | Когда использовать | Когда не нужна |
|---|---|---|---|---|
| C4 Context | Показать систему среди пользователей и соседних систем | Бизнес, аналитики, архитекторы | В начале обсуждения решения | Для деталей классов и таблиц |
| C4 Container | Показать приложения, БД, внешние сервисы и связи | Разработка, DevOps, security | Для high-level design | Когда важен бизнес-процесс |
| C4 Component | Показать компоненты внутри контейнера | Разработчики, Tech Lead | Для сложного приложения | Для презентации заказчику |
| Deployment diagram | Показать размещение в средах и инфраструктуре | DevOps, cloud, security | Перед оценкой эксплуатации | Когда нет инфраструктурных решений |
| Sequence diagram | Показать порядок вызовов и альтернативные сценарии | Разработка, QA, аналитики | Для сложной интеграции | Для общей карты landscape |
| Integration map | Показать системы и обмены | Архитекторы, интеграторы | Когда много API, событий и batch | Для внутренних модулей одного сервиса |
| Data flow diagram | Показать движение данных | Data, security, compliance | Когда важны данные и контроль | Для UI-сценариев без данных |
| BPMN | Описать бизнес-процесс | Бизнес, аналитики, внедрение | Для процессов и ролей | Для low-level software design |
| UML class diagram | Показать модель предметной области или классы | Разработка | Когда важны связи сущностей | Для enterprise roadmap |
| UML component diagram | Показать компоненты и зависимости | Разработка, архитекторы | Для технического дизайна | Для пресейла без команды реализации |
| Archimate | Связать business, application и technology layers | Enterprise architects, architecture board | Для enterprise landscape и governance | Для быстрых delivery-обсуждений |
| ERD | Показать модель данных | Data, backend, analysts | Для БД и migration planning | Когда нет структурированных данных |
| API contract | Зафиксировать интерфейс интеграции | Разработчики, QA, vendors | Для согласования обмена | Как замена общей архитектуре |
| Roadmap diagram | Показать порядок внедрения | Бизнес, delivery, PM | Для фаз проекта | Для технических деталей |
| Risk heatmap | Показать impact и вероятность рисков | Бизнес, PM, архитекторы | Для risk review | Как единственный risk register |
Solution Architect может участвовать в пресейле, но не должен превращаться в продавца презентаций без ответственности за реализуемость. Техническая честность на раннем этапе снижает риск проекта.
| Этап | Роль Solution Architect | Что нельзя обещать без проверки | Какой артефакт нужен | Где граница с продажами |
|---|---|---|---|---|
| Первичный пресейл | Понимает задачу и ограничения на верхнем уровне | Сроки, интеграции и кастомизации | Discovery notes, assumptions | Не заменяет коммерческое обещание техническим фактом |
| Discovery | Задаёт вопросы о процессе, данных, системах и NFR | Полноту требований без владельцев | Question log, context diagram | Не продаёт стек вместо анализа |
| Оценка трудоёмкости | Выделяет риски и неизвестные | Фиксированную оценку при открытых вопросах | Risk register, estimation assumptions | Не скрывает uncertainty ради сделки |
| Выбор платформы | Сравнивает варианты по fit, TCO и рискам | Что вендор закроет все сценарии | Option comparison, ADR | Не выдаёт preference за архитектурное решение |
| Подготовка предложения | Помогает описать реализуемый scope | Неверифицированные интеграции | Architecture outline, MVP scope | Продажа не должна стирать constraints |
| Защита решения | Объясняет trade-offs заказчику и команде | Идеальную архитектуру без компромиссов | Presentation, ADR summary | Не обещает то, что delivery не примет |
| Contract / SOW | Проверяет технические допущения в scope | Согласуем после подписания | Assumptions and exclusions | Архитектор не заменяет юриста, но видит технические риски |
| Kickoff реализации | Передаёт контекст и архитектурные решения | Что команда сама догадается | Technical handover | Не исчезает после продажи |
| Технический дизайн | Уточняет детали с delivery-командой | Что high-level схема достаточна для реализации | Detailed diagrams, NFR list | Не микроменеджит код без необходимости |
| PoC | Проверяет рискованные гипотезы | Что PoC доказывает production readiness полностью | PoC report | Не превращает PoC в декоративную демо |
| Delivery support | Помогает принимать изменения и закрывать вопросы | Что архитектура не изменится после фактов | Change log, updated ADR | Не блокирует команду без причин |
| Change request | Оценивает impact изменений | Что изменение бесплатно для архитектуры | Impact assessment | Не прячет последствия ради скорости |
| Post-implementation review | Сверяет решение с результатом и уроками | Что внедрение завершает архитектурную ответственность | Lessons learned, backlog | Не подменяет поддержку продажей следующей фазы |
Solution Architect отвечает за реализуемое решение под бизнес-задачу, внедрение, интеграции, риски и ограничения. Ниже границы с близкими ролями, чтобы не путать архитектора решений с системным аналитиком, пресейлом или архитектором ПО.
| Роль | Главный фокус | Чем занимается | Какие артефакты делает | Чем отличается от Solution Architect |
|---|---|---|---|---|
| Solution Architect | Реализуемое решение под бизнес-задачу | Соединяет требования, интеграции, данные, безопасность, TCO, риски и delivery | Solution vision, diagrams, ADR, risk register, roadmap | Это центральная роль страницы |
| Software Architect | Внутреннее устройство ПО | Проектирует модули, сервисы, кодовые границы, паттерны и техническое качество | Component diagrams, coding standards, technical design | Глубже в код, уже в бизнес/внедрение |
| System Architect | Системный ландшафт и технические правила | Смотрит на взаимосвязи систем, платформы и архитектурные стандарты | System landscape, technical standards | Чаще меньше customer-facing и business trade-offs |
| Enterprise Architect | Стратегия компании и portfolio | Работает с capability map, roadmap, governance и enterprise standards | Capability map, target architecture, principles | Выше уровень абстракции и горизонт планирования |
| Cloud Architect | Cloud/hybrid architecture | Проектирует compute, network, storage, IAM, monitoring, DR и cost optimization | Cloud diagrams, landing zone, Well-Architected review | Глубже в cloud, не всегда отвечает за весь бизнес-сценарий |
| Integration Architect | API, события, шины, ETL и data flow | Проектирует контрактные границы и обмены между системами | Integration map, API contracts, event model | Уже в интеграционную глубину |
| Data Architect | Данные и аналитическая архитектура | Проектирует модели, DWH, data platform, governance и качество данных | Data model, lineage, data governance artifacts | Не всегда отвечает за весь solution scope |
| Security Architect | Безопасность решения | Оценивает угрозы, доступы, compliance, security controls | Security view, threat model, controls | Фокусируется на security, а не на полной delivery-архитектуре |
| Presale Architect | Техническая поддержка продажи | Помогает оценить и защитить предложение до контракта | Proposal architecture, assumptions, demo scope | Может не сопровождать внедрение, если роль отделена |
| System Analyst | Требования и спецификации | Формализует процессы, требования, данные, сценарии и acceptance criteria | BRD, SRS, BPMN, use cases | Не всегда принимает архитектурный выбор и trade-offs |
| Business Analyst | Бизнес-процесс и ценность | Описывает потребности, метрики и изменения процесса | Process map, requirements, business case | Меньше технической ответственности |
| Tech Lead | Реализация команды и качество кода | Ведёт разработчиков, технический дизайн и delivery внутри команды | Technical design, code standards, backlog decisions | Ближе к реализации, меньше к enterprise/stakeholder alignment |
| Product Manager | Ценность продукта и roadmap | Приоритизирует функции, пользователей и бизнес-метрики | Product roadmap, requirements, metrics | Не отвечает за архитектурную реализуемость напрямую |
| Delivery Manager | Сроки, команда и выполнение | Управляет планом, рисками доставки, ресурсами и коммуникациями | Delivery plan, status, staffing | Не выбирает архитектуру, но зависит от её реалистичности |
По срезу SkillStat рынок почти полностью senior-heavy: Senior 97.5%, Lead 3%, Middle —, Junior —. Поэтому junior как самостоятельная вакансия почти не встречается, а переход обычно идёт через опыт в смежных ролях.
| Уровень | Роль | Типичные задачи | Какие навыки нужны | Что показать в портфолио | Куда расти дальше |
|---|---|---|---|---|---|
| Intern / Trainee | Редко встречается как архитектурная позиция | Помощь с документацией, диаграммами, inventory систем, протоколами решений | База системного анализа, API, диаграммы, аккуратность | Учебный context diagram, integration map, requirements notes | Junior/Middle-adjacent role |
| Junior Solution Architect | Чаще не отдельная рыночная роль, а внутренний рост | Проектирует фрагменты под контролем старшего архитектора | API, SQL, C4/UML, NFR basics, communication | ADR по небольшому выбору, OpenAPI, NFR checklist | Middle SA или system/integration architect |
| Middle Solution Architect | Ведёт часть решения | API, интеграции, миграции, авторизация, модули платформы, инфраструктурные варианты | Integration architecture, data ownership, cloud basics, risk register | Architecture pack для учебного enterprise-кейса | Senior Solution Architect |
| Senior Solution Architect | Отвечает за сложное решение целиком | Discovery, варианты, trade-offs, TCO, security, delivery handover, stakeholder alignment | Enterprise context, NFR, presale honesty, vendor selection | Обезличенный кейс внедрения с ADR, рисками и результатом | Lead SA, Enterprise Architect, CTO-track |
| Lead Solution Architect | Отвечает за портфель решений и стандарты | Governance, крупные сделки, архитектурный комитет, развитие архитекторов | Architecture governance, negotiation, portfolio thinking | Набор решений, стандарты, шаблоны ADR и risk review | Principal, Enterprise Architect, Head of Architecture |
| Principal / Enterprise track | Влияет на архитектурные принципы компании | Capability map, target architecture, standards, investment decisions | Enterprise architecture, strategy, business alignment | Портфельный case study без NDA-данных | CTO-track, architecture governance |
Переход чаще идёт через опыт, где уже есть понимание систем, людей и последствий решений.
| Откуда переходить | Что уже полезно | Чего не хватает | Как собрать портфолио |
|---|---|---|---|
| Из backend-разработки | Код, API, данные, production bugs | Stakeholders, cost, security, integration scope | Solution case вокруг API/data platform |
| Из системного анализа | Требования, процессы, данные, API | Architecture tradeoffs и platform constraints | Case с NFR, ADR и target architecture |
| Из DevOps/cloud | Инфраструктура, delivery, reliability, cost | Business scope и integration architecture | Cloud solution case с risk register |
| Из integration/ESB | API, events, legacy, data exchange | Business framing и solution roadmap | Integration map для enterprise-кейса |
| Из пресейла | Client communication, discovery, proposal | Delivery realism и technical depth | Presale-to-delivery case |
| Из Tech Lead | Команда, реализация, code quality | Cross-team constraints и business tradeoffs | Architecture decision beyond one team |
| Из 1С/ERP/CRM внедрения | Enterprise processes, users, legacy, rollout | Platform/API/security/cloud context | Fit-gap и migration plan |
Портфолио архитектора решений должно показывать ход решения, а не набор логотипов технологий.
| Кейс | Что показать | Какой результат ожидается | Что написать в README |
|---|---|---|---|
| B2B-интеграция | API/events/data flow, ownership, errors, security | Понятная integration map | Почему выбран REST, events или hybrid |
| Миграция legacy | Current state, target state, этапы, риски, rollback | Реалистичный migration roadmap | Как снижали риск перехода |
| Cloud/Kubernetes solution | Deployment view, environments, CI/CD, cost, security | Решение можно сопровождать | Что не стали выносить в cloud |
| CRM/ERP/1С внедрение | Fit-gap, интеграции, данные, пользователи, rollout | Решение учитывает business process | Ограничения вендора и legacy |
| Event-driven architecture | Kafka/RabbitMQ, topics/queues, ownership, retry, idempotency | Событийный обмен не превращается в хаос | Контракты и boundaries |
| Data platform integration | Источники, ETL, consistency, access, quality | Понятный data flow | Кто владеет данными |
| Security-sensitive solution | Access, audit, data classes, threat assumptions | Security встроена в архитектуру | Какие риски остались |
| Cost tradeoff case | TCO, licenses, cloud cost, support effort | Решение экономически объяснимо | Почему отвергнут дорогой вариант |
Интервью проверяет не только system design, но и умение уточнять ограничения, объяснять tradeoffs и защищать решение перед разными сторонами.
| Тема | Пример вопроса | Что проверяет интервьюер | Что добавить в портфолио |
|---|---|---|---|
| Discovery | Какие вопросы зададите заказчику до выбора архитектуры? | Умение искать constraints | Discovery checklist |
| NFR | Как согласовать availability, performance и cost? | Приоритизацию tradeoffs | NFR table |
| Integration | Когда REST, когда events, когда hybrid? | Понимание связности и consistency | Integration map |
| Microservices | Когда не надо дробить систему? | Зрелость архитектурного мышления | Rejected alternatives |
| Kafka/RabbitMQ | Как выбрать messaging подход? | Понимание событий, очередей и владения | Event-driven case |
| Data | Как определить владельца данных? | Data governance и consistency | Data flow |
| Security | Как встроить безопасность до реализации? | Risk thinking | Security assumptions |
| Cost | Как объяснить дорогой, но безопасный вариант? | Business communication | Cost model |
| Delivery | Что делать, если команда не может реализовать целевую схему? | Практичность решения | Implementation roadmap |
| Role boundaries | Чем Solution Architect отличается от System Architect? | Понимание ответственности | Role comparison notes |
Главная ошибка новичка — учить фреймворки архитектуры вместо практики решений и ограничений.
| Не начинать с | Почему | Что сделать вместо этого |
|---|---|---|
| TOGAF по верхам | Сертификат не заменяет solution case | Сделать 2-3 архитектурных кейса |
| Одного cloud-вендора | Vendor knowledge не равно архитектура решения | Учить tradeoffs и constraints |
| Красивых схем без текста | Диаграмма без решений не помогает delivery | Писать ADR и assumptions |
| Микросервисов по умолчанию | Распределённость создаёт стоимость и риск | Сравнить monolith/modular/microservices |
| Kubernetes как ответа на всё | Платформа не решает business scope | Начать с требований и NFR |
| Presale-презентаций без delivery | Можно продать нереализуемое решение | Проверять roadmap и implementation risk |
| Списка технологий в резюме | Архитектора оценивают по решениям | Показывать artifacts и tradeoffs |
сценарии, критерии и постановка задачи
данные, api, статусы и интеграции
согласование и работа с разработкой
Работа Solution Architect начинается до разработки и не заканчивается на схеме. Роль держит связь между задачей бизнеса, ограничениями и реализацией.
Уточняет, что должно измениться для бизнеса, какие процессы затронуты и почему текущего решения недостаточно.
Фиксирует данные, legacy, безопасность, SLA, нагрузку, интеграции, бюджет, сроки и ограничения команды.
Готовит несколько возможных схем, а не один красивый вариант без альтернатив.
Показывает, что выигрывает и теряет компания в каждом варианте: скорость, стоимость, риск, vendor lock-in, сложность сопровождения.
Документирует архитектуру, границы, API, события, данные, риски и план внедрения понятным языком.
Проверяет, что бизнес, разработка, безопасность, эксплуатация и заказчик одинаково понимают решение.
Отвечает на вопросы команды, помогает уточнить спорные места и следит, чтобы реализация не разрушила архитектурный смысл.
После запуска смотрит, насколько решение соответствует ожиданиям по стоимости, надёжности, интеграциям и сопровождению.
Архитектурные роли часто пересекаются, но отвечают за разные уровни решения. Ошибка в названии вакансии может привести к неправильному ожиданию от работы.
Проектирует реализуемое решение под бизнес-задачу, constraints, интеграции, стоимость и delivery.
Фокус страницы: solution scope и согласование между сторонами.
Может задавать структуру приложения внутри решения.
Глубже в коде, модулях, паттернах и техническом устройстве software.
Пересекается на системных границах, данных и инфраструктуре.
Чаще смотрит на устройство системы как инженерного целого, меньше на customer/presale контекст.
Получает от него принципы, стандарты и целевую карту организации.
Работает выше: capability map, landscape, governance, portfolio и стратегия компании.
Согласует реализацию и технические ограничения команды.
Отвечает за командную поставку, code quality и людей; не всегда проектирует solution end-to-end.
Уточняет требования, процессы, данные и API-контракты.
Описывает, что нужно построить; архитектор выбирает, как это связать и реализовать.
Помогает в техническом пресейле и оценке решения.
Может быть ближе к продаже продукта; Solution Architect несёт больше ответственности за реализуемость.
Использует продукт или платформу как часть решения.
Чаще привязан к конкретному продукту или вендору.
В вакансиях SkillStat чаще всего встречаются Microservices 31%, REST API 26%, Apache Kafka 25%, Kubernetes 25%, PostgreSQL 17%, архитектура 17%, Docker 15%, 1С 14%, Java 14%, CI/CD 12%, SQL 12%, RabbitMQ 11%, ETL 10%, SOAP 10%, Redis 9%, ClickHouse 8%, Linux 8%, Python 8% и ArchiMate 7%.
Этот набор показывает не один стек, а характер задач: интеграции, API, события, данные, контейнеры, enterprise-системы, legacy и документация архитектуры. Важно не превращать Solution Architect в Java-разработчика, DevOps или системного аналитика: технологии нужны как язык проектирования решения и проверки ограничений.
Среди работодателей в накопленной статистике видны Сбер. IT, БЮРО 1440, АРЕАЛ, Лента, МТС, АО Системы Коммуникаций, КОРУС Консалтинг, Яндекс, Ростелеком ИТ, Сбер для экспертов, Ренессанс Девелопмент и Aston. Это хорошо отражает enterprise/B2B-профиль роли.
Рынок ориентирован на опытных специалистов.
Столько требований работодатели обычно собирают в одной позиции по этой роли.
Соответствие рассчитано по стеку из 40 вакансий — это не реклама, а совпадение со спросом работодателей.
Вакансии SkillStat показывают смешанный профиль: архитектура, интеграции, cloud/platform context, данные и коммуникация. Частые сущности: Microservices 31%, REST API 26%, Kubernetes 25%, Apache Kafka 25%, PostgreSQL 17%, Docker 15%, Java 14%, 1С 14%, SQL 12%, CI/CD 12%.
| Группа навыков | Что входит | Зачем нужно | Как показать опыт |
|---|---|---|---|
| Architecture skills | Solution design, system design, integration architecture, cloud architecture, NFR, trade-offs, ADR | Чтобы выбирать реализуемую архитектуру, а не только стек | Architecture pack с context, NFR, ADR и rejected options |
| Integration & data | REST API, OpenAPI, SOAP, Kafka, RabbitMQ, ETL, SQL, PostgreSQL, source of truth, data ownership | Большая часть enterprise-решений держится на обменах и данных | Integration map, API contract, data flow, migration plan |
| Infrastructure & cloud | Kubernetes, Docker, CI/CD, Linux, cloud, IAM, networking, observability, DR, cost optimization | Архитектор должен понимать, как решение будет работать и сопровождаться | Deployment view, NFR, cost assumptions, cloud option comparison |
| Enterprise platforms | CRM, ERP, 1С, SAP, BPM, DWH, data platform, customer portals, vendor platforms | Помогает проектировать B2B/enterprise-внедрения | Обезличенный кейс внедрения или интеграции платформ |
| Communication & leadership | Stakeholder management, facilitation, negotiation, documentation, presentation, technical honesty | Архитектура должна быть согласована людьми, а не только нарисована | Презентация решения, decision log, risk review |
| Middle level | Проектирование фрагментов решения и интеграций | Нужен переход от анализа к архитектурным решениям | ADR, API, integration map, NFR checklist |
| Senior level | Discovery, trade-offs, TCO, risk management, delivery support | Senior отвечает за реалистичность и последствия | Полный architecture case study |
| Lead level | Governance, standards, portfolio, mentoring | Lead масштабирует архитектурную практику | Стандарты, шаблоны, portfolio decisions |
Инструменты Solution Architect нужны не для демонстрации владения софтом, а для ясных решений, проверяемых контрактов, прозрачных рисков и передачи команде внедрения.
| Инструмент / класс | Для чего нужен | На каком уровне нужен | Как описать в резюме | Что важно понимать |
|---|---|---|---|---|
| C4 Model | Контекст, контейнеры, компоненты и deployment view | Middle+ | Описывал architecture views по C4 для B2B-решений | Диаграмма должна отвечать на вопрос аудитории |
| UML | Sequence, component, class diagrams | Middle+ | Использовал UML для интеграционных и технических сценариев | Не все UML-диаграммы нужны каждому проекту |
| BPMN | Описание бизнес-процессов | Middle+ | Читал и уточнял BPMN для discovery и внедрения | Процесс влияет на архитектуру и роли |
| Archimate | Enterprise layers и landscape | Senior/Lead | Работал с Archimate в enterprise-контексте | Нотация полезна, если есть governance |
| Draw.io / diagrams.net | Быстрые архитектурные схемы | Junior+ | Готовил context и integration diagrams | Инструмент не заменяет содержание |
| Miro / Lucidchart / Visio | Совместные схемы и воркшопы | Junior+ | Вёл архитектурные воркшопы и схемы | Нужно фиксировать результат вне доски |
| PlantUML / Structurizr | Diagrams as code | Middle+ | Вёл схемы как код для review | Подходит не всем аудиториям |
| Confluence / Wiki / Notion | Architecture pack и документация | Junior+ | Вёл архитектурную документацию и decision log | Документация должна обновляться вместе с решением |
| Jira | Связь architecture decisions с delivery | Junior+ | Связывал архитектурные задачи с roadmap | Не превращать архитектуру в набор тикетов без контекста |
| ADR templates | Фиксация решений и последствий | Middle+ | Вёл ADR с rejected options и consequences | ADR без контекста бесполезен |
| OpenAPI / Swagger | Контракты API | Middle+ | Согласовывал API contracts и версии | Контракт должен быть источником правды для интеграции |
| Postman | Проверка и демонстрация API-сценариев | Junior+ | Использовал для безопасной проверки интеграционных сценариев | Не заменяет контракт и тестовую стратегию |
| SQL / PostgreSQL | Понимание моделей данных и запросов | Middle+ | Проектировал data ownership и migration assumptions | Архитектору важны данные, не только таблицы |
| Kafka / RabbitMQ | События и очереди | Middle+ | Сравнивал event-driven и queue-based варианты | Выбор зависит от semantics и ownership |
| Kubernetes / Docker | Cloud-native и deployment context | Middle+ | Учитывал container/platform constraints в design | Не сводить Solution Architecture к кластеру |
| CI/CD / GitLab | Delivery flow и релизные ограничения | Middle+ | Проектировал deployment flow и handover для команды | Архитектура должна дойти до поставки |
| Terraform | IaC-контекст и повторяемость окружений | Middle+ | Учитывал IaC и environment strategy | Не обязательно писать весь IaC самому |
| AWS / Azure Well-Architected | Проверка cloud-решений по quality attributes | Senior+ | Проводил Well-Architected review и cost/risk review | Framework не заменяет discovery |
| Cost calculator / TCO tools | Оценка стоимости владения | Senior+ | Сравнивал TCO cloud/vendor/custom вариантов | Цена старта не равна стоимости владения |
| Risk register template | Управление рисками и открытыми вопросами | Middle+ | Вёл risk register, assumptions и dependencies | Риски должны иметь владельцев |
| RACI matrix | Распределение ответственности | Middle+ | Фиксировал ownership систем, данных и support | Без ownership архитектура не внедряется |
| Presentation tools | Защита решения перед стейкхолдерами | Middle+ | Защищал architecture decisions для бизнеса и delivery | Презентация не должна скрывать компромиссы |
По SkillStat зарплатная оценка Solution Architect в Москве и МО на 23.06.2026 — 300 000 ₽ в estimated-режиме. Зарплатную оценку SkillStat нужно читать как ориентир по вакансиям региона и даты среза, а не как гарантированную медиану для каждого Solution Architect.
| Фактор | Почему повышает доход | Как подтвердить |
|---|---|---|
| Масштаб enterprise-проектов | Чем больше систем, пользователей и зависимостей, тем выше цена ошибки | Кейсы с несколькими системами и стейкхолдерами |
| Customer-facing ответственность | Архитектор влияет на доверие заказчика и реалистичность обещаний | Опыт discovery, защиты решений и technical handover |
| Пресейл крупных сделок | Снижает риск до подписания договора | Assumptions, risk register, option comparison |
| Cloud/hybrid architecture | Cloud влияет на безопасность, стоимость, DR и эксплуатацию | Well-Architected review, landing zone/context diagrams |
| Интеграции и API | Интеграции часто определяют сроки и риски внедрения | Integration map, OpenAPI, event map |
| Data migration | Ошибки миграции дорого обходятся бизнесу | Migration plan, data quality assumptions |
| Security and compliance | Enterprise-проекты требуют согласований и auditability | Security view, NFR, compliance notes |
| NFR и reliability | Нефункциональные требования меняют архитектуру и стоимость | NFR catalog, trade-offs, SLO/SLA context |
| TCO и cost optimization | Бизнес платит за решение целиком, а не только за релиз | TCO estimate, buy/build/customize comparison |
| Risk management | Прозрачные риски уменьшают провалы delivery | Risk register with owners and actions |
| Vendor/product selection | Выбор платформы влияет на lock-in и future cost | Vendor comparison, PoC report |
| Архитектурные артефакты и ADR | Документированные решения переживают смену команды | Architecture pack and ADR portfolio |
| Руководство несколькими командами | Lead/Principal roles требуют координации и governance | Portfolio of solutions, standards |
| Опыт внедрения | Ценится не схема, а решение, которое дошло до эксплуатации | Before/after, implementation review |
| Способность снижать риск до старта | Сильный архитектор экономит бюджет ещё до реализации | Discovery checklist, rejected options, PoC criteria |
На 23.06.2026 SkillStat видит 40 активных вакансий Solution Architect в Москве и МО, спрос 19/100, ранг #36 из 71 и статус «низкий». Динамику лучше читать в live-графике. Такой рынок не массовый junior-набор: он ориентирован на опытных специалистов.
| Показатель | Значение SkillStat | Как читать |
|---|---|---|
| Активные вакансии | 40 | Роль нишевая, но заметная для enterprise и системной интеграции |
| Спрос | 19/100, #36 из 71, статус низкий | Ниже массовых ролей разработки, выше узких архитектурных специализаций |
| Динамика | 7 дней назад 76, 30 дней назад 57; тренд см. в live-графике | Короткий всплеск не надо читать как долгосрочный прогноз |
| Средние 30 дней | См. live-график спроса | Стабильный фон без резкого изменения спроса |
| Формат | Удалённо 15%, гибрид 63%, офис 23% | Stakeholder work и enterprise-контекст усиливают гибрид |
| Уровни | Senior 97.5%, Lead 3%, Middle — | Рынок ждёт специалистов с опытом решений и внедрения |
| Junior-вход | — | Путь чаще идёт через senior system analyst, backend, integration, cloud или presale |
| Навыков на вакансию | См. live-блок навыков | Работодатели ждут широкий профиль: интеграции, платформы, данные, коммуникация |
| Скрытый спрос | Architect IT solutions, presale architect, cloud solution architect, integration architect | Ищите не только точное название Solution Architect |
| Как отличить реальную вакансию | Есть ответственность за реализуемое решение, NFR, риски, интеграции, внедрение | Если роль сводится к презентациям без delivery, это ближе к чистому пресейлу |
Для estimated-режима грейдовые зарплаты не показываются, чтобы не создавать ложную точность.
Зарплатную оценку SkillStat нужно читать как ориентир по вакансиям региона и даты среза, а не как гарантированную медиану для каждого Solution Architect. Активный рынок сильно senior-heavy: Senior 97.5%, Lead 3%, Middle —, Junior —. Поэтому отдельный junior-ориентир по зарплате был бы ложной точностью.
На доход сильнее всего влияет масштаб ответственности: enterprise-интеграции, cloud и Kubernetes, микросервисы, Kafka/RabbitMQ, API, данные, безопасность, presale/customer-facing работа, цена архитектурной ошибки и способность довести решение до реализации. Выше оцениваются архитекторы, которые не только рисуют схемы, но и заранее видят риски внедрения, стоимость владения и последствия для нескольких команд.
Спрос на архитектора решений лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.
В активном срезе SkillStat по Москве и МО на 23.06.2026 видно 40 вакансий Solution Architect, спрос 19/100 и ранг #36 из 71. Формально статус спроса низкий относительно всего IT-рынка, но для архитектурной роли это заметный объём: такие вакансии появляются в enterprise, интеграторах, банках, телекоме, retail, cloud, B2B-продуктах и vendor-командах.
Сглаженный тренд лучше читать в live-графике. Для архитектурной роли важнее не дневной всплеск, а устойчивость спроса на сложные внедрения, интеграции и модернизацию систем.
Формат работы: удалённо 15%, гибрид 63%, офис 23%. Solution Architect часто работает с заказчиком, stakeholder alignment, внутренними комитетами, безопасностью и delivery-командами, поэтому гибрид встречается чаще чистой удалёнки.
Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.
Грейдовые медианы не показаны: для архитектора решений сейчас используется estimated-режим зарплаты, поэтому SkillStat не выводит отдельные зарплаты по уровням, чтобы не создавать ложную точность.
Junior-вход в активном срезе не виден. Близкий старт — senior engineer, системный аналитик, integration analyst, presale engineer или technical lead с архитектурными задачами.
Ведёт решение в пределах продукта, клиента или доменной области: собирает constraints, готовит схемы, согласует API, данные, риски и implementation plan.
Отвечает за крупное enterprise-решение, несколько систем, stakeholder alignment, архитектурные tradeoffs, безопасность, стоимость и delivery risk.
Формирует стандарты solution architecture, review-процесс, presale/delivery методологию, архитектурные артефакты и развитие команды архитекторов.
Solution Architect нужен там, где решение затрагивает несколько систем, команд или сторон. Это системные интеграторы, enterprise-компании, банки, телеком, retail, облачные и платформенные провайдеры, B2B-продукты, vendor-команды, 1С/ERP/CRM-внедрения, data/platform teams и крупные внутренние цифровые программы. В интеграторе роль часто ближе к presale и delivery: нужно быстро понять клиента, предложить реализуемую схему и помочь команде не потерять смысл при внедрении. Во внутренней enterprise-команде архитектор дольше живёт с последствиями решений: legacy, безопасность, эксплуатация, стоимость и развитие платформы становятся важнее красивого стартового документа.
Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.
В Solution Architect обычно переходят не с нуля, а из senior-разработки, системного анализа, интеграций, DevOps/cloud, внедрения enterprise-систем, технического пресейла или технического руководства. База — умение понимать требования, ограничения и последствия решения для нескольких команд. Учить нужно не только system design. Начните с API, интеграций, данных, безопасности, NFR, микросервисов, legacy, cloud/container basics, messaging, документации и архитектурных решений. Затем добавьте stakeholder work: workshops, discovery, tradeoff matrix, risk register, implementation roadmap и защиту решения. Портфолио должно показывать артефакты: контекстную схему, integration map, ADR, список constraints, NFR, cost/security tradeoffs, план миграции, roadmap внедрения и объяснение, почему отвергнуты альтернативы. Без этого резюме выглядит как набор технологий, а не как архитектурная роль.
Сопоставили программы с реальным стеком из 40 вакансий — оценка соответствия рассчитана автоматически, это не реклама.
Соответствие — доля ключевых навыков из вакансий, которые охватывает программа курса
Из-за слабого junior-входа этот roadmap лучше читать как план перехода из смежной IT-роли. Новичку без опыта сначала нужна база разработки, анализа, интеграций или внедрения, а затем архитектурные артефакты.
| Период | Что изучить | Что сделать руками | Результат |
|---|---|---|---|
| 0-2 месяца | Роль Solution Architect, основы системного анализа, API, HTTP, REST, SOAP, SQL, модели данных | Описать текущий landscape учебной системы и базовые требования | Понимание, что архитектор начинает с задачи, а не с технологии |
| 2-4 месяца | Интеграции, события, очереди, ETL, source of truth, C4, UML, BPMN, базовые NFR | Сделать integration map, OpenAPI draft, NFR checklist | Первый architecture pack для учебного кейса |
| 4-6 месяцев | Cloud basics, Kubernetes/Docker на концептуальном уровне, CI/CD, IAM, observability, cost/TCO basics | Сравнить cloud/vendor/custom варианты и написать ADR | Навык объяснять trade-offs и последствия |
| 6-9 месяцев | CRM, ERP, data platform, customer portal, cloud migration cases, PoC, risk register, assumptions log | Собрать risk register, migration plan и implementation roadmap | Портфолио с рисками и планом внедрения |
| 9-12 месяцев | Presale/discovery, stakeholder management, negotiation, vendor work | Подготовить presentation для бизнеса и technical handover для delivery | Готовность к смежным архитектурным собеседованиям |
| 12-18 месяцев | Enterprise context, governance, advanced cloud/certifications, CRM/ERP/1С/SAP context, mentoring | Разобрать 2-3 обезличенных enterprise-кейса | Переход к Senior/Lead Solution Architect path |
| Что не учить на старте | TOGAF в глубину, полный Archimate, сложные enterprise-frameworks, low-level Kubernetes, vendor-specific детали | Вернуться после базы требований, интеграций, данных, NFR и решений | Не тонуть в frameworks до практики |
Сертификат помогает структурировать знания, но не заменяет опыт проектирования и внедрения. Cloud-сертификат сам по себе не делает человека полноценным Solution Architect без требований, данных, рисков, stakeholder management и delivery-контекста.
| Направление | Что подходит | Кому полезно | Что показать кроме сертификата |
|---|---|---|---|
| AWS | AWS Certified Solutions Architect Associate / Professional | Cloud Solution Architect, backend/cloud engineers | Cloud option comparison, Well-Architected review, TCO notes |
| Microsoft Azure | Azure Solutions Architect Expert | Специалистам по Azure/hybrid enterprise | Architecture diagram, IAM/security assumptions, DR plan |
| Google Cloud | Professional Cloud Architect | Cloud/data/platform контекст | Case study с cost, reliability и data flow |
| Yandex Cloud | Релевантные облачные курсы и сертификации при наличии | Для российского cloud-контекста | Cloud architecture pack без production-секретов |
| TOGAF | Enterprise architecture framework | Senior/Lead, governance и enterprise track | Capability map, principles, architecture governance notes |
| Archimate | Нотация enterprise architecture | Enterprise/System architects | Landscape diagram с пояснением для аудитории |
| IASA | Architecture skill framework, если применимо | Архитекторам, которым нужна рамка компетенций | Portfolio evidence, а не только badge |
| Kubernetes | KCNA/CKA как cloud-native фундамент | Cloud/platform-adjacent architects | Conceptual deployment view и operational constraints |
| SAP/1С/CRM/ERP | Vendor certifications и продуктовые курсы | Архитекторам внедрения и enterprise platforms | Fit-gap, integration map, migration assumptions |
| Практика | Учебные кейсы, open-source разборы, обезличенные рабочие артефакты | Всем уровням | ADR, risk register, NFR, TCO, diagrams, roadmap без NDA-данных |
Solution Architect подходит тем, кто умеет держать несколько уровней задачи одновременно: бизнес-цель, данные, интеграции, безопасность, стоимость, командные ограничения и будущую поддержку. Комфортнее всего в роли людям, которым интересно договариваться о tradeoffs, а не доказывать один любимый стек.
Solution Architect — это архитектор решений, который переводит бизнес-задачу в реализуемую техническую архитектуру. Он учитывает требования, интеграции, данные, безопасность, стоимость, сроки, ограничения и риски. Его работа заканчивается не схемой ради схемы, а решением, которое команда может внедрить, заказчик — принять, а эксплуатация — поддерживать.
Архитектор решений уточняет бизнес-цель, изучает текущий системный landscape, собирает functional и non-functional requirements, проектирует интеграции, данные, безопасность и варианты реализации. Он сравнивает buy, build и customize, фиксирует trade-offs в ADR, ведёт risk register и помогает delivery-команде не потерять смысл решения при внедрении.
Да, переход из DevOps или cloud engineering возможен, особенно в cloud solution architecture. Сильная база по инфраструктуре, CI/CD, Kubernetes, observability, security и cost помогает, но её нужно дополнить требованиями, бизнес-процессами, integration/data architecture, vendor selection, ADR, TCO и коммуникацией с заказчиком. Иначе роль останется инфраструктурной, а не solution-wide.
Solution Architect нужны solution design, system design, integration architecture, data basics, cloud basics, security basics, NFR, trade-offs, ADR, risk register, TCO, документация и stakeholder management. По вакансиям SkillStat часто встречаются Microservices, REST API, Kubernetes, Apache Kafka, PostgreSQL, Docker, Java, 1С, SQL, CI/CD, RabbitMQ, SOAP и ETL.
Да, backend-, Java-, Python-, Node.js- или Go-разработчик может перейти в Solution Architect, если расширит взгляд от кода к бизнес-задаче, интеграциям, данным, безопасности, стоимости и внедрению. Разработчикам часто помогает опыт system design, API, микросервисов, баз данных и CI/CD. Недостающие зоны — discovery, stakeholder management, TCO, risk register и presale/delivery alignment.
Да, переход из системного анализа в Solution Architect реалистичен. У аналитика уже есть база требований, процессов, коммуникации и документации. Обычно нужно усилить архитектурный выбор, интеграции, cloud/platform context, NFR, TCO, ADR, risk register и ответственность за последствия решения. Хороший шаг — собрать портфолио architecture artifacts по учебному или обезличенному кейсу.
Работать Solution Architect удалённо можно, но по данным SkillStat для Москвы и МО на 23.06.2026 удалённый формат встречается в 15% вакансий, гибрид — 63%, офис — 23%. Это связано с количеством встреч, discovery, согласований и enterprise-контекстом. Часть работы можно делать онлайн, но многие работодатели хотят регулярное взаимодействие с бизнесом, delivery, безопасностью и заказчиком.
Стать Solution Architect с полного нуля напрямую сложно, потому что рынок ждёт опытных специалистов. Реалистичный путь — сначала получить базу в разработке, системном анализе, интеграциях, cloud/DevOps, data engineering, внедрении CRM/ERP/1С или техническом пресейле. Затем нужно собрать портфолио архитектурных артефактов: context diagram, integration map, NFR, ADR, risk register и roadmap.
ИИ не стоит рассматривать как гарантированную замену архитекторов решений. Он будет автоматизировать черновую документацию, поиск паттернов, сравнение вариантов и проверку полноты, но человек останется нужен для stakeholder alignment, переговоров, ответственности, оценки рисков, vendor context, коммерческих ограничений и доведения решения до внедрения. Ценность сместится к архитекторам, которые умеют проверять ИИ и принимать решения.
ИИ ускоряет черновики диаграмм, ADR, сравнений вариантов, описаний API, risk register, NFR checklist и презентаций. Он помогает найти противоречия и подготовить вопросы для discovery, но не знает скрытые ограничения организации, реальные договорённости, политический контекст и ответственность за trade-offs. Поэтому ИИ усиливает архитектора, но не заменяет архитектурное решение как управленческий акт.
По текущему срезу SkillStat среди работодателей Solution Architect в Москве и МО видны Сбер. IT, БЮРО 1440, АРЕАЛ, Лента, МТС и АО Системы Коммуникаций. Это не полный список рынка, а снимок активных вакансий на дату обновления. Для поиска стоит смотреть также названия architect IT solutions, архитектор внедрения, presale architect, cloud solution architect и integration architect.
На собеседовании Solution Architect спрашивают discovery, business и functional requirements, NFR, system landscape, API, REST vs SOAP, synchronous vs asynchronous integration, Kafka vs RabbitMQ, SQL и data modeling, source of truth, data migration, security, cloud architecture, TCO, vendor lock-in, buy vs build, ADR, risk register, C4/UML/BPMN/Archimate и stakeholder conflicts.
Зарплата Solution Architect считается в estimated-режиме, когда прямых прозрачных зарплатных данных недостаточно для честного диапазона по активным вакансиям. SkillStat использует расширенное окно профессии, но не рисует ложную точность по грейдам. Это особенно важно для senior-heavy ролей, где условия часто зависят от проекта, заказчика и ответственности.
По данным SkillStat на 23.06.2026 в Москве и МО зарплатная оценка Solution Architect составляет 300 000 ₽ в estimated-режиме. Это ориентир по вакансиям региона и даты среза, а не гарантированная медиана каждого архитектора решений. Доход зависит от масштаба проектов, cloud/integration-глубины, пресейла, ответственности и опыта внедрения.
Архитекторы решений чаще работают в enterprise-компаниях, банках, телекоме, retail, системной интеграции, B2B-внедрениях, cloud-провайдерах, продуктовых платформах, CRM/ERP/1С/SAP-проектах и data/platform initiatives. Роль появляется там, где решение затрагивает несколько систем, команд, данных, интеграций и стейкхолдеров, а ошибка архитектуры дорого стоит бизнесу.
В Solution Architect чаще переходят из backend-разработки, системного анализа, software architecture, integration engineering, data engineering, DevOps/cloud, внедрения CRM/ERP/1С/SAP и технического пресейла. У каждой траектории свои пробелы: разработчикам часто не хватает business discovery, аналитикам — cloud и integration depth, пресейлу — delivery accountability.
Архитектору решений полезны C4 Model, UML, BPMN, Archimate, Draw.io, Miro, Lucidchart, Visio, PlantUML, Structurizr, Confluence, Jira, ADR templates, OpenAPI/Swagger, Postman, SQL, Kafka, RabbitMQ, Kubernetes, Docker, CI/CD, GitLab, Terraform, cloud architecture centers, TCO tools, risk register и RACI. Важно не владение кнопками, а качество решений.
Подходящий курс для Solution Architect должен давать не только паттерны, но и discovery, requirements, architecture artifacts, C4/UML/BPMN/Archimate, integration/API, data architecture, cloud, security/NFR, TCO, ADR, trade-offs, risk register, presale и stakeholder management. Курсы Software Architect, System Analyst, Cloud Architect и TOGAF полезны как смежные треки, но не всегда закрывают всю роль.
TOGAF полезен Solution Architect, если работа связана с enterprise architecture, governance, архитектурными принципами и портфелем систем. Но TOGAF не заменяет практику discovery, интеграций, NFR, ADR, TCO и внедрения. На старте лучше не тонуть в framework: сначала нужны практические артефакты и понимание реальных ограничений проекта.
Solution Architect не всегда пишет код каждый день, но должен понимать разработку достаточно глубоко, чтобы принимать реалистичные решения. Важно разбираться в API, данных, интеграциях, CI/CD, cloud, безопасности, ограничениях платформ и стоимости изменений. Опыт программирования помогает видеть последствия архитектуры, но для роли важны ещё коммуникация, NFR, риски и внедрение.
AWS и Azure-сертификаты полезны, если Solution Architect работает с cloud или hybrid-решениями. Они помогают структурировать знания по compute, storage, network, IAM, monitoring, reliability и cost optimization. Но cloud-сертификат не делает человека полноценным архитектором решений без требований, интеграций, данных, stakeholder management, рисков и delivery-контекста.
У Solution Architect почти нет junior-входа, потому что роль требует опыта решений, ограничений, интеграций, коммуникаций и последствий внедрения. По текущему срезу SkillStat рынок ориентирован на опытных специалистов: Senior 97.5%, Lead 3%, Middle —, Junior —. Это не значит, что путь закрыт: чаще переходят из системного анализа, backend, integration, DevOps/cloud, внедрения или технического пресейла.
Срок зависит от стартовой роли. Опытному системному аналитику, backend-разработчику или integration engineer часто нужен 6-18-месячный переход: усилить NFR, архитектурные диаграммы, cloud basics, trade-offs, TCO, stakeholder management и портфолио. Новичку без IT-опыта сначала потребуется несколько лет практики в смежной роли, потому что курс сам по себе не заменяет delivery-опыт.
Идти в Solution Architecture в 2026 году стоит тем, у кого уже есть сильный IT-бэкграунд и интерес к решениям на стыке бизнеса, систем, данных, интеграций и внедрения. Это не массовая junior-профессия: по срезу SkillStat отдельный junior-вход почти не виден, рынок ориентирован на Senior. Но для опытных разработчиков, аналитиков, интеграторов, cloud/DevOps и пресейла это сильная траектория роста.
Системный аналитик формализует требования, процессы, данные, сценарии, спецификации и acceptance criteria. Solution Architect использует эти материалы, но отвечает за архитектурный выбор: варианты решения, интеграции, NFR, безопасность, TCO, риски, ADR и roadmap внедрения. Переход из системного анализа в Solution Architecture возможен, если усилить техническую и архитектурную часть.
Системный архитектор чаще фокусируется на системном ландшафте, технических стандартах, платформах и взаимосвязях систем. Solution Architect обычно ближе к конкретной бизнес-задаче и внедрению: он выбирает вариант решения, согласует trade-offs, риски, NFR и помогает довести проект до реализации. В enterprise эти роли часто пересекаются.
Cloud Architect глубже отвечает за cloud или hybrid-архитектуру: compute, network, storage, IAM, monitoring, disaster recovery, cost optimization и governance облака. Solution Architect может включать cloud в решение, но его фокус шире: бизнес-сценарий, данные, интеграции, вендоры, NFR, внедрение и коммуникация со стейкхолдерами. Cloud-сертификат полезен, но не заменяет эту ширину.
Enterprise Architect работает на уровне компании: capability map, целевая архитектура, стандарты, governance, портфель систем и долгосрочный roadmap. Solution Architect работает ближе к конкретному решению или проекту: CRM, интеграция, cloud migration, платформа данных, клиентский портал. Он должен учитывать enterprise-правила, но отвечает за реализуемость отдельного решения.
Integration Architect глубже занимается API, событиями, очередями, ESB, ETL, data flow, контрактами и границами систем. Solution Architect отвечает за решение целиком и должен понимать интеграции достаточно хорошо, чтобы оценить риски, стоимость и внедряемость. В сложных проектах Integration Architect может быть отдельным экспертом внутри команды решения.
Presale Architect помогает продать и защитить техническое предложение до подписания договора. Solution Architect может участвовать в пресейле, но сильная роль не заканчивается презентацией: важно сохранить связь с delivery, рисками, ограничениями и реализацией. Если архитектор обещает возможности без discovery, PoC или проверки вендора, проект получает риск ещё до старта.
Solution Architect отличается от Software Architect шириной ответственности. Software Architect глубже отвечает за устройство программной системы: модули, сервисы, паттерны, кодовые границы и техническое качество. Solution Architect смотрит шире: бизнес-задача, интеграции, данные, вендоры, стоимость, безопасность, риски, пресейл и delivery. В небольших командах роли могут совмещаться.
Tech Lead ведёт техническую реализацию команды: качество кода, кодовые решения, decomposition задач, review и delivery внутри команды. Solution Architect отвечает за целостность решения шире одной команды: бизнес-цель, системы, интеграции, данные, вендоры, безопасность и эксплуатация. В небольших компаниях Tech Lead может выполнять часть архитектурных функций, но это не одно и то же.
Solution Architect означает «архитектор решений». В русскоязычных вакансиях также встречаются варианты «архитектор IT-решений», «архитектор ИТ-решений», «архитектор внедрения» и «cloud solution architect». Название подчёркивает, что специалист отвечает не за отдельный модуль или кодовую базу, а за целостное решение под задачу бизнеса.
В портфолио начинающему Solution Architect стоит показать обезличенный architecture pack: context/container diagrams, integration map, OpenAPI-контракт, ADR с rejected options, NFR checklist, risk register, TCO-сравнение, migration plan, RACI и implementation roadmap. Все рабочие артефакты нужно очистить от NDA, персональных данных, коммерческой тайны и чувствительной информации.
ADR, или Architecture Decision Record, — это короткая запись архитектурного решения. В хорошем ADR есть контекст, выбранный вариант, последствия, rejected options и условия пересмотра. ADR помогает будущей команде понять, почему решение было принято, чем пожертвовали и какие допущения действовали. Без ADR архитектура часто выглядит как набор схем без памяти решений.
Buy vs build vs customize — это выбор между покупкой готового продукта, собственной разработкой и настройкой или расширением вендорского решения. Solution Architect сравнивает варианты по срокам, fit к процессу, стоимости владения, поддержке, интеграциям, рискам, lock-in и будущей гибкости. В enterprise часто побеждает не самый красивый вариант, а самый реализуемый.
C4 model — это подход к архитектурным диаграммам с уровнями context, container, component и code. Для Solution Architect чаще всего полезны context и container diagrams: они помогают объяснить систему, соседние системы, пользователей, контейнеры, базы данных и интеграции. C4 удобен тем, что даёт общий язык между бизнесом, аналитиками, разработкой и архитектурой.
NFR — это нефункциональные требования: доступность, производительность, масштабируемость, безопасность, compliance, observability, поддерживаемость, стоимость, disaster recovery, RTO/RPO и другие свойства решения. Они отвечают не на вопрос «что делает система», а на вопрос «как хорошо и в каких ограничениях она должна работать». NFR нельзя оставлять на конец проекта.
Risk register — это реестр рисков проекта или решения. В нём фиксируют технические, интеграционные, data, migration, vendor, security, compliance, performance, cost и delivery risks, а также владельцев и следующие действия. Для Solution Architect это рабочий инструмент, потому что риск, не записанный явно, легко теряется между пресейлом, контрактом и реализацией.
TCO, или total cost of ownership, — это полная стоимость владения решением. Она включает не только внедрение, но и лицензии, инфраструктуру, интеграции, поддержку, обучение, миграции, безопасность, вендорские ограничения и будущие изменения. Дешёвый старт может оказаться дорогой эксплуатацией, поэтому Solution Architect сравнивает варианты по полной стоимости и рискам.
Vendor lock-in — это зависимость от конкретного поставщика, платформы или облака, из-за которой смена решения становится дорогой или сложной. Это не всегда плохо: managed services и готовые платформы могут ускорить запуск и снизить операционную нагрузку. Плохой вариант — принять lock-in неосознанно и не описать последствия в ADR, TCO и risk register.
Да, Solution Architect и архитектор решений обычно означают одну роль. Разница чаще в языке вакансии и контексте компании: в международных и cloud-вакансиях пишут Solution Architect, в российских enterprise-проектах — архитектор решений или архитектор IT-решений. Важно смотреть не только на название, а на обязанности, артефакты и ответственность за внедрение.