Салют! Сегодня затронем наболевшую тему многих системных аналитиков «
Архитектура ПО для аналитика: зачем разбираться и как применять»Меня часто спрашивают: «
Зачем аналитику знать архитектуру ПО? Ведь это же задача архитекторов и разработчиков».
Отвечу просто:
без понимания архитектуры вы будете писать требования вслепую, а это рисковать проектом.
Вот мой развернутый ответ на этот вовпрос:
1️⃣
Зачем аналитику разбираться в архитектуре? -
Говорить на одном языке с разработчиками – чтобы вас понимали, а ваши требования не казались «магией».
-
Предвидеть ограничения – если знаешь, что система монолитная, не предложишь микросервисное решение без серьезной причины.
-
Оценивать сложность изменений – иногда «простая кнопка» требует перелопачивания половины backend-логики.
-
Архитектурно значимые требования – аналитик должен выявлять нефункциональные требования (масштабируемость, отказоустойчивость), иначе система развалится под нагрузкой.
2️⃣
Что нужно знать? (минимум для работы и понимания)
✅
Базовые стили архитектуры: -
Монолит vs
Микросервисы – плюсы, минусы, где что применяется.
-
Слоистая архитектура (Presentation-Business-Data) – чтобы понимать, в каком слое искать проблему.
-
Event-Driven – если система работает на событиях (например, Kafka), аналитик должен уметь описывать сценарии.
✅
Паттерны проектирования: -
MVC, CQRS, Saga – не надо глубоко, но понимать, зачем они нужны, важно.
-
Клиент-серверная vs Peer-to-Peer – влияет на требования к сети и безопасности.
✅
Интеграции: -
REST, GraphQL, gRPC – чтобы не путать синхронные и асинхронные API.
-
Message Brokers (Kafka, RabbitMQ) – если система обрабатывает потоки данных.
✅
Базы данных: - Реляционные (PostgreSQL) vs NoSQL (MongoDB) – от этого зависит, как писать требования к хранению данных.
3️⃣
С какими проблемами сталкивалась я? 🔹
Разработчики говорят: «Это невозможно» – а на деле просто сложно, потому что архитектура не позволяет. Если аналитик знает ограничения, он может предложить альтернативу.
🔹
Требования «висят в воздухе» – когда не понимаешь, куда в системе встроить функционал, получается «костыль».
🔹
Неучтенные нефункциональные требования – например, забыли про нагрузку, и система падает при 1000 пользователей.
4️⃣
Мои советы 🔸
Читайте документацию и схемы – если есть архитектурная диаграмма, изучите ее перед написанием требований.
🔸
Задавайте вопросы – «Как этот модуль общается с другим?», «Где будет храниться эти данные?».
🔸
Учитесь на реальных кейсах – разбирайте open-source проекты или спрашивайте у разработчиков, как устроены системы, с которыми работаете.
🔸
Пишите требования с учетом архитектуры – если знаете, что backend медленный, не обещайте пользователю мгновенный поиск.
____________________
Архитектура – это не страшно. Это просто еще один инструмент, который делает вас
сильным аналитиком, а не просто «писателем ТЗ».
📎 Пару статей вам в помощь для понимания:
-
Как системный аналитик влияет на проектирование архитектуры-
Как стать архитектором в ИТ-
Системный аналитик. Краткий гайд по профессии. Часть 3. Архитектура приложений и их масштабирование-
От требований к постановкам задач на разработку с помощью архитектурного проектаИсточник:
@ba_and_sa 
