System Architect, или системный архитектор, проектирует не один сервис, а устройство крупной ИТ-системы или целого ИТ-ландшафта. Простыми словами, он помогает компании понять, какие системы за что отвечают, как они связаны интеграциями, где живут данные, кто ими владеет, какие регламенты, ограничения эксплуатации и безопасности нужно учитывать, как проводить миграции и по каким правилам менять архитектуру без цепной реакции поломок.
Результат работы системного архитектора - не красивая схема ради схемы, а набор решений и артефактов: карта ландшафта, интеграционная схема, data flow, NFR, ADR, roadmap миграции, стандарты и архитектурные правила. По данным SkillStat на 23.06.26 для Москвы и МО, в срезе 31 активных вакансий, зарплатная оценка составляет 320 000 ₽ в estimated-режиме. В требованиях чаще встречаются архитектурные и инфраструктурные навыки: CI/CD, microservices, PostgreSQL, Linux, Apache Kafka, Kubernetes, REST API и SQL. Рынок заметно senior-heavy: junior-вход по текущему срезу всего —, поэтому путь в System Architect обычно строится через разработку, системный анализ, интеграции, DevOps/cloud, инфраструктуру или data engineering. SkillStat помогает увидеть не только описание профессии, но и реальные вакансии, зарплатную оценку, спрос, навыки, работодателей и релевантность курсов требованиям рынка.
Как ещё называют системного архитектора
Вакансии могут использовать русские и английские названия. Читать нужно не заголовок, а обязанности: есть ли ответственность за ландшафт, данные, интеграции, NFR, миграции и правила изменений. System Architect и системный архитектор в большинстве российских вакансий означают одну роль, но конкретный смысл всегда нужно проверять по обязанностям.
Свежий срез SkillStat показывает нишевую, но дорогую роль: 31 активных вакансий в Москве и МО, зарплатная оценка 320 000 ₽, спрос 13/100 и ранг #42 из 71.
Формат работы в текущих вакансиях в основном гибридный: удаленно 77%, гибрид 77%, офис 19%. В среднем вакансия требует около 8 навыков, а junior-вход составляет —. Это не массовая стартовая профессия, а роль для специалистов, которые уже видели реальные системы, данные, интеграции и эксплуатацию.
System Architect отвечает за целостность IT-ландшафта: системы, данные, интеграции, NFR, миграции и архитектурные правила.
Для этой профессии доступны ограниченные данные. Аналитика носит ориентировочный характер.
По зарплате у профессии нет достаточной собственной актуальной выборки. Поэтому на странице показана оценка с явной маркировкой источника, а не точная медиана только по текущим активным вакансиям.
Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.
Актуальный срез по вакансиям, зарплате, спросу и динамике найма для системного архитектора в Москве и МО.
System Architect, или системный архитектор, отвечает за то, как устроена крупная IT-система или целый ландшафт систем. Он выясняет, какие приложения существуют, где проходят границы ответственности, кто владеет данными, какие интеграции связывают сервисы, какие требования накладывают безопасность, регламенты, эксплуатация и стоимость изменений.
В отличие от разработчика, системный архитектор смотрит шире одного сервиса. Его интересует, что произойдёт, если изменить API, вынести функцию в отдельный компонент, заменить legacy-систему, перенести данные, добавить очередь или подключить внешнего поставщика. Хороший архитектор заранее показывает, где появятся риски для отчётности, SLA, поддержки, безопасности, бизнес-процесса и соседних команд.
Это не просто архитектор ПО: Software Architect глубже отвечает за внутреннее устройство продукта и кодовые границы. Это не просто Solution Architect: архитектор решений чаще собирает конкретное внедряемое решение под бизнес-задачу. System Architect удерживает системный ландшафт, целевые правила и последствия изменений для нескольких систем.
Системный архитектор держит не один сервис, а связи между системами, данными, интеграциями, владельцами и эксплуатацией.
Архитектура должна позволять менять ландшафт без хаоса, потери данных и постоянных конфликтов между командами.
Это не просто разработчик, системный аналитик, архитектор ПО или Tech Lead: у System Architect другой горизонт ответственности.
В банках, телекоме, госсекторе, ритейле, интеграторах и крупных платформах одно изменение может задеть десятки систем, регламентов и команд. Системный архитектор заранее показывает последствия и помогает организации не копить системный долг.
Схема полезна, если за ней есть владельцы, данные, NFR, ADR, rejected options, план миграции и правила изменения. Иначе она быстро превращается в красивую, но устаревшую картинку.
По текущему срезу SkillStat Junior занимает —, Senior - 96.8%, Lead - 3%. Работодатели ждут человека, который уже видел реальные интеграции, legacy, эксплуатацию, безопасность и последствия неверных решений.
Сводка помогает быстро понять, кто такой System Architect, чем он отличается от смежных ролей и как читать рыночные данные SkillStat.
| Параметр | Значение | Как читать |
|---|---|---|
| Кто это | Системный архитектор крупной системы или ИТ-ландшафта | Отвечает за связи между системами, данными, интеграциями, владельцами и эксплуатацией |
| Главная задача | Сделать изменения управляемыми | Архитектура должна снижать хаос, а не усложнять систему ради схем |
| Что проектирует | Системы, границы, интеграции, данные, NFR, миграции, правила изменений | Фокус шире одного сервиса или одной команды |
| Главный объект работы | System landscape | Ландшафт включает приложения, владельцев, данные, API, регламенты, эксплуатацию и ограничения |
| Хороший результат | Изменение можно внедрить, сопровождать и объяснить | Есть владельцы, ADR, проверенные trade-offs и roadmap |
| Ключевые артефакты | Landscape map, integration map, data flow, NFR, ADR, migration roadmap | Артефакты должны отвечать на вопросы конкретной аудитории |
| Ключевые практики | Architecture review, governance, standards, exception process, technology radar | Практики помогают принимать согласованные решения быстрее |
| Ключевые навыки | См. live-блок частых навыков на странице | Частотность по вакансиям SkillStat на дату среза |
| Популярные инструменты | C4, UML, BPMN, ArchiMate, ADR, OpenAPI, Kafka, RabbitMQ, ESB, API Gateway, Confluence, Jira | Инструменты важны как язык архитектурных решений |
| Зарплатная оценка SkillStat | 320 000 ₽, Оценка по профессии и близкому рынку, n=3 | Ориентир по вакансиям, не гарантированная медиана каждого специалиста |
| Вакансии | 31 активных вакансий в Москве и МО на 23.06.2026 | Нишевая роль, а не массовый junior-набор |
| Спрос | 13/100, ранг #42 из 71, статус низкий | Спрос ниже массовых ролей разработки |
| Формат работы | Удалённо 3%, гибрид 77%, офис 19% | Гибрид доминирует из-за большого числа согласований |
| Уровень входа | Junior —, Middle —, Senior 96.8%, Lead 3% | Рынок ориентирован на опытных специалистов |
| Кому подходит | Специалистам, которые видят последствия изменений за пределами одной команды | Нужны системность, коммуникация и готовность работать с компромиссами |
| Где работает | Банки, телеком, ритейл, госсектор, интеграторы, большие платформы, enterprise-контуры | Роль нужна там, где много систем, данных, регламентов и legacy |
| Куда растёт дальше | Lead System Architect, Principal Architect, Enterprise Architect, CTO-track | Рост идёт через масштаб ландшафта, governance и влияние на портфель систем |
Roadmap лучше читать как путь перехода из смежной IT-роли. Один курс без опыта реальных систем не делает человека System Architect, особенно при junior-входе 2% по текущему срезу.
| Период | Фокус | Что сделать | Результат |
|---|---|---|---|
| 0-2 месяца | Роль, системный анализ, API, HTTP, REST, SOAP, SQL, документация | Описать текущий landscape учебной системы и базовые requirements | Понимание систем, границ и владельцев |
| 2-4 месяца | Интеграции, события, очереди, ETL, source of truth, ownership данных, C4, UML, BPMN | Сделать integration map, OpenAPI draft и source of truth matrix | Первые архитектурные артефакты |
| 4-6 месяцев | Docker/Kubernetes концептуально, CI/CD, Linux, IAM, monitoring, logging, ADR, rejected options | Описать trade-off между REST, очередью и событиями | Умение объяснять последствия выбора |
| 6-9 месяцев | Case studies: банк, ритейл, телеком, CRM/ERP, платформа данных | Подготовить migration roadmap, data flow diagram, risk register | Портфолио по изменению ландшафта |
| 9-12 месяцев | Governance, technology radar, standards, exceptions, stakeholder management, legacy | Собрать architecture review checklist и интервью-пакет | Готовность к смежным архитектурным задачам |
| 12-18 месяцев | Enterprise context, ArchiMate/TOGAF basics, cloud/hybrid, advanced integrations, leadership | Оформить полный обезличенный architecture pack | Переход к Middle/Senior-adjacent System Architect задачам |
| Что не учить в начале | Глубокий TOGAF, сложный ArchiMate, low-level Kubernetes, vendor-specific детали | Сначала закрыть требования, интеграции, данные, NFR и ADR | Новичок не тонет в enterprise-frameworks до базы |
Системный архитектор начинает не с выбора технологии, а с понимания ландшафта. Карта должна показывать владельцев и правила изменений, а не только прямоугольники: отсутствие владельца данных - архитектурный риск.
| Элемент ландшафта | Что нужно описать | Зачем это важно | Что будет, если не описать | Артефакт |
|---|---|---|---|---|
| Системы | Назначение, границы, критичность, жизненный цикл | Понять объект изменений | Команды спорят, что именно меняется | System landscape map |
| Владельцы систем | Business owner, technical owner, support owner | Решения должны иметь ответственных | Нет кому согласовать изменение | Ownership matrix |
| Команды | Кто разрабатывает, сопровождает и принимает изменения | Увидеть реальные зоны влияния | Архитектура не совпадает с delivery | Team map |
| Домены | Бизнес-области и границы ответственности | Не смешивать разные модели данных | Появляются универсальные монолиты | Domain map |
| Бизнес-процессы | Сценарии, роли, события, ручные шаги | Связать архитектуру с работой бизнеса | Решение ломает процесс | BPMN / process map |
| Пользователи | Типы пользователей, каналы, права | Учитывать безопасность и нагрузку | Ошибки в доступах и UX | Context diagram |
| Source of truth | Главный источник по сущности и атрибутам | Не допустить расхождений данных | Дубли и спорные отчёты | Source of truth matrix |
| Master data | Ключевые справочники и правила изменения | Стабильность процессов и отчётности | Справочники расходятся | Master data catalog |
| Интеграции | Направление, протокол, владелец, SLA, ошибки | Понять цепочку зависимостей | Невидимые точки отказа | Integration map |
| API | Контракты, версии, совместимость, ошибки | Безопасно менять интерфейсы | Breaking changes | OpenAPI / API catalog |
| События | Producer, consumer, схема, семантика события | Понимать асинхронный обмен | События без владельца | Event catalog |
| Очереди | Маршрутизация, потребители, обработка ошибок | Управлять задачами и нагрузкой | Сообщения теряются в ответственности | Queue map |
| Batch-процессы | Расписание, объём, контроль качества | Не нарушать отчётность и операции | Данные устаревают без контроля | Batch schedule |
| Хранилища данных | БД, DWH, витрины, реплики, архивы | Понимать владение и консистентность | Нельзя найти источник расхождений | Data storage map |
| Регламенты | Compliance, релизные окна, security rules | Сделать решение внедряемым | Архитектура конфликтует с правилами | Constraints log |
| SLA/SLO | Цели доступности, времени ответа, поддержки | Связать ожидания с архитектурой | Команды обещают разное | SLA/SLO matrix |
| Безопасность | Доступы, зоны, аудит, персональные данные | Снизить риск нарушений | Security дорабатывают в конце | Security view |
| Наблюдаемость | Метрики, логи, трассировка, владельцы алертов | Поддерживать систему после релиза | Инциденты расследуются вслепую | Observability view |
| Эксплуатация | Runbook, support model, on-call, окна работ | Решение должно жить после внедрения | Система не поддерживается | Support model |
| Вендоры | Зависимости, ограничения, SLA поставщика | Учитывать внешние риски | Vendor lock-in становится сюрпризом | Vendor dependency map |
| Legacy-ограничения | Технические долги, версии, старые контракты | Планировать реалистичный переход | Целевая схема невнедряема | Legacy constraints log |
| Планируемые изменения | Roadmap, связанные инициативы, зависимости | Не проектировать в отрыве от будущих работ | Решения конфликтуют между проектами | Architecture roadmap |
Рабочий день System Architect состоит из discovery, встреч, сравнения вариантов, фиксации ADR, обновления карты ландшафта, architecture review и передачи решений командам.
| Ситуация | Что делает системный архитектор | Какой артефакт получается | Как проверить качество | Когда нужна эскалация |
|---|---|---|---|---|
| Новая функция затрагивает несколько систем | Уточняет владельцев, данные, API, события, зависимости и NFR | Context diagram, integration map | Понятны все затронутые системы и владельцы | Нет владельца системы или данных |
| Команды спорят, где должен жить источник данных | Разбирает создание, изменение, потребление и качество данных | Source of truth matrix, ADR | Есть один главный источник или осознанная модель копий | Бизнес-владелец не определён |
| Нужно заменить legacy-систему | Описывает coexistence, миграции, зависимости и ограничения | Transition architecture, migration roadmap | Есть промежуточные состояния и criteria of done | Риск остановки критичного процесса |
| Требуется новая интеграция с внешним контуром | Проверяет SLA, security, ошибки, версионирование и поддержку | API contract, risk register | Контракт согласован и поддерживаем | Поставщик не подтверждает условия |
| Появился дублирующий справочник | Сравнивает владельцев, качество, потребителей и миграционный путь | Ownership matrix, data quality notes | Команды понимают, что является master data | Нет согласия по владельцу данных |
| Миграция данных может остановить бизнес-процесс | Разделяет данные, процессы, интеграции и fallback | Migration roadmap, rollback/fallback plan | Понятны окна, риски и критерии возврата | Нет безопасного окна или владельца риска |
| Команда хочет синхронный API, но нагрузка нестабильна | Сравнивает REST/gRPC, события, очередь и batch | Trade-off table, ADR | Выбор связан с SLA, задержками и поддержкой | Компромисс влияет на стоимость или сроки |
| Нужно выбрать между Kafka, RabbitMQ и REST | Сопоставляет сценарий, семантику сообщений, владение и эксплуатацию | Integration decision ADR | Объяснены плюсы, риски и rejected options | Нет команды, готовой поддерживать решение |
| Безопасность требует новых ограничений | Переводит ограничения в NFR, security view и правила доступа | Security view, NFR checklist | Ограничения видны до реализации | Security меняет архитектурный вариант |
| Эксплуатация не готова поддерживать новое решение | Проверяет runbook, observability, incident flow и ownership | Support model, operational readiness checklist | Понятно, кто поддерживает систему после релиза | Нет владельца эксплуатации |
| Старое временное решение стало постоянным | Фиксирует architecture debt, срок жизни и владельца | Architecture debt backlog | Есть срок пересмотра и критерий закрытия | Долг влияет на безопасность или данные |
| Архитектурная схема устарела после релиза | Сверяет фактическую реализацию, ADR и landscape map | Updated landscape map | Документация отражает реальное состояние | Расхождение касается критичных интеграций |
Одна универсальная схема не заменяет architecture pack. Хороший артефакт отвечает на вопрос конкретной аудитории, а rejected options и assumptions важны так же, как выбранное решение.
| Артефакт | Для чего нужен | Кто читает | Что должно быть внутри | Типичная ошибка |
|---|---|---|---|---|
| System landscape map | Показать системы и связи | Архитекторы, аналитики, delivery | Системы, владельцы, интеграции, критичность | Рисовать системы без владельцев |
| Context diagram | Показать окружение системы | Бизнес, аналитики, архитекторы | Пользователи, внешние системы, границы | Смешивать контекст с деталями реализации |
| C4 context diagram | Объяснить систему на верхнем уровне | Бизнес и delivery | Система, пользователи, соседние системы | Перегружать низкоуровневыми деталями |
| C4 container diagram | Показать приложения, БД и связи | Разработка, DevOps, security | Контейнеры, технологии, протоколы | Не показать ownership |
| Integration map | Показать обмены и зависимости | Integration, support, development | Протоколы, направления, SLA, владельцы | Стрелки без контрактов |
| Data flow diagram | Показать движение данных | Data, analytics, business owners | Источники, трансформации, потребители | Не отличать копию от источника |
| Source of truth matrix | Назначить главный источник данных | Бизнес, data, архитекторы | Сущности, атрибуты, владельцы | Оставить спорные атрибуты |
| Ownership matrix | Показать ответственность | Руководители, delivery, support | Business/tech/support owners | Путать владельца системы и данных |
| API contract / OpenAPI | Согласовать API | Разработка, QA, external consumers | Методы, схемы, ошибки, версии | Контракт не соответствует реализации |
| Event catalog | Управлять событиями | Разработка, integration, data | Producer, consumer, schema, meaning | Публиковать события без семантики |
| Sequence diagram | Показать порядок взаимодействий | Разработка, QA, аналитики | Участники, вызовы, ошибки | Использовать для всей карты ландшафта |
| Deployment view | Показать размещение | DevOps, security, support | Окружения, сети, зависимости | Не связать с эксплуатацией |
| Security view | Показать зоны и доступы | Security, architects, teams | Данные, роли, trust boundaries, аудит | Добавлять security после дизайна |
| NFR checklist | Зафиксировать качество | Все стейкхолдеры | Availability, security, performance, supportability | Писать общие слова без критериев |
| Architecture Decision Record | Сохранить решение | Будущие команды | Контекст, варианты, выбор, последствия | Не фиксировать rejected options |
| Trade-off table | Сравнить варианты | Архитекторы, бизнес, delivery | Плюсы, минусы, цена, риски | Показывать только любимый вариант |
| Rejected options | Объяснить отказ от альтернатив | Будущие команды | Почему вариант не выбран | Удалять альтернативы из истории |
| Risk register | Не потерять риски | PM, delivery, business owners | Риск, владелец, mitigation, status | Оставлять риски в переписке |
| Assumptions log | Фиксировать допущения | Архитекторы, аналитики, delivery | Допущение, источник, дата пересмотра | Выдавать предположение за факт |
| Open questions | Управлять неизвестным | Все участники discovery | Вопрос, владелец, срок ответа | Забывать вопросы после встречи |
| Migration roadmap | Показать путь перехода | Delivery, data, operations | Этапы, зависимости, риски, критерии | Планировать только финальную схему |
| Transition architecture | Описать промежуточное состояние | Архитекторы, команды, support | Coexistence, временные связи, owners | Не ограничить временное решение сроком |
| Architecture standards | Унифицировать решения | Команды, архитекторат | Принципы, правила, исключения | Стандарты без exception process |
| Technology radar | Управлять стеком | Архитекторы, CTO, команды | Adopt, trial, assess, hold | Не обновлять после внедрений |
| Architecture review checklist | Проверять изменения | Архкомитет, команды | Критерии review и evidence | Проводить review без критериев |
| Runbook / support model | Подготовить эксплуатацию | Support, DevOps, teams | Алерты, действия, владельцы, эскалации | Передать систему без support ownership |
| Architecture pack for delivery team | Передать решение в реализацию | Delivery team | Схемы, ADR, NFR, risks, open questions | Оставить команды с одной картинкой |
NFR нельзя оставлять на потом: они определяют архитектуру раньше выбора технологии. Часть требований конфликтует друг с другом, поэтому системный архитектор показывает компромиссы, а не обещает максимум скорости, безопасности, дешевизны и гибкости одновременно.
| Характеристика | Что означает | Как влияет на системную архитектуру | Как проверить | Типичная ошибка |
|---|---|---|---|---|
| Availability | Доступность сервиса | Меняет redundancy, failover и support model | SLO, incident history, test plan | Обещать 100% без цены |
| Reliability | Стабильность результата | Влияет на retries, идемпотентность и контроль ошибок | Failure scenarios | Путать с availability |
| Scalability | Рост нагрузки | Меняет storage, compute, queues и partitioning | Load model | Проектировать без прогноза роста |
| Performance | Время ответа и throughput | Влияет на кэш, БД, API и async flow | Performance budget | Говорить "быстро" без метрики |
| Security | Защита данных и доступа | Меняет границы систем и trust zones | Security review | Подключать security в конце |
| Compliance | Регуляторные ограничения | Влияет на хранение, аудит, доступы | Compliance checklist | Считать регламенты внешней проблемой |
| Observability | Видимость работы системы | Требует метрик, логов, трассировок, owners | Monitoring coverage | Не планировать видимость заранее |
| Maintainability | Удобство изменений | Влияет на границы и документацию | Change impact review | Сделать систему нечитаемой |
| Supportability | Поддерживаемость | Требует runbook и ownership | Operational readiness | Передать без поддержки |
| Resilience | Устойчивость к сбоям | Меняет degradation, fallback, isolation | Chaos/failure scenarios | Не описывать деградацию |
| Disaster recovery | Восстановление после серьёзного сбоя | Требует DR strategy и процедур | DR exercise | DR только на бумаге |
| RTO | Время восстановления | Влияет на резервирование и процессы | Recovery drill | Не согласовать с бизнесом |
| RPO | Допустимая потеря данных | Влияет на replication и backup | Restore test | Не связать с данными |
| Data consistency | Согласованность данных | Влияет на sync/async, transactions, events | Consistency rules | Обещать strong consistency везде |
| Data retention | Срок хранения данных | Меняет архивы, удаление, compliance | Retention policy | Хранить всё "на всякий случай" |
| Auditability | Возможность восстановить историю | Требует audit trail и immutable logs | Audit scenario | Логи не отвечают на вопросы аудита |
| Interoperability | Совместимость систем | Требует контрактов и форматов | Contract tests | Каждая система говорит на своём языке |
| Backward compatibility | Совместимость изменений | Влияет на versioning и rollout | Compatibility matrix | Ломать потребителей без окна |
| Cost optimization | Стоимость владения | Влияет на cloud/on-prem, sizing, tooling | TCO comparison | Оптимизировать только CAPEX |
| Deployment constraints | Ограничения поставки | Меняет release flow и environments | Deployment review | Игнорировать окна релизов |
| Migration constraints | Ограничения перехода | Требует transition architecture | Migration rehearsal | Планировать только финал |
| Operational readiness | Готовность к эксплуатации | Требует support model, alerting, runbook | Readiness checklist | Релизить без поддержки |
Хороший архитектор не скрывает компромиссы. ADR фиксирует контекст, решение, последствия и отвергнутые варианты; без rejected options архитектура выглядит как постфактум-оправдание.
| Ситуация | Какие варианты есть | Что выбираем | Чем жертвуем | Что фиксируем в ADR |
|---|---|---|---|---|
| Синхронный API или событийная интеграция | REST/gRPC, event-driven, очередь, batch | По требованиям к задержке и владению | Простотой или независимостью систем | Контекст, SLA, error model, consumers |
| REST или gRPC | HTTP/JSON или contract-first RPC | По потребителям, latency, tooling | Универсальностью или производительностью | Почему выбран протокол |
| REST или SOAP для legacy | Современный API или legacy contract | По ограничениям внешней системы | Чистотой архитектуры или совместимостью | Legacy constraints |
| Kafka или RabbitMQ | Event streaming или broker/queue | По типу обмена и эксплуатации | Гибкостью или простотой поддержки | Семантика сообщений и ownership |
| ETL или event-driven data flow | Пакетный обмен или события | По свежести данных и контролю качества | Latency или операционной простотой | Data freshness и reconciliation |
| Единый source of truth или локальные копии | Master-система, реплики, локальное владение | По доменной ответственности | Консистентностью или автономностью | Owner и sync rules |
| Монолит, modular monolith или микросервисы | Разная степень разделения | По командам, domain boundaries, release flow | Независимостью или сложностью эксплуатации | Почему не микросервисы "просто так" |
| Централизованный справочник или доменные справочники | Один master или несколько owners | По бизнес-владению атрибутами | Единством или доменной автономией | Границы ownership |
| One big migration или поэтапная миграция | Big bang, strangler, coexistence | Обычно поэтапный путь | Скоростью или снижением риска | Transition states и fallback |
| Сохранять legacy или заменить | Рефакторинг, wrapper, replacement | По цене риска и бизнес-приоритету | Временем или долгосрочным долгом | Причины замены/сохранения |
| On-prem или cloud | Свой контур, cloud, hybrid | По compliance, cost, skills, DR | Гибкостью или контролем | Constraints and TCO |
| Своя разработка или вендорский продукт | Build, buy, hybrid | По time-to-market и fit-gap | Контролем или скоростью внедрения | Vendor risks |
| Высокая доступность или снижение стоимости | HA design или cheaper topology | По цене простоя | Стоимостью или доступностью | Business impact |
| Быстрый MVP или полноценная transition architecture | Short path или planned transition | По критичности и сроку жизни решения | Скоростью или техническим долгом | Debt owner and review date |
| Унификация стандартов или исключение | Standard path или exception | По критичности системы | Единообразием или локальной оптимальностью | Exception process |
Системная архитектура ломается, если никто не владеет данными. "Скопируем справочник в новую систему" часто создаёт долгосрочный системный долг, поэтому данные проектируют вместе с процессами и интеграциями.
| Область | Что должен выяснить архитектор | Почему важно | Какой риск возникает | Артефакт |
|---|---|---|---|---|
| Source of truth | Где главный источник сущности или атрибута | Снижает расхождения | Две системы считают себя главными | Source of truth matrix |
| Master data | Какие справочники ключевые для процессов | Определяет стабильность операций | Справочники расходятся | Master data catalog |
| Reference data | Кто владеет кодами и классификаторами | Влияет на отчётность и интеграции | Разные коды в системах | Reference data registry |
| Data ownership | Кто принимает решения о данных | Нужна ответственность | Нет владельца качества | Ownership matrix |
| Data steward | Кто следит за качеством и правилами | Помогает операционно управлять данными | Данные есть, процесса нет | Stewardship model |
| Data quality | Какие критерии полноты и точности | Качество влияет на решения | Ошибки распространяются | Data quality rules |
| Data lineage | Откуда пришли данные и куда ушли | Нужно для анализа ошибок | Нельзя объяснить расхождения | Lineage diagram |
| Data migration | Что переносим, как проверяем, кто принимает | Миграции часто ломают процессы | Потеря или порча данных | Migration plan |
| Data duplication | Где копии допустимы и зачем | Копии должны быть осознанными | Неясно, какая копия актуальна | Duplication register |
| Data synchronization | Как и когда синхронизируются данные | Влияет на консистентность | Запаздывания ломают процесс | Sync rules |
| Eventual consistency | Где допустима задержка согласованности | Позволяет проектировать async flow | Бизнес ждёт мгновенности | Consistency model |
| Audit trail | Какие изменения нужно восстанавливать | Нужно для расследований и compliance | Нельзя доказать, кто изменил данные | Audit view |
| Personal data | Какие данные чувствительные | Требует security и privacy controls | Нарушение регламентов | Data classification |
| Regulatory data | Что регулируется законом или отраслью | Влияет на хранение и доступ | Штрафы и запреты | Compliance map |
| Reporting data | Какие данные идут в отчёты | Отчёты зависят от source of truth | Разные цифры у бизнеса | Reporting data flow |
| Analytical data | Какие данные идут в DWH/BI | Нужны lineage и quality | Аналитика не доверяет источникам | DWH flow |
| Operational data | Какие данные нужны для операций | Влияет на SLA процессов | Операции блокируются | Operational data map |
| Data retention | Сколько храним и зачем | Влияет на cost и compliance | Храним лишнее или удаляем нужное | Retention policy |
| Deletion policy | Как удаляем и где остаются копии | Важно для privacy и compliance | Данные остаются в теневых копиях | Deletion flow |
| Access control | Кто видит и меняет данные | Снижает риск утечек | Слишком широкие права | Access matrix |
Выбор интеграционного подхода зависит от данных, SLA, нагрузки, задержек, владения и эксплуатации. System Architect проектирует не только протокол, но и ответственность, ретраи, версионирование, мониторинг и поддержку.
| Подход / технология | Когда подходит | Плюсы | Риски | Что должен решить архитектор |
|---|---|---|---|---|
| REST API | Синхронные запросы, широкая совместимость | Просто потреблять и документировать | Breaking changes, tight coupling | Контракты, версии, ошибки, владельцы |
| gRPC | Внутренние сервисы, latency, строгие контракты | Производительность, typed contracts | Сложнее для внешних потребителей | Границы применения и совместимость |
| SOAP | Legacy и enterprise-интеграции | Формальные контракты, совместимость с legacy | Тяжёлый формат и tooling | Как изолировать legacy constraints |
| OpenAPI | Описание REST-контрактов | Единый язык для команд | Спецификация расходится с кодом | Lifecycle контракта |
| Event-driven integration | Асинхронные процессы и слабая связность | Автономность систем | Сложнее tracing и consistency | Семантика событий и consumers |
| Apache Kafka | Потоки событий и data streaming | Масштабирование и replay | Нужна зрелая эксплуатация | Topics, ownership, retention, schema |
| RabbitMQ | Очереди задач и routing | Гибкая маршрутизация | Не замена event log | Patterns и support model |
| ESB | Централизованная интеграционная шина | Контроль enterprise-интеграций | Бутылочное горлышко и vendor lock-in | Границы ESB и правила исключений |
| API Gateway | Единая точка API, auth, rate limiting | Контроль внешнего доступа | Слишком много логики в gateway | Какая логика живёт в gateway |
| ETL | Пакетная загрузка и трансформации | Контроль качества и reconciliation | Задержки и ночные окна | Свежесть и контроль ошибок |
| CDC | Изменения данных из источника | Меньше ручных batch-процессов | Сложность схем и ownership | Границы и downstream consumers |
| Batch exchange | Периодический обмен | Простота и предсказуемость | Устаревшие данные | Окна, объёмы, проверки |
| File exchange | Legacy или внешний контур | Простой контракт обмена | Ошибки формата и контроля | Валидация и ownership |
| Webhooks | Уведомления внешним потребителям | Простая реактивность | Повторы, недоставка, security | Retry policy and signatures |
| Message broker | Буферизация задач | Разгрузка систем | Неясная семантика сообщений | Delivery guarantees |
| Integration platform / iPaaS | Готовые коннекторы и orchestration | Скорость внедрения | Стоимость и lock-in | Fit-gap and governance |
| 1С integration | Учётные и ERP-контуры | Близость к бизнес-процессам | Legacy, регламенты, справочники | Master data и окна обмена |
| CRM/ERP integration | Клиенты, продажи, склад, финансы | Единый процесс | Разные owners и модели данных | Границы систем и данные |
| External vendor API | Внешние сервисы и партнёры | Быстрый доступ к функциям | SLA, changes, security, support | Fallback и contract monitoring |
Целевая архитектура без переходного плана опасна. Временные решения нужно ограничивать сроком и владельцем, а миграции данных, интеграций и процессов планировать вместе.
| Сценарий | Что меняется | Главный риск | Какой план нужен | Что фиксировать в артефактах |
|---|---|---|---|---|
| Замена legacy-системы | Функции и интеграции переезжают в новую систему | Остановка критичного процесса | Поэтапный rollout и coexistence | Transition architecture, risk register |
| Миграция данных | Данные переносятся или синхронизируются | Потеря качества и доверия | Mapping, validation, reconciliation | Migration plan, data quality rules |
| Новая интеграционная схема | Меняются API, события или шина | Потребители не готовы | Compatibility plan | Integration roadmap |
| Разделение монолита | Функции уходят в отдельные сервисы | Новые распределённые зависимости | Domain boundaries and rollout | C4 container, ADR |
| Объединение справочников | Несколько справочников сводятся к модели master data | Конфликт владельцев | Ownership and cleansing plan | Source of truth matrix |
| Новая мастер-система | Меняется главный источник данных | Нарушение downstream процессов | Consumer migration plan | Master data ADR |
| Batch на события | Пакетный обмен заменяется event flow | Consistency и tracing | Event model and fallback | Event catalog, NFR |
| On-prem на cloud | Меняется инфраструктурный контур | Compliance, network, cost | Hybrid transition plan | Deployment view, TCO notes |
| Замена ESB | Меняется интеграционная шина | Много скрытых зависимостей | Inventory and phased cutover | Integration inventory |
| API Gateway | Вводится единая точка API | Перенос лишней логики в gateway | Gateway policy and ownership | API governance rules |
| Новая платформа аналитики | Меняется DWH/BI/data platform | Расхождение отчётов | Parallel run and reconciliation | Data flow, lineage |
| Вынос функций в новый сервис | Меняются границы ответственности | Неясный owner | Domain and ownership decision | ADR, ownership matrix |
| Coexistence-архитектура | Старое и новое работают вместе | Временное становится постоянным | Exit criteria | Transition architecture |
| Rollback / fallback plan | Описывается безопасный возврат или деградация | Нет пути назад | Fallback scenarios | Runbook and risk register |
Governance - не бюрократия, если помогает командам быстрее принимать согласованные решения. Стандарты должны иметь механизм исключений, а архитектура без обновления после реализации быстро становится устаревшей картинкой.
| Практика | Зачем нужна | Как выглядит на практике | Типичная ошибка | Метрика качества |
|---|---|---|---|---|
| Architecture review | Проверить изменения до внедрения | Команда приносит ADR, схемы, NFR и риски | Review без критериев | Доля решений с закрытыми рисками |
| Architecture board | Согласовать решения между доменами | Регулярный совет по сложным изменениям | Комитет ради статуса | Время принятия решения |
| Technology radar | Управлять стеком | Adopt/trial/assess/hold | Не обновлять после опыта | Актуальность радара |
| Architecture principles | Дать базовые правила выбора | Короткие принципы с примерами | Слишком общие лозунги | Применимость в ADR |
| Standards | Снизить хаос и дубли | API, data, integration, observability standards | Стандарты без владельца | Доля решений по стандарту |
| Guardrails | Дать командам безопасные рамки | Разрешённые паттерны и limits | Запретить всё нестандартное | Количество решений без escalation |
| Exception process | Разрешать обоснованные исключения | Исключение с причиной, сроком и owner | Исключения навсегда | Доля исключений с review date |
| ADR repository | Сохранять память решений | Единое место для ADR | ADR в личных документах | Найденность решений |
| API governance | Управлять контрактами | Версии, owners, compatibility | API без lifecycle | Breaking changes |
| Data governance | Управлять данными | Owners, quality, lineage, access | Нет владельцев данных | Data quality incidents |
| Integration standards | Унифицировать обмены | Rules для REST, events, queues, batch | Каждая команда изобретает своё | Повторное использование patterns |
| Security review | Встроить безопасность рано | Threats, data classification, IAM | Security на финале | Defects after release |
| Observability standards | Сделать системы поддерживаемыми | Метрики, логи, traces, owners | Алерты без владельцев | MTTR and alert quality |
| Documentation lifecycle | Сохранять актуальность | Review after release and after incidents | Документы не обновляются | Freshness of docs |
| Ownership matrix | Назначить ответственность | Business/tech/support owners | Владельцы не указаны | Unowned systems count |
| Architecture debt backlog | Управлять долгом | Debt item, owner, impact, deadline | Долг без срока | Closed debt items |
| Post-implementation review | Проверить факт после внедрения | Сравнение ADR и реализации | Не возвращаться к решению | Findings closed |
| Нотация / диаграмма | Для чего нужна | Кому полезна | Когда использовать | Когда не нужна |
|---|---|---|---|---|
| C4 Context | Показать систему среди пользователей и соседей | Бизнес, аналитики, архитекторы | Discovery, scope, boundaries | Для деталей классов |
| C4 Container | Показать приложения, БД и связи | Разработка, DevOps, security | Разделение сервисов и хранилищ | Для бизнес-процесса |
| C4 Component | Показать компоненты внутри container | Разработка | Когда важны внутренние границы | Для enterprise-карты |
| Deployment diagram | Показать размещение | DevOps, security, support | Окружения, сети, runtime | Когда инфраструктура вне scope |
| Sequence diagram | Показать порядок взаимодействий | Разработка, QA, integration | Сценарии и ошибки | Для полной карты ландшафта |
| Integration map | Показать системные связи | Архитекторы, support, teams | API, events, batch, external systems | Для детализации алгоритма |
| Data flow diagram | Показать движение данных | Data, analytics, architects | Source, transformation, consumers | Для UI-потоков |
| UML component diagram | Показать компоненты и зависимости | Разработка, архитекторы | Техническое устройство | Для бизнес-аудитории |
| UML sequence diagram | Показать вызовы во времени | Разработка, QA | Сложные сценарии интеграций | Для статичной структуры |
| UML deployment diagram | Показать размещение артефактов | DevOps, architects | Runtime topology | Для бизнес-процесса |
| BPMN | Описать бизнес-процесс | Бизнес, аналитики, внедрение | Роли, события, ручные шаги | Для low-level software design |
| ArchiMate | Связать business/application/technology layers | Enterprise architects | Capability, roadmap, portfolio | Для быстрой delivery-встречи |
| ERD | Показать сущности и связи данных | Data, developers, analysts | Модель данных | Для системных интеграций без данных |
| API contract | Зафиксировать интерфейс | Разработка, QA, consumers | REST/gRPC/SOAP contracts | Для стратегического roadmap |
| Roadmap diagram | Показать этапы перехода | Business, delivery, architects | Migration and transition states | Для деталей API |
| Capability map | Показать бизнес-возможности | Enterprise, product, business | Стратегический scope | Для runtime flow |
| Risk heatmap | Показать архитектурные риски | Leadership, delivery, architects | Приоритизация рисков | Для описания system behavior |
Название вакансии нужно читать по обязанностям. System Architect отвечает за ландшафт систем, интеграции, данные, границы, эксплуатацию и управляемость изменений; смежные роли могут пересекаться, но держат другой фокус.
| Роль | Главный фокус | Чем занимается | Артефакты | Где пересекается | Чем отличается |
|---|---|---|---|---|---|
| System Architect | Системный landscape | Системы, данные, интеграции, NFR, миграции, governance | Landscape map, ADR, migration roadmap | Со всеми архитектурными ролями | Держит межсистемную целостность |
| Software Architect | Внутреннее устройство ПО | Модули, сервисы, code boundaries, technical quality | Component diagrams, technical design | С архитектурой сервисов | Глубже в код и продукт |
| Solution Architect | Решение под бизнес-задачу | Fit-gap, vendor/product choice, внедрение, стоимость | Solution design, estimates | С целевой архитектурой | Чаще привязан к конкретному решению/заказчику |
| Enterprise Architect | Стратегия компании | Capability map, enterprise roadmap, standards, governance | Capability map, principles | С governance | Работает выше уровня отдельных систем |
| Integration Architect | API, события, шины, ETL | Контракты, data flow, integration patterns | Integration map, event catalog | С интеграциями | Глубже в обмены и платформы интеграции |
| Data Architect | Данные и модели | Data models, DWH, lineage, master data, quality | Data model, lineage, MDM design | С source of truth | Глубже в data layer |
| Infrastructure Architect | Compute, network, storage, cloud/on-prem | DR, capacity, virtualization, platform constraints | Deployment view, capacity plan | С эксплуатацией | Глубже в инфраструктурный слой |
| Cloud Architect | Cloud/hybrid architecture | Cloud landing zone, IAM, network, cost, reliability | Cloud design, TCO | С infrastructure и NFR | Глубже в облачные сервисы |
| Security Architect | Защита систем и данных | Threat model, IAM, audit, controls | Security view, threat model | С NFR и compliance | Глубже в безопасность |
| System Analyst | Требования и спецификации | Use cases, API specs, acceptance criteria | Requirements, BPMN, specs | С discovery и API | Не всегда отвечает за trade-offs и целевой landscape |
| Business Analyst | Бизнес-процессы и ценность | Needs, process changes, business rules | BPMN, business requirements | С процессами | Не проектирует системную архитектуру |
| Tech Lead | Реализация команды | Code quality, reviews, delivery, mentoring | Tech design, team standards | С инженерными решениями | Не всегда держит весь межсистемный landscape |
| Product Manager | Ценность продукта | Priorities, metrics, roadmap, users | Product roadmap, metrics | С целями изменений | Не владеет технической архитектурой |
| Delivery Manager | Поставка | Plan, risks, dependencies, status | Delivery plan, risk log | С roadmap и рисками | Не проектирует архитектурное решение |
По данным SkillStat текущий рынок senior-heavy: Senior 96.8%, Lead 3%, Middle —, Junior —. Junior System Architect почти не встречается как самостоятельная рыночная позиция; чаще это рост из системного анализа, разработки, интеграций, инфраструктуры или DevOps.
| Уровень | Роль | Типичные задачи | Навыки | Артефакты | Портфолио | Куда расти |
|---|---|---|---|---|---|---|
| Intern / Trainee | Помогает собирать контекст | Inventory систем, простые схемы, протоколы встреч | Документация, API basics, SQL basics | Notes, simple diagrams | Учебный landscape без NDA | Junior / System Analyst |
| Junior System Architect | Работает под контролем старшего архитектора | Помощь со схемами, integration inventory, open questions | C4, UML basics, API, SQL, NFR basics | Context diagram, assumptions log | Landscape map и integration map | Middle |
| Middle System Architect | Отвечает за часть landscape | Подсистема, integration flow, migration, domain area | Integration, data ownership, NFR, ADR | ADR, source of truth matrix, NFR checklist | Case по подсистеме | Senior |
| Senior System Architect | Проектирует решения для нескольких систем | Architecture review, trade-offs, migration roadmap, stakeholder alignment | Governance, security, operations, legacy | Full architecture pack | Обезличенный case с последствиями | Lead / Principal |
| Lead System Architect | Формирует целевой landscape и стандарты | Architecture governance, roadmap, review process, mentoring | Leadership, enterprise context, standards | Principles, technology radar, standards | Portfolio decisions | Enterprise / Principal |
| Principal / Enterprise Architect | Влияет на портфель систем и стратегию | Enterprise roadmap, capability map, platform decisions | Enterprise governance, portfolio thinking | Capability map, target architecture | Стратегический case без чувствительных данных | Head of Architecture / CTO-track |
системы, владельцы, данные и границы
NFR, варианты, компромиссы и ADR
миграции, ревью и правила изменений
Типовой поток работы системного архитектора начинается с карты ландшафта и заканчивается не схемой, а согласованными правилами изменений.
Системный архитектор начинает с того, что описывает существующие системы, границы, владельцев, интеграции, данные и ограничения. Это нужно, чтобы не проектировать "в вакууме" и не предлагать решение, которое красиво выглядит на схеме, но не выдерживает реального контекста.
Архитектурный риск часто появляется не из-за технологии, а из-за того, что никто не отвечает за данные, API, регламент или поддержку. Архитектор фиксирует, кто принимает решения, кто поддерживает систему и кто согласует изменения.
Он выясняет, какая система является source of truth, где появляются копии, как синхронизируются данные и где возможны расхождения. Без этого невозможно безопасно проектировать отчетность, миграции, интеграции и мастер-данные.
Функциональные требования отвечают, что должна делать система; NFR отвечают, как хорошо она должна это делать. Availability, performance, security, observability, data consistency и operational readiness нельзя оставлять на конец проекта.
Он описывает, какие системы остаются, какие меняются, какие интеграции появляются, где должны жить данные и как будет выглядеть целевой ландшафт. Целевая архитектура должна учитывать реальные команды, сроки, legacy, стоимость владения и эксплуатацию.
Архитектор не обещает максимум скорости, надежности, безопасности и дешевизны одновременно. Он показывает варианты, объясняет, чем приходится жертвовать, и фиксирует выбранный компромисс.
Решение должно быть не только реализуемым, но и поддерживаемым. Системный архитектор согласует ограничения с безопасностью, инфраструктурой, эксплуатацией и командами разработки.
Большие системы редко меняются одним релизом. Архитектор описывает transition architecture: промежуточные состояния, coexistence, миграцию данных, переключение интеграций, fallback и ограничения временных решений.
Документация нужна не для архива, а чтобы команды понимали контекст, решение, последствия и rejected options. Если решение нельзя объяснить и найти через месяц, оно плохо управляется.
Системный архитектор переводит один и тот же компромисс на разные языки: бизнесу - через риски и эффект, разработке - через границы, эксплуатации - через поддержку, безопасности - через контроль.
Архитектура не заканчивается после согласования схемы. Архитектор проверяет, что реализация не ушла от ключевых ограничений, а новые факты попали обратно в решение.
Если в ходе внедрения изменились данные, нагрузка, регламенты или возможности команды, архитектурное решение нужно пересмотреть. Хорошая архитектура живет вместе с системой, а не замораживается в презентации.
Название вакансии может быть широким. Смотрите, есть ли ответственность за ландшафт, интеграции, данные, владельцев, миграции, NFR, архитектурные правила, ревью и сопровождение изменений.
Если вакансия в основном про код, модули и сервисы одного продукта, это ближе к Software Architect.
Если роль про требования, спецификации и процессы без архитектурных trade-offs, это ближе к System Analyst.
Если основной фокус - реализация одной команды и code review, это может быть Tech Lead.
Если есть несколько систем, source of truth, integration map, NFR, ADR и migration roadmap, это ближе к настоящей System Architect-роли.
Вакансии с архитектурными названиями нужно читать по зоне ответственности. System Architect отвечает за системный ландшафт, интеграции, данные, границы, эксплуатацию и управляемость изменений.
| Роль | Главный фокус | Чем занимается | Какие артефакты делает | С кем чаще общается | Где пересекается с System Architect | Чем отличается | Когда нужна компании |
|---|---|---|---|---|---|---|---|
| System Architect | Ландшафт систем, данные, интеграции, эксплуатация | Управляет устройством и изменениями нескольких систем | Landscape map, integration map, ADR, NFR, migration roadmap | Бизнес, разработка, data, ops, security | Базовая роль сравнения | Держит межсистемные последствия | Когда много систем и цена ошибки высока |
| Software Architect | Внутреннее устройство продукта | Проектирует модули, сервисы, code boundaries | Component diagrams, API, tech decisions | Разработка, tech leads | Сервисы, API, NFR | Глубже в код и продукт | Когда продукт сложен технически |
| Solution Architect | Решение под бизнес-задачу | Собирает реализуемое решение, внедрение, vendor/product выбор | Solution design, estimates, integration view | Заказчик, delivery, presale | Интеграции, NFR, ограничения | Больше customer-facing и delivery scope | Когда нужно внедрить конкретное решение |
| Enterprise Architect | Стратегия и портфель | Управляет capability map, roadmap, standards | Capability map, enterprise roadmap, principles | Топ-менеджмент, домены | Governance и стандарты | Выше уровень абстракции | Когда нужен контроль портфеля систем |
| Integration Architect | Интеграции | Проектирует API, события, шины, ETL, data flow | Integration map, event catalog, API standards | Integration teams, vendors | Интеграции и контракты | Глубже в обмены | Когда много сложных связей |
| Data Architect | Данные | Модели, DWH, master data, lineage, quality | Data model, lineage, MDM map | Data teams, BI, business owners | Source of truth, ownership | Глубже в модели и качество данных | Когда данные критичны |
| Infrastructure Architect | Инфраструктура | Compute, network, storage, virtualization, DR | Deployment view, capacity plan, DR design | DevOps, ops, security | Deployment и DR | Глубже в инфраструктуру | Когда важны платформы и мощности |
| Cloud Architect | Cloud/hybrid | Проектирует cloud services, landing zones, cost, security | Cloud architecture, migration plan | Cloud teams, security, finance | Cloud constraints, migration | Глубже в cloud provider | При cloud/hybrid трансформации |
| Security Architect | Безопасность | Threat model, IAM, controls, compliance | Security view, threat model | Security, compliance, ops | Security NFR | Глубже в риски ИБ | При строгих требованиях безопасности |
| System Analyst | Требования и спецификации | Формализует требования, сценарии, API, процессы | Requirements, specs, BPMN, use cases | Бизнес, разработка, QA | Требования и процессы | Не всегда отвечает за architecture trade-offs | Когда нужно уточнить, что строить |
| Business Analyst | Бизнес-потребности | Описывает цели, процессы, value, constraints | Business requirements, process maps | Бизнес, product | Бизнес-контекст | Меньше технических решений | Когда нужно понять задачу бизнеса |
| Tech Lead | Реализация команды | Ведет разработку, качество кода, delivery | Tech design, code standards | Команда разработки | Технические решения и качество | Не всегда держит весь ландшафт | Когда нужна инженерная лидерская роль |
| Product Manager | Продуктовая ценность | Приоритизирует фичи и метрики | Roadmap, backlog, product requirements | Бизнес, пользователи, команда | Ограничения и roadmap | Фокус на value, не на архитектуре | Когда нужен продуктовый курс |
| Delivery Manager | Поставка | Управляет сроками, рисками, зависимостями | Delivery plan, risks, status | Команды, заказчик | Риски и зависимости | Не проектирует архитектуру | Когда важна управляемая поставка |
Обе роли работают с архитектурой, но смотрят на разные уровни системы.
Ландшафт систем, данные, интеграции, владельцы, NFR, миграции и эксплуатация.
Внутреннее устройство программного продукта, модули, сервисы, кодовые границы и техническое качество.
Изменение ломает несколько систем, данные, отчетность, регламенты или поддержку.
Решение ухудшает продукт, кодовую базу, производительность или скорость разработки.
Landscape map, integration map, source of truth matrix, NFR, ADR, migration roadmap, standards.
Component diagrams, API design, module boundaries, technical design, code standards.
Организация может менять большой ИТ-ландшафт без хаоса.
Команда развивает продукт поддерживаемо и технически качественно.
Работодатели ждут не только знания нотаций и инструментов, а способность мыслить ландшафтом. В требованиях часто встречаются инфраструктурные, интеграционные и data-навыки: CI/CD, Microservices, PostgreSQL, Linux, Apache Kafka, Kubernetes, REST API, SQL, Git, 1С, ETL, gRPC, ClickHouse, Docker, UML и VMware. Точные доли лучше читать в live-блоке навыков на странице.
На практике проверяют, может ли кандидат объяснить, как изменение в одной системе повлияет на данные, отчетность, безопасность, эксплуатацию, соседние команды и миграционный план. Если специалист видит только один сервис, он может быть сильным инженером, но не закрывать системную архитектуру.
Рынок ориентирован на опытных специалистов.
Столько требований работодатели обычно собирают в одной позиции по этой роли.
Вакансии SkillStat показывают широкий профиль: CI/CD, Microservices, PostgreSQL, Linux, Apache Kafka, Kubernetes, REST API, SQL, Git, 1С, ETL, gRPC, UML, VMware и управление командой. Точные доли меняются вместе со свежим срезом, поэтому их лучше читать в live-блоке навыков.
| Группа | Что входит | Зачем нужно | Как показать |
|---|---|---|---|
| Architecture skills | System design, system landscape, integration architecture, data architecture basics, infrastructure basics, security basics, NFR, trade-offs, ADR, governance, documentation, transition architecture, migration planning | Удерживать целостность большого ландшафта | Architecture pack, ADR, roadmap |
| Integration & data | REST API, OpenAPI, gRPC, SOAP, Kafka, RabbitMQ, ESB, API Gateway, ETL, SQL, PostgreSQL, Oracle, ClickHouse, Redis, source of truth, master data, ownership, migration, data quality | Системы связаны через данные и обмены | Integration map, data flow, source of truth matrix |
| Infrastructure & operations | Linux, Kubernetes, Docker, CI/CD, Git, VMware, observability, logging, monitoring, DR, backup, HA, capacity planning, cloud/on-prem/hybrid basics | Решение должно быть внедряемым и поддерживаемым | Deployment view, operational readiness checklist |
| Modeling & documentation | C4, UML, BPMN, ArchiMate, sequence diagrams, deployment diagrams, data flow diagrams, ERD, ADR, Confluence, Jira, architecture repository, technology radar | Команды должны одинаково понимать решение | Схемы, decision log, repository |
| Communication & leadership | Stakeholder management, facilitation, negotiation, documentation, presentation, expectation management, ability to say no, conflict resolution, influence without authority, technical debt explanation | Архитектура внедряется людьми | Review notes, ADR, stakeholder map |
| По уровням | Junior - схемы и inventory; Middle - подсистема и интеграции; Senior - несколько систем и review; Lead - стандарты и governance; Enterprise/Principal - портфель систем | Навыки растут вместе с масштабом ответственности | Портфолио по уровню |
Инструменты не должны превращаться в production-инструкцию. Для System Architect важнее понимать, какой архитектурный вопрос решает C4, UML, OpenAPI, Kafka, Kubernetes или technology radar.
| Инструмент / класс | Для чего нужен | На каком уровне нужен | Как описать в резюме | Что важно понимать |
|---|---|---|---|---|
| C4 Model | Context/container/component views | Junior+ | Описывал system landscape через C4 | C4 не заменяет NFR и ADR |
| UML | Sequence, component, deployment diagrams | Middle+ | Фиксировал взаимодействия и зависимости | Выбирать диаграмму под вопрос |
| BPMN | Бизнес-процессы | Middle+ | Связывал процессы с системными изменениями | BPMN не описывает runtime architecture |
| ArchiMate | Enterprise layers | Senior+ | Работал с business/application/technology layers | Нужен для enterprise context |
| Draw.io / diagrams.net / Miro / Lucidchart / Visio | Визуализация схем | Junior+ | Готовил architecture diagrams | Схема должна иметь владельца и дату |
| PlantUML / Structurizr | Diagrams as code | Middle+ | Вёл схемы рядом с документацией | Нужна дисциплина обновления |
| Archi / Enterprise Architect | Enterprise modeling | Senior+ | Вёл enterprise/architecture models | Инструмент не заменяет governance |
| Confluence / Jira | Architecture repository and delivery tracking | Junior+ | Связывал ADR с roadmap и задачами | Документы должны обновляться после релиза |
| ADR templates | Фиксация решений | Junior+ | Вёл ADR с context, decision, consequences | Rejected options обязательны |
| OpenAPI / Swagger / Postman | API contracts and validation | Middle+ | Согласовывал API-контракты | Спецификация должна жить вместе с API |
| SQL / PostgreSQL / Oracle / ClickHouse | Данные и проверки | Middle+ | Учитывал source of truth и migration constraints | Архитектору важны ownership и качество |
| Kafka / RabbitMQ / API Gateway / ESB | Интеграции | Middle+ | Проектировал integration patterns | Нужно понимать эксплуатацию и ownership |
| Kubernetes / Docker / CI/CD / GitLab / Git / Linux | Deployment and delivery constraints | Middle+ | Учитывал platform constraints в architecture review | Не превращать роль в администрирование |
| VMware / cloud / hybrid tooling | Инфраструктурный контекст | Middle+ | Сравнивал on-prem/cloud constraints | Учитывать DR, capacity, compliance |
| Observability tools | Мониторинг, логи, трассировки | Middle+ | Закладывал operational readiness | Алерты должны иметь owners |
| Architecture repository | Единое место архитектуры | Senior+ | Поддерживал repository и decision log | Без lifecycle быстро устаревает |
| Technology radar | Управление стеком | Lead+ | Вёл radar и exception process | Нужен механизм пересмотра |
| Risk register / ownership matrix / roadmap tools | Управление рисками, владельцами и переходом | Middle+ | Фиксировал risks, owners, migration steps | Не хранить риски только во встречах |
Зарплатную оценку SkillStat нужно читать как ориентир по региону и дате среза, а не как гарантированную медиану для каждого системного архитектора. На 23.06.2026 для Москвы и МО оценка составляет 320 000 ₽, n=3, источник — Оценка по профессии и близкому рынку.
| Фактор | Почему повышает доход | Как подтвердить |
|---|---|---|
| Масштаб ИТ-ландшафта | Больше систем и зависимостей - выше цена ошибки | Кейс с несколькими системами |
| Количество систем и команд | Нужно согласовывать решения между владельцами | Stakeholder map and review notes |
| Интеграционная сложность | REST, gRPC, Kafka, RabbitMQ, ESB, ETL требуют trade-offs | Integration map and ADR |
| Data ownership и master data | Ошибки данных распространяются по landscape | Source of truth matrix |
| Миграции legacy | Переходные состояния сложнее финальной схемы | Migration roadmap |
| High availability и DR | Доступность и восстановление влияют на business impact | NFR and DR view |
| Security and compliance | Регуляторные требования меняют архитектуру | Security view and compliance notes |
| Architecture governance | Стандарты снижают системный долг | Review checklist and technology radar |
| ADR и архитектурные артефакты | Решения можно объяснить и поддерживать | Architecture pack |
| Transition architecture | Целевая схема становится внедряемой | Transition states and fallback |
| Опыт в банках, телекоме, ритейле, интеграторах и платформах | Там больше систем, регламентов и рисков | Обезличенные enterprise cases |
| Умение снижать системный долг | Архитектура влияет на долгосрочную скорость изменений | Debt backlog and resolved decisions |
| Коммуникация между бизнесом, разработкой, эксплуатацией и безопасностью | Решение должно быть принято и внедрено | ADR, workshop notes, approvals |
По SkillStat на 23.06.2026 в Москве и МО: 31 активных вакансий, спрос 13/100, ранг #42 из 71, статус низкий. 7 дней назад было 49, 30 дней назад - 64; средний тренд смотрите в live-графике ниже.
| Показатель | Значение | Как читать |
|---|---|---|
| Активные вакансии | 31 | Роль нишевая, не массовая junior-профессия |
| Спрос | 13/100, #42 из 71, низкий | Ниже массовых ролей разработки |
| Динамика | 7 дней назад 49, 30 дней назад 64 | Срез нужно перепроверять при обновлении данных |
| Средние вакансии по месяцам | См. live-график спроса | Июнь нельзя сравнивать как полный месяц |
| Формат работы | Удалённо 3%, гибрид 77%, офис 19% | Гибрид связан с большим числом встреч и согласований |
| Навыков на вакансию | В среднем 8 | Работодатели ждут широкий профиль |
| Уровни | Senior 96.8%, Lead 3%, Middle —, Junior — | Рынок ориентирован на опытных специалистов |
| Почему часть спроса скрыта | Вакансии могут называться архитектор ИТ-систем, архитектор информационных систем, архитектор решений, корпоративный архитектор, integration architect, infrastructure architect | Нужно читать обязанности, а не только title |
| Как отличить настоящую System Architect-вакансию | Искать ответственность за landscape, интеграции, данные, владельцев, NFR, миграции, architecture review | Если фокус только код, требования или team delivery - это может быть другая роль |
| Работодатели | См. live-блок работодателей на странице | Данные активного среза, не постоянный рейтинг |
Эти роли чаще всего пересекаются с системной архитектурой по навыкам, задачам или траектории перехода.
Для estimated-режима грейдовые зарплаты не показываются, чтобы не создавать ложную точность.
Оценка не равна зарплате каждого грейда: текущий рынок senior-heavy, а начинающие позиции почти не представлены. На доход сильнее всего влияют масштаб IT-ландшафта, количество систем и команд, интеграционная сложность, data ownership, legacy-миграции, NFR, security, compliance, architecture governance и способность снижать системный долг.
Спрос на системного архитектора лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.
По срезу SkillStat на 23.06.2026 в Москве и МО по профессии System Architect найдено 31 активных вакансий. спрос — 13/100, ранг #42 из 71, статус — низкий. Это нишевая роль: часть спроса скрыта под названиями архитектор IT-систем, архитектор информационных систем, архитектор ПО, Solution Architect, enterprise architect и infrastructure architect.
Настоящую вакансию System Architect отличает ответственность за ландшафт, подсистемы, интерфейсы, данные, владельцев, миграции, NFR, архитектурные правила, ревью и сопровождение изменений. Если роль сводится к поддержке серверов или рисованию схем после уже принятых решений, это слабый сигнал для системной архитектуры.
Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.
Грейдовые медианы не показаны: для системного архитектора сейчас используется estimated-режим зарплаты, поэтому SkillStat не выводит отдельные зарплаты по уровням, чтобы не создавать ложную точность.
Junior System Architect почти не встречается как самостоятельная рыночная позиция. Чаще это внутренний рост из анализа, разработки, интеграций или инфраструктуры под контролем старшего архитектора.
Middle отвечает за подсистему, интеграционный поток, доменную область, миграцию или часть ландшафта. Важно уверенно работать с NFR, ADR, source of truth и integration map.
Senior проектирует решения для нескольких систем, проводит архитектурные ревью и отвечает за последствия изменений для данных, интеграций, эксплуатации и безопасности.
Lead формирует целевой ландшафт, архитектурные стандарты, дорожные карты, правила управления архитектурой и помогает организации не копить системный долг.
Много критичных процессов, интеграций, регуляторных ограничений, master data и legacy. Цена ошибки обычно высока.
Сложный ландшафт, биллинг, provisioning, интеграции, отказоустойчивость и эксплуатационные ограничения.
Роль часто связана с Solution Architecture, migration roadmap, vendor constraints, API, ESB, 1С/SAP/CRM/ERP и согласованием сторон.
Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.
Понять роль System Architect; повторить основы системного анализа; разобраться в API, HTTP, REST, SOAP; изучить SQL и базовые модели данных; освоить requirements, diagrams, decisions; научиться описывать текущий системный ландшафт Проверка результата: Простая landscape map учебной системы, список владельцев, API и открытых вопросов
Интеграции: API, события, очереди, ETL; данные: source of truth, ownership, миграции, качество; нотации C4, UML, BPMN; базовые NFR: performance, security, availability, scalability, observability; OpenAPI и integration map Проверка результата: C4 context/container, integration map, первый OpenAPI-фрагмент, NFR checklist
Kubernetes/Docker на концептуальном уровне; CI/CD и deployment flow; Linux и инфраструктурная база; security and IAM basics; monitoring and logging; ADR и rejected options; risk register и assumptions log Проверка результата: 2-3 ADR, trade-off table, risk register для учебного кейса
Architecture governance; technology radar; standards and exceptions; stakeholder management; legacy; портфолио; интервью; смежные роли: senior system analyst, software architect, integration architect, infrastructure architect, solution architect Проверка результата: Портфолио из 5-7 обезличенных артефактов
Enterprise context; ArchiMate / TOGAF basics, если нужно; advanced integration patterns; data architecture; cloud/hybrid architecture; leadership and mentoring; переход в Senior/Lead System Architect Проверка результата: Кейсы с несколькими системами, governance и transition architecture
Безопасный портфель можно собрать на учебном ландшафте банка, ритейла или B2B-платформы. Реальные рабочие артефакты нужно очищать от NDA, персональных данных, коммерческих тайн и чувствительной информации.
Опишите текущий ландшафт: системы, владельцы, данные, интеграции, регламенты и ограничения.
Зафиксируйте NFR, ADR, rejected options, assumptions, risk register и migration roadmap.
Соберите architecture pack для delivery-команды: что меняется, кто владеет, как проверять качество и где нужны ревью.
Переход обычно строится через роль, где уже видны живые системы, ограничения и последствия изменений. Ошибка - пытаться выглядеть архитектором только через нотации без реальных trade-offs.
| Откуда | Что уже полезно | Чего не хватает | Что учить в первую очередь | На какие вакансии смотреть | Портфолио | Ошибка |
|---|---|---|---|---|---|---|
| Системный анализ | Требования, процессы, API, спецификации | NFR, trade-offs, infrastructure, ownership | NFR, ADR, landscape, source of truth | Senior System Analyst, Junior/Middle Architect-adjacent | Landscape + ADR к своим требованиям | Оставаться только в спецификациях |
| Backend-разработка | API, БД, сервисы, code ownership | Landscape, governance, stakeholder work | C4, integration, NFR, data ownership | Software Architect, Backend Lead, System Architect с кодовой базой | Integration map and migration case | Смотреть только на код |
| Java/Python/Go/Node.js-разработка | Backend stack, сервисы, интеграции | Enterprise constraints and governance | System design, data, operations | Senior developer with architecture tasks | ADR and service boundaries | Путать архитектуру с фреймворком |
| DevOps / cloud engineering | CI/CD, Kubernetes, Linux, observability, DR | Business process, data ownership, API | Landscape, source of truth, NFR business impact | Platform Architect, Cloud Architect, System Architect hybrid | Deployment view + NFR | Свести System Architect к платформе |
| Data engineering | ETL, SQL, DWH, data quality | Системные границы, бизнес-процессы, integration governance | Source of truth, master data, integration patterns | Data Architect, System Architect data-heavy | Data flow + source of truth matrix | Видеть только data layer |
| Integration engineering | API, ESB, Kafka, RabbitMQ, external systems | Target landscape, NFR, governance | ADR, architecture review, data ownership | Integration Architect, System Architect integration-heavy | Integration map + trade-off table | Проектировать связи без owners |
| Инфраструктура / администрирование | Эксплуатация, сети, Linux, enterprise systems | Требования, данные, business context | C4, API, NFR, ADR | Infrastructure Architect, System Architect infra-heavy | Operational readiness case | Остаться в поддержке |
| Нагрузочное тестирование | Performance, capacity, bottlenecks | Данные, интеграции, governance | NFR catalog, system design, migration planning | Performance Architect, System Architect with NFR focus | NFR checklist + risk register | Видеть только нагрузку |
| CRM/ERP/1С/SAP внедрение | Бизнес-процессы, справочники, integrations | Общая системная архитектура, cloud/infra basics | Source of truth, migration, API, ADR | Solution Architect, System Architect enterprise | CRM/ERP integration map | Ограничиться настройкой продукта |
| Technical presales / Solution Architecture | Сбор решения, стоимость, заказчик, vendor fit | Глубина operating model and governance | Landscape, NFR, data ownership, transition architecture | Solution Architect -> System Architect | Architecture pack for implementation | Продавать схему без внедряемости |
Реальные артефакты нужно обезличить: убрать NDA-данные, персональные данные, внутренние URL, коммерческие цифры и чувствительные детали инфраструктуры. Учебные кейсы должны быть безопасными и правдоподобными.
| Кейс | Что показать | Инструменты | Результат | Как описать в резюме | Ошибку новичка закрывает | Как обезличить |
|---|---|---|---|---|---|---|
| Карта ИТ-ландшафта учебного банка/ритейла | Системы, owners, данные, интеграции, регламенты | C4, diagrams.net, Miro | Понятный landscape | Описал landscape и зоны ответственности | Начинать с технологии | Заменить названия систем и цифры |
| C4 context/container для B2B-платформы | Пользователи, внешние системы, containers | C4, Structurizr, PlantUML | Границы системы | Собрал C4 views | Смешивать уровни | Удалить реальные домены |
| Integration map для CRM, ERP, склада и витрины | API, события, batch, owners | OpenAPI, diagrams.net | Карта обменов | Описал интеграционные зависимости | Рисовать стрелки без контрактов | Обобщить бизнес-процесс |
| Source of truth matrix для клиентских данных | Сущности, атрибуты, owners | Table, wiki | Понятный owner данных | Определил source of truth | Копировать справочники без правил | Заменить поля на учебные |
| ADR по REST, gRPC и событиям | Контекст, варианты, выбор, последствия | ADR template | Прозрачный trade-off | Фиксировал ADR и rejected options | Показывать только финальный ответ | Убрать vendor names |
| ADR по Kafka/RabbitMQ/REST | Сценарий интеграции и эксплуатация | ADR, trade-off table | Обоснованный выбор | Сравнил integration patterns | Выбирать по модности | Оставить только типовой контекст |
| Migration roadmap для legacy | Этапы, coexistence, fallback, owners | Roadmap, risk register | Переходная архитектура | Спланировал migration roadmap | Рисовать только целевую схему | Убрать реальные сроки и системы |
| Data flow diagram для отчётности | Sources, transformations, consumers | DFD, lineage table | Путь данных понятен | Описал data flow and quality risks | Не показывать lineage | Заменить отчёты и метрики |
| NFR checklist для критичной системы | Availability, security, performance, supportability | Checklist | Проверяемые NFR | Перевёл NFR в критерии | Писать "быстро и надёжно" | Без реальных SLO |
| Risk register для миграции данных | Риски, owner, mitigation, status | Risk register | Управляемые риски | Вёл risk register | Оставлять риски в чате | Заменить impact на категории |
| Transition architecture для поэтапного перехода | Текущее, промежуточное, целевое состояние | C4, roadmap | Внедряемый переход | Описал transition states | Игнорировать coexistence | Сделать учебный пример |
| Architecture governance checklist | Review criteria, standards, exceptions | Wiki/Jira | Повторяемый review | Подготовил architecture review checklist | Review без критериев | Удалить внутренние процессы |
| Technology radar для небольшого ландшафта | Adopt, trial, assess, hold | Radar, wiki | Управление стеком | Сформировал technology radar | Список технологий без правил | Оставить категории без компаний |
| Rejected options document | Почему варианты не выбраны | ADR appendix | История решения | Фиксировал rejected options | Потерять контекст решения | Обезличить ограничения |
| Architecture pack для delivery-команды | Схемы, ADR, NFR, risks, open questions | Wiki, diagrams, Jira | Команда понимает внедрение | Собрал architecture pack | Передать одну картинку | Удалить коммерческие детали |
Интервью проверяет не знание модных терминов, а способность объяснить границы, последствия и компромиссы. Опасные production-команды здесь не нужны: готовиться лучше через безопасные кейсы и артефакты.
| Тема | Пример вопроса | Что проверяет интервьюер | Как отвечать | Что добавить в портфолио |
|---|---|---|---|---|
| System landscape | Как описать текущий ИТ-ландшафт? | Системное мышление | Начать с систем, owners, данных, интеграций и NFR | System landscape map |
| C4 | Когда нужен context, а когда container? | Понимание уровней | Объяснить аудиторию и вопрос диаграммы | C4 context/container |
| UML | Где использовать sequence diagram? | Детализация взаимодействий | Показать сценарий и ошибки | Sequence diagram |
| BPMN | Как процесс влияет на архитектуру? | Связь бизнеса и систем | Показать роли, события, ручные шаги | BPMN + system map |
| ArchiMate | Зачем ArchiMate в enterprise? | Enterprise context | Связать business/application/technology layers | Small capability map |
| ADR | Что должно быть в ADR? | Память решений | Контекст, варианты, выбор, последствия, rejected options | ADR examples |
| NFR | Как собрать NFR? | Quality attributes | Дать измеримые критерии и владельцев | NFR checklist |
| REST API | Как проектировать контракт? | API governance | Версии, ошибки, compatibility, owners | OpenAPI draft |
| gRPC | Когда он лучше REST? | Protocol trade-offs | Latency, typed contracts, consumers | REST vs gRPC ADR |
| SOAP | Когда legacy диктует SOAP? | Работа с legacy | Изолировать constraints и compatibility | Legacy integration note |
| Kafka vs RabbitMQ | Что выбрать для интеграции? | Integration thinking | Отталкиваться от семантики обмена и эксплуатации | Trade-off table |
| ETL | Когда batch лучше событий? | Data flow | Freshness, quality, reconciliation | ETL data flow |
| API Gateway | Что можно класть в gateway? | Boundaries | Auth/routing/rate limits, без бизнес-логики | Gateway policy |
| SQL / PostgreSQL | Что важно архитектору в БД? | Data ownership | Source of truth, consistency, migration | Data model notes |
| Source of truth | Что делать при двух источниках клиента? | Data governance | Разобрать атрибуты и владельцев | Source of truth matrix |
| Master data | Кто владеет справочником? | MDM basics | Показать owner, steward, sync rules | Master data catalog |
| Data migration | Как проверить перенос? | Migration safety | Mapping, validation, reconciliation, acceptance | Migration plan |
| Data consistency | Где допустима eventual consistency? | Trade-off thinking | Связать с процессом и SLA | Consistency ADR |
| Kubernetes/Docker концептуально | Что должен понимать System Architect? | Operational awareness | Deployment constraints, not commands | Deployment view |
| CI/CD | Как delivery влияет на архитектуру? | Release thinking | Окружения, compatibility, rollback/fallback | Deployment flow |
| Linux | Зачем знать основы Linux? | Infrastructure literacy | Понимать эксплуатационные ограничения | Operational constraints |
| Observability | Что заложить до релиза? | Supportability | Метрики, логи, traces, owners | Observability view |
| Security | Когда подключать security? | Secure architecture | Рано, через data classification и threat context | Security view |
| High availability | Как понять нужный уровень HA? | Business impact | Цена простоя, SLO, support model | NFR catalog |
| Disaster recovery | Что такое RTO/RPO? | DR readiness | Связать с данными и бизнесом | DR notes |
| Transition architecture | Как заменить legacy без остановки? | Migration maturity | Coexistence, states, fallback, owners | Migration roadmap |
| Architecture governance | Как не сделать бюрократию? | Pragmatic governance | Standards, guardrails, exceptions | Review checklist |
| Legacy modernization | Когда не надо переписывать legacy? | Cost/risk thinking | Сравнить replace, wrap, refactor | Legacy ADR |
| System Architect vs Software Architect | В чём отличие? | Role boundaries | Landscape vs internal software structure | Role comparison note |
| System Architect vs Solution Architect | В чём отличие? | Role boundaries | Landscape vs solution under business task | Comparison note |
| System Architect vs System Analyst | В чём отличие? | Role boundaries | Requirements vs target architecture and trade-offs | Comparison note |
| Case: замена legacy-системы | Как построите план? | End-to-end architecture | Inventory, risks, migration, owners, rollout | Transition architecture |
| Case: интеграция CRM/ERP/1С | Как найдёте риски? | Enterprise integrations | Справочники, owners, API/batch, регламенты | Integration map |
| Case: дублирование справочников | Что делать? | Data ownership | Source of truth, quality, migration | Source of truth matrix |
| Case: миграция данных | Как принять результат? | Data migration | Validation, reconciliation, business acceptance | Migration checklist |
Курс-блок не должен создавать ощущение, что любой курс по архитектуре ПО равен System Architect. Прямой System Architecture-трек - основной, если он есть; Software Architect, System Analyst, Solution Architect, Cloud, DevOps, TOGAF и нотации - смежные треки. CTA: Сравнить курсы системного архитектора по навыкам из вакансий.
| Трек | Для кого | System Architecture-релевантность | Что должно быть в программе | Что проверить по SkillStat | Комментарий SkillStat |
|---|---|---|---|---|---|
| Прямой System Architecture-трек | Специалисты с опытом IT | Высокая | Landscape, artifacts, NFR, ADR, migrations, governance | Связь с CI/CD, Microservices, PostgreSQL, Linux, Kafka, Kubernetes, REST API, SQL | Основной трек, если курс действительно про системную архитектуру |
| Software architecture | Senior developers, Tech Leads | Смежная высокая | Service boundaries, modularity, API, quality, code-level architecture | Microservices, REST API, Java, Docker, Git | Фундамент, но не вся роль System Architect |
| System analysis | Аналитики и начинающие архитекторы | Смежная высокая | Requirements, BPMN, UML, API specs, acceptance criteria | UML, REST API, SQL, Confluence/Jira | Хорошая база требований и процессов |
| Integration architecture | Интеграторы, backend, analysts | Высокая | API, Kafka, RabbitMQ, ETL, ESB, API Gateway, OpenAPI | Kafka 18%, REST API 16%, ETL 10%, gRPC 8% | Критичный трек для System Architect |
| Data architecture | Data engineers, analysts, architects | Высокая | Source of truth, master data, DWH, migration, data quality, lineage | SQL 16%, PostgreSQL 20%, ClickHouse 8% | Закрывает data ownership и migration risks |
| Cloud / infrastructure architecture | DevOps, cloud, infra | Смежная высокая | Kubernetes, Docker, CI/CD, Linux, cloud/on-prem, DR, observability | CI/CD, Linux, Kubernetes, Docker, VMware | Не заменяет System Architect без данных, интеграций и governance |
| Enterprise architecture | Senior/Lead architects | Смежная для Senior+ | TOGAF, ArchiMate, capability map, governance, technology radar | Связь с architecture governance | Полезно на Lead/Enterprise уровне |
| Documentation and modeling | Все треки | Поддерживающая | C4, UML, BPMN, ADR, arc42, sequence, deployment, data flow | UML 8%, C4/BPMN/ArchiMate как сущности роли | Нотации важны, но не заменяют опыт решений |
Сертификат полезен как структура обучения, но не заменяет опыт реальных систем. Cloud-сертификат не делает человека полноценным System Architect без понимания landscape, данных, интеграций, NFR, миграций и governance.
| Направление | Что подходит | Кому полезно | Почему не заменяет опыт | Что показать в резюме |
|---|---|---|---|---|
| TOGAF | Enterprise architecture framework | Middle/Senior/Lead | Не описывает ваши реальные системы за вас | Как применяли principles, governance, roadmap |
| ArchiMate | Язык enterprise-моделирования | Senior/Lead, enterprise контекст | Нотация без решений не даёт архитектуры | Capability/application/technology views |
| C4 Model resources | Материалы по context/container/component/code | Junior+ и разработчики | C4 не фиксирует trade-offs сам по себе | C4 diagrams в architecture pack |
| arc42 | Шаблон архитектурной документации | Middle+ | Шаблон нужно наполнить реальным контекстом | Architecture documentation example |
| AWS Solutions Architect Associate / Professional | Cloud architecture | Cloud-adjacent path | Cloud focus не равен System Architect | Cloud option comparison and NFR |
| Microsoft Azure Solutions Architect Expert | Azure architecture | Cloud/hybrid path | Нужны данные, интеграции и governance | Hybrid architecture case |
| Google Professional Cloud Architect | GCP architecture | Cloud/data path | Не заменяет enterprise landscape | Cloud migration option |
| Kubernetes certifications | KCNA/CKA как смежный фундамент | DevOps/infrastructure path | Kubernetes - только часть platform context | Deployment constraints view |
| UML/BPMN courses | Нотации моделирования | Analysts and architects | Нотация не принимает решения | Process + system diagrams |
| Системный анализ | Requirements, API, BPMN, specs | Вход из анализа | Требования не равны target architecture | Requirements to architecture case |
| Учебные кейсы | Банк, ритейл, CRM/ERP, data platform | Новички и переходящие специалисты | Нужно честно показывать учебный характер | Safe architecture pack |
| Open-source разборы | Архитектурные разборы открытых систем | Все уровни | Open-source редко показывает enterprise constraints полностью | Architecture review notes |
| Обезличенные рабочие кейсы | Артефакты без NDA, персональных данных и секретов | Опытные специалисты | Нельзя раскрывать чувствительные детали | Sanitized portfolio artifacts |
System Architect нужен там, где landscape сложнее одного сервиса: legacy, cloud, данные, интеграции, безопасность, миграции и governance требуют отдельной архитектурной ответственности.
ИИ поможет готовить черновики схем, ADR, NFR, risk register и искать противоречия, но не заменит знание конкретного ландшафта, владельцев данных, регламентов и цены компромисса.
ИИ, вероятно, ускорит черновики диаграмм, ADR, сравнений вариантов, NFR-checklist, risk register и описаний интеграций. Он поможет находить противоречия в документации, готовить вопросы для discovery и поддерживать architecture repository. Но человек останется нужен там, где нужно понять конкретный ландшафт, владельцев данных, регламенты, политические ограничения, эксплуатацию и реальную цену компромисса.
Будет расти значение архитекторов, которые умеют соединять legacy, cloud, данные, безопасность, интеграции, AI-сервисы и переходные состояния. Особенно ценны специалисты, которые не просто рисуют схемы, а доводят архитектурные решения до внедрения, governance и обратной связи. Отдельный рост возможен у System Architect, которые понимают AI/LLM-интеграции, data governance, платформы данных, безопасность и cost management. Но корректнее говорить о смещении роли, а не о гарантированной замене или гарантированной незаменимости.
Роль подходит специалистам, которым интересно видеть систему целиком: приложения, данные, интеграции, владельцев, регламенты, эксплуатацию и последствия изменений. Нужны спокойствие к сложности, аккуратность в документации и способность договариваться без формальной власти над всеми участниками.
Системный архитектор - это специалист, который отвечает за устройство крупной ИТ-системы или ландшафта систем. Он смотрит, какие приложения участвуют в процессе, как они обмениваются данными, кто владеет данными, какие есть ограничения безопасности, эксплуатации и регламентов. Его задача - сделать так, чтобы изменения проходили управляемо: без случайных поломок, дублирования справочников, непонятных интеграций и конфликтов между командами. Это не просто человек, который рисует схемы, а тот, кто связывает архитектурное решение с реальной работой бизнеса и ИТ.
Системный архитектор описывает текущий ИТ-ландшафт, выясняет владельцев систем и данных, проектирует интеграции, собирает NFR, сравнивает архитектурные варианты, фиксирует ADR и планирует переход к целевой архитектуре. Он участвует в ревью, согласует решения с бизнесом, разработкой, безопасностью, инфраструктурой и эксплуатацией. Главная задача не в том, чтобы выбрать модную технологию, а в том, чтобы изменение можно было внедрить, поддерживать и развивать без системного хаоса.
Да, DevOps, cloud engineer или инфраструктурный специалист может перейти в System Architect, если добавит понимание бизнес-процессов, данных, API, интеграций и архитектурных trade-offs. Сильная база в CI/CD, Kubernetes, Linux, observability, DR и эксплуатации полезна, потому что System Architect должен учитывать operational readiness. Но нельзя сводить системную архитектуру только к платформе: нужны data ownership, source of truth, migration roadmap и governance.
Системному архитектору нужны system design, system landscape, integration architecture, data architecture basics, infrastructure basics, security basics, NFR, ADR, trade-off analysis, migration planning, architecture governance и сильная коммуникация. Среди частых требований SkillStat встречаются CI/CD, Microservices, PostgreSQL, Linux, Apache Kafka, Kubernetes, REST API, SQL, Git, ETL, 1С, gRPC и UML; актуальные доли лучше смотреть в live-блоке навыков.
Да, разработчик может перейти в System Architect, особенно если работал с backend, API, БД, микросервисами, CI/CD и сложными интеграциями. Ему нужно расширить фокус за пределы кода: системный ландшафт, data ownership, NFR, эксплуатация, безопасность, миграции, governance и коммуникация с разными командами. Хороший переходный шаг - Tech Lead, Software Architect или роль разработчика с архитектурной ответственностью за несколько сервисов.
Да, из системного анализа перейти в системную архитектуру можно, и это один из логичных путей. У системного аналитика уже есть база требований, процессов, API, спецификаций и коммуникации с бизнесом. Нужно усилить NFR, architecture trade-offs, system landscape, integration architecture, source of truth, migration planning и ADR. В портфолио стоит добавить не только требования, но и архитектурные решения: карты ландшафта, интеграции и rejected options.
Работать системным архитектором удаленно можно, но по текущему срезу SkillStat удаленных вакансий мало: 3% в Москве и МО на 23.06.2026. Доминирует гибрид - 77%, офис - 19%. Это связано с тем, что роль часто требует согласований с бизнесом, разработкой, безопасностью, эксплуатацией и руководителями. Удаленный формат вероятнее в продуктовых или распределенных командах, но в enterprise-контуре гибрид остается более типичным.
Стать системным архитектором с нуля можно только как долгий путь, а не как короткий скачок после одного курса. Новичку нужно сначала освоить системный анализ, API, SQL, данные, интеграции, C4/UML/BPMN, NFR, ADR и базовую инфраструктуру. Затем важно собирать учебные и обезличенные кейсы: landscape map, integration map, source of truth matrix, migration roadmap. Реальный рынок ориентирован на опытных специалистов, поэтому старт часто идет через смежную IT-роль.
Нельзя надежно утверждать, что ИИ полностью заменит или точно не заменит системных архитекторов. Часть работы по черновикам схем, документации и сравнению вариантов будет автоматизироваться. Но ответственность за компромисс, знание конкретного ландшафта, согласование владельцев данных, регламентов, безопасности, эксплуатации и реальной цены ошибки пока остается человеческой. Роль, вероятно, сместится в сторону более сильного governance и работы с AI/LLM-интеграциями.
ИИ может ускорить подготовку черновиков диаграмм, ADR, NFR checklist, risk register, описаний интеграций, вопросов для discovery и проверки противоречий в документации. Но он не знает реальный контекст организации без данных от людей: владельцев, регламентов, политических ограничений, эксплуатации, качества данных и цены ошибки. Поэтому ИИ скорее становится помощником в черновиках и анализе, а не самостоятельным владельцем архитектурного решения.
По срезу SkillStat на 23.06.2026 среди работодателей для системного архитектора заметны крупные технологические, банковские, инфраструктурные и интеграторские команды. Конкретный список лидеров лучше читать в live-блоке работодателей: это данные на дату среза, а не постоянный рейтинг. Рынок может быстро меняться, а часть вакансий скрыта под смежными названиями.
На собеседовании System Architect спрашивают про system landscape, C4, UML, BPMN, ArchiMate, ADR, NFR, REST, gRPC, SOAP, Kafka vs RabbitMQ, ETL, API Gateway, SQL, PostgreSQL, source of truth, master data, migration, consistency, Kubernetes/Docker концептуально, CI/CD, observability, security, HA, DR, transition architecture и governance. Часто дают кейсы: замена legacy, интеграция CRM/ERP/1С, дублирующие справочники или миграция данных.
Estimated-режим означает, что SkillStat показывает оценку по доступным зарплатным данным, а не точный диапазон по каждому грейду. Для System Architect используется расширенное окно профессии. Диапазон не показывается, потому что данных недостаточно для надежной публикации всех деталей. Такой подход честнее, чем создавать видимость точной статистики там, где рынок узкий и многие вакансии не раскрывают зарплату.
По данным SkillStat на 23.06.2026 для Москвы и МО, зарплатная оценка системного архитектора составляет 320 000 ₽. Это ориентир по профессии в estimated-режиме. Эту цифру нельзя читать как гарантированную медиану для каждого специалиста или как обещание зарплаты после курса. На доход влияют масштаб ландшафта, количество систем, интеграционная сложность, данные, legacy, NFR, безопасность, governance и уровень ответственности.
Системные архитекторы чаще нужны там, где есть сложный ИТ-ландшафт: банки, телеком, крупный ритейл, госсектор, интеграторы, большие платформы, инфраструктурные компании, корпоративные продукты, CRM/ERP/1С/SAP-контуры и организации с legacy. Чем больше систем, данных, интеграций, регламентов и команд, тем выше потребность в роли, которая удерживает архитектурную целостность и управляемость изменений.
В System Architect чаще переходят из системного анализа, backend-разработки, Java/Python/Go/Node.js-разработки, DevOps/cloud engineering, data engineering, integration engineering, инфраструктуры, нагрузочного тестирования, внедрения CRM/ERP/1С/SAP и Solution Architecture. У каждой траектории есть сильная база и пробелы. Аналитику нужно усилить NFR и архитектурные trade-offs, разработчику - ландшафт и governance, DevOps - данные и бизнес-процессы.
Системному архитектору полезны C4, UML, BPMN, ArchiMate, Draw.io, Miro, PlantUML, Structurizr, Confluence, Jira, ADR templates, OpenAPI/Swagger, SQL, PostgreSQL, Kafka, RabbitMQ, API Gateway, ESB, Kubernetes, Docker, CI/CD, Git, Linux, observability tools, architecture repository, technology radar, risk register и ownership matrix. Важно не просто знать инструменты, а понимать, какой архитектурный вопрос они помогают решить.
Для системного архитектора подходят прямые курсы по System Architecture, если они действительно есть, а также смежные треки: software architecture, system analysis, integration architecture, data architecture, cloud/infrastructure architecture, enterprise architecture и modeling/documentation. Важно не обещать, что любой курс по архитектуре ПО равен профессии System Architect. Курс стоит выбирать по наличию landscape, integration, data ownership, NFR, ADR, migration roadmap и governance.
ArchiMate уместен в enterprise architecture, когда нужно связать бизнес-возможности, процессы, приложения, данные, технологии, мотивацию и roadmap. Он помогает работать на уровне компании, портфеля систем и стратегических изменений. Для начинающего System Architect ArchiMate не всегда нужен в первые месяцы: сначала важнее освоить ландшафт, интеграции, данные, NFR и ADR. На Senior/Lead уровне ArchiMate может быть полезен для governance и enterprise context.
BPMN стоит использовать для описания бизнес-процессов, ролей, событий, решений и переходов между участниками. Для системного архитектора BPMN полезен, когда архитектурное решение зависит от процесса: кто инициирует действие, какие системы участвуют, где есть ручные шаги, где появляется риск блокировки. BPMN не заменяет C4, UML или integration map, потому что описывает процесс, а не внутреннюю техническую архитектуру системы.
UML стоит использовать, когда нужно детально показать структуру или поведение системы: sequence diagram для взаимодействий во времени, component diagram для зависимостей, deployment diagram для размещения. UML полезен разработке, аналитикам и архитекторам, но не всегда нужен бизнес-аудитории. Ошибка - пытаться описать весь enterprise-landscape одной UML-схемой. Нотацию нужно выбирать под вопрос, а не использовать ради формальности.
TOGAF может быть полезен системному архитектору на Middle/Senior/Lead уровне, особенно если он работает в крупной организации с enterprise architecture, governance, принципами и roadmap. Но TOGAF не заменяет опыт реальных систем, интеграций, данных, миграций и эксплуатации. Новичку лучше сначала освоить практические артефакты: landscape map, integration map, NFR, ADR, source of truth matrix и migration roadmap. TOGAF стоит добавлять после базы.
Системному архитектору не всегда нужно писать production-код каждый день, но он должен понимать разработку достаточно глубоко, чтобы оценивать границы сервисов, API, данные, CI/CD, эксплуатацию и технические trade-offs. Для перехода из разработки это сильное преимущество. При этом роль не сводится к программированию: не менее важны NFR, integration architecture, data ownership, миграции, документация, коммуникация и способность объяснять последствия решений разным участникам.
AWS, Azure или GCP-сертификаты полезны, если System Architect работает с cloud/hybrid-архитектурой, инфраструктурой, DR, security и cost management. Но cloud-сертификат сам по себе не делает человека полноценным системным архитектором. Нужно понимать ландшафт, данные, интеграции, NFR, миграции, governance и ограничения конкретной организации. Для DevOps/cloud специалистов сертификаты могут быть хорошим мостом, но не заменой архитектурного портфолио.
Junior-вход у системного архитектора низкий, потому что роль требует опыта живых систем и ответственности за последствия изменений. По срезу SkillStat на 23.06.2026 Junior занимает —, Middle —, Senior 96.8%, Lead 3%. Архитектор должен понимать интеграции, данные, эксплуатацию, безопасность, миграции, legacy и коммуникацию с несколькими командами. Поэтому чаще в System Architect переходят из системного анализа, разработки, интеграций, DevOps/cloud, data engineering или инфраструктуры.
Базовый roadmap можно уложить в 6-18 месяцев, если у человека уже есть IT-фундамент. За первые месяцы стоит закрыть API, SQL, требования, diagrams и текущий ландшафт. Затем добавить интеграции, data ownership, NFR, ADR, migration planning и governance. Если предыдущего IT-опыта нет, путь будет длиннее: сначала нужна практика в разработке, аналитике, интеграциях, DevOps, data engineering или корпоративных внедрениях.
Идти в системную архитектуру в 2026 году стоит тем, кто хочет работать шире одной команды и готов отвечать за последствия изменений в большом ИТ-ландшафте. Роль ценна в сложных организациях, но вход высокий: по срезу SkillStat junior-вход —, спрос 13/100, рынок ориентирован на Senior и Lead. Это хороший путь для опытных аналитиков, разработчиков, интеграторов, DevOps, data и infrastructure специалистов, но не быстрый способ получить работу после короткого курса.
Системный архитектор смотрит шире, чем архитектор ПО: его фокус - ландшафт систем, межсистемные интеграции, данные, владельцы, регламенты, эксплуатация и управляемость изменений. Архитектор ПО глубже отвечает за внутреннее устройство программного продукта: модули, сервисы, кодовые границы, API внутри продукта, техническое качество и инженерные решения команды. Роли пересекаются, но System Architect чаще работает с последствиями изменений за пределами одного приложения.
Системный аналитик обычно формализует требования, процессы, сценарии, спецификации и API для конкретного изменения. Системный архитектор отвечает за более широкий уровень: целевую системную архитектуру, trade-offs, NFR, интеграции, source of truth, миграции и последствия изменений для нескольких систем. Хороший системный аналитик может вырасти в System Architect, но ему нужно добавить ответственность за архитектурные решения, ownership данных и межсистемный landscape.
Data Architect глубже отвечает за модели данных, master data, DWH, lineage, качество данных, аналитический и операционный контуры. System Architect обязан понимать эти темы, но не всегда проектирует data platform во всех деталях. Его задача - встроить данные в системный ландшафт: определить source of truth, ownership, влияние данных на процессы, интеграции, миграции и NFR. Если данные критичны, System Architect и Data Architect должны работать вместе.
Enterprise Architect работает на более стратегическом уровне: capability map, портфель систем, enterprise roadmap, стандарты, принципы и governance компании. System Architect ближе к конкретным системам, интеграциям, данным, миграциям и эксплуатационным ограничениям. Если Enterprise Architect отвечает, куда должна двигаться архитектура организации, то System Architect отвечает, как конкретный ландшафт систем будет устроен и изменен без разрушительных последствий.
Infrastructure Architect отвечает за инфраструктурный слой: compute, storage, network, virtualization, cloud/on-prem, disaster recovery, capacity и эксплуатационные платформы. System Architect учитывает эти ограничения, но его фокус шире: системы, данные, интеграции, процессы, NFR и правила изменений. В хорошей архитектуре системный и инфраструктурный архитекторы согласуют deployment, availability, observability, DR и стоимость владения, а не принимают решения отдельно.
Integration Architect глубже специализируется на интеграциях: API, событиях, очередях, ESB, ETL, data flow, контрактах и совместимости систем. System Architect тоже работает с интеграциями, но его фокус шире: ландшафт, данные, владельцы, NFR, миграции, эксплуатация и governance. В сложных компаниях эти роли дополняют друг друга: Integration Architect проектирует интеграционный слой, а System Architect увязывает его с общей системной архитектурой.
System Architect отвечает за системный ландшафт, данные, интеграции и правила изменений внутри организации или крупной платформы. Solution Architect чаще проектирует реализуемое решение под конкретную бизнес-задачу, внедрение, клиентский контур, продуктовую комбинацию или presale/delivery. В реальности роли могут пересекаться: обе работают с NFR, интеграциями и компромиссами. Отличие в горизонте: System Architect держит устойчивость ландшафта, Solution Architect - реализуемость конкретного решения.
Tech Lead отвечает за инженерную реализацию команды: качество кода, технические решения, delivery, ревью и развитие разработчиков. System Architect чаще работает за пределами одной команды: он смотрит на несколько систем, данные, интеграции, владельцев, NFR, эксплуатацию и миграции. Tech Lead может выполнять часть архитектурных функций внутри продукта, но не всегда отвечает за весь ИТ-ландшафт и архитектурные правила организации.
System Architect означает "системный архитектор". В вакансиях это название может трактоваться по-разному, поэтому читать нужно не только заголовок, но и обязанности. Если роль отвечает за ландшафт систем, интеграции, данные, NFR, миграции, architecture governance и правила изменений, это близко к System Architect. Если фокус только на внутреннем устройстве одного приложения, роль ближе к Software Architect. Если фокус на внедрении решения для клиента или продукта, это может быть Solution Architect.
Начинающему системному архитектору стоит показать не список технологий, а архитектурные артефакты: карту ИТ-ландшафта, C4 context/container, integration map, source of truth matrix, ADR с rejected options, migration roadmap, data flow diagram, NFR checklist, risk register, transition architecture и architecture review checklist. Все реальные кейсы нужно обезличить: убрать названия компаний, систем, персональные данные, коммерческие тайны и чувствительную информацию.
Карта ИТ-ландшафта - это схема и описание систем, владельцев, данных, интеграций, процессов, регламентов, NFR, эксплуатации и планируемых изменений. Она нужна, чтобы видеть последствия архитектурных решений за пределами одной команды. Хорошая карта показывает не только системы, но и кто за них отвечает, где источник правды, какие связи критичны и какие правила изменений действуют. Без такой карты архитектура часто превращается в набор локальных решений.
ADR, или Architecture Decision Record, - это запись архитектурного решения. В хорошем ADR есть контекст, варианты, выбранное решение, последствия, trade-offs, rejected options и условия пересмотра. ADR нужен, чтобы через месяц или год было понятно, почему команда выбрала именно этот путь. Для системного архитектора ADR особенно важен: его решения часто затрагивают несколько систем, данные, интеграции и команды, поэтому память о причинах решения должна быть сохранена.
Architecture governance - это правила, практики и процессы, которые помогают организации принимать согласованные архитектурные решения. Сюда входят architecture review, architecture board, standards, guardrails, exception process, ADR repository, API governance, data governance, technology radar и documentation lifecycle. Хороший governance не тормозит команды, а снижает повторные споры и хаос. У стандартов обязательно должен быть механизм исключений и пересмотра.
C4 Model - это подход к визуализации архитектуры через уровни: context, container, component и code. Он помогает объяснять систему разным аудиториям: от общего окружения до внутренней структуры. Для System Architect особенно полезны context и container, потому что они показывают границы, внешние зависимости, сервисы, хранилища и интеграции. C4 не заменяет NFR, ADR, data ownership и migration roadmap, но помогает сделать архитектуру понятнее.
Master data - это ключевые данные, которые используются многими системами и процессами: клиенты, продукты, контрагенты, договоры, сотрудники, точки продаж, справочники. Для системного архитектора master data важны потому, что ошибки в них распространяются по всему ландшафту. Нужно понимать, кто владеет мастер-данными, где они создаются, как синхронизируются, кто отвечает за качество, как проходят миграции и какие системы могут хранить копии.
NFR, или нефункциональные требования, описывают не "что делает система", а "как хорошо она должна это делать". Это availability, reliability, performance, scalability, security, observability, maintainability, data consistency, RTO, RPO, compliance и operational readiness. Для System Architect NFR критичны, потому что они определяют архитектурные решения. Если оставить NFR на потом, можно выбрать подход, который не выдержит нагрузку, безопасность или эксплуатацию.
Source of truth - это признанный главный источник данных для конкретной сущности или набора атрибутов. Например, одна система может быть главным источником клиентского профиля, другая - договоров, третья - статусов заказов. Для System Architect важно определить source of truth до проектирования интеграций и миграций. Если источник правды не определен, появляются дубли, спорные справочники, расхождения в отчетах и долгосрочный системный долг.
Transition architecture - это описание промежуточного состояния между текущей и целевой архитектурой. В больших системах редко можно сразу перейти из legacy в идеальное состояние. Нужно показать coexistence старого и нового, временные интеграции, миграцию данных, ограничения, владельцев, fallback и срок жизни временных решений. Без transition architecture целевая схема может быть правильной, но невнедряемой или слишком рискованной для бизнеса.