😡 «Я системный аналитик, а не архитектор»: где реально заканчивается ваша ответственность?

Эту фразу часто слышно, когда в проекте или на собеседовании нужно:

▫️ определить микросервисы
▫️ выбрать синхронное или асинхронное взаимодействие
▫️ решить, нужен ли брокер сообщений
▫️ почитать нагрузку на сервера, чем вообще DevOps-ы занимаются 😱

Если в команде есть Архитектор, финальная ответственность за архитектурное решение обычно лежит на нём.

Но принять такое решение без участия аналитика сложно: именно СА глубоко понимает бизнес-процессы, данные, исключения и зависимости между системами.

Поэтому задача аналитика — не единолично утверждать архитектуру, а участвовать в её проектировании, предлагать варианты и проверять, как выбранное решение будет работать в реальных сценариях



Границы ролей 👇

1️⃣ Зона СА

Системный аналитик отвечает за то, как система должна вести себя в конкретных сценариях:

▫️ какие компоненты участвуют в процессе
▫️ какие данные и в какой момент передаются
▫️ кто владеет данными и изменяет их
▫️ какие методы API, события и статусы нужны
▫️ что произойдёт при ошибке, повторном запросе или недоступности системы
▫️ какие проверки и бизнес-правила должны выполняться

Например, недостаточно написать:
После создания заказа отправить событие в брокер

Нужно определить:
+ какое именно событие публикуется
+ какие данные оно содержит
+ кто его получает
+ можно ли обработать его повторно
+ что произойдёт, если получатель временно недоступен
+ когда процесс считается завершённым

👉 Это проектирование поведения системы с учетом особенностей архитектуры — прямая зона ответственности системного аналитика



2️⃣ Зона СА + Архитектора

Часть решений нельзя корректно принять без понимания полной картины требований:

▫️ выделение сервисов и их границ
▫️ выбор между синхронным и асинхронным взаимодействием
▫️ использование API Gateway и брокеров сообщений
▫️ распределение ответственности за данные
▫️ выбор хореографии или оркестрации
▫️ обеспечение безопасности и отказоустойчивости

Здесь СА приносит бизнес-сценарии, ограничения, данные и варианты решения, которые влияют на итоговую архитектуру.

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

👉 СА не просто ждёт готовое решение Архитектора. Он участвует в его подготовке и должен уметь предложить и обосновать свой вариант



3️⃣ Зона Архитектора

Архитектор отвечает за согласованность решения на уровне всей системы или нескольких систем:

▫️ целевую схему архитектуры
▫️ организацию кода
▫️ технологии
▫️ взаимодействие между компонентами
▫️ масштабирование и отказоустойчивость
▫️ безопасность
▫️ инфраструктурные требования
▫️ стоимость и сложность сопровождения
▫️ согласованность архитектурных решений между командами.

При этом архитектор не обязан самостоятельно описывать каждый метод API, формат события и альтернативный сценарий.

Для этого ему как раз нужен сильный системный аналитик



❗️ Где проходит реальная граница?

По масштабу решения и ответственности за последствия:

🔹 Middle СA проектирует детальное поведение системы и взаимодействия в рамках задачи или подсистемы

🔹 Senior СА предлагает архитектурные варианты, оценивает ограничения и защищает решения перед командой

🔹 Архитектор отвечает за согласованность решения на уровне всей системы и целевого архитектурного ландшафта

👉 На практике эти зоны пересекаются. Особенно в продуктовых командах, где отдельного архитектора может вообще не быть.

Поэтому чем выше уровень СА, тем чаще от него ждут не только требований, но и ответа на архитектурные вопросы.



На практической программе «Проектирование архитектуры» мы развиваем именно эту зону: идём от требований к проектированию сервисов, данных, интеграций и сквозных процессов.


💎 Проектирование архитектуры
🗓 Старт — 15 сентября

Завтра завершается предзапись на спец условиях:
🎁 сниженная цена + «Интеграции 4.0 — продвинутый уровень» в подарок

👉 Посмотреть программу и записаться


✅ Бесплатный вводный практикум