Салют! Сегодня затронем наболевшую тему многих системных аналитиков «Архитектура ПО для аналитика: зачем разбираться и как применять»
Меня часто спрашивают: «Зачем аналитику знать архитектуру ПО? Ведь это же задача архитекторов и разработчиков».
Отвечу просто: без понимания архитектуры вы будете писать требования вслепую, а это рисковать проектом.
Вот мой развернутый ответ на этот вовпрос:
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
Меня часто спрашивают: «Зачем аналитику знать архитектуру ПО? Ведь это же задача архитекторов и разработчиков».
Отвечу просто: без понимания архитектуры вы будете писать требования вслепую, а это рисковать проектом.
Вот мой развернутый ответ на этот вовпрос:
- Говорить на одном языке с разработчиками – чтобы вас понимали, а ваши требования не казались «магией».
- Предвидеть ограничения – если знаешь, что система монолитная, не предложишь микросервисное решение без серьезной причины.
- Оценивать сложность изменений – иногда «простая кнопка» требует перелопачивания половины backend-логики.
- Архитектурно значимые требования – аналитик должен выявлять нефункциональные требования (масштабируемость, отказоустойчивость), иначе система развалится под нагрузкой.
- Монолит 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) – от этого зависит, как писать требования к хранению данных.
🔹 Разработчики говорят: «Это невозможно» – а на деле просто сложно, потому что архитектура не позволяет. Если аналитик знает ограничения, он может предложить альтернативу.
🔹 Требования «висят в воздухе» – когда не понимаешь, куда в системе встроить функционал, получается «костыль».
🔹 Неучтенные нефункциональные требования – например, забыли про нагрузку, и система падает при 1000 пользователей.
🔸 Читайте документацию и схемы – если есть архитектурная диаграмма, изучите ее перед написанием требований.
🔸 Задавайте вопросы – «Как этот модуль общается с другим?», «Где будет храниться эти данные?».
🔸 Учитесь на реальных кейсах – разбирайте open-source проекты или спрашивайте у разработчиков, как устроены системы, с которыми работаете.
🔸 Пишите требования с учетом архитектуры – если знаете, что backend медленный, не обещайте пользователю мгновенный поиск.
____________________
Архитектура – это не страшно. Это просто еще один инструмент, который делает вас сильным аналитиком, а не просто «писателем ТЗ».
- Как системный аналитик влияет на проектирование архитектуры
- Как стать архитектором в ИТ
- Системный аналитик. Краткий гайд по профессии. Часть 3. Архитектура приложений и их масштабирование
- От требований к постановкам задач на разработку с помощью архитектурного проекта
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍7🔥2
Салют! В продолжении темы по архитектуре ПО, хочу разместить пару опросов для проверки знаний.
Завтра выложу развернутые пояснения, с моей точки зрения, почему именно так я считаю верно. Если кто-то не согласен, или есть вопросы/пояснения, всегда жду в комментах))
P.s. Если зайдет такой формат, то периодически буду делать опросы с моими развернутыми ответами по раскрытой теме😉 для этого ставьте реакции👇
Завтра выложу развернутые пояснения, с моей точки зрения, почему именно так я считаю верно. Если кто-то не согласен, или есть вопросы/пояснения, всегда жду в комментах))
P.s. Если зайдет такой формат, то периодически буду делать опросы с моими развернутыми ответами по раскрытой теме
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥9👍5
Если система обрабатывает события (например, уведомления), какой подход скорее всего используется?
Anonymous Poll
6%
MVC
92%
Event-Driven
3%
CQRS
Какой стиль архитектуры подходит для стартапа с быстрыми изменениями?
Anonymous Poll
38%
Монолит
50%
Микросервисы
11%
Слоистая архитектура
Что может пойти не так, если не учесть архитектуру при написании требований?
Anonymous Poll
3%
Разработчики просто проигнорируют ТЗ
94%
Функционал будет реализован с «костылями» или окажется слишком дорогим
3%
Ничего страшного, архитектура – это проблема команды разработки
Салют! Обещала разобрать свои опросы, но вчера не успела 🙈 Будем делать сегодня)))
1️⃣ Какой стиль архитектуры подходит для стартапа с быстрыми изменениями?
✅ Микросервисы
2️⃣ Если система обрабатывает события (например, уведомления), какой подход скорее всего используется?
✅ Event-Driven
3️⃣ Что может пойти не так, если не учесть архитектуру при написании требований?
✅ Функционал будет реализован с «костылями» или окажется слишком дорогим
P.s. делитесь в комментах своими мыслями на этот счет))
Источник: @ba_and_sa
Почему?
- Монолит сложно масштабировать и изменять, а микросервисы позволяют гибко развивать отдельные части системы.
- Но у микросервисов есть и минусы (сложность управления), поэтому в реальности выбор зависит от контекста.
Почему?
- Event-Driven архитектура заточена под асинхронную обработку событий (например, через Kafka или RabbitMQ).
- MVC и CQRS тоже могут быть частью системы, но именно Event-Driven специализируется на событиях
Почему?
- Пример: если система монолитная, а вы запросили «гибкое независимое обновление модуля», разработчики либо откажут, либо сделают криво.
- Архитектура влияет на стоимость и сроки — её игнорирование = риски для проекта
P.s. делитесь в комментах своими мыслями на этот счет))
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2
Более подробный разбор вопросов:
1️⃣ Какой стиль архитектуры подходит для стартапа с быстрыми изменениями?
✅ Микросервисы
Что это значит?
Микросервисная архитектура — это подход, при котором большое приложение разбивается на множество небольших, независимых сервисов. Каждый сервис отвечает за свою узкую задачу (например, один — за пользователей, другой — за платежи, третий — за уведомления).
Почему это подходит для стартапа?
- Независимость команд: Разные команды могут разрабатывать, тестировать и развертывать свои сервисы независимо друг от друга. Это ускоряет выпуск новых фич.
- Гибкость технологий: Для каждого сервиса можно выбрать самый подходящий язык программирования или базу данных. Не нужно принимать единое решение на весь проект.
- Масштабируемость: Если один компонент (например, аутентификация) испытывает высокую нагрузку, можно масштабировать только его, а не все приложение целиком.
А что не так с монолитом?
Монолит — это единая, неделимая кодовая база. Чтобы изменить одну маленькую деталь, нужно пересобрать и заново развернуть всю систему. Это медленно, рискованно и тормозит развитие на стадии активного роста.
Важный нюанс: Микросервисы несут и сложности (управление взаимодействием, мониторинг, отладка), но для стартапа, где скорость изменений критична, их преимущества перевешивают.
2️⃣ Если система обрабатывает события, какой подход скорее всего используется?
✅ Event-Driven (Событийно-ориентированная архитектура)
Что это значит?
В этой архитектуре компоненты системы общаются друг с другом путем отправки и обработки событий. Событие — это сообщение о том, что что-то произошло (например,
Как это работает?
1. Один сервис (источник) создает событие и публикует его в «шину событий» (специальный брокер, like Kafka или RabbitMQ).
2. Другие сервисы (подписчики), которым интересно это событие, «слушают» шину и реагируют на него асинхронно. Например, сервис уведомлений получит событие
Почему это подходит для обработки событий?
- Гибкая связь: Сервисы не знают друг о друге. Они знают только о событиях. Это позволяет легко добавлять новую функциональность без переделки существующих сервисов.
- Асинхронность: Сервисы работают независимо. Если сервис уведомлений упал, события будут накапливаться в шине и обработаются, когда он вернется в строй.
Почему не MVC или CQRS?
- MVC — это архитектурный шаблон для организации кода внутри одного приложения (внутри монолита), а не для взаимодействия между распределенными сервисами.
- CQRS (Command Query Responsibility Segregation) часто используется вместе с Event-Driven, но это не одно и то же. CQRS разделяет операции чтения и записи данных, а Event-Driven — это про способ коммуникации.
3️⃣ Что может пойти не так, если не учесть архитектуру?
✅ Функционал будет реализован с «костылями» или окажется слишком дорогим
- «Костыли» — это неудачные, временные решения, которые нарушают архитектурную целостность системы. Они возникают, когда бизнес-требование пытаются «впихнуть» в систему, для которой оно не предназначено.
- «Слишком дорогой» — оценка в человеко-часах или деньгах оказывается в разы выше ожидаемой, потому что для простого с виду требования нужно перелопачивать половину системы.
- Роль аналитика — быть «адвокатом реализма». Вы должны понимать технический контекст, чтобы:
1. Задавать правильные вопросы: «Архитекторы, мы хотим сделать так. Насколько это сложно в рамках текущей системы?»
2. Предлагать жизнеспособные альтернативы: «Если изменение процесса заказа слишком дорогое, может, мы просто добавим новое поле на третьем шаге?»
3. Управлять ожиданиями бизнеса: Объяснить стейкхолдерам, почему «простая кнопка» не может быть сделана за два дня
Источник: @ba_and_sa
Что это значит?
Микросервисная архитектура — это подход, при котором большое приложение разбивается на множество небольших, независимых сервисов. Каждый сервис отвечает за свою узкую задачу (например, один — за пользователей, другой — за платежи, третий — за уведомления).
Почему это подходит для стартапа?
- Независимость команд: Разные команды могут разрабатывать, тестировать и развертывать свои сервисы независимо друг от друга. Это ускоряет выпуск новых фич.
- Гибкость технологий: Для каждого сервиса можно выбрать самый подходящий язык программирования или базу данных. Не нужно принимать единое решение на весь проект.
- Масштабируемость: Если один компонент (например, аутентификация) испытывает высокую нагрузку, можно масштабировать только его, а не все приложение целиком.
А что не так с монолитом?
Монолит — это единая, неделимая кодовая база. Чтобы изменить одну маленькую деталь, нужно пересобрать и заново развернуть всю систему. Это медленно, рискованно и тормозит развитие на стадии активного роста.
Важный нюанс: Микросервисы несут и сложности (управление взаимодействием, мониторинг, отладка), но для стартапа, где скорость изменений критична, их преимущества перевешивают.
Что это значит?
В этой архитектуре компоненты системы общаются друг с другом путем отправки и обработки событий. Событие — это сообщение о том, что что-то произошло (например,
UserRegistered, OrderPaid, `PaymentFailed`).Как это работает?
1. Один сервис (источник) создает событие и публикует его в «шину событий» (специальный брокер, like Kafka или RabbitMQ).
2. Другие сервисы (подписчики), которым интересно это событие, «слушают» шину и реагируют на него асинхронно. Например, сервис уведомлений получит событие
OrderPaid и отправит смс клиенту.Почему это подходит для обработки событий?
- Гибкая связь: Сервисы не знают друг о друге. Они знают только о событиях. Это позволяет легко добавлять новую функциональность без переделки существующих сервисов.
- Асинхронность: Сервисы работают независимо. Если сервис уведомлений упал, события будут накапливаться в шине и обработаются, когда он вернется в строй.
Почему не MVC или CQRS?
- MVC — это архитектурный шаблон для организации кода внутри одного приложения (внутри монолита), а не для взаимодействия между распределенными сервисами.
- CQRS (Command Query Responsibility Segregation) часто используется вместе с Event-Driven, но это не одно и то же. CQRS разделяет операции чтения и записи данных, а Event-Driven — это про способ коммуникации.
- «Костыли» — это неудачные, временные решения, которые нарушают архитектурную целостность системы. Они возникают, когда бизнес-требование пытаются «впихнуть» в систему, для которой оно не предназначено.
- «Слишком дорогой» — оценка в человеко-часах или деньгах оказывается в разы выше ожидаемой, потому что для простого с виду требования нужно перелопачивать половину системы.
- Роль аналитика — быть «адвокатом реализма». Вы должны понимать технический контекст, чтобы:
1. Задавать правильные вопросы: «Архитекторы, мы хотим сделать так. Насколько это сложно в рамках текущей системы?»
2. Предлагать жизнеспособные альтернативы: «Если изменение процесса заказа слишком дорогое, может, мы просто добавим новое поле на третьем шаге?»
3. Управлять ожиданиями бизнеса: Объяснить стейкхолдерам, почему «простая кнопка» не может быть сделана за два дня
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤3🙏1
Салют! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA, и затронем тему архитектуры ПО, тем более мы затрагивали целую неделю эту тему:
#вопросыссобеседования | @ba_and_sa
Часть 20:
📍Вопрос 1: Расскажите кратко, что такое архитектура ПО, и для чего ее нужно понимать аналитику?
✅Краткий ответ:
Архитектура ПО — это фундаментальная организация системы, воплощенная в виде ее компонентов, их взаимоотношений друг с другом и окружением, а также принципов, governing ее проектирование и эволюцию.
Для чего она аналитику?
1. Говорить с разработчиками на одном языке и формулировать требования, реализуемые в рамках существующих ограничений.
2. Оценивать сложность и риски изменений. Простая на вид фича может потребовать огромных усилий, если нарушает архитектурные принципы.
3. Выявлять архитектурно-значимые требования (масштабируемость, отказоустойчивость, безопасность), которые часто неочевидны для бизнеса, но vital для технического успеха проекта.
4. Проектировать интеграции между системами, понимая стили взаимодействия (REST, messaging, events) и их последствия.
Вместо итога: понимание архитектуры позволяет аналитику предлагать не просто корректные, но и реализуемые в рамках системы решения
📎Материалы по теме:
- Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина
- Роль системного аналитика при проектировании архитектурных решений
📍Вопрос 2: Как вы учитываете архитектуру системы при сборе требований и написании ТЗ?
✅ Краткий ответ:
Это помогает:
1. Предлагать реализуемые решения — предлагать функции, которые вписываются в текущую систему, а не требуют её перестройки.
2. Учитывать интеграции — правильно описывать взаимодействие компонентов, протоколы и форматы данных.
3. Выявлять скрытые сложности — например, понимать, что «простая» функция может потребовать изменений в нескольких микросервисах или создать нагрузку на базу данных.
В ТЗ выделяются архитектурно-значимые требования — производительность, безопасность, масштабируемость — чтобы разработка сразу закладывала их в реализацию
📍Вопрос 3: Какие технологии и паттерны вы бы использовали при проектировании системы для обработки большого объема транзакций в реальном времени с гарантией доставки и без потерь данных?
✅ Краткий ответ:
- Технологии: Kafka (для очередей), Apache Flink/Spark Streaming (для обработки), PostgreSQL (с репликацией) или Cassandra (для масштабируемости).
- Паттерны:
- CQRS (разделение на запись и чтение для масштабирования).
- Event Sourcing (хранение всех событий для восстановления состояния).
- Saga Pattern (для управления распределенными транзакциями).
- Гарантии доставки: подтверждение (ack) в Kafka, idempотентные операции, Dead Letter Queue (DLQ) для обработки ошибок.
📎Материалы по теме:
- Архитектурные паттерны
- Введение в Apache Kafka для системных аналитиков и проектировщиков интеграций
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 20:
📍Вопрос 1: Расскажите кратко, что такое архитектура ПО, и для чего ее нужно понимать аналитику?
✅Краткий ответ:
Архитектура ПО — это фундаментальная организация системы, воплощенная в виде ее компонентов, их взаимоотношений друг с другом и окружением, а также принципов, governing ее проектирование и эволюцию.
Для чего она аналитику?
1. Говорить с разработчиками на одном языке и формулировать требования, реализуемые в рамках существующих ограничений.
2. Оценивать сложность и риски изменений. Простая на вид фича может потребовать огромных усилий, если нарушает архитектурные принципы.
3. Выявлять архитектурно-значимые требования (масштабируемость, отказоустойчивость, безопасность), которые часто неочевидны для бизнеса, но vital для технического успеха проекта.
4. Проектировать интеграции между системами, понимая стили взаимодействия (REST, messaging, events) и их последствия.
Вместо итога: понимание архитектуры позволяет аналитику предлагать не просто корректные, но и реализуемые в рамках системы решения
📎Материалы по теме:
- Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина
- Роль системного аналитика при проектировании архитектурных решений
📍Вопрос 2: Как вы учитываете архитектуру системы при сборе требований и написании ТЗ?
✅ Краткий ответ:
Я рассматриваю архитектуру, как набор возможностей и ограничений. При работе с требованиями, я сначала изучаю текущую архитектуру через документацию и обсуждения с разработчиками.
Это помогает:
1. Предлагать реализуемые решения — предлагать функции, которые вписываются в текущую систему, а не требуют её перестройки.
2. Учитывать интеграции — правильно описывать взаимодействие компонентов, протоколы и форматы данных.
3. Выявлять скрытые сложности — например, понимать, что «простая» функция может потребовать изменений в нескольких микросервисах или создать нагрузку на базу данных.
В ТЗ выделяются архитектурно-значимые требования — производительность, безопасность, масштабируемость — чтобы разработка сразу закладывала их в реализацию
📍Вопрос 3: Какие технологии и паттерны вы бы использовали при проектировании системы для обработки большого объема транзакций в реальном времени с гарантией доставки и без потерь данных?
✅ Краткий ответ:
- Технологии: Kafka (для очередей), Apache Flink/Spark Streaming (для обработки), PostgreSQL (с репликацией) или Cassandra (для масштабируемости).
- Паттерны:
- CQRS (разделение на запись и чтение для масштабирования).
- Event Sourcing (хранение всех событий для восстановления состояния).
- Saga Pattern (для управления распределенными транзакциями).
- Гарантии доставки: подтверждение (ack) в Kafka, idempотентные операции, Dead Letter Queue (DLQ) для обработки ошибок.
По технологиям и архитектурным паттернам будет большой пост, но позже
📎Материалы по теме:
- Архитектурные паттерны
- Введение в Apache Kafka для системных аналитиков и проектировщиков интеграций
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
🔥14👍2❤1
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Автоматизация аналитических процессов с помощью GitHub Actions: практический гайд
Привет, Хабр! Хочу поделиться своей историей того, как я пришла к GitHub Actions в попытках автоматизировать сбор аналитики для личного использования. Статья будет полезна аналитикам, которые хотят...
❤2
Проектирование GraphQL API
Цикл статей про аспекты работы с технологией GraphQL и разбор проектирования GraphQL API.
- Введение в GraphQL
- Схема GraphQL
- Архитектура и GraphQL
BA|SA
Цикл статей про аспекты работы с технологией GraphQL и разбор проектирования GraphQL API.
- Введение в GraphQL
- Схема GraphQL
- Архитектура и GraphQL
BA|SA
systems.education
■ Статья. Введение в GraphQL
❤6👍3👌3
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Концепции информационной безопасности
Данная статья про преданные забвению, уверенно существующие и шагающие в будущее концепции информационной безопасности. Так как человек придумал буквы и много слов, то и в мире информационной...
🔥4❤2👍2