Analyst IT
11.6K subscribers
145 photos
86 videos
7 files
1.06K links
Авторский канал для аналитиков в индустрии ИТ. Все, что надо знать аналитику в одном месте.

Сотрудничество: @the_real_bird
BA/SA: @ba_and_sa

Регистрация РКН: https://knd.gov.ru/license?id=673c6a15b7aeb106ce045ee5&registryType=bloggersPermission
加入频道
Салют, коллеги-аналитики! 👋 сегодня суббота и хотела немного отойти от рабочих будней, тем более на дворе солнце, жара, лето☀️🌞))

Пока мы проектируем системы и рисуем схемы, моя семья проектирует… полёты!

Со мной многие знакомы, Я - Оксана, системный аналитик, который живет на Кавказе, и мои родственники уже много лет занимаемся полётами на воздушном шаре. А сейчас, когда лето в разгаре, и многие приезжают отдыхать в Кавказские Минеральные Воды, хочу рассказать, почему это стоит попробовать!

Почему это круто?

Невероятные виды – Кавказ с высоты птичьего полёта завораживает: горы, долины, рассветы и закаты.

Ощущение свободы – никакого шума двигателей, только ветер и абсолютный покой.

Романтика и адреналин – даже если вы не экстремал, плавный подъём на шаре запомнится на всю жизнь.

Мои родные ведут канал, где делятся красотами полётов и атмосферой Кавказа – Полет на воздушном шаре КМВ. Если хотите вдохновиться или даже запланировать такой опыт в своём путешествии – заглядывайте и пишите админам для приобретения незабываемых впечатлений!!! А их я вам - гарантирую!!!

P.s. это не реклама, а мой личный рекомендасьон!! Вы точно зарядитесь крутыми эмоциями на долго!!!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥42👍1
Салют! Сегодня затронем наболевшую тему многих системных аналитиков «Архитектура ПО для аналитика: зачем разбираться и как применять»

Меня часто спрашивают: «Зачем аналитику знать архитектуру ПО? Ведь это же задача архитекторов и разработчиков».
Отвечу просто: без понимания архитектуры вы будете писать требования вслепую, а это рисковать проектом.

Вот мой развернутый ответ на этот вовпрос:

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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥82
Салют! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль 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

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
6🔥3👍1
⁉️ Провели Event Storming и теперь нужно систематизировать все идеи и данные? Время перейти к модели архитектуры. Но как перевести хаос в структурированные решения?

На открытом вебинаре «Моделирование архитектуры в ArchiMate на основе Event Storming» 4 сентября в 19:00 МСК мы расскажем, как из артефактов Event Storming строить многослойные модели архитектуры с использованием ArchiMate.

Урок полезен архитекторам решений, бизнес-аналитикам, системным аналитикам и всем, кто работает с Event Storming и нуждается в ясной и структурированной документации. Вы получите практическую схему превращения неструктурированных данных в понятные диаграммы.

➡️ Зарегистрируйтесь на вебинар и получите скидку на полный курс «Archimate»: https://clck.ru/3NykBt

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
🔎 Хотите освоить профессию, которая открывает двери в сотни компаний и сфер? Аналитик данных — специалист, без которого сегодня не обходится ни один успешный бизнес.

🚀 Курс OTUS «Аналитик данных» создан для тех, кто готов прокачать навыки анализа данных и научиться работать с инструментами, востребованными в индустрии: SQL, Python, BI-платформы, визуализация и дашборды, общение со стейкхолдерами и новый модуль по машинному обучению — всё это в одной программе.

💡 Что вы получите:

- уверенное начало карьеры в аналитике или сокращение рутины на текущем месте работы;
- автоматизация отчётности, поиск закономерностей в данных и презентация выводов просто и понятно;
- диплом OTUS, ценится на рынке и соответствует требованиям ведущих компаний.

🎯 Запишитесь на курс прямо сейчас, пройдите короткое тестирование и получите скидку по промокоду DA08 — 5% до 15 сентября: https://clck.ru/3P3GRy

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
😁1🙈1